CMSC 345

Section 0301

Software Design and Development

Fall 2004

 

System Design Document Template

 

 

 

 

General Instructions

 

  1. Provide a cover page that includes the document name, product name, customer name, team name, team member names, and the current date.
  2. Number the pages of the document.
  3. Number and label all figures.  Refer to the figures by number in the text.
  4. All sections should have an introductory sentence or two.
  5. Do not use vague words and phrases such as may, might, could, possibly, should, assumed to be, some, a little, and a lot. Use strong, definite words and phrases such as shall, will, will not, can, and cannot.
  6. Watch your spelling, punctuation, and grammar.  It is a reflection on your professionalism.

 

Be sure that your document is

  • Complete - No information is missing
  • Clear - Every sentence's meaning must be clear to all parties
  • Consistent – The writing style and notation is consistent throughout the document and the document does not contradict itself.
  • Verifiable - All facts stated are verifiable

 

 

Remember that you are required to do a peer review of this document.

 

When you think you are done with the SDD, ask yourself, "Could someone who was not part of the development of this SDD write the corresponding code?"

 

Product Name

System Design Document

 

 

Table of Contents

 

                                                                                                                                                 Page

  1. Introduction

 

1.1    Purpose of This Document

1.2    References

 

  1. System Architecture

 

  1. Component Design

 

3.1    Static Aspects

3.2    Dynamic Aspects

 

  1. Persistent Data Design

4.1    Database Descriptions

4.2    File Descriptions

 

  1. Runtime Environment

 

  1. Requirements Matrix

 

 

Appendix A – Peer Review Sign-off

 

Appendix B – Agreement Between Customer and Contractor

1.      Introduction

 

1.1  Purpose of This Document

 

State the purpose of this document and specify the intended readership.

 

1.2  References

 

Provide a list of all applicable and referenced documents and other media.  Minimally, references to the SRS and UI Design Document go here.  If you used any other documents or references to arrive at this design (e.g., the Somerville text, UML references, documents provided by the customer, websites), list them here.  For each reference, provide the title, author, publisher (if applicable), date, and URL (for websites).

 

2.      System Architecture

 

A brief description of all major subsystems and data repositories and their interconnections.

 

Put the architectural block diagram or layer diagram here.

 

 

3.      Component Design

 

3.1 Static Aspects

Put class diagrams here.  (Include attributes and public operations only.  Omit setters, getters, and destructors.)  Supplement with text as needed.

 

Provide descriptions of the purpose of each function and/or method, its preconditions, and its postconditions.

Purpose, preconditions, and postconditions for all methods in all classes in the class diagrams of Section 2.2.  PDL for all non-trivial methods.

 

3.2  Dynamic Aspects

 

Put activity and sequence  diagrams here.  Supplement with text as needed.

 

4.       Persistent Data Design

 

4.1    Database Descriptions

 

Describe the database(s) that are part of the system.  Include diagrams of the schema with complete table and column descriptions.

 

4.2    File Descriptions

 

Describe the file(s) that are a part of the system.  Include a detailed format description.

 

 

5.      Runtime Environment

 

List the software and hardware that will be required to run the product.  For software, this will include such things as the operating system, any database software (e.g., Oracle), web servers (e.g., Apache), and browsers.  Be thorough.  Be sure to give the exact name and version number(s) that are required.  Although the compiler used (for compilable languages) is not required to run the product, list it also.

 

For hardware, list the runtime system’s processor, clock speed, RAM, and the minimum disk space needed for program execution (executable file, data space, and possibly code as with PHP).  If you are using the UMBC gl system, you do not need to list the processor, clock speed, or RAM.

 

For web-based applications, you need to list the requirements for the client computer (i.e., web browser(s), processor, clock speed, RAM, and anything else).

 

 

6.      Requirements Matrix

 

Use a tabular format to show which system components (i.e., functions and/or methods) satisfy each of the functional requirements from the SRS.  Refer to the functional requirements by use case number and name.

 

Appendix A – Peer Review Sign-off

 

Provide a separate page with a short paragraph stating that all members of the team have reviewed the document and agree on its content and format.  Provide lines for printed names, signatures, and dates.  Also provide space for team member comments.  This space is to be used to state any minor points regarding the document that a member may not agree with.  Note that there may not be any major points of contention.

 

 

Appendix B – Agreement Between Customer and Contractor

 

Provide a separate page that describes what the customer and your team are agreeing to when all sign off on this document.  Provide lines for printed names, signatures, and dates.