Design Document Template

• Concise
• Clear
• Complete
• Informative and
• It should serve as a basis for evaluating whether your design is good. That is, a technical person (peer, non team member) should be able to evaluate whether the design is correct and that it is the "best" among the many possible correct designs.

• It provides justification for each implementation decision. For example, if you choose to use a linked list instead of an array, you need to justify your choice.
• The document describes the role of this module within the overall system. This is usually by means of a high-level architecture diagram.
• The document describes the behavior of this module. Again diagrams come in useful. Depending on the module, a class diagram, sequence diagram, state-transition diagram, or a combination may have to be used.
• For each method and attribute in the module, the document will justify its existence, provide its signature, and describe its behavior.
• If you are breaking up the module into sub-modules, you will need to provide the above three pieces of information in the context of the main module, for each sub-module.

• Project name
• Module name, author, date
• Design document version. You will turn in version 1.0.
• Project Sponsors (CS425/625)
• Project Team (Name, role)
• Overview: Why does the system need this module? Short description of how this module fits in the system.
• Introduction
  • Definitions: Define terms before you use them.
  • Architectural diagram: Describes where your module fits in the system. The accompanying description helps explain this modules relationship to other modules. Control and data flow may also be depicted and explained.
  • Architectural description
• Behavioral view: This could be a state transition diagram, sequence diagram, class diagram, or combination that describes the module and any sub-modules. You need to show how a module behaves within its context, how it relates to other modules, sub-modules, and data and control flow through your module and sub-modules.
• Functional Specification: For each module/submodule, for each method within such a module/submodule:
  • Method signature
  • Method behavior description
  For example, if you are using a linked list in galaxy sleuth to track players, you would depict the linked list as a sub-module, and list all public and private methods in the linked list.
• Which specific requirements does this module help to meet.