<Organization Name>

Architectural Document

<Project Title>

<Group name >

Submitted To……

<date>

1
 Table of Contents
1. INTRODUCTION

1.1. Purpose ……………………………………………………………………………….

1.2. Scope ………………………………………………………………………………….

1.3. Overview …………………………………………………………………………….

1.4. Intended Users ………………………………………………………………………

1.5. Definitions and Acronyms ……………………………………………………………

2. SYSTEM OVERVIEW AND CONSTRAINTS ……………………………………………

2.1. System Overview ……………………………………………………………………

2.2. Constraints ………………………………………………………………………….

3. QUALITY ATTRIBUTE SCENARIOS AND TACTIC SELECTION……………………

3.1. Quality Attribute Scenarios ……………….. …………………………………………

3.2. Tactic Selection ……………………………………………………………………….

4. SYSTEM ARCHITECTURE …….………………………………………………………….

4.1 Architectural design ………………………………………………………………….

4.2. Module View …………………………………………………………………………

4.3. Component and Connector View ……………………………………………………

4.4. Allocation View ………………………………………………………………………

4.5 Design Rationale ……………………………………………………………………

5. DATA DESIGN …………………………………………………………………………….

5.1 Data Description ……………………………………………………………………

5.2 Data Dictionary …………………………………………………………………….

6. COMPONENT DESIGN ……………………………………………………………………

7. REQUIREMENTS MATRIX …………………………………………………………………

8. DESIGN PATTERN…………………………………………………………………
2
Creational Design Pattern ………………………………………………………………………………

Structural Design Pattern…………………………………………………………………………………

Behavioural Design pattern……………………………………………………………………………..

List of Tables…………………………………………………………..
List of Figures………………………………………………………..
ReferenceMaterial…………………………………………………………….

3
1. INTRODUCTION

1.1 Purpose

Identify the purpose of this SDD 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.

1.3 Overview

Provide an overview of this document and its organization.

1.4. Intended Users

Of this document
1.5 Reference Material

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

1.6 Definitions, Abbreviations and Acronyms

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

2.1. System Overview

4
2.2. Constraints

This section captures the special constraints that may apply: design and implementation strategy,
development tools, team structure, schedule, legacy code, and so on.

3. QUALITY ATTRIBUTE SCENARIOS DEFINITION AND TACTIC

SELECTION

3.1. Quality Attribute Scenarios

Take at least five high priority non-functional requirements and define their specific quality attribute
scenarios based on the template discussed in class.

3.2. Tactic Selection

For each quality attribute what design decision (tactics) are chosen and why. This can be presented
tabular as
Quality Attribute Design concern Tactic selected
QA-1 (Name..) Fault recovery
Spare
……… …………….. ………………..

Note that: for a given quality attribute there may be more than one design concerns and tactics selected;
and for design concern there may be tactics selected.

4. SYSTEM ARCHITECTURE

4.1 Architectural Design

Decompose a big system into subsystem and explain the relationships between the subsystems 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
5
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 .

4.2. Module View

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 object-oriented description. For a functional
description, put top level data flow diagram (DFD) and structural decomposition diagrams. For an OO
description, put class or object diagrams, generalization hierarchy diagram(s) (if any), and aggregation
hierarchy diagram (if any).

4.3. Component and Connector View

Choose one or more component and connecter view model (client-server, concurrency, process, shared

data) and depict runtime components and connectors. Detailed use case realization diagram e.g.

Sequence diagram can also be used here Explain what are the major executing components and how do

they interact?

4.4. Allocation View

Allocation views show the relationship between the software elements and the elements in one or more

external environments in which the software is created and executed. Choose one e.g. deployment

model/diagram and describe the elements of the model.

4.5. Design Rationales

Discuss the rationale for selecting the architecture described in 4.2, 4.3 and 4.4 including critical issues
and trade/offs that was considered. You may describe design rational for each view with their
respective sections or in this section. You may discuss other architectures that were considered,
provided that you explain why you didn’t choose them.

6
5. DATA DESIGN

5.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.
5.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 4.2, list all the functions and function parameters. If you
provided an OO description, list the objects and its attributes, methods and method parameters.

6. 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 4.2, provide a summary of your algorithm for each function
listed in 4.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 4.2 in PDL or pseudocode.
Describe any local data when necessary and describe its interface.

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. SOFTWARE DESIGN PATTERN