The quality models: ISO/IEC 25010 and how to use it

What a quality model is for

Section 2.1 argued that quality attributes decide most of an architecture. The obvious next question is: which qualities? Left to themselves, stakeholders mention the two or three that hurt them last, usually speed and uptime, and forget the rest until it is too late. A quality model is a structured list of quality characteristics, each broken into narrower sub-characteristics, with agreed names and definitions. It does two jobs. It gives people a shared vocabulary, so that 'reliability' means the same thing to the product owner, the tester and the supplier. And it acts as a checklist, prompting you to consider qualities that nobody has raised yet.

A model does not tell you which qualities matter for your system or how much of each you need. That comes from stakeholders and business goals (Section 2.8). Nor does it tell you how to achieve them; that is the job of tactics, patterns and the rest of this course. It is a map of the territory, not a route through it.

ISO/IEC 25010:2023: the product quality model

The most widely referenced model is ISO/IEC 25010, part of the SQuaRE family of standards (Systems and software Quality Requirements and Evaluation). The second edition, published in November 2023, defines a product quality model of nine characteristics. It applies to software products and to wider ICT products, and the standard lists its uses: specifying requirements, checking that requirements are complete, setting design and test objectives, defining acceptance criteria and establishing quality measures. Related standards in the family define how to measure each sub-characteristic (ISO/IEC 25023) and how to evaluate a product.

The nine characteristics are functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility and safety. The first describes whether the system does the right things correctly; the other eight describe how well it does them and how well it can be operated, protected and changed. The diagram below shows the structure; the table after it lists every sub-characteristic with an example question an architect might ask.

A few definitions are worth knowing precisely, because they differ from everyday usage. In ISO/IEC 25010, availability is a sub-characteristic of reliability: the degree to which a system is operational and accessible when required. Faultlessness is the degree to which a system performs its functions without fault under normal operation. Capacity, under performance efficiency, is the maximum limit of a parameter, such as concurrent users or transactions per second, that still meets requirements. Scalability sits under flexibility, which reflects a view of scaling as the ability to adapt to changing load rather than a matter of raw speed. Resistance, new under security, is the capability to sustain operations while under attack. Sections 2.4 to 2.7 return to these qualities in depth; Section 2.5 shows how to calculate availability.

What changed from the 2011 edition

The first edition, ISO/IEC 25010:2011, replaced the older ISO/IEC 9126 model and became the standard reference for a decade. Many textbooks, tender documents and templates still use its eight characteristics, so it is worth knowing what moved.

The renamings are more than cosmetic. 'Interaction capability' widens the focus from ease of use to the whole exchange of information between users and the product across different contexts of use, and the new inclusivity sub-characteristic places accessibility for people of different ages and abilities at the centre rather than the edge. 'Flexibility' groups the qualities that let a product cope with change in its environment: new platforms, new installation targets, and more or less load. Adding safety as a product characteristic reflects how much software now controls physical things, from cars to medical devices.

The second structural change is that quality in use, the quality experienced by people using the product in a real context, now lives in its own standard, ISO/IEC 25019:2023. Its three characteristics are beneficialness (usability, accessibility and suitability in use), freedom from risk (economic, health, human life, and environmental and societal risk) and acceptability (experience, trustworthiness and compliance). The split clarifies a useful distinction for architects: product quality is what you build and can test in the product; quality in use is the outcome for real people, which also depends on training, context and how the product is deployed.

Other lists you will meet

ISO/IEC 25010 is not the only taxonomy, and practitioners often use simpler or differently cut lists. FURPS+ grew out of FURPS, a classification developed at Hewlett-Packard and set out by Robert Grady and Deborah Caswell in Software Metrics: Establishing a Company-Wide Program (1987). FURPS groups requirements into functionality, usability, reliability, performance and supportability; the later '+' extension adds constraints: design, implementation, interface and physical constraints and, in some versions, business rules. FURPS+ became popular through the Rational Unified Process and its successors. Its strength is brevity; its weakness is that 'supportability' lumps together maintainability, testability, configurability, installability and localisation.

Bass, Clements and Kazman, in the fourth edition of Software Architecture in Practice (2021), do not try to be exhaustive. They devote a chapter each to the qualities that most often drive architectures: availability, deployability, energy efficiency, integrability, modifiability, performance, safety, security, testability and usability, followed by a chapter on working with other qualities. For each, they give a general scenario and a catalogue of tactics. Their list is organised around design rather than evaluation, which makes it especially useful to architects.

Mark Richards and Neal Ford, in Fundamentals of Software Architecture, use the term architecture characteristics and sort them into groups such as operational (availability, performance, scalability), structural (modifiability, extensibility, portability) and cross-cutting (security, accessibility, legal) groups. Gernot Starke's open Q42 model, maintained alongside the arc42 template, takes yet another approach: it tags well over a hundred named qualities with nine dimensions (efficient, flexible, maintainable, operable, reliable, safe, secure, suitable, usable) and provides example requirements for each.

These lists disagree in detail but overlap heavily. The disagreement is itself instructive: there is no single correct decomposition of 'quality', only more or less useful ones for a purpose. Using a standard model helps when you need to communicate with procurement, auditors or other organisations; a lighter list may serve a product team better day to day.

Using a model as a checklist without creating bureaucracy

The great risk of a quality model is that it becomes a form. A requirements template with a heading for each of the 40 sub-characteristics invites people to fill every box, and the result is a document full of statements such as 'the system shall be maintainable' that nobody reads and nobody tests. Effort spreads evenly across qualities that matter very unevenly, and the two or three qualities that will really decide the architecture are lost among the rest.

A better approach treats the model as a prompt for a conversation. Walk through the characteristics with stakeholders once, quickly, asking for each: does this matter for our system, and if so, what would failure look like? Discard the irrelevant ones explicitly (writing 'safety: not applicable, the app cannot cause physical harm' is useful, because it records a decision). Turn the relevant ones into a small number of concrete, measurable scenarios (Section 2.3). Rank them (Section 2.8). Then put the model away until the next review.