Quality scenario
A quality scenario turns a general quality wish into a checkable design and measurement question.
- StimulusWho or what triggers the situation?
- ConditionWhat load or environment applies?
- MeasureWhich value establishes the response?
Context
Why this is important
Express quality requirements as concrete situations with measurable responses.
A structured requirement artifact for design, review and later measurement.
From quality wish to checkable scenario
For product queries, the team sets a measurable latency target under a stated catalog load.
This is how you read the picture
- Stimulus Request
- Condition Load
- Measure Latency
| Aspect | Meaning | Validation |
|---|---|---|
| Target statement | Stimulus and context. | Expected response. |
| Proof | Define load profile. | Collect measurement window. |
Benefits & limitations
Helps if:
- Measurable response targets are needed for design or review.
- Stakeholders use vague quality terms with different expectations.
Boundaries
- A target without representative load and measurement point is not reliable.
- A scenario describes a quality goal; it is not a guarantee or measurement of current behavior.
In practice
- Choose a concrete use case and name its stimulus, source and operating condition. Separate the observable stimulus from its internal cause.
- State the expected system response and choose a measurable value with target and measurement window. Add measurement point, time window and representative load profile.
- Check with domain and operations experts that load, failure mode and target are realistic and define how evidence will be collected.
Read the detailed explanation
A structured scenario names source and stimulus, system environment, affected element, expected response and a measure with a target. Scenarios need not use identical wording, but assumptions and measurement conditions must be clear.
Scenarios help prioritise quality goals and analyse architecture decisions. A target must fit the use case and needs a measurement plan; the statement alone does not prove the system achieves it.
A Quality Tree organises several scenarios; the quality overview explains shared trade-offs.
The Quality Attributes page places trade-offs in context.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
Which measure does the shop example use?
View the solution with justification
Share of requests below the latency threshold.
ApplyingTransferred to a new situation
How can “fast” be made more precise for product queries?
View the solution with justification
With load condition, latency measure, target and window.
EvaluateWeighing an alternative
What does a target prove without a load profile?
View the solution with justification
Too little to test the requirement realistically.
Explore further
These building blocks continue the thoughts of this page.
References
- CMU SEI · Quality Attributes (opens in new tab)Research report on quality attributes and architecture decisions.
- CMU SEI · Scenario-Based Analysis of Software Architecture (opens in new tab)Describes scenarios for architecture evaluation.
- arc42 · Quality Requirements (opens in new tab)Practical guidance for quality scenarios and requirements.