by Dinesh Thakur

IEEE defines software design documentation as 'a description of software created to facilitate analysis, planning, implementation, and decision-making. This design description is -used as a medium for communicating software design information and can be considered as a blueprint or model of the system.

While developing SDD, the design should be described up to the refinement level that is sufficient for explaining every task including inter-task communications, data structures, and databases. No refinement of any task should be left to be made during the coding phase.

The information that the software design document should describe depends on various factors including the type of software being developed and the approach used in its development. A number of standards have been suggested to develop a software design document. However, the most widely used standard is by IEEE, which acts as a general framework. This general framework can be customized and adapted to meet the needs of a particular organization. This template consists of several sections, which are listed below.

  1. Scope: Identifies the release or version of the system being designed. The system is divided into modules; the relationship between them and functionalities will be defined. Every iteration of the SDD document describes and identifies the software modules to be added or changed in a release.
  2. References: Lists references (both hardware and software documents and manuals) used in the creation of the SDD that may be of use to the designer, programmer, user, or management personnel. This document is also considered useful for the readers of the document. In this section, any references made to the other documents including references to related project documents, especially the SRS are also listed. The existing software documentation (if any) is also listed.
  3. Definition: Provides a glossary of technical terms used in the document along with their definitions.
  4. Purpose: States the purpose of this document and its intended audience. This is meant primarily for individuals who will be implementing the system.
  5. Design description information content: Consists of the following subsections.


  1. Introduction: Since SDD represents the software design that is to be implemented, it should describe the design entities into which the system has been partitioned along with their significant properties and relationships.
  2. Design entity: It is a software design component that is different from other design entities in terms of structure and function. The objective of creating design entities is to partition the system into a set of components that can be implemented and modified independently. Note that each design entity is assigned with a unique name and serves a specific purpose and function but all possess some common characteristics.
  3. Design entity attributes: They are properties of the design entity and provide some factual information regarding the entity. Every attribute has an attached description, which includes references and design considerations. The attributes and their associated information are listed in Table.

                                            Table Attributes and Description




Identifies name of the entity. All the entities have a unique name.


Describes the kind of entity. This specifies the nature of the entity.


Specifies why the entity exists.


Specifies what the entity does.


Identifies sub-ordinate entity of an entity.


Describes relationships that exist between one entity and other entities.


Describes how entities interact among themselves.


Describes elements used by the entity that are external to the design.


Specifies rules used to achieve the specified functions.


Identifies data elements that form part of the internal entity.

6. Design description organization: Consists of the following subsection.

7. Design views: They describe the software design in a comprehensive manner so that the process of information access and integration is simplified. The design of software can be viewed in multiple ways and each design view describes a distinct aspect of the system. Table lists various design views and their attributes.

                               Table Design Views and their Description

Design View



Decomposition description

Partitions the system into design entities.

Identification, type, purpose, function, and subordinate

Dependency description

Describes relationships between entities.

Identification, type, purpose,

dependencies, and resources

Interface description

Consists of list that is required by the stakeholders (designers, developers, and testers) in order to design entities.

Identification, function and


Detail description

Describes internal details of the design entity.

Identification, processing, and data