Haramaya University

Software
Architecture and
Design Document
Template
For Documenting the Architectural and detailed Design of Graduating
Year Projects

Department of Software Engineering

1.1 Purpose

Describe the purpose of this document and its intended audience. (e.g. “This software design
document describes the architecture and system design of XX. ….”).

1.2 Scope

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.

NOTE: Remember this part is taken from your previous documents like Proposal and SRS.

1.3 Overview

Provide an overview of this document and its organization. This is a place to tell to the reader how
the remaining part of your architecture and design document is organized. It is written:

The remaining of (rest) this document is organized as follows; section 2 deals about the software
architecture where the architecture of the software under discussion will be presented using the
4+1 view model. In the next section, section 3, xxx will be presented …

1.4 Reference Material

This section is optional. List the resources (materials) and documents you used as base for
repairing this document. Your proposal and SRS are among the FIRST to mention here

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 software architecture and design (SAD) document. These definitions should be items used in
your SAD document that are most likely not known to the audience.

Note! You need to include besides the terminologies defined in the SRS document any new
terminologies that a design and architecture phase has bring about.
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

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 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. Do it as follows, keep the steps;

1. In other words, this is where you put the Architectural Pattern you have used using diagram
of your system decomposition using the specified architectural pattern (it is not MUST for
you to use architectural pattern. In that case, you will show the architecture you used
instead).
2. Once, step one the generic system model is shown then include the (logical, physical,
process, development, scenario) 4+1 view models of the system you are designing. You
may use HEADING for each of them but the decision is yours.
3. Make sure you have made every model self-descriptive. If models are complex you can
add text description for each. For the logical view, in each subsystem, clearly state the
interface for its functionalities or services in the model.
3.2 Decomposition Description

This is simply a second level refinement of the system subsystems. It is mainly concerned with the
logical view model. Describe each subsystem in the logical view a little better way than in the
overall logical view model.

Provide a decomposition of logical or functional view model subsystems in the architectural

Put high level subsystem model and you better use this template below to describe the
components/subsystems in the logical view model.

IdentificationThe unique name for the component and the location of the component in the system.
Type A module, a subprogram, a data file, a control procedure, a class, etc
Purpose Function and performance requirements implemented by the design component,
including derived requirements. Derived requirements are not explicitly stated in the
SRS, but are implied or adjunct to formally stated SDS requirements.
Function What the component does, the transformation process, the specific inputs that are
processed, the algorithms that are used, the outputs that are produced, where the data
items are stored, and which data items are modified.
Subordinates The internal structure of the component, the constituents of the component, and the
functional requirements satisfied by each part.
Dependencies How the component's function and performance relate to other
Components. How this component is used by other components. The other
components that use this component. Interaction details such as timing, interaction
conditions (such as order of execution and data sharing), and responsibility for
creation, duplication, use, storage, and elimination of components.
Interfaces Detailed descriptions of all external and internal interfaces as well as of any
mechanisms for communicating through messages, parameters, or common data
areas. All error messages and error codes should be identified. All screen formats,
interactive messages, and other user interface components (originally defined in the
SRS) should be given here.
Resources A complete description of all resources (hardware or software) external to the
component but required to carry out its functions. Some examples are CPU execution
time, memory (primary, secondary, or archival), buffers, I/O channels, plotters,
printers, math libraries, hardware registers, interrupt structures, and system services.
Processing The full description of the functions presented in the Function subsection. Pseudocode
can be used to document algorithms, equations, and logic.
 Data For the data internal to the component, describes the representation method, initial
values, use, semantics, and format. This information will probably be recorded in the
data dictionary.

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

Put a bridge statement/paragraph discussing about data design general stuff.

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, 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 you can create new heading using the component name as a title.

For example, 5.1. ACCOUNT MANANGEMENT SUBSYSTEM, 5.2. FILE TRANSFER

Include detailed level subsystem model, object diagrams, interaction models, state diagrams,
generalization hierarchy diagram(s) (if any), aggregation hierarchy diagram(s) (if any), interface
specifications, and sequence diagrams here. Not go detail here; there will be a place for that in
section 5. Describe any local data when necessary. Summarize each object member function for
all the objects listed in 3.2 in PDL or pseudo-code.

Any group having interest to use design patterns you can use them and do the design accordingly.
Remember you are not supposed to use design pattern for every subsystem or classes in you design.
You can use it for 1 object even throughout your system.

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
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 cross reference 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

Add any important document in your design which you feel the design template has not allowed
you to put it in place. However, it must be something a value adding.