“The system must be fast, secure and easy to change” sounds useful but does not yet guide a design or a test. A quality-attribute scenario turns an adjective into observable behaviour by naming the source, stimulus, environment, affected artefact, expected response and a measurable response threshold.

Six parts of a useful scenario

  1. Source: who or what causes the situation — a user, operator, external system or failure.
  2. Stimulus: the specific event, such as a traffic increase, dependency failure or rule change.
  3. Environment: the conditions — normal operation, peak load, deployment or disaster recovery.
  4. Artefact: the part of the system affected.
  5. Response: what the system does after the stimulus.
  6. Response measure: the threshold that makes success testable.
Fictional modifiability example: when a team changes the name and allowed values of a field used by two application versions during a normal release, the system supports a compatible transition and code rollback without losing writes; no outage is required and data discrepancies remain at zero for an agreed observation window.

Why is a quality label insufficient?

Two people can interpret “high availability” differently. One may mean an individual API is reachable; another may mean the customer completes an end-to-end journey. A scenario exposes that difference before a technology is chosen. It also reveals trade-offs: faster change may require temporary support for two contracts, while lower cost may limit redundancy.

ISO/IEC 25010:2023 provides a product quality model, but a catalogue of characteristics does not replace system-specific requirements. Software Engineering Institute material uses scenarios in Quality Attribute Workshops so stakeholders can generate and prioritise situations involving a stimulus, environment and response.

How does a scenario support a decision?

  1. Start with an event that matters to a stakeholder, not with a product or pattern.
  2. State the environment and measure. “95% below 300 ms at 500 requests per second” is a different problem from the same latency without a load condition.
  3. Compare options by response and cost. Record in the ADR which scenarios the decision supports and which trade-offs remain.
  4. Turn the measure into a test, production observation or failure exercise. If the result cannot be checked, the scenario remains too vague.
Illustrative ADR excerpt: Context: a rolling release leaves two application versions running together. Quality scenario: after a schema change, both versions serve traffic correctly and code rollback loses no data. Decision: use expand–migrate–contract stages. Verification: mixed-version test, missing-value checks and a rollback rehearsal before the old field is removed.

Project question: which three situations — peak load, dependency failure, contract change, security incident or recovery — truly shape your architecture, and what measure will decide success?

Sources: Software Engineering Institute — Quality Attribute Workshop Collection; ISO/IEC 25010:2023 — Product quality model. The system details, values and ADR are original fictional examples.