SDS Outline

The Software Design Specification (SDS) sections given in this outline are guidelines to the contents of your SDS. Include at least these sections. Your team may have good reasons for wanting to deviate from this proposed outline. In this case, you must motivate any deviations to me. If a section is not applicable in your case, do not delete it; instead, give the topic heading and write "Not applicable".

You will note that there is some overlap in the contents from document to document. This redundancy allows each document to stand on its own.

SDS recommended content

1.  Introduction

    1.1  Purpose of this Document
           Full description of the main objectives of the SDS document.

    1.2  Scope of the Development Project
           This will be similar to what was written in the SRS.

    1.3  Definitions, Acronyms, and Abbreviations
           Be sure to alphabetize.

    1.4  References
           This section will include technical books and documents
           related to design issues.  At a minimum, this section
           should reference the SRS.  Give links to documents as
           appropriate.  Be certain that the references you give
           are complete and in the appropriate format.

    1.5  Overview of Document
           A short description of how the rest of the SDS is organized 
           and what can be found in the rest of the document.  This is 
           *not* simply a table of contents.  Motivate and briefly 
           describe the various parts!

2.  System Architecture Description

NOTE: This section is the main focus of the high-level conceptual design. The reader should come away with a good view of exactly how your solution is to be organized.

    2.1  High-level Design Overview
           Introduce the various components and systems at a high conceptual 
           level.  
    2.2  User Interface Issues
           This subsection will present the main principles of the product's
           user interface.  If you used personas in section 2.1 of the SRS,
           use them again here to make specific examples.  This section should
           not touch on the technical details.  You may want to include sketches 
           and/or specific text messages of the user interface. 
    2.3  Overview of Modules / Components
           This subsection will introduce the various components
           and subsystems that are elaborated on in sections 3.2 to 3.n.  
           Use the same labels for each module/component in this section 
           as in 3.2 to 3.n.
    2.4  Structure and relationships
           This subsection will make clear the interrelationships and 
           dependencies between modules/components.  Structure charts can 
           be useful here. Another good idea is to use a simple finite 
           state machine that demonstrates the operation of the product 
           you are designing.  There should always be explanatory text to 
           help the reader understand any charts.

3.  Detailed Description of Components

NOTE: This section is the main focus of the technical design portion of the SDS, the detailed design. This section will provide most of the basis for implementing the product.

    3.1  Component template description
           This section is not part of your design.  It is a
           pattern you will use to describe the components given
           in subsections 3.2 - 3.n.  Each part of the template
           will be identified by a label.  Here in 3.1, you must
           briefly explain the purpose of each point.  To make the
           presentation clear, use a table or bullet list.  You may 
           adapt the template suggested below to your particular
           needs (although deviations from the suggested template
           should be minimal and well motivated).
    3.2  X Component (or Class or Function ...)
           Use *exactly* the template you define in 3.2.  If a
           part of the template is not applicable, then mark it
           N/A rather than omitting it.
    3.3  Y Component (or Class or Function ...)
    ...
    3.n  Z Component (or Class or Function ...)

4. Design Rationale

    This section outlines the critical issues and tradeoffs 
    that were considered in generating the design.  Its purpose
    is to document the thought behind the design, and why certain
    aspects of the design were chosen.  This section can also capture
    good ideas that were abandoned and the reasons for leaving them
    out of the design 

5. Pseudocode for components

    This section provides pseudocode for all the components listed
    in section 3.2.  Use the same numbering system as in section 3.2.

6. Appendices (is any)

SDS component template

The template given below suggests a reasonable structure for giving a thorough description of each component described in Part 3 of the SDS. The specific information depends in part on the design approach. Your team must adapt this template to your needs and describe it in section 3.1 of your SDS.

Identification	The unique name for the component and the location of the component in the system.
Type	A module, a subprogram, a data file, a control procedure, a class, etc
Purpose	Function and performance requirements implemented by the design component, including derived requirements. Derived requirements are not explicitly stated in the SRS, but are implied or adjunct to formally stated SDS requirements.
Function	What the component does, the transformation process, the specific inputs that are processed, the algorithms that are used, the outputs that are produced, where the data items are stored, and which data items are modified.
Subordinates	The internal structure of the component, the constituents of the component, and the functional requirements satisfied by each part.
Dependencies	How the component's function and performance relate to other components. How this component is used by other components. The other components that use this component. Interaction details such as timing, interaction conditions (such as order of execution and data sharing), and responsibility for creation, duplication, use, storage, and elimination of components.
Interfaces	Detailed descriptions of all external and internal interfaces as well as of any mechanisms for communicating through messages, parameters, or common data areas. All error messages and error codes should be identified. All screen formats, interactive messages, and other user interface components (originally defined in the SRS) should be given here.
Resources	A complete description of all resources (hardware or software) external to the component but required to carry out its functions. Some examples are CPU execution time, memory (primary, secondary, or archival), buffers, I/O channels, plotters, printers, math libraries, hardware registers, interrupt structures, and system services.
Processing	The full description of the functions presented in the Function subsection. Pseudocode can be used to document algorithms, equations, and logic.
Data	For the data internal to the component, describes the representation method, initial values, use, semantics, and format. This information will probably be recorded in the data dictionary.

Primary reference used in preparing this outline:

Vicki Almstrum's CS373 SDS Outline, UT Austin, Spring 2003

http://www.cs.utexas.edu/users/almstrum/cs373/current/doc-stds/SDS-outline.html