System Design Document Template

CS 325, Software Engineering Concepts, Spring 2000

This template for this system design document (SDD) is adopted from the architecture and detailed design documents used by the European Space Agency (Software Engineering Guides, C. Mazza et. al., Prentice Hall) which, in turn, was adopted from the 1994 edition of the IEEE Software Engineering Standards Collection, IEEE Press. Details below marked with an asterisk (*) are less important than details not marked with an asterisk; your work should emphasize the unmarked details in preference to the marked details.

You need not use this template for your specification system design document, but, whatever format you use, you should make sure your report covers all the categories listed here.

1. Introduction - Provide an overview of the SDD and a description of the scope of the software.

   1. Purpose - define the purpose of this SDD and specify intended readership.

   2. Scope - identify the software products to be produced by name; explain what the proposed software will do (and not do, if necessary); describe the relevant benefits, objectives and goals as precisely as possible; and be consisten with related higher-level specifications.

   3. Definitions, Acronyms, and Abbreviations - provide definitions of all terms, acronyms and abbreviations needed for the SDD.

   4. References - provide a complete list of all the applicable and referenced documents.

   5. Overview - describe what the rest of the SDD contains and explain how the SDD is organized.

2. System Overview - Breifly introduce the system context and design, and discuss the background to the project.

3. System Design

   1. Design method - Describe the design method used.

   2. Decomposition description - Summarise the software components, including the hierarchy and control and data flows.

4. Component Description - A top-down description of the design components.

   1. Component identifier - An identifier unique throughout the SDD.

      1. Type - the logical (e.g., class or library) and physical (e.g., subroutine, file) characteristics.

      2. Purpose - A reference back to the requirements spec.

      3. Function - What does the component do?

      4. Subordinates - The components used by this component.

      5. Dependencies - Constraints placed on this component by other components.

      6. Interfaces - Control and data flow into and out of the component.

      7. Data - Descriptions of internal data.

5. * Resource Estimates - A summary of computer resource estimates required to operate the software.

Here are some things to keep in mind when creating the system design:

• The system design describes the structure of the solution to the problem given in the requirements specification. The solution is described in terms of the algorithms used to solve the problem, not in terms of how those algorithms are implemented. As usual, however, if the customer has implementation-specific requirements, they should be reflected in the system design.

• It's useful to have a checklist or two to help review and validate the system design document.

• Taligent as a set of design guidlines and programming conventions to help with object-oriented design and programming.

• Some comments about the SDD drafts.

This page last modified on 16 February 2000.