Quality Attribute

A quality attribute describes how well a system does what it does, as distinct from what it does. Latency, availability, scalability, security, and modifiability are quality attributes; placing an order is a function. The distinction is the same one that separates functional from quality requirements when they are written down.

The term is standard vocabulary in architecture practice, and ISO/IEC 25010:2023 provides a formal product quality model organized into characteristics and sub-characteristics, intended for specifying, measuring, and evaluating requirements. The value of having a defined set is mostly that it stops teams from inventing a private vocabulary for the same handful of concerns.

A quality requirement needs a way to judge whether it is met. For operational latency, specify the eligible requests, workload, measurement boundary, threshold, and time window. For example, at the agreed request rate, at least 95 percent of profile lookups must complete within 200 milliseconds at the load balancer in each five-minute window. That can be an SLO. Other quality requirements need different evidence: a portability requirement may be checked by transferring a representative workload, while a changeability requirement may limit which components must change for a specified extension. Starting production does not automatically turn those requirements into service-level objectives.

Quality attributes interact, but the trade-off depends on the design. Waiting for another replica before acknowledging a write may improve its durability while increasing latency; removing unnecessary work may improve several attributes together. Recovery has two distinct objectives, RTO and RPO, for recovery time and recoverable data position. Availability has a separate measure of service success over time or requests. Set these targets from business tolerance and verify each independently.

Components also have quality properties. One team can reduce a service’s query time or improve its recovery procedure; whether that meets the end-to-end target depends on the remaining dependencies and workload. Evaluate local improvements at the required system boundary. Where targets conflict, record the minimum acceptable conditions and the priorities used to choose between feasible designs, so teams do not discover incompatible assumptions during an incident.

How each attribute is measured for data and platform systems, and which pairs genuinely trade against each other, is set out in Quality Attributes and Trade-offs.

References:

• ISO/IEC 25010:2023, Product quality model (public overview)
• Google SRE, Service Level Objectives