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 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.

What makes an attribute usable is not the name but the specification. Four things have to be stated: what is measured, where and for whom, over what window, and what value counts as acceptable. “Fast” is an adjective. “95 percent of profile lookups complete within 200 milliseconds, measured at the load balancer over each five-minute window” is an attribute with a target — and only the second form can be met, missed, or argued about with evidence. Written that way it is already the shape of an SLO, which is what the target becomes once the system is running.

Two properties make these harder than functional requirements. They interact: raising availability usually costs latency, money, or both, so a list of targets is meaningless without saying which ones give way. Availability and recovery have their own pair of targets, RTO and RPO, which are set from business tolerance rather than from tooling. And they are properties of the whole system rather than of any component, which is why they are decided architecturally and cannot be retrofitted by any single team.

The practical consequence is that a design ought to name the attributes deliberately given lower priority, not only the ones it optimizes. An unstated ranking gets discovered during an incident, when it turns out two teams held different assumptions about which one mattered.

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.