Software Design Document (SDD) Template

(Team Name)
(Project Title)
Software Design Document

Name (s):
Lab Section: Workstation:
Date: (mm/dd/yyyy)
 Software Design Document

TABLE OF CONTENTS

1. INTRODUCTION 2
1.1 Purpose 2
1.2 Scope 2
1.3 Overview 2
1.4 Reference Material 2
1.5 Definitions and Acronyms 2
2. SYSTEM OVERVIEW 2
3. SYSTEM ARCHITECTURE 2
3.1 Architectural Design 2
3.2 Decomposition Description 3
3.3 Design Rationale 3
4. DATA DESIGN 3
4.1 Data Description 3
4.2 Data Dictionary 3
5. COMPONENT DESIGN 3
6. HUMAN INTERFACE DESIGN 4
6.1 Overview of User Interface 4
6.2 Screen Images 4
6.3 Screen Objects and Actions 4
7. REQUIREMENTS MATRIX 4
8. APPENDICES 4

1. INTRODUCTION
1.1 Purpose
This software design document describes the architecture and system design of PC World
Company. For Develop a fully functional application, software designing process is very
important to fulfill the user requirement and system Requirements. SDD Is the key for
developers.

1
 Software Design Document

1.2 Scope
Pc World Company’s previous software based on water fall methodology because of that,
they Unable to add new feature in that system. because of that they decide to use new eb
based application for their company. So new web-based application Developed based on
agile methodology and some of the new features of it

• Receive a sales order via telephone, or email – carried out by an Order Handling Clerk.
• Check stock in a warehouse – carried out by an Order Handling Clerk.
• Create an acknowledgement copy of the sales order with a delivery date after the order
has been confirmed with the warehouse – carried out by a Warehouse Operative.
• Create an acknowledgement copy of the sales order stating the item is out of stock and
the date it will be available after the order has been confirmed with the warehouse –
carried out by a Warehouse Operative.
• Credit-check customers and reject them if they are not creditworthy – carried out by an
Order Handling clerk.
• Create a daily report of orders that have been dispatched – carried out by the Production
Manager.
• Create an invoice for business customers after the delivery – carried out by the Chief
Accountant.
• Accept credit card payment from domestic customers after the order has been confirmed
with the warehouse - carried out by an Order Handling Clerk.
• Create a final demand if a business customer has not paid an invoice after 30 days –
carried out by the Chief Accountant

Goal – Complete the software development successfully and increase overall the satisfaction
levels for clients calling to the company PC World Company.

Objectives -

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.

1.3 Overview
Provide an overview of this document and its organization.

2
 Software Design Document

1.4 Reference Material

This section is optional.
List any documents, if any, which were used as sources of information for the test plan.

1.5 Definitions and Acronyms

This section is optional.
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 OVERVIEW
Give a general description of the functionality, context and design of your project. Provide any
background information if necessary.

3. SYSTEM ARCHITECTURE

3.1 Architectural Design

Develop a modular program structure and explain the relationships between the modules to
achieve the complete functionality of the system. This is a high level overview of how
responsibilities of the system were partitioned and then assigned to subsystems. 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. Don’t 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.2 Decomposition Description

Provide a decomposition of the subsystems in the architectural design. Supplement with text
as needed. You may choose to give a functional description or an objectoriented description.
For a functional description, put toplevel data flow diagram (DFD) and structural
decomposition diagrams. For an OO description, put subsystem model, object diagrams,
generalization hierarchy diagram(s) (if any), aggregation hierarchy diagram(s) (if any),
interface specifications, and sequence diagrams here.

3
 Software Design Document

3.3 Design Rationale

Discuss the rationale for selecting the architecture described in 3.1 including critical issues
and trade/offs that were considered. You may discuss other architectures that were
considered, provided that you explain why you didn’t choose them.

4. DATA DESIGN

4.1 Data Description

Explain how the information domain of your system is transformed into data structures.
Describe how the major data or system entities are stored, processed and organized. List any
databases or data storage items.

4.2 Data Dictionary

Alphabetically list the system entities or major data along with their types and descriptions. If
you provided a functional description in Section 3.2, list all the functions and function
parameters. If you provided an OO description, list the objects and its attributes, methods and
method parameters.

5. COMPONENT DESIGN
In this section, we take a closer look at what each component does in a more systematic way. If
you gave a functional description in section 3.2, provide a summary of your algorithm for each
function listed in 3.2 in procedural description language (PDL) or pseudocode. If you gave an
OO description, summarize each object member function for all the objects listed in 3.2 in PDL
or pseudocode. Describe any local data when necessary.

6. HUMAN INTERFACE DESIGN

6.1 Overview of User Interface

Describe the functionality of the system from the user’s perspective. Explain how the user
will be able to use your system to complete all the expected features and the feedback
information that will be displayed for the user.

4
 Software Design Document

6.2 Screen Images

Display screenshots showing the interface from the user’s perspective. These can be hand
drawn or you can use an automated drawing tool. Just make them as accurate as possible.
(Graph paper works well.)

6.3 Screen Objects and Actions

A discussion of screen objects and actions associated with those objects.

7. REQUIREMENTS MATRIX

Provide a crossreference that traces components and data structures to the requirements in your
SRS document.

Use a tabular format to show which system components satisfy each of the functional
requirements from the SRS. Refer to the functional requirements by the numbers/codes that you
gave them in the SRS.

8. APPENDICES
This section is optional.
Appendices may be included, either directly or by reference, to provide supporting details that could
aid in the understanding of the Software Design Document.