Detailed Design Document Format
COMP 413W Semester Project
Penn State Harrisburg Fall 2006
Note: This document is the same as the architectural design document except that Section 2.2 has been expanded and the deployment diagram has been omitted. You will need to revisit and possibly update the other sections, but the real work is in Section 2.2.
Title Page
Contains the name of project, date, document version number, and approval block.
Abstract
A one-to-three paragraph summary of the problem solved by this project.
Project Team
List project team members and their roles.
Table of Contents
Provide major headings and page numbers. The page footer should contain the page number ("Page x of y,")
1.0 Introduction
This section provides an overview of the entire design document. This document describes all data, architectural, interface and component-level design for the software.
1.1. Goals and Objectives
Describe overall goals and business objectives to be realized by the software.
1.2. Scope of Solution
Describe the boundaries of the solution here. State what functionality is included and what is excluded. This statement is given in terms of business functions. A rationale for which parts are excluded should also be included.
1.3. Constraints
List any unusual factors that may impede the expedient implementation of full functionality of the product. There is no need to include the obvious constraints of staying within budget or on time unless one or both of these constrains is unusual in its severity. (For example, Y2K was an immovable deadline!)
2.0 Architectural and Component-Level Design
Describe the overall system architecture and component partitioning in general terms. Include a rationale for the partitioning choices.
2.1. Architecture diagram
Include a pictorial (UML) representation of the system and its constituent components.
2.2. Description of Components
Supply a detailed description of the constituent classes of each component. List the important attributes of each class, and describe the purpose and processing of each major method within each class. Suitable UML diagrams should be provided to illustrate the relationships between each class within the component and any interactions between classes within separate comonents.
2.2.1 Component #1
Class#1 (Use the clas name)
Attributes: (Data elements/variables)
Method #1 (Use the method name):
Precondition: List any assumptions that must be true in order for Component 1 to operate correctly. A good example is that Component 1 may assume that certain files are open or that a certain Internet connection has been established.
Postcondition: Describe the changes to the state of the system that have occurred as a result of the execution of this module. Note: This is the "what" requirement of the module.
Algorithm: List the steps (pseudocode, perhaps) taken by this component to achieve its intended purpose.
Error handling/Exception processing: Describe any error processing that is not made clear in the description of the algorithm.
Method #2:
Precondition:
Postcondition:
Algorithm:
Error handling/Exception processing:
Class#2
Attributes:
Method #1:
Method #2:
2.2.2. Component #2
2.2.n. Component #n
2.3 Requirements Traceability Matrix
Provide a cross reference between each (numbered) functional requirement and the component to which it maps.
2.4. External system interfaces
Describe all interfaces to other systems, products, or networks if any. Include details as to the names, data types, and order of all parameters passed to other systems or components.
3.0 Data Architecture
Description all persistent data structures here including temporary data structures.
3.1. Entity-Relation Diagram
Data structures that are passed among components the software are described.
3.2. Temporary data structure(s)
Describe files or other storage elements created for interim use.
4.0 Quality Assurance
This section presents the detailed test case specifications for the modules described in Section 2.2. Also include any other means by which the quality of the product will be evaluated. An introductory paragraph, placed here, outlines the basic approach to the testing. The paragraphs below provide the details.
4.1 Detailed Test Plans
4.1.1. Test Plan for Component #1
4.1.2. Test Plan for Component #2
4.1.n. Test Plan for Component #n
Appendices
Include any other supporting material that you feel will be of assistance to the coders. Detailed layouts for external interfaces may be placed here instead of in the body of the document.
Appendix A Screen Layouts
See template that follows.
Appendix B Report Layouts
See template that follows.
Graphical Screen Layout
Project Name: / Date:Author: / Phase:
Component Name: / Version:
Screen Title:
Report Layout
Project Name: / Date:Author: / Phase:
Component Name: / Version:
Report Title:
Date: 99/99/99 Page 999
Page 1 of 3