Identify the Architectural Goals
Architectural goals provide the motivation and rationale for decisions. These goals are often driven by
the requirements. Architectural goals define how the system needs to respond to change over time. Architectural goals
tend to address the following questions:
What is the expected lifespan of the system?
Will the system need to respond to technological changes over time, such as new versions of
middleware or other products?
How frequently is the system expected to adapt to change?
What changes can we anticipate in the future, and how can we make them easier to accomodate?
These considerations will have a significant effect on the structure of the system.
Identify Architecturally Significant Requirements
Identify which of the current requirements are architecturally significant. Architecturally significant
requirements are those which need to be satisfied before the architecture can be considered "stable". These
requirements must be implemented for the system to work.
For example, if the requirement is that the system must deploy on Microsoft Windows XP and Linux
(because that is what the user is using), then if this requirement is not implemented the system will not be usable.
Another example may be those requirements which are considered standards. The system must encrypt all network traffic.
This is not just implemented for a specific system; this is a standard for all applications.
List any constraints. A variety of factors may place constraints on the architecture being
Use of a given database vendor or an existing database.
Web environment (server configurations, firewall, DMZ's and so forth).
Servers (hardware model, operating system).
Use of a third party software or a particular technology.
Compliance with existing standards.
For example, if a company uses only one type of database, you will probably try to use it as much as
possible to leverage the existing database administration skills rather than introducing a new one.
Capturing these constraints will ease integration with the environment, and may reduce risk, cost, and
duplication of solution elements.
Identify Interfaces to the System
|Identify the internal and external systems with which the system must interact. An external system may be
anything from software to hardware units that the current system will use, such as printers, terminals, alarm devices, and
Identify the Data Design
Define how the major data or system entities are stored, processed, and organized. This can be done
through Data Flow Diagrams if necessary. Also list all of the major data elements that will be required and thier
descriptions. Provide a Conceptual Data Model with the entity types, relationships, candidate primary and foreign
keys, etc. This will later be used to develop the Logical Model. If there is any data that will need to be converted
from a legacy system, be sure to determine how the data will be converted over and what tools will be used.
Identify the Interface Design
Identify the high level features that will be provided in the system. These can normally be determined
by looking for common themes in the requirements document. Provide screenshots showing the interface from a users
perspective. These can be hand drawn or you can use PowerPoint, Visio, Word, etc. For each screenshot, determine the
main functionality of the screen and any sub-functions, how the user will navigate to the screen, the different roles
that will have access to the screen, and if they will see different functionality depending on their role.
Trace Design Elements to Requirements
|Provide a cross reference that traces the design components and data structures to the requirements in the