Skip to content

Software Quality

Quality dimensions

There is no single measure of quality, only distinct ways it fails.

Quality is several distinct dimensions rather than one, each needing its own verification. A program can be correct but slow, fast but insecure, secure but impossible to change six months on. The five dimensions developed here are five of ISO/IEC 25010's eight product-quality characteristics (ISO/IEC 2011)1, the ones that carry a distinct verification method — close to the source-measurable set of CISQ (Consortium for Information and Software Quality (CISQ) 2021)2, plus Functionality. (The full mapping against Garvin, McCall, Boehm, FURPS, ISO, and CISQ is on the framework comparison.)

Choosing methods for a system

Picking and ordering the methods for a given part is its own procedure, set out under Choosing methods: rank the part's dimensions, match a method to each failure mode through the axes, then sequence them by contextual cost. The method lists here are that procedure run once, for a typical part that already has continuous integration and a test suite; they illustrate the procedure rather than replace it.

The tools live on the method pages. A dimension's own page carries its failure modes and what success on it looks like.

Functionality

Security

Reliability

Performance

Maintainability

Usability

Mentioned, not developed. Ease of use for the intended user. A separate field with its own literature and tooling verifies it — WCAG audits, axe-core, user-research platforms, A/B experimentation (Statsig, GrowthBook).

Aesthetics

Mentioned, not developed. Fit, finish, perceived quality, trustworthiness signals. No method in this catalog verifies it: the oracle is a human judgment about the product's finish, not a check on its behavior.

Data quality

A parallel vocabulary, not a sixth dimension. When the subject under test is the data itself — data pipelines, analytics, ML feature stores — rather than the program, the governing model is ISO/IEC 25012 (ISO/IEC 2008)3, the data-quality sibling of the ISO/IEC 25010 software model these dimensions rest on. Its concerns include accuracy, completeness, consistency, credibility, and currentness.

Those concerns land inside Functionality, Reliability and Performance rather than beside them: a field carrying a wrong value is a functionality failure, a feed that silently stops is a reliability one, and data arriving too late to act on is a performance one.

Referenced by

References

  1. ISO/IEC. 2011. ISO/IEC 25010:2011: Systems and software engineering — SQuaRE — System and software quality models. International Organization for Standardization. https://www.iso.org/standard/35733.html. ↩

  2. Consortium for Information and Software Quality (CISQ). 2021. Automated Source Code Quality Measures: Reliability, Security, Performance Efficiency, Maintainability (ISO/IEC 5055:2021). https://www.it-cisq.org/standards/code-quality-standards/. ↩

  3. ISO/IEC. 2008. ISO/IEC 25012:2008: Software engineering — SQuaRE — Data quality model. International Organization for Standardization. https://www.iso.org/standard/35736.html. ↩