What is a Software Design Document?

Overview

A design document needs to be a stable reference and outline all parts of the software and how they will work. The document should give a fairly complete description while maintaining a high-level view of the software. The Software Design Document (SDD) is a comprehensive software design model consisting of four distinct but interrelated activities:

1. data design
2. architectural design
3. interface design
4. procedural design.

There are two kinds of design documents:

• HLDD - High Level Design Document and
• LLDD - Low Level Design Document

A comprehensive example that combunes the two can be found at http://db.daffodilsw.com/PDF/design-document.pdf.

Question: Who uses these documents? Answer: Just about everyone on the development team to some degree!
Figure 1. Development team roles

The IAT351 HLDD

For the purposes of this course, you will be learning how to use a HLDD (High Level Design Document) both as an internal planning tool and as a communication/documentation tool. Don't worry! I don't expect you to write a full book on your design and implementation. However, i do expect you to describe your implementation and design using the following categories:

1. data design. What kinds of input and output are you manipulating? What are the sources (it may be input from the user, as in text or mouse clicks) but it may also be database input, sensor input, etc. How are you modeling this data? For example, if you have a restricted set of values of certain data (days of the week are always 7 and always have the same names) , how are you modeling this as opposed to a continuous value (temperature) or a set of open-ended values (as in the tags for a journal entry that the user can specify herself)?
2. architecture design. How have you structured your modules? Typically we use UML diagramming for this, but you do not have to learn this. However a diagram like the ones in Figures 2 and 3 provides a good overview.

Figure 2. The top level diagram lays out the modules.
	Figure 3. Details are specified in the class diagram with short descriptions. Circles represent the conceptual actors or elements in the system.

3. interface design. In the general context, interface means the connection points between communicating elements in the system (such as a database, or even *gasp* the user.) For your purposes, provide a sketch of the user interface components and how they fit together.
4. procedural flow. Those of you who took IAT201 will remember specifying the system rules in the requirements. This is simply the description of what happens when. A familiar way of describing this is the oft-maligned flowchart (see the example in Figure 4). A simple layout of the expected behaviour in step form (Figure 5) should accompany whatever diagram you use.

Figure 4. A standard flowchart

Figure 5. Behaviour descriptions - what actually happens in what conditions.

Rationale

It should be clear by now that this document is not just something you whip up at the end of a project for archival or communication purposes. It is actually a fundamental design tool as you are working out how to build your system and how to explore alternatives. The most useful ones are those that reflect the thorough "thinking out" process that every system architect undergoes.