SEI Architecture Analysis Techniques and When to Use Them

1 Introduction
Quality Attribute Workshops (QAWs) provide a method for analyzing a system’s architecture
against a number of critical quality attributes—such as availability, performance, security,
interoperability, and modifiability—that are derived from mission or business goals [Barbacci
02]. The QAW does not assume the existence of a software architecture. It was developed to
complement the Architecture Tradeoff Analysis MethodSM (ATAMSM)1 in response to customer
requests for a method that identifies important quality attributes and clarifies system
requirements before there is a software architecture to which the ATAM could be applied2
[Kazman 00]. The QAW can be applied to a conceptual (or “notional”) architecture or a system
architecture. The QAW and the ATAM, which are described in detail in various Software
Engineering Institute (SEISM)3 technical reports, in the book Evaluating Software Architectures:
Methods and Case Studies [Clements 01], and on the SEI Web site [SEI 02], can be used
in combination to obtain early and continuous benefits. It should be noted that the SEI has
developed related evaluation techniques, namely the Software Architecture Analysis Method
(SAAM, a predecessor of the ATAM), Active Reviews for Intermediate Designs (ARID), and
the Cost Benefit Analysis Method (CBAM), which are not covered in this technical note.
In an ATAM evaluation, an external team facilitates meetings between stakeholders during
which scenarios representing the quality attributes of the system are developed, prioritized,
and analyzed against the architectural approaches chosen for the system. Typical stakeholders
include developers, users, maintainers, and buyers. The results of the analysis are expressed as
risks, sensitivity points, and tradeoffs. To conduct an ATAM evaluation, an articulation of the
business drivers and an initial draft of the software architecture are required. A typical ATAM
evaluation would involve 2 two-to-three day meetings between the evaluation team and the
stakeholders over the course of a few weeks.
The QAW involves similar activities earlier in the life cycle of a project. In the QAW, an external
team facilitates meetings between stakeholders, during which scenarios representing quality
attribute requirements are generated, prioritized, and refined (refining involves adding
details about the personnel and assets required, the sequence of activities, and questions aboutthe requirements). After the scenario generation meeting(s), the refined scenarios are converted
into architectural test cases that the architecture team analyzes against the system architecture.
The architectural test case development and analysis often takes place over an
extended period of time (perhaps months) before the architecture team presents the results of
the analysis to the stakeholders.
The remainder of this technical note describes the QAW and the ATAM and uses a hypothetical
example (based on a common United States government acquisition strategy) to illustrate
when various QAW and ATAM activities are applicable.
http://www.sei.cmu.edu/reports/02tn005.pdf