Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 10

Assosa University

College of Computing and Informatics


Department of Computer Science

<Insert Name of the Project>

A Software Project Documentation Submitted to the


Department of Computer Science of Assosa University in Partial Fulfillment of
Requirements for the Course of Software Engineering

Prepared by:
Name of Student 1
Name of Student 2
Name of Student 3
…….

Advisors’ Name:
Main Advisor ……………
Co-Advisor ……………

<Submission Date>
Software Design Description
for

<Insert Name of the Project>

Version 1.0 approved

Prepared by <author1, author2, author3, …. >

<organization>

<date created>

i
Acknowledgement
<Acknowledge organizations or people who cooperate and help you in providing information
during the preparation of this SDD document.>
Contents
ACKNOWLEDGEMENT................................................................................................ II
1 INTRODUCTION....................................................................................................1
1.1 PURPOSE.....................................................................................................1
1.2 DESIGN GOALS............................................................................................1
1.3 SCOPE.........................................................................................................1
1.4 OVERVIEW...................................................................................................1
1.5 REFERENCES...............................................................................................1
1.6 DEFINITIONS, ACRONYMS AND ABBREVIATIONS..............................................1
2 SYSTEM OVERVIEW............................................................................................2

3 SYSTEM ARCHITECTURE...................................................................................3
3.1 PROPOSED SYSTEM ARCHITECTURE.............................................................3
3.2 DESIGN RATIONALE......................................................................................3
4 DATA DESIGN.......................................................................................................4
4.1 ENTITY RELATIONSHIP DIAGRAM...................................................................4
4.2 DATA DICTIONARY........................................................................................4
4.3 PERSISTENCE MODELING..............................................................................4
5 COMPONENT DESIGN.........................................................................................5
5.1 LOGICAL MODELING......................................................................................5
5.2 INTERACTION MODELING...............................................................................5
5.2.1 Activity Diagram........................................................................................5
5.2.2 Sequence Diagram.....................................................................................5
5.2.3 Collaboration Diagram.............................................................................5
5.3 STATE DYNAMIC MODELING..........................................................................5
5.4 DEPENDENCY MODELING..............................................................................5
5.4.1 Subsystem Decomposition.........................................................................5
5.4.2 Component Diagram.................................................................................5
5.4.3 Deployment Diagram.................................................................................5
6 HUMAN INTERFACE DESIGN..............................................................................6
6.1 OVERVIEW OF USER INTERFACE...................................................................6
6.2 SCREEN IMAGES...........................................................................................6
6.3 Screen Objects and Actions.......................................................................6

Revisions
Version Primary Author(s) Description of Version Date Completed
Draft Type Full Name Information about the revision. This table does not need 00/00/00
and Number to be filled in whenever a document is touched, only
when the version is being upgraded.

ii
Software Design Description for <Insert Name of the Project>

1 Introduction
1.1 Purpose
< Describe the purpose of this SDD document and its intended audience.

TO DO:
 Write 1-2 paragraphs describing the purpose of this document as explained above.
 E.g. “This software design document describes the architecture and system design of
XX. ….”.>

1.2 Design Goals


< The design goals are derived/ inferred from the non-functional requirements identified and
specified in the SRS. Design goals describe the qualities of the system that developers
should optimize. Discus Performance Criteria (Response time, Throughput, Memory),
Dependability Criteria (Robustness, Reliability, Availability, Fault Tolerance and Security),
End User Criteria (Usability, Utility), Maintenance Criteria (Extensibility, Modifiability,
Portability, and Adaptability) from the point of view of your system.>

1.3 Scope
< Provide a short description and scope of the software and explain the goals, objectives
and relevant benefits of the project. This will provide the basis for the brief description of the
product.>

1.4 Overview
< Describe what the rest or remainder of the SDD contains and explain how the SDD is
organized section wise following the logical ordering of the contents to be overviewed.

TO DO:
 E.g. The remaining of (rest) this document is organized as follows; Section 2, provides
general descriptions of major subsystems being modeled in the design. Section 3, deals
about the software architecture where the architecture of the software under discussion
will be presented…. In the next section, Section 4, presents design of logical database
requirements, Section 5, provides detailed level of subsystem modeling with UML The
last section, Section 6, provides the Design of Human Interface from user’s
perspective....>

1.5 References
<List all referenced documents (complete list of all documents) including sources used in
preparation of the SDD and specify sources from which the references can be obtained.
Apply IEEE Referencing Style throughout the SDD document.>

1.6 Definitions, Acronyms and Abbreviations


<Provide the definitions of all terms, acronyms, and abbreviations required to properly
interpret the SDD sorted in alphabetical order.>

1
Software Design Description for <Insert Name of the Project>

2 System Overview
<Give a general description of the functionality, context and design of your project. Provide
any background information if necessary.
Provide general description of major components/modules to be modeled as subsystems.
Example: Account Management Subsystem, Payment Processing Subsystem and etc.
Describe the type of the system being designed (Web-based, Distributed System, or Mobile-
based or other system.
Describe the parts of the system being designed like Client Machines, Server Machines and
other external systems/components that interact with the system.>

2
Software Design Description for <Insert Name of the Project>

3 System Architecture
<Put a bridge statement/paragraph(s) stating the general information guiding your reader
when reading this section. It is up to you to decide what to put here but should be value
adding to the reader.>

3.1 Proposed System Architecture


<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 (supplement with text as
needed). Provide descriptions of the design components if models are complex. You can
select appropriate System Architecture for your project. Refer to the book “OOSD, System
Design (Chapter 4), Bahrami Ali.>

3.2 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 with justification.>

3
Software Design Description for <Insert Name of the Project>

4 Data Design
<Put a bridge statement/paragraph discussing about data design general stuff.

Provide information viewpoint (logical database requirements) in entity relationship diagram,


data dictionary and persistent data management (relationship among tables).

Describe the persistent data stored by system and the data management infrastructure
required for it. This section typically includes the description of data schemes, selection of a
database, and the description of the encapsulation of database.>

4.1 Entity Relationship Diagram


 <Draw the ERD (Entity Relationship Diagram) for the entire System using OO
Modeling.>

4.2 Data Dictionary


 <Alphabetically list the system entities or major data along with their types and
descriptions. If you are providing an OO description, list the objects entities and its
attributes.
 Construct the Data Dictionary based on the ERD.>

4.3 Persistence Modeling


 <Draw the Persistent Data Management (Relationship among database tables) based
on the Data Dictionary.>

4
Software Design Description for <Insert Name of the Project>

5 Component Design
<In this section, you take a closer look at what each component does in a more systematic
way. This section is the longest in content than any other section in your design document.
Hence, for each component/subsystem (Set of Functional Requirements in the SRS) you
are required to include detailed level subsystem model with Logical Models, Interaction
Models, State Dynamic Models and Dependency Models here. [NB: You are not required to
model everything in the SRS, the decision is yours. Refer to the books by Bahrami Ali
(Object Oriented Systems Development), Scott W. Ambler (The Elements of UML Style),
Zhiming Liu (Object-Oriented Software Development with UML) for Component Modeling
with UML, Roger S. Pressman(Software Engineering, APRACTITIONER’S APPROACH)
and Ian Sommerville(Software Engineering)..>

5.1 Logical Modeling


<The logical modeling elaborates design types as classes with their structural relation.>

 Draw the System Class Diagram for System.


 Describe all Classes and Methods>

5.2 Interaction Modeling

5.2.1 Activity Diagram


 <Draw the Activity Diagrams.>

5.2.2 Sequence Diagram


 <Draw the Sequence Diagrams.>

5.2.3 Collaboration Diagram


 <Draw the Collaboration Diagrams.>

5.3 State Dynamic Modeling


 <Draw the State Chart Diagrams.>

5.4 Dependency Modeling

5.4.1 Subsystem Decomposition


 <Draw the Subsystem Decomposition (Package Diagram) for the entire System.>

5.4.2 Component Diagram


 <Draw the Component Diagram for the entire System.>

5.4.3 Deployment Diagram


 <Draw the Deployment Diagram (Hardware/Software Mapping) for the entire System.>

5
Software Design Description for <Insert Name of the Project>

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.>

6.2 Screen Images


<Display screenshots showing the interface from the user’s perspective. These can be hand
drawn (Screen Mock-ups) or you can use an automated drawing tool. Just make them as
accurate as possible. Graph paper works well. This section can be unified with section 6.3>

6.3 Screen Objects and Actions


<A discussion of screen objects and actions associated with those objects i.e., where does
the user needs to "Click", and what sequence in which Use Case, will come to action.>

You might also like