India (+91)22 66809000
USA (+1) 949.630.9568

See Ontra detailsSeeOntra Details


SDD : Software Design Document. Contains the design description and the list of design entities required for a project.
FSD : Functional Specification Document. Lists the detailed specifications of the project.

Purpose and Scope
This Design Methodology is used to guide the design team into producing a viable and accurate Software Design Document (SDD) while, at the same time, describing the process to be used by the design team and defining the required contents of the SDD. The main purpose of the SDD is to ensure that the final product the customer receives fulfils the entire customer requirements defined in the FSD.

The development team leader, who will be required to make sure the project is completed according to the FSD, SDD and software development plan, will need to have a method of keeping track and documenting project development information.
This document will also define the contents of a Development Workbook. The Development Workbook will define the information that the team leader will be required to keep track of and the order that information is presented.

Software Design Document
The main purpose of the SDD is to ensure that the final product the customer receives fulfils the entire customer requirements defined in the FSD. The SDD also sets a guideline of required information that will help ensure that the project is a success. Depending on the size and scope of the project, not all sections of the SDD will be required. However, if the section is not applicable to the given project, then the section heading must be included with a NOT APPLICABLE requirement. Some of the areas that an SDD will consist of are itemized below;

  • 1 Definition of the project
  • 2 High Level System Design
  • 3 Relationship to other Projects
  • 4 Project Responsibility
  • 5 Project Phases
  • 6 Project Environment
  • 7 Design Entities
  • 8 Development Phases
  • 9 Analysis of Potential Problems
  • 10 Detailed Design
  • 11 Requirements Traceability Matrix
  • 12 Team Structure and Responsibility
  • 13 Development Project Plan

Decomposition of an FSD
The objective of the FSD decomposition is to review the FSD and based on the information provided, divide the system into separate components that can be considered, developed, changed and tested with a minimal effect or dependency on the other components. These components are called entities. The entities may be an entire system, a sub system, a module, a program, a set of programs, user interfaces or data-stores depending on the complexity and the programming environment. The design team will determine which of the requirements to group as an entity.

SDD Design Process
The first step in creating an SDD is to take the FSD and break out the objectives, requirements and entities that the customer needs and then look for informal requirements, preconceived solutions and any specific hardware or software requirements. After this is completed, the design team needs to consider if there are any design issues that need be addressed specifically by the design team. If not the design of the first level entities will be assigned to the individual programmers. In many cases the actual design of the entity will be assigned to the programmers. The SDD would address specific program design issues is only when it effects the system architecture or is required to address a specific customer requirement or performance issue.

Informal Requirements
Determine what requirements are implied but not formally listed. The FSD may refer to a particular module, service or entity, but there may be supporting entities required that are not listed.
If any informal requirements are detected, they will be added to the SDD as entities and noted that this is an informal entity.

Determine Preconceived Solutions
Determine if any requirements are actually solutions and not requirements. Review the SDD to make sure the design has not been preconceived and verify with the project manager if this was intentional and part of the actual FSD or not. The design may be the correct one to use, but you want to be sure of what is actually a requirement and what is not.

Design Review Process
Design reviews are performed during the design stage, but may take place during the development, verification and validation of the software if the team leader or management determines that one is needed.

Design Review
The design review will consist of an informal review of the design by the design team (or appointed representative) and may include other members of the software development group.
The members of the design review need to identify the following:

  • What kind of review is it. Is this a design document review, a code walkthrough review, a post project design review?
  • 1 Who is present at the review
  • 2 Decisions made at the design review meeting
  • 3 Follow up required from the design review meeting
  • 4 Status of pass or fail on the design review meeting

The development team leader or appointed scribe will record the activities to be done and the decision made in the meeting. These records are retained as part of the project in the product development binder, but are not quality records.

Critical Design Review
A critical design review (CDR) will take place some time after the design review. The CDR will be conducted by the Design Review Team, which will consist of the development team leader (or appointed representative), a representative from Sales and Marketing, a representative from Professional Services and any specialist that may be required. The CDR will discuss:

  • 1 Decisions made at the CDR meeting
  • 2 Follow up required from the CDR meeting
  • 3 Status of pass or fail on the design review meeting

The conclusions and directives of the CDR will be recorded and retained as quality records.

ANMSoft Technologies 2010-2014
Go to top