<Project Name>
System Architecture Document
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and must be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
Revision History
Date |
Version |
Description |
Author |
<dd/mmm/yy> |
<x.x> |
<details> |
<name> |
Table of Contents
1.3 Definitions, Acronyms, and Abbreviations
2. Architectural Principles and Critical Requirements
2.2.2 System Supplementary Requirements
4.4 Supplementary Requirements Flowdown
6.1 System Physical Layout, Characteristics, and Properties
6.4 Implementation Level Model
7.1 Business Information Rules
System Architecture Document
[The introduction of the System Architecture Document provides an overview of the entire System Architecture Document.]
This document provides a comprehensive architectural overview of the system, using a number of different architectural viewpoints to depict different aspects of the system. It is intended to capture and convey the significant architectural influences and decisions which affect the system.
[This section defines the purpose of the System Architecture Document, in the overall project documentation, and briefly describes the structure of the document. Identify the specific audiences for the document, with an indication of how they are expected to use the document.]
[A brief description of the applicability of the System Architecture Document; what is affected or influenced by this document.]
[This subsection provides identification of the system to which this document applies, in the form of identifying numbers, names, versions, and so on.]
[This subsection describes the purpose and general nature of the system to which this document applies. When the system exists in some form, or has some precursors, this subsection also summarize the history of the system and its operation. Identify the key stakeholders, for example, the acquirer, the user(s), operating agencies, and so on.]
[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the System Architecture Document. This information can be provided by reference to the project Glossary.]
[This subsection provides a complete list of all documents referenced elsewhere in the System Architecture Document. Identify each document by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information can be provided by reference to an appendix or to another document.]
[This subsection describes what the rest of the System Architecture Document contains and explains how the System Architecture Document is organized.]
[In this section, the predetermined styles, rules and heuristics which are used to shape the system architecture are described, along with the rationale for their selection (for example, environmental, organizational, and domain influences). Architectural style includes identification of (classes of) reusable elements and compositions of these (and the rules that allow composition), and descriptions of methods for presentation and analysis of systems using a particular style.]
[This subsection lists system use cases or scenarios from the System Use-Case Model if they represent some significant, central functionality of the final system, or if they have a large architectural coverage, that is, if they exercise many architectural elements, or if they stress or illustrate a specific, delicate point of the system architecture. Identify any associated performance requirements that are to be tracked as part of the Technical Performance Measurement process.]
[This subsection lists critical physical, environmental, quality of service, specialty engineering or other constraints that significantly shape the system architecture. Also, identify which of these are tracked as part of the Technical Performance Measurement process.]
[This section illustrates significant aspects of the system from the worker viewpoint, which concerns itself with the roles and responsibilities of the organization and system workers (and policies affecting these).]
[TBD]
[TBD]
[TBD]
[TBD]
[This section illustrates significant aspects of the system from the logical viewpoint, which concerns itself with the way the system performs its functions in terms of its partitioning into subsystems, their connections, interactions and processing, and how the non-functional requirements, including quality of service and other constraints are flowed down to the subsystems.]
[This subsection describes the architecturally significant elements from the Context Diagram in the System Analysis Model, for example, entities with which the system interacts, connections and material, data, or other flows to be supported.]
[In this subsection, describe the significant interfaces (offered and required) that support the entities, connections, and flows identified in 4.1 System Context.]
[This subsection identifies and describes the subsystems that play an architecturally significant role, in terms of the interfaces (capabilities and attributes) they support and require, and the nature of their relationships, one to the other, and external to the system.]
[This subsection describes how the significant use cases and use-case scenarios are realized in terms of subsystem interactions, and how critical system performance requirements are reflected in performance constraints placed on subsystem capabilities and the links between subsystems.]
[This subsection describes how the critical physical, environmental, quality of service, specialty engineering and other constraints, are flowed down to the subsystems, and how the subsystem characteristics, so determined, combine to yield the desired system characteristics.]
[This subsection describes the trade studies, analysis, and reasoning that led to the definition and selection of this logical architecture, and why the particular subsystems and interactions chosen are significant. Where decisions have been taken to include humans as part of the operational system, the trade-off between humans and performance of the same functions in hardware or software, and the way in which human performance characteristics have been taken into account, are of particular interest. This subsection also describes the rationale (for example, modeling, analysis, prototyping) used for the budgeting or assignment of the non-functional requirements.]
[This section illustrates significant aspects of the system from the process viewpoint, which concerns itself with the way the system architecture is designed to take advantage of concurrency (multiple processes performed apparently or actually in parallel), to yield simpler (and so more easily maintained) architectures, and to address scalability, performance, throughput, and reliability concerns.]
[In this subsection, the significant or critical active elements of the system (subsystems, classes, objects) are identified and their important relationships and interactions described. This information comes from the System Analysis Model and System Design Model, with a focus on the active elements that represent the processes in the system.]
[The analysis, reasoning, and trade studies that resulted in the process architecture are described here, as well as an explanation of why the processes and interactions discussed are important.]
[This section illustrates significant aspects of the system from the physical viewpoint, which concerns itself with the physical infrastructure required to support system functionality and distribution.]
[This subsection describes important aspects of the system's physical placement, equipment installation and assembly, and safe, reliable, physical operation. Aspects to be considered include weight, power supply, heat generation and dissipation, acceleration/vibration effects, electromagnetic interference, physical access, and so on.]
[Describe significant or critical aspects of the Locality Model, including locality decomposition (if any), locality and connection characteristics, hosted subsystems, and interesting locality interactions.]
[Describe significant or critical aspects of the System Deployment Model at the Descriptor level, where the types of processing resources at a locality are specified - these are nodes, which might include computing devices (servers, workstations, and so on), people, or other electro-mechanical devices.]
[Describe significant or critical aspects of the System Deployment Model at the Implementation level, where the actual hardware selection is made, numbers of role instances (in the case of human resources) are determined, and a set of configurations, capacity, power (and other environmental requirements), cost, and performance is defined.]
[The analysis, reasoning and trade studies that resulted in the physical layout and deployment architecture are described here, with an explanation of why the particular aspects presented are important.]
[TBD]
[TBD]
[TBD]
[TBD]
[TBD]