Design Document

Suggested Outline


Sources: Prof. Lewis, SUNY Stony Brook

Title

Title, Author, Date, Version Number

Related Documents

For example, the Specification Document, an Object Library, a Standards Document.

Objectives

An overview of the system, so that the reader can understand the rest of the document. What is the system supposed to do. What are its key features. What are its performance requirements.

High-Level Design

An informal description of the design so the reader can more easily follow the more detailed descriptions in the later sections. Among the items that might be included are
  1. Decomposition of the systems into modules or objects
  2. Class Diagrams and Object Diagrams
  3. Procedure calling tree
Also included in this section can be the rationale for any design decisions that need to be documented. For example, why a particular data structure was selected.

Global Data Structures and Database Design

  1. The complete (compilable) declaration of all global data structures. Each item must be documented with its intended use and any constraints on its values.
  2. If necessary the complete (compilable) set of CREATE TABLE statements (and other SQL statements) that declare the database schema, including integrity constraints, domain specifications, assertions, and access privileges -- documented with the intended use of each table and column

Graphical User Interface

  1. A reference for the section in the Specification Document that contains pictures of all the forms in the User Interface.
  2. For each form in the User Interface
    1. The names of the events, methods, or procedures that cause that form to be displayed
    2. The names of the controls and fields on that form
    3. The names of the events, methods, or procedures triggered by each control

Detailed Description of Each Procedure

  1. Procedure Name
  2. Arguments, each documented with its intended use
  3. Return Value, suitably documented
  4. Informal description of what the procedure does
  5. Global Data Structures and Database Tables it accesses
  6. Preconditions: Assumptions the procedures can make about the state of the global data structures and database when it starts
  7. Validity Checks, Errors, and other Anomalous Situations: Validity checks the procedure must make about the state of the global data structures, the database, and its arguments, including the actions that must be taken when such a check fails.
  8. Postconditions: The changes the procedure is supposed to make to the global data structures and database.
  9. Called by: The procedures or events that call it
  10. Calls: The procedures it calls and any events it causes.

Detailed Description of Each Object

  1. Data Declarations: as described above for Global Data Structures
  2. Methods: as described above for Procedures
  3. Parent/Child Relationships