Design Standards

You want to know if we are the people to handle your requirements, you will also want to know how much it will cost and how long it will take to deliver them. Realistically it is very difficult to provide an accurate estimate of the costs without having a lot of detail about the requirements. Working out the duration and cost is a matter of refinement, the more that is known about the requirement the less will be guesswork.

During the life of a development a number of steps need to be taken, before any code is written, and before any hardware or other purchases are made, it is vital to know WHAT must be delivered.

A part of the process therefore is writing down in detail what it is that has to happen. When everyone is satisfied, and only then, will it be feasible to work out the timescales and costs.

Often a project is already well under way and commitments have been made before it is truly understood what the product to be delivered is. We think this approach is too risky for the client and have taken another look at how a development could be executed.

Our view is that the documentation and estimation process should fall outside of the scope of a project. There are usually up to four documents that need to exist at some point in the project a domain model (DM) which describes what happens now.

A general user requirement which describes what the client wants to happen in the future.

A detailed user requirement that provides an unambiguous description of what will be produced, we would expect the client to sign off this document it represents exactly what they want.

A system specification which describes in a technical format what is going to be built.

Each of these documents refines the requirements until it is known to a high degree of accuracy what has to be done. All these steps are taken, but usually within the scope of the project. Therefore the actual costs and timescales are not firmed up until the project is already in motion.

Up to this point the costs are guesswork and probably only in the form of 'ball park' estimates. We suggest, if appropriate that a domain model document is written, depending on the complexity of the issues involved this can take between one and five days. At this point the customer has a document that describes what is happening now and can be used to instigate remedial changes to current work processes.

The general user requirement should be the work of the customer although we can provide examples of others and can also help with this document. This will be of value in getting all the ideas on paper and could be used as part of the process for seeking tenders for the work.

The detailed user requirement is definitely something we would write. The time required depends on the size and complexity of the requirement and the assistance provided by the client. This is a period where a lot of detailed questions are asked and answers sought. This document can definitely be used to seek tenders for the work, and will give a pretty good idea of the development cost.

The System Specification is again a document that we would write. This document will provide sufficient detail that a developer would be able to take it away and begin designing and building the solutions. Once again it is eminently suitable as a tender document and will refine once more the cost and duration of the development. It is at this stage that we feel that the project can really begin.

A project should detail the steps that are to be taken to achieve the development, management and ownership, milestones and timescales, quality issues, standards issues and criteria for measuring success.