5. Design Specification
Now that the users and the analyst have agreed the overall project, it is time to provide details that the development team can use to actually start work.
The design specification document is likely to contain details of the following:
Purpose of the system | What problem the system is designed to solve |
Screen layouts and style templates | Background colour or images Font style and weights Label text and other information on screen Titles, sub titles Character widths of input boxes Design features such as margins, borders and shading These features will usually incorporate the businesses' house style |
Data structures | The design and layout of the new tables |
Inputs | The inputs for the new system, e.g. forms, buttons, list boxes, combo boxes |
Outputs | The outputs from the system e.g. printed outputs, onscreen outputs |
Processing | The processing that will take place and the hardware necessary to support that processing |
Validation rules | The validation which needs to be set up to ensure data integrity |
Error messages | Error messages which will appear if the validation rules are broken or an error occurs in the system |
Modelling diagrams | Data flow diagrams, entity relationship diagrams and state transition diagrams |
Software | The software and programming languages to be used to develop the system |
Hardware | The hardware that will be required to develop the system |
Test plan | The test plan which will be used during the testing phase to check the system works properly |
One popular way of explaining to the developer what is required is to produce a mock-up of the screen. This mock-up is produced with the help of an image editing application such as Photoshop or Paintshop Pro.
The design document should be comprehensive enough for the developer to start work. It does not need to explain *how* it is to be done but *what* needs to be done.
challenge see if you can find out one extra fact on this topic that we haven't already told you
Click on this link: Design Specification