Software Design Document (SDD) Template

Software design is a process by which the software requirements are

translated into a representation of software components, interfaces,
and data necessary for the implementation phase. The SDD shows how
the software system will be structured to satisfy the requirements. It is
the primary reference for code development and, therefore, it must
contain all the information required by a programmer to write code.
The SDD is performed in two stages. The first is a preliminary design in
which the overall system architecture and data architecture is defined.
In the second stage, i.e. the detailed design stage, more detailed data
structures are defined and algorithms are developed for the defined
architecture.
This template is an annotated outline for a software design document
adapted from the IEEE Recommended Practice for Software Design
Descriptions. The IEEE Recommended Practice for Software Design
Descriptions have been reduced in order to simplify this assignment
while still retaining the main components and providing a general idea
of a project definition report. For your own information, please refer to
IEEE-Std-1016-1998 for the full IEEE Recommended Practice for
Software Design Descriptions.

Software Design Document

for

<Project>
Version <n>

Prepared by <author>

<organization>

<date created>

Table of Contents

1. Introduction
1.1 Purpose of this document
This software design document describes the architecture and system design of
XX.
Provide a description and scope of the software and explain the goals, objectives
and benefits of your project. This will provide the basis for the brief description of
your product.
Description of the organization of the document
1.2 Definitions and Acronyms
Provide definitions of all terms, acronyms, and abbreviations that might exist to
properly interpret the SDD. These definitions should be items used in the SDD
that are most likely not known to the audience.
2. System Architecture
The architectural design is the design of the entire software system; it gives a
high-level overview of the software system, such that the reader can more easily
follow the more detailed descriptions in the later sections. It provides information
on the decomposition of the system into modules (classes), dependencies between
modules, hierarchy and partitioning of the software modules.
Develop a block diagram and explain the relationships between the modules to
achieve the complete functionality of the system. Identify each high level
subsystem and the roles or responsibilities assigned to it. Describe how these
subsystems collaborate with each other in order to achieve the desired
functionality. Dont go into too much detail about the individual subsystems. The
main purpose is to gain a general understanding of how and why the system was
decomposed, and how the individual parts work together. Provide a diagram
showing the major subsystems and data repositories and their interconnections.
Describe the diagram if required.
3. Database Design
The database design specifies how the date of the software is going to be stored.
Tables schemas
The complete (compilable) set of CREATE TABLE statements (and other SQL
statements) that declare the database schema, including integrity constraints, domain
specifications, assertions, and access privileges -- documented in a template with the
intended use of each table and column.

This is a suggested template you may use1:

Name of the table
Description

This table describes

Attribute
Id

Description
Id of a student

Type
Integer

Name
Primary Key
Foreign Keys
SQL Code

Name of a student

String

Examples of values
Between 1 and
999999999
John

Tables data:
The tables have to be populated by you and your client. Each table must contain an
appropriate number of data. The contents of the tables has to be provided (in an organized
way.)
SQL queries:
Provide all SQL queries that you will need.
Transactions implementation:
Explain how you will implement the ACID (atomicity, consistency, isolation and
durability) properties of transactions (programs that access databases.)
4. Graphical User Interface
Provide, in an organized way, the pictures of all the forms in the graphical user
interface with a reference to the functional requirement it implements. You may
use html to present the graphical user interfaces.
For each form in the graphical user interface, provide:
o The names of the controls and fields on that form,
o The names of the events, methods, or procedures that cause that form to be
displayed, and
o The names of the events, methods, or procedures triggered by each
control.
5. Class Diagram and Classes
Provide a class diagram and an inheritance tree/diagram.

You may define your own template. This is only a suggestion.

Each method has to be defined:

1. Method Name
2. Parameters, each documented with its intended use
3. Return Value, suitably documented
4. Informal description of what the procedure does
5. Data structure and tables it accesses
6. Pre-conditions: Assumptions the method can make about the state of the global
data structures and database when it starts
7. Validity Checks, Errors, and other Anomalous Situations: Validity checks the
method must make about the state of the global data structures, the database, and
its parameters, including the actions that must be taken when such a check fails.
8. Post-conditions: The changes the method is supposed to make to the global data
structures and database.
9. Called by: The methods or events that call it
10. Calls: The methods it calls and any events it causes.
6. Design process
Describe the methodology used in the design phase.
Describe the design review process that you used.
7. References
List of books, papers, URLs, tools that you consulted and used to design this document
8. Appendix
Hard copy or pointers to the documents that permitted you to assemble this document in
collaboration with your client
Definitions of the important terms and acronyms used in the document.