Artifact: System Architecture Document |
 |
The System Architecture Document provides a comprehensive architectural overview at the system level, using a number of different architectural views to depict different aspects of the system. |
Domain:
Systems Engineering
Work Product Kinds:
Specification |
|
Purpose
The System Architecture Document provides a comprehensive overview of the architecture at the system
level. It serves as a communication medium between the System Architect, the project, and
subprojects regarding architecturally significant decisions. The System Architecture Document describes the
system's:
-
architectural principles and guidelines
-
behavior (as visible externally and as realized internally)
-
structure (in component terms)
-
interface design
-
physical layout
-
architectural rationale and support for non-functional requirements
-
other resources
Snapshots from the Use-Case Model, System Analysis Model, System Design Model, and System Deployment Model
are provided in the System Architecture Document to illustrate these system facets from several
viewpoints:
-
Worker - concerned with the roles and responsibilities of the organization and system workers (and
policies affecting these)
-
Logical - focuses on the decomposition of the system into subsystems which interact through
interfaces
-
Information - concerned with the persistent information stored within the system
-
Physical - focuses on the physical partitioning and how distributed interaction between subsystems
is supported
-
Process - dealing with the system's ability to:
-
Accept and process multiple external stimuli concurrently.
-
Meet performance and resource constraints through concurrent processing, and the internal
mechanisms for concurrency, communication and synchronization which support this.
|
Relationships
Roles | Responsible:
| Modified By:
|
Tasks | Input To:
| Output From:
|
Illustrations
Tailoring
Representation Options | UML Representation:
You need to adjust the outline of the System Architecture Document to suit the nature of the system being
developed, for example:
-
Some classes of system might not need the section on System Layout, which has mainly to do with
the physical placement and assembly of (non-software) components.
-
You might need additional appendices to explain certain aspects, such as the rationale of certain
critical choices together with the solutions that have been eliminated, or to define acronyms or
abbreviations, or present general design principles.
-
The order of the various sections can vary, depending on the system's stakeholders and their focus or
interest.
All of the system architecture viewpoints probably need to be explored, although an individual viewpoint
does not always have the same importance, across different types of system.
|
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.
|
| |
|