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
-
Decomposition of the systems into modules or objects
-
Class Diagrams and Object Diagrams
-
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
-
The complete (compilable) declaration of all global data structures. Each
item must be documented with its intended use and any constraints on its
values.
-
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
-
A reference for the section in the Specification Document that contains
pictures of all the forms in the User Interface.
-
For each form in the User Interface
-
The names of the events, methods, or procedures that cause that form to
be displayed
-
The names of the controls and fields on that form
-
The names of the events, methods, or procedures triggered by each control
Detailed Description of Each Procedure
-
Procedure Name
-
Arguments, each documented with its intended use
-
Return Value, suitably documented
-
Informal description of what the procedure does
-
Global Data Structures and Database Tables it accesses
-
Preconditions: Assumptions the procedures can make about the state of the
global data structures and database when it starts
-
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.
-
Postconditions: The changes the procedure is supposed to make to the global
data structures and database.
-
Called by: The procedures or events that call it
-
Calls: The procedures it calls and any events it causes.
Detailed Description of Each Object
-
Data Declarations: as described above for Global Data Structures
-
Methods: as described above for Procedures
-
Parent/Child Relationships