<Project Name>

Software Architecture Document

Usage note: There is procedural guidance within this template that appears in a style named InfoBlue. This style has a hidden font attribute allowing you to toggle whether it is visible or hidden in this template. Use the Word menu Tools(Options(View(Hidden Text checkbox to toggle this setting. A similar option exists for printing Tools(Options(Print.

Introduction

Architecture Goals and Constraints

[SEI] Formulate a set of goals that the architecture should meet in order to satisfy the structural requirements of the software. Note that the goals of the architecture are not the same as the requirements of the software. While the software requirements focus on the external view of the software, the goals of the architecture capture the long-term requirements of the structure of the software. The goals of the architecture should be such that as long as the architecture meets these goals, the software is more likely to evolve and survive changes during its lifetime.

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

Architectural Style/ Patterns

[Software architectures may have an attribute called architectural style, which reduces the set of possible forms to choose from, and imposes a certain degree of uniformity to the architecture. The style may be defined by a set of patterns, or by the choice of specific components or connectors as the basic building blocks. Style plays a major part in the understandability and integrity of the architecture.]

Guiding Principles

Describe the principles that the software architecture should follow in order to meet the above goals. The architecture principles may be expressed as certain rules, DOs and DONTs, and guidelines that the designers and developers should adhere to.

Architectural Views

This section enumerates the views that are necessary for describing the software architecture for the current system. Explain how documentation is organized and enclose by reference the documents describing these views.

Mapping Architecture to Requirements

Significant Driving Requirements

Describe behavioral and quality attribute requirements (original or derived) that shaped the software architecture. List use cases or scenarios if they represent some significant, central functionality of the system or if they have a large architectural coverage. Describe how the software architecture contributes to all capabilities (other than functionality) of the system: extensibility, reliability, portability, and so on.]

Requirements	Architecture Solution / Notes	[Use case or Quality ]	Reason about the solution for this requirement. If needed refer the related architectural elements described in the views.

Use-Case Realizations

[This section illustrates how the software actually works by giving a few selected use-case (or scenario) realizations, and explains how the various design model elements contribute to their functionality.]

Relations among views

Describe the general relationship among the views chosen to represent the architecture. Discuss the consistencies among those views and identify any known inconsistencies. Show how the elements in related views are associated. The intent of this section is not match each possible pair of views but only the ones that are useful for better understanding the system.

Element in View X	Element in View Y

Analysis Results

Describe the results of any quantitative or qualitative analyses that have proven the software architecture is fit for purpose.

<Project Name>
Software Architecture Document	Date: <dd/mmm/yy>

Confidential	(<Company Name>, 2006	Page 1

Software Architecture Document

<Project Name>

rbalduino

2006-09-19

<Company Name>