Which scenarios cannot be sorted by the SRE (Golden Signals) model?

Introduce pick-up, shipping partner only changes own orders and second payment provider. They are under “without equivalent” because the model measures the running system.

A department requires that customers can place orders even in the event of provider failure. Which category and which scenario fit in the ISO model?

Reliability (reliability) with the scenario “order acceptance despite provider failure”. Triggers, environment, reaction and measurands sharpen the demand.

Is a single model sufficient as a checklist, or should the team use SRE signals rather than ISO?

A model is sufficient as a memory support, but not as a substitute for scenarios. ISO covers all five, SRE only operating signals. Development goals such as changeability require a broader model or additional scenarios.

Quality attributeChapter I · Requirements · Building block 2 of 6

Quality attributes

A quality requirement specifies how well a function must work, such as how fast, how reliable or how changeable. Often called non-functional requirements (NFR); ISO and arc42 say quality requirements because the term names what they describe rather than what they are not.

By Michael Meierhoff · Meierhoff Systems

Quality modelA catalogue of categories as a checklist.
ScenarioA concrete situation with an expected response.
Measurement variableHow to check the achievement.

Context

Why this is important

Those who describe quality only with words like “fast” or “stable” cannot check it. A quality model helps to forget nothing. Measurable scenarios make removable targets from this, which you can prove in the test or operation.

This building block explains the form of measurable quality scenarios. For specific time and load measures, see Performance.

At a glance · Make quality measurable as a scenario

A quality model provides categories; a scenario describes stimulus and response, and a measure makes it testable.

Shop example · Quality tree

One quality tree, five scenarios of the shop

For the shop, the reaction to a payment request under normal load is described in concrete terms. The numbers are an illustrative learning example.

This is how you read the picture

Quality model The model switch categorizes the same five scenarios into other categories.
Scenario When clicking, a scenario shows the source, trigger, environment, affected part, reaction and metric.
Measurement variable The part “measured variable” of each scenario, e.g. B. 95 Percent within illustrative 800 ms.

The perspective of an international standard: quality as a catalogue of product features, nine features, here used five.

Quality of the shop

Performance Efficiency
Reliability (reliability)
Maintainability (maintenance)
Security (security)
Flexibility (flexibility)

Quality scenario

Payment request is answered quickly

Source: Customer
Triggers: confirms payment for order B-1042
Environment: Normal operation with illustrative 20 Payment requests per second
Part affected: Payment function of the shop
Reaction: delivers authorized, rejected or clarification is ongoing
Measurement variable: 95 Percentage of responses within illustrative 800 ms

Recesses: Performance

Select a quality model and click on a scenario. The scenarios remain the same, only the categories change. Figures are illustrative.

The scenario “Payment request is answered quickly” can be verified: In 20 Questions/requests are 95. percentile at 780 ms, the target of 800 MS is fulfilled. In case of: 30 Requests/s tips it (all numbers illustrative).Check the target in the performance controller

Where it continues

Where the atlas deepens each feature

The Nine Characteristics of ISO/IEC 25010:2023 show which qualities the atlas covers in detail and where it deliberately leaves gaps.

Functional SuitabilityFunctional requirements and their architectural referenceFunctional requirements
Performance EfficiencyResponse time and throughput through load reduction and distributionPerformance Caching Partitioning Backpressure
Compatibility (compatibility)Contracts and versions ensure interaction with other systemsAPI contracts API versioning Anti-Corruption Layer
Interaction capability (interaction capability/usability)Primarily topic of UX and surface design, here not deepenedNot deepened
Reliability (reliability)Detect failures, intercept and restore the systemAvailability Circuit Breaker Recovery SLIs, SLOs & error budgets
Security (security)Boundaries of trust, threats, identity and minimal rightsTrust Boundaries Threat Modeling Authentication & authorisation Least Privilege
Maintainability (maintenance)Low coupling, high cohesion and clear module boundariesModifiability Module boundaries Cohesion Coupling
Flexibility (flexibility)Interchangeability by ports and adapters, scalability by partitioningHexagonal architecture Anti-Corruption Layer Partitioning
Safety (functional safety)Protection of people and the environment; hardly relevant for an online shopNot deepened

Benefits & limitations

Helps if:

A technical choice should be assessed against business-relevant quality criteria.
Product promises and operational monitoring require common measurable criteria.

Boundaries

A general term such as “fast” has no unambiguous measurement point. Define a concrete scenario and link it to the appropriate Architecture driver.
A single target for every function can misdirect effort. Evaluate properties for each process and use specialised goals such as Performance where needed.

In practice

Interview stakeholders using a quality model. Use a model such as ISO 25010 or Q42 as a checklist and ask business, operations and development teams which categories matter to them. This helps cover every perspective.
Prioritise the top 3–5 quality goals. Select and record the few goals that shape the design (arc42 chapter 1.2). They feed into the Architecture drivers.
Build a quality tree with measurable scenarios. Assign concrete scenarios with a metric to each goal (arc42 chapter 10). iSAQB and ATAM call this a Utility Tree. Typical examples are Performance and Availability.
Check scenarios in reviews and tests. Include them in architecture reviews and automated tests to catch deviations early. In production, SLIs, SLOs & Error Budgets help.

Read the detailed explanation

Terms such as availability, performance and modifiability name areas of quality but are not testable on their own. A scenario adds a trigger, operating conditions, the affected function and a measurable response. Architecture drivers prioritise these goals; specialised entries such as Availability make individual properties concrete.

A measurement point, time period and target value connect a quality goal to testing or production operation. Quality goals can compete: immediate joint confirmation can improve consistency while increasing response time. A clear priority shows which property takes precedence in a given process and which consequence the design accepts.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
Which scenarios cannot be sorted by the SRE (Golden Signals) model?
View the solution with justification
Introduce pick-up, shipping partner only changes own orders and second payment provider. They are under “without equivalent” because the model measures the running system.
ApplyingTransferred to a new situation
A department requires that customers can place orders even in the event of provider failure. Which category and which scenario fit in the ISO model?
View the solution with justification
Reliability (reliability) with the scenario “order acceptance despite provider failure”. Triggers, environment, reaction and measurands sharpen the demand.
EvaluateWeighing an alternative
Is a single model sufficient as a checklist, or should the team use SRE signals rather than ISO?
View the solution with justification
A model is sufficient as a memory support, but not as a substitute for scenarios. ISO covers all five, SRE only operating signals. Development goals such as changeability require a broader model or additional scenarios.

Explore further

These building blocks continue the thoughts of this page.

References

Continue on the learning path

Next in Requirements & quality: Constraints.

6 Building blocks

Continue withConstraints