architecture · advanced
Quality-Attribute Scenarios
Quick answer
A quality-attribute scenario specifies a stimulus, environment, artifact, response, and measure for a non-functional concern (availability, latency, security, modifiability, cost). Staff architects use scenarios so “make it scalable” becomes something you can review, test, and refuse.
Why this matters
- Vague NFRs produce architecture theater.
- Architecture reviews need concrete acceptance criteria.
- Trade-offs only make sense against measured responses.
- Bridges product language (“fast enough”) and engineering SLOs.
Learning objectives
- Write a complete quality-attribute scenario.
- Cover common attributes without boiling the ocean.
- Use scenarios in reviews and ADRs.
- Spot fake measures (“highly available”).
- Prioritize scenarios by risk.
Explain like I am 5
Instead of “be strong,” say: “If a big kid pushes the tower, it can wobble but must not fall for 10 seconds.”
Mental model
flowchart LR
Stimulus --> System
Environment --> System
System --> Response
Response --> Measure
| Part | Example (availability) |
|---|---|
| Source | Load balancer health check |
| Stimulus | Primary region network partition |
| Environment | Peak traffic, degraded mode allowed |
| Artifact | Checkout API |
| Response | Fail over to secondary within 60s |
| Measure | Error rate < 1% during fail over; RTO ≤ 60s |
Core concepts
Attributes are plural
You never optimize one attribute alone. Latency, cost, security, and modifiability compete. Scenarios make the competition explicit.
Stimulus must be realistic
“Server dies” is better than “chaos.” Prefer production-shaped faults: dependency timeout, traffic spike, bad deploy, certificate expiry.
Response + measure
Without a measure, you have a wish. Prefer numeric SLOs, error budgets, or pass/fail checks in a game day.
Prioritize
10 scenarios beat 200 unused ones. Rank by business risk and likelihood.
Feed reviews and tests
Architecture reviews walk scenarios. Chaos/game days exercise them. ADRs cite them as constraints.
Worked example
Modifiability scenario
- Stimulus: Product requires a new payment rail within one quarter.
- Environment: Two squads; shared platform.
- Artifact: Payments domain services.
- Response: New rail adapter without rewriting core ledger.
- Measure: ≤ 2 services touched; no dual-write to legacy for happy path; feature flag for 100% ramp in 2 weeks.
Trade-offs
| Too many scenarios | No scenarios |
|---|---|
| Analysis paralysis | Hand-wavy reviews |
| Clear test plan | Unverifiable claims |
Failure modes
| Mode | Mitigation |
|---|---|
| “Highly scalable” prose | Force a measure |
| Lab-only stimuli | Use production incidents as sources |
| Orphan scenarios | Link to SLOs and reviews |
| Attribute silos | Explicit trade-off tables |
Interview mode
Skeleton: “I express non-functionals as quality-attribute scenarios—stimulus, environment, response, measure—so architecture choices and reviews are testable, not slogans.”
Knowledge check
A realistic stimulus and a measurable response
A single adjective like “scalable”
Only a list of technologies
A full UI mock only
Related
By Shubham Jain