Design Document Guidelines

The design document shows how you will satisfy the requirements you listed in the requirements document. The design document describes the system architecture and specifies its components down to classes, attributes, methods, functions, signatures, input/output specifications and header files.

Later, when you implement your design you should be able to select a class from your design document and implement it without the need to go back to the requirements document, and without the need to contact the other members of your team. In this way, all the members of your team will be able to work concurrently on the implementation. During that phase you will appreciate the work you put into the design document.

The design document also serves as documentation. In particular, anyone who wants to modify your system later on will appreciate a discussion of design rationales and design alternatives.

Make sure you include a high-level description of the system architecture, low-level descriptions of classes and modules, and a description of protocols and algorithms. You might want to re-read the chapters in the textbook that deal with design and modeling methods.

The design components should be traceable to the requirements in the requirements document. Traceability can be made explicit by providing a table that lists, for each design component, the requirement that it satisfies. The design should be complete, that is, it should satisfy all the requirements.

Lastly, as any document, the design document should be readable, understandable, easy to use, modifiable, and consistent.