Software Architectural Design
(SWAD)
Document Number: [nn]
Date: Day, Month Day, Year
[Project Name]
[Author 1]
[Author 2 - if none, leave blank line]
[Author 3 - if none, leave blank line]
[Author 4 - if none, leave blank line]
Professor [Name]
Software Engineering Department
Monmouth University
West Long Branch, NJ 07764-1898
Table of Contents
1 SCOPE
1
1.1 IDENTIFICATION
1
1.2 SYSTEM OVERVIEW
1
1.3 DOCUMENT OVERVIEW
1
2 REFERENCED DOCUMENTS
ERROR! BOOKMARK NOT DEFINED.
3 CURRENT SYSTEM OR SITUATION
2
3.1 BACKGROUND, OBJECTIVES, AND SCOPE
2
3.2 OPERATIONAL POLICIES AND CONSTRAINTS
2
3.3 DESCRIPTION OF PRELIMINARY SOFTWARE DESIGN
2
3.3.1 SPECIFY ARCHITECTURAL MODEL PROCESS
2
3.3.2 DEVELOP CLASS CATEGORIES/CLASSES/OPERATIONS
3
3.3.3 MAP SOFTWARE REQUIREMENTS PROCESS
4
3.3.4 CONDUCT SOFTWARE DESIGN REVIEW PROCESS
4
3.4 USERS OR INVOLVED PERSONNEL
5
4 NOTES
5
i
Software Architectural Design (SWAD)
[Project Name]
1
Scope
[This section shall be divided into the following paragraphs.]
1.1
Identification
[This paragraph shall contain a full identification of the system and the software to which
this document applies, including, as applicable, identification number(s), title(s),
abbreviation(s), version number(s), and release number(s).]
1.2
System Overview
[This paragraph shall briefly state the purpose of the system and the software to which this
document applies.
It shall describe the general nature of the system and software;
summarize the history of system development, operation, and maintenance; identify the
project sponsor, acquirer, user, developer, and support agencies; identify current and
planned operating sites; and list other relevant documents.]
1.3
Document Overview
[This paragraph shall summarize the purpose and contents of this document and shall
describe any security or privacy considerations associated with its use.]
[Example: The developer shall define and record the architectural design of each Software
Item (SWI) (identifying the Software Units (SU) comprising the SWI, their interfaces, and
a concept of execution among them) and the traceability between the SUs and the SWI
requirements. The result shall include all applicable items in the architectural design and
traceability sections of the SDD. Design pertaining to interfaces may be included in the
SDDs or IDDs.
Note: SUs may be made up of other SUs and may be organized into as many levels as are
needed to represent the SWI architecture. For example, a SWI may be divided into three
SUs, each of which is divided into additional SUs, and so on.]
2
References
[Use the citations and bibliography functionality of MS Word. (It will save you a lot of
time)]
1
Software Architectural Design (SWAD)
[Project Name]
[1] J. Smith and J. Smith, "Software Requirements Document," 2013.
3
Current System or Situation
[This section shall be divided into the following paragraphs to describe the system or
situation as it currently exists.]
3.1
Background, Objectives, and Scope
[This paragraph shall describe the background, mission or objectives, and scope of the
current system or situation.]
3.2
Operational Policies and Constraints
[This paragraph shall describe any operational policies and constraints that apply to the
current system or situation.]
3.3
Description of Preliminary Software Design
The Software Preliminary Design phase begins during development of the SSS and SRS.
Preliminary software design supports modeling the [Project Name] system. The model is
placed under informal Software Design Team control and is used as input to the SDD. The
processes associated with preliminary software design are:




Specify architectural model
Develop class categories/classes/methods
Map software requirements
Conduct software design review
3.3.1 Specify Architectural Model Process
[This paragraph shall describe the architectural model process being used for the [Project
Name]. The entry criteria for this task are the completion of the formal design
methodology. The exit criteria for this task is the acceptance of the architectural model
and the allocation of requirements for the architectural components.]
2
Software Architectural Design (SWAD)
[Project Name]
[Example: An Architecture Working Group (AWG) is formed to address system-wide
architectural issues. The AWG participants are senior systems and software engineers and
representatives from each of the technical groups and teams on the [Project Name]. The
AWG defines an overall architectural model that depicts the logical and physical software
design for [Project Name].]
PRINCIPAL PARTICIPANT(S): Architecture Working Group (AWG)
ACTIVITIES:






Review available documentation on requirements, assumptions, and
constraints.
Formulate and evaluate architectural alternatives.
Select architectural model. Define entity-objects, their interactions, data flow,
and functional processes.
Allocate known requirements to architectural components.
Review architectural model and requirements allocation.
Software Project Manager accepts architectural model.
3.3.2 Develop Class Categories/Classes/Operations
[This paragraph describes the process followed to develop classes and operations. The
entry criteria for this task are the acceptance of the architectural model and the requirements
allocated for the project. The exit criteria for this task are to ensure that all class categories
/classes are defined and the architectural model is updated.]
[Example: The Develop Class Categories/Classes/Operations process follows an OOD
methodology to identify the top-level class categories, subordinate class categories, and
classes for the [Project Name] software design. It provides specific definitions of class
types, attributes, properties, and operations.]
PRINCIPAL PARTICIPANT(S): Software Design Team
ACTIVITIES:



Define class generalization hierarchy.
Define class categories and dependencies.
Define sub classes.
3
Software Architectural Design (SWAD)
[Project Name]




Define class attributes.
Define class operations.
Update architectural model.
Review and approve updated architectural model.
3.3.3 Map Software Requirements Process
[This paragraph describes the process followed to map the software requirements. The
entry criteria for this task are that the class categories/classes are defined and the known
software requirements are identified. The exit criteria for this task requires that the
software requirements are mapped to classes.]
[Example: The Software Design Team maps software requirements from the SSS to
classes. The mapping process may be repeated several times during the incremental design
of the software.]
PRINCIPAL PARTICIPANT(S): Software Design Team
ACTIVITIES:



Review known software requirements and identified class categories and
classes.
Using unique requirement identifiers, map the identified software requirements
to classes.
The Architecture Working Group verifies completeness and consistency of
requirements mapping.
3.3.4 Conduct Software Design Review Process
[This paragraph shall describe the process used to conduct the software design review. The
entry criteria for this task is that the software design is ready for review. The exit criteria
for this task is an approved software design.]
[Example: Software Design Reviews occur at all levels of the software design—from TopLevel through Detailed, and can encompass all or part of any set of software units. The
Software Design Team submits a software design package for review. Review schedule is
coordinated with the Software Development Manager. Separate reviews may be conducted
for overall Top-Level Design, or for localized software units. The Software Design Team
includes the results of the Software Design review conducted and the action items
identified and tracked to closure in the SDF for the reviewed software.]
4
Software Architectural Design (SWAD)
[Project Name]
PRINCIPAL PARTICIPANT(S): Software Development Manager
ACTIVITIES:






Software Design Team notifies Software Development Manager of readiness
for software design review.
Select software design review team participants, assign roles, and schedule
review.
Distribute software design review package to review participants.
Conduct software design review. Software Design Team leader presents the
design. Participants assess compliance with requirements, completeness,
efficiency, and adherence to design methodology. Participants identify and
discuss defects.
Recorder documents defects, action items, and
recommendations. Software designer includes record of software design
review in SDF.
Software Design Team corrects any defects in design. Update design review
material as required. Distribute recorded design review information
The Software Development Manager obtains the Software Project Manager’s
approval of the software design.]
3.4
Users or Involved Personnel
[This paragraph shall describe the types of users of the system, or personnel involved in
the current situation, including, as applicable, organizational structures, training/skills,
responsibilities, activities, and interactions with one another.]
4
Notes
[This section shall contain any general information that aids in understanding this
document (e.g., background information, glossary, rationale). This section shall include
an alphabetical listing of all acronyms, abbreviations, and their meanings as used in this
document and a list of terms and definitions needed to understand this document.]
5