The Software Design Description (SDD) shows how the software system will be structured to satisfy the requirements identified in the Software Requirements Specification. It is a translation of requirements into a description of the software structure, software components, interfaces, and data necessary for the implementation phase. In essence, the SDD becomes a detailed blueprint for the implementation activity. In a complete SDD, each requirement must be traceable to one or more design entities. In documenting the design of a software artifact, several different views of the design need to be considered, so as to meet the requirements of the different users of the design. Possible design views to be considered for incorporation in a Design Document include: Decomposition - the partition of the system into design entities; Dependency - the description of the relationships among entities and system entities; Interface - all the details of interfaces and relationships between the different design entities that make up the system; Detail - the internal design details of a design entity. The Design Description will be heavily dependent on the design approach chosen for the project, and the specific views included in the document may vary from project to project. IEEE Std 1016.1, Guide to Software Design Descriptions, provides examples of what should be included in a Design Document for a number of different design approaches. The following design approaches are covered in the Guide: Function-oriented - e.g. Structured Analysis and Design Data-oriented - e.g. Jackson Structured Programming Real-time control-oriented - e.g. the Ward and Mellor approach Object-oriented - e.g. the Coad and Yourdon approach Formal language-oriented - e.g. Z Language Specifications The following sample Table of Contents for a Software Design Description is based on ANSI/IEEE Std 1016-1987, Recommended Practice for Software Design Descriptions. 1.  Introduction 1.1  Purpose 1.2  Scope 1.3  Definitions and Acronyms 2.  References 3.  Decomposition Description 3.1  Module Decomposition 3.1.1  Module 1 Description 3.1.2  Module 2 Description 3.2  Concurrent Process Description 3.2.1  Process 1 Description 3.2.2  Process 2 Description 3.3  Data Decomposition 3.3.1  Data Entity 1 Description 3.3.2  Data Entity 2 Description 4.  Dependency Description 4.1  Intermodule Dependencies 4.2  Interprocess Dependencies 4.3  Data Dependencies 5.  Interface Decomposition 5.1  Module Interface 5.1.1  Module 1 Description 5.1.2  Module 2 Description 5.2  Process Interface 5.2.1  Process 1 Description 5.2.1  Process 1 Description 6.  Detailed Design 6.1  Module Detailed Design 6.1.1  Module 1 Detail 6.1.2  Module 2 Detail 6.2  Data Detailed Design 6.2.1  Data Entity 1 Detail 6.2.2  Data Entity 2 Detail For example, using the Structured Design Approach, the Decomposition Description would be defined by Structure Charts; the Dependency Description would be defined by a set of Data Flow Diagrams; the Interface Description would be defined in a Data Dictionary and Context Diagram; and the Detail Description would be defined in the Process Specifications. There is much supporting information on Design Techniques available on the Web; information can be found on Object Orientation and Formal Methods, among others. Checklists for reviewing Design Descriptions may also be found on the Web. Original Author: Terry Rout Redesigned: 12 October, 1996 by Tracey Osborne Last Updated: 29 January, 1998 by Jo Orr Send comments, errors and suggestions to Terry Rout, T.Rout@cit.gu.edu.au