Quality Attribute Scenario
also called QA Scenario, Testable NFR
A six-part template that turns a vague quality goal into something you can measure and argue about.
A quality attribute scenario has six parts: source, stimulus, environment, artefact, response, response measure. It exists because "the system must be resilient" cannot be designed for, tested, or disputed, and every one of those is required.
Worked example:
Source: an automated botnet. Stimulus: 40x normal request volume to the login endpoint. Environment: normal operation, single region degraded. Artefact: the edge and auth service. Response: legitimate users continue to authenticate; abusive traffic is shed at the edge. Measure: p99 login latency stays under 800 ms; fewer than 0.1% of legitimate requests rejected.
That is arguable. Somebody can now say "40x is the wrong number" or "0.1% is too generous", and that argument is exactly the value of writing it down.
Industry example
Cloudflare's architecture is a set of quality-attribute scenarios made concrete. Absorbing a multi-terabit volumetric attack without degrading legitimate traffic is not a feature; it is a response measure, and it dictates that mitigation must happen in the network at every edge location rather than at a scrubbing centre the traffic is redirected to. The measure — how much attack traffic is dropped how close to its source — chooses the topology.
The instructive part is that a different measure produces a different, equally valid design. If your requirement were "absorb a 10 Gbps attack against one origin", a scrubbing provider is cheaper and simpler, and building a global anycast network would be malpractice.
Common quality attributes and their real measures
| Attribute | Bad statement | Usable measure |
|---|---|---|
| Availability | "highly available" | 99.95% monthly, measured by synthetic probes from 3 regions |
| Latency | "fast" | p99 under 300 ms at 2,000 RPS, measured at the edge |
| Scalability | "scales" | 10x traffic absorbed within 5 minutes with no manual action |
| Recoverability | "recovers quickly" | RTO 15 min, RPO 30 s, demonstrated quarterly |
| Modifiability | "maintainable" | new payment method added by one team in one sprint |
Trade-off
Scenarios are cheap to write and expensive to guarantee. Six well-chosen ones beat forty aspirational ones, because each must ultimately be paid for in redundancy, coordination or engineering time.
Interview question
"Convert 'the system should degrade gracefully' into a quality attribute scenario, then tell me what you would build to satisfy it."