Information Technology Reference
In-Depth Information
Apart from the usual scope, intended audience, definitions, abbrevia-
tions, and overview, the architecture document should necessarily have
the following details.
Architectural Goals
This section describes the goals of the system, especially those that will
have a significant impact on the software architecture, like security, any
third-party software components, portability, scalability, and need for
reuse. The goals may not necessarily be explicit in the r equirements
document — they will have to be derived from it. It is imperative that
goals are listed in their order of priority. Prioritization requires assigning
proper weighting; the architect will have to use his or her prudence in
allocating this weighting on the basis of the user requirements.
Constraints
This is possibly the most important section of the document because it
has implications on the shape and the future of the system under devel-
opment. Consequently, it would be desirable to be as exhaustive as
possible. Architects should cross-reference these constraints at various
places in the document, where an architectural choice is mentioned. This
helps future generations of the team who may want to evolve the system.
Constraints (Figure 5.2) can be of two kinds:
1.
. Users can specify their choice of
operating system, scalability, response time, and user interaction
needs, delivery timelines, and the like. These may become con-
straints while developing the architectural blueprint for the system,
and may force the architect to make some choices. The architect
should review such overarching constraints with the business ana-
lyst (or the customer directly, if, as we recommend, the architect
Imposed by user requirements
Imposed by user
requirements
Constraints are
important
Due to architectural
choices
Figure 5.2
The reality of constraints.
