| Scope | Phases | Roles | Activities | Abstraction/Refinement Level |
|---|---|---|---|---|
Entire system, individual parts |
Analysis |
Application architects, other architects |
SMART NFR Elicitation |
n/a (requirements) |
also known as: SMART Non-Functional Requirement (NFR) Specification
A quality attribute scenario specifies a measurable quality goal for a particular context.
There might be multiple goals and corresponding scenarios, even when dealing with a single quality in a single context.
It is not sufficient to find out and specify what a system under construction is supposed to do. It is equally important to investigate how it does so (from an architectural point of view). Vague statements such as "we value a splendid user experience" or "the faster, the better" are not verifiable and lead to tension between the project team and its external stakeholders.
QAS are created, refined, and used in:
- Requirements elicitation (analysis), see SMART NFR Elicitation activity
- Architecture design and architectural decision making
- Test preparation and testing (stress testing in particular)
- Establishment of Service Level Agreement (SLA)
- Reviews and planning of re-engineering and refactoring
The full template look as follows (with explanations). Note that the six rows in the middle, from "Stimulus" to "Response Measure", which are grouped as "Scenario Components", form the core of a QAS. The other ones provide context information and deal with consequences of the specified response and response measure.
See the sample chapter of ADD 3.0 book by Humberto Cervantes and Rick Kazman (@Cervantes:2016) or the section overview of arc42 for QAS visualizations.
This is a text artifact, possibly structured with the help of templates and tables. Any word processing or other tool supporting item lists and table formatting can be used to create QAS instances, including wikis, markup languages, and Markdown.
Requirements management tools provide additional tooling options.
- Focus on key qualities, prioritize elicitation and documentation effort by business value and technical risk (for instance, via a test for architectural significance).
- Define the desired behavior in different environments such as steady state, high workload, and error cases. Create multiple QAS instances as/if needed.
- Do not let the scope of this analysis artifact creep, for instance, by morphing it into a design document. The response measure is an observable quality, not a means to achieve this quality.
- The SEI books and technical reports established the template since the late 1990s (@Bass:2012).
- The arc42 template also features it in its Section 10.
- Methods such as the Unified Process have/had similar concepts.
Relate activities in DPR are:
- SMART NFR Elicitation features "specific" and "measurable" as quality criteria for quality requirements; QAS satisfy these properties when filled out properly.
- The Architecture Modeling activity uses QAS (or other forms of SMART NFRs) as input.
Many artifacts require specific and measurable NFRs as input, including but not limited to Architectural Decision Records (ADRs) and Deployment Diagrams.
Related concepts include:
- Agile landing zones for NFRs
- NFR checklists, for instance, regarding the SMARTness of the quality goals
- Planguage, explained in detail in the article "Rich Requirement Specs: The use of Planguage to clarify requirements" @Gilb:2006.
The blog post "Do Software Architectures Meet Extra-Functional or Non-Functional Requirements?" covers NFRs.
title: "Design Practice Repository (DPR): Quality Attribute Scenario"
author: Olaf Zimmermann (ZIO)
date: "08, 30, 2024"
copyright: Olaf Zimmermann, 2023-2024 (unless noted otherwise). All rights reserved.
license: Creative Commons Attribution 4.0 International License