Software Design Specification

<Project Title>

Project Code:

Internal Advisor:

External Advisor:

Project Manager:

Project Team:

Submission Date:

_____________________
Project Manager’s SignatureDocument
<Project code> Software Design Specification
<Version x>

Document Information

Category Information
University UOS
Project <Project Title>
Document Software Design Specification
Document Version 1.0
Identifier
Status Draft
Author(s) <Names of all the authors of this document>
Approver(s) PM
Issue Date Sept. 15, 2003
Document Location
1. Advisor
Distribution 2. PM
3. Project Office

Definition of Terms, Acronyms and Abbreviations

This section should provide the definitions of all terms, acronyms, and abbreviations required to interpret the terms
used in the document properly.

Term Description
ASP Active Server Pages
DD Design Specification

Oct. 15, 2003 Page 2 of 7

<Project code> Software Design Specification
<Version x>

Oct. 15, 2003 Page 3 of 7

<Project code> Software Design Specification
<Version x>

Table of Contents

1. Introduction..............................................................................................................................4
1.1 Purpose of Document.....................................................................................................................4
1.2 Project Overview.............................................................................................................................4
1.3 Scope................................................................................................................................................4

2. Design Considerations.............................................................................................................4
2.1 Assumptions and Dependencies..................................................................................................4
2.2 Risks and Volatile Areas................................................................................................................4

3. System Architecture................................................................................................................4
3.1 System Level Architecture.............................................................................................................4
3.2 Sub-System / Component / Module Level Architecture............................................................5
3.3 Sub-Component / Sub-Module Level Architecture (1…n)........................................................5

4. Design Strategies......................................................................................................................5
4.1 Strategy 1…n....................................................................................................................................5

5. Detailed System Design...........................................................................................................5

6. References.................................................................................................................................6

7. Appendices................................................................................................................................6

Oct. 15, 2003 Page 4 of 7

<Project code> Software Design Specification
<Version x>

Section 1

1. Introduction
1.1 Purpose of Document
Describe the purpose of this document and provide a description of the intended audience i.e., the personnel
who will be reading this document. Also state the type of design methodology (structural/Object Oriented
design methodology) that you will use for the project.

1.2 Project Overview

Provide a general description of the software system briefly stating its functionality and the basic design
approach that you will undertake to develop the software.

1.3 Scope
List down the scope of the project. Describe what the system will and will not do.

2. Design Considerations
This section describes many of the issues which need to be addressed or resolved before attempting to devise a
complete design solution. In other words, this section is used to formally set the groundwork for the system
design.

2.1 Assumptions and Dependencies

Assumptions and dependencies for the system and project are already captured in the FS document. This
section should not repeat those issues. Instead it should deal with previously stated issues in the context of
design, if appropriate, or bring up new issues that are only relevant to design.

2.2 Risks and Volatile Areas

Discuss the most likely sources of change and risks (new requirements, technology, etc.) that would impact the
design of the system. If appropriate, describe how the system will be designed to allow timely response to
changes or what the contingency path is for changes.

3. System Architecture
This section should provide a high-level overview of how the functionality and responsibilities of the system are
partitioned and then assigned to subsystems or components. The main purpose is to gain a general
understanding of how the system is decomposed, and how the individual parts work together to provide the
desired functionality.

3.1 System Level Architecture

The architecture should decompose the system at a top level in a way that provides a foundation for more
detailed design work. The architecture discusses relationships and roles of system elements (subsystems,
components, modules, etc.), but does not provide internal details. Areas for consideration are:
 System decomposition into elements
 The relationship between the elements
 Interfaces to external systems
 Major physical design issues such as where elements will execute

Oct. 15, 2003 Page 5 of 7

<Project code> Software Design Specification
<Version x>

 Global design strategies such as error handling

NOTE: You may use appropriate UML diagrams (Package and Deployment diagrams) to document the overall system
architecture. Similarly you can describe the top-level decomposition of the system using Component diagrams.

3.2 Sub-System / Component / Module Level Architecture

Identify the sub-systems, component or modules of your overall software system and provide their
diagrammatic view using appropriate detailed architecture diagram presenting how the system is further
divided into sub systems, components and modules and the relationships and interactions between them.

3.3 Sub-Component / Sub-Module Level Architecture (1…n)

Identify all the sub components or sub modules (if any) of the already identified modules and components.
Provide their diagrammatic view using appropriate detailed architecture diagram presenting how those sub
systems, modules and components are further divided into sub components and sub modules and how they
interact with each other.

4. Design Strategies
Describe the design strategies or decisions that impact the overall organization of the system and its high-level
structures. This information should provide the reader with insights into the key abstractions and mechanisms
used in the system architecture.

4.1 Strategy 1…n

For each strategy, discuss the reasoning employed (possibly referring to previously stated design goals and
principles) and any trade-offs. Areas for consideration include:

 Future system extension or enhancement

 System reuse
 User interface paradigms
 Data management (storage, distribution, persistence)
 Concurrency and synchronization

5. Detailed System Design

A detailed design should include the following:

 Detailed class diagram along with a detailed description of all attributes, functions or methods
specifying interactions between different classes/modules.
 Detailed Sequence diagram with parameter list
 State Transaction Diagram
 Logical data model (E/R model)
 Physical data models
 Detailed GUIs

Oct. 15, 2003 Page 6 of 7

<Project code> Software Design Specification
<Version x>

6. References
This section should provide a complete list of all documents referenced at specific point in time. Each document
should be identified by title, report number (if applicable), date, and publishing organization. Specify the sources
from which the references can be obtained (This section is like the bibliography in a published book).

Ref. No. Document Title Date of Release/ Publication Document Source

PGBH01- Project Proposal Oct 20, 2003 <Give the path of your
2003- Project repository/Folder>
Proposal
PGBH01- Functional Specification Oct 20, 2003 <Give the path of your
2003-FS Project repository/Folder>

7. Appendices
Include supporting detail that would be too distracting to include in the main body of the document.

Oct. 15, 2003 Page 7 of 7