Design Descriptions |
 |
 |
 |
| Written by Graham Stoney | |||
|
The purpose of a design description is to show how a design meets its requirements. It consists of a textual description, liberally augmented with pictures, architecture diagrams, schematics, structure charts and whatever else is necessary to fully describe the design. Some of the components of a design description may be incorporated by reference, such as an object model maintained in a modelling tool database; but they're still logically part of the design documentation. Like all documents, a design description evolves over the life of the project. For example, the design description for a circuit board won't include the PCB layout until after the schematics have been finalised. Design descriptions are written in the present tense, and describe how the entity in question works (i.e. meets its requirements); even though the entity doesn't physically exist yet when the document is first drafted. For example:“A diode on the power input protects the circuitry from having the batteries inserted backwards.” Architecture documents are simply design descriptions that occur in the system at a high level. They are the result of system architectural design, and these system level design descriptions are often called the “System Architecture” document. Its purpose is to show how the system meets the system requirements by describing how the system is decomposed into subcomponents, and the role of each subcomponent in meeting the system requirements. Every design description, not just the system level ones, should begin with a chapter describing the architecture of the element being described, usually with a picture showing its internal structure. This architectural information should be reviewed before significant detailed design work is done. Interface descriptions and protocols between components should be reviewed while design of those components is ramping up, but before too much component design work has been done. Draft design descriptions for electrical designs should be reviewed before significant schematic capture or VHDL coding begins. Draft software data flow diagrams, structure charts and class diagrams should be reviewed before significant software coding begins. Data structures should be reviewed before significant algorithmic development is done. In all cases, the motivation is to avoid unnecessary rework when design changes are required due to anomalies found during review. A balance is necessary here, because the “waterfall model” is not a time-efficient way to develop a system. A better approach is concurrent engineering, which involves an element of risk since all the information required for any task will not be at a complete level of maturity when the task is started. The risk needs to be managed however, and design reviews are one way of doing that. The mere act of writing a draft design description often causes issues that the designer hadn't considered to come to light, and the attempt to explain it to others is often enlightening for the designer. Having said that, if a designer is truly stuck with options, whiteboarding the design in front of a group of engineers can be productive, as can disseminating a discussion paper. However, care should be taken to ensure that the designer is not simply reluctant to commit to a particular design choice. There are many ways to skin a cat, and many design solutions could be equally good ways to meet the input requirements. Many choices in engineering are arbitrary or come down to the designers' personal preference. I would rather see a design document that says “it works like this” that is then reviewed, critiqued, modified as necessary and then used as the basis for the way forward than have major design choices avoided. Social Bookmark this page:         
|