Software Design

Description
for

[Project]

Version [1.0]
<Note: Must follow the latest number in Revision History table.>

Prepared by
[Team]
[List of Name (Student Id)]

[Date Created]
<Note: Must follow the latest date in Revision History table.>

Copyright © 1999 by TMA Training Center. Permission is granted to use, modify, and distribute this document.
Software Design Description for [Project] Page ii

Table of Contents
Table of Contents...........................................................................................................................ii
Revision History............................................................................................................................iii
1. Introduction..............................................................................................................................1
1.1 Purpose.........................................................................................................................................1
1.2 Definitions, Acronyms and Abbreviations...................................................................................1
1.3 Intended Audience and Reading Suggestions..............................................................................1
1.4 Product Scope...............................................................................................................................1
1.5 References....................................................................................................................................1
2. High Level Design....................................................................................................................2
2.1 Design Considerations..................................................................................................................2
2.2 System Level Desired Behavior...................................................................................................2
2.3 Logical Representation of the Architecture..................................................................................2
2.4 Architectural Component Overview.............................................................................................2
2.5 Process Architecture.....................................................................................................................3
2.6 Deployment Architecture.............................................................................................................3
3. Detailed Design.........................................................................................................................4
3.1 Class Diagram...............................................................................................................................4
3.2 Class Summary.............................................................................................................................4
4. GUI Mockups...........................................................................................................................5
5. Open Issues...............................................................................................................................6
Appendix A: Approval..................................................................................................................7
Appendix B: Glossary....................................................................................................................8
Appendix C: Sequence Diagram...................................................................................................9
Appendix D: To Be Determined List..........................................................................................10
Software Design Description for [Project] Page iii

Revision History
Name Date Reason For Changes Version
Software Design Description for [Project] Page 1

1. Introduction

1.1 Purpose
<Note: Identify the product whose software designs are specified in this document, including the
revision or release number. Describe the scope of the product that is covered by this SDD,
particularly if this SDD describes only part of the system or a single subsystem.>

1.2 Definitions, Acronyms and Abbreviations

<Note: Describe any standards or typographical conventions that were followed when writing this
SDD, such as fonts or highlighting that have special significance. For example, state whether
priorities for higher-level requirements are assumed to be inherited by detailed requirements, or
whether every requirement statement is to have its priority.>

1.3 Intended Audience and Reading Suggestions

<Note: Describe the different types of readers that the document is intended for, such as
developers, project managers, marketing staff, users, testers, and documentation writers. Describe
what the rest of this SDD contains and how it is organized. Suggest a sequence for reading the
document, beginning with the overview sections and proceeding through the sections that are most
pertinent to each reader type.>

1.4 Product Scope

<Note: Describe the boundaries of the design here. State what functionality is included and what is
excluded. This statement is given in terms of business functions.>

1.5 References
<Note: The following references are cited in this document:

 [SRS] Please refer to the latest approved version of the document <Put SRS title here>.
<Please provide the hyperlink to the library containing this SRS for the SRS title>
 [Traceability Matrix TM)] Please refer to the latest approved version of the document. TM
can be used to trace all requirements related to the component.<Put TM title here>.
<Please provide the hyperlink to the library containing this TM for the TM title>

(Optional) – Note any references or related materials here.(Some other technical documents like:
IETF, RFC… that you mentioned above.)>
Software Design Description for [Project] Page 2

2. High Level Design

2.1 Design Considerations

<Note: In this section, consider high-level design options. Consider non-functional (product or
technology) requirements, which push your design in a specific direction.>

2.1.1 Design Options

<Note: At a high-level, describe the design direction and rationale. Also, describe alternative
approaches considered and rationale for them not being chosen.>

2.1.2 Assumptions

<Note: Document the assumptions, open issues, concerns that guide the design or have the
possibility of affecting the design.

Open issues should be addressed before the design is completed. If assumptions are invalidated
or change, the design must be revisited to ensure design changes are made as necessar.>

2.1.3 Constraints

<Note: Indicate the constraints that affect the design, i.e. restrictions imposed on the design that
force the design decisions a certain way. Once again, this is driven by non-functional
requirements, such as real-time, memory, reliability, scalability etc.>

2.2 System Level Desired Behavior

<Note: This is equivalent to the Scenario View as per the 4+1 model.

You can use the Use Case Diagram and describe briefly the function and purpose of every use
cases.>

2.3 Logical Representation of the Architecture

<Note: This is equivalent to the Logical View as per the 4+1 model.

At the very highest level, describe a logical representation of the architectural design that will be
used to satisfy the functional requirements. This representation is not constrained by existing
software architectures, product requirements or target hardware platforms upon which the
functional requirements will be satisfied.

You may use architectural style here.>

2.4 Architectural Component Overview

<Note: This is equivalent to the Implementation View as per the 4+1 model.
Software Design Description for [Project] Page 3

Identify and describe the software components that make up the architecture and their
relationships. Identify new, changed, and if applicable, deleted software components required to
satisfy the functional requirements.

It is important to take into account non-functional requirements (such as real-time, redundancy

etc.) when describing the architecture at this level.

You may use application architectural design here.>

2.4.1 Software Dependencies

<Note: At a high-level, describe software upon which this design depends. If applicable, reference
other features which are being done in parallel to support a larger project or other features which
may have impact due to interactions or known changes in the same software being changed by
this feature.>

2.4.2 Third Party Component Description

<Note: If your design includes the use of third party software, document build versus buy analysis
and rationale for the decision around adoption of this approach and describe how it will be
integrated into the rest of the design.

Please note that we should be strongly encouraging use of existing software in order to avoid
licensing costs incurred as a result of using 3rd party S/W.>

2.5 Process Architecture

<Note: This section is optional. This is equivalent to the Process View as per the 4+1 model.

At a high-level, describe the process architecture required to satisfy the functional requirements.
Identify new tasks or processes needed and/or changes to existing tasks to support the necessary
execution flows.

If the design is within a single task or process and/or is completely task unaware, simply state
this.>

2.6 Deployment Architecture

<Note: List the user documentation components (such as user manuals, online help, and tutorials)
that will be delivered along with the software. Identify any known user documentation delivery
formats or standards.>
Software Design Description for [Project] Page 4

3. Detailed Design
<Note: This section and its subsections specify internal details of components/modules. They also
design algorithms, data types, and data structures for components and interfaces.

Typical activities include:

- Allocate all software requirements to modules
- Select algorithms, data types, and data structures for modules
- Specify data types for module interfaces.>

3.1 Class Diagram

<Note: This subsection includes the detail (design) class diagram.>

3.1.1 Scenarios

<Note: This subsection includes the high-level scenarios relevant to the system. For detail
scenarios, please refer to Appendix C>

3.2 Class Summary

<Note: This subsection includes a complete description of each class: methods, attributes,
operations. Also, for a class, which already exists, highlight here the changes made. ><Repeat for
each class.>

3.2.1 Class: <Class#1 (Use the class name)>

<Note: You need to repeat this subsection to cover all classes in your class diagram.>

Attributes: <(A list of detail information of the data

elements/variables in the class)>
<Method #1 (Use the 1. Pre-condition:
method name)> <List any assumptions that must be true in order for
Component 1 to operate correctly. A good example is that
Component 1 may assume that certain files are open or
that a certain Internet connection has been established.>
2. Post-condition:
<Describe the changes to the state of the system that
have occurred as a result of the execution of this module.
Note: This is the "what" requirement of the module.>
3. Algorithm:
<List the steps (pseudocode, perhaps) taken by this
component to achieve its intended purpose.>
4. Error handling/Exception processing:
<Describe any error processing that is not made clear in
the description of the algorithm.>
Software Design Description for [Project] Page 5

… … <Repeat for every methods in the class.>

4. GUI Mockups
<Note: Include any screen layouts or user interface mockups for this component.>
Software Design Description for [Project] Page 6

5. Open Issues
<Note: List out any open issues herein.>
Software Design Description for [Project] Page 7

Appendix A: Approval
The undersigned acknowledge they have reviewed the [Project Name] Software Design Description and
agree with the approach it presents. Changes to this Software Design Description will be coordinated with
and approved by the undersigned or their designated representatives.

<Note: List the individuals whose signatures are desired. Examples of such individuals are Quality
Manager or Tester. Add additional lines for signature as necessary. Although signatures are
desired, they are not always required to move forward with the practices outlined within this
documentation.>

1. Signature: _______________________________________ Date: _____________

Name: _______________________________________
Student Id: _______________________________________
Role: _______________________________________

2. Signature: _______________________________________ Date: _____________

Name: _______________________________________
Student Id: _______________________________________
Role: _______________________________________

3. Signature: _______________________________________ Date: _____________

Name: _______________________________________
Student Id: _______________________________________
Role: _______________________________________
Software Design Description for [Project] Page 8

Appendix B: Glossary
<Note: Define all the terms necessary to properly interpret the SDD, including acronyms and
abbreviations. You may wish to build a separate glossary that spans multiple projects or the entire
organization, and just include terms specific to a single project in each SDD.>
Software Design Description for [Project] Page 9

Appendix C: Sequence Diagram

<Note: Include Sequence Diagram for all use cases.>
Software Design Description for [Project] Page 10

Appendix D: To Be Determined List

<Note: Collect a numbered list of the TBD (to be determined) references that remain in the SDD so
they can be tracked to closure.>