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. Every software quality model rests on that premise, from Garvin's original framing (Garvin 1987)1 onward. The five dimensions developed here are five of ISO/IEC 25010's eight product-quality characteristics (ISO/IEC 2011)2, the ones that carry a distinct verification method — close to the source-measurable set of CISQ (Consortium for Information and Software Quality (CISQ) 2021)3, 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 ordered list and success picture on each dimension page 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.

Each dimension here names what it means and the methods that verify it; the tools live on the method pages. The dimension's own page carries its failure modes, erosion signals, and methods in order of adoption.

Functionality

Security

Reliability

Performance

Maintainability

Usability

Mentioned, not developed. Ease of use for the intended user. A separate field with mature literature and tooling — 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)4, the data-quality sibling of the ISO/IEC 25010 software model these dimensions rest on. Its concerns are accuracy, completeness, consistency, timeliness, and schema or distribution drift over time.

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. Garvin, David A. 1987. "Competing on the Eight Dimensions of Quality." Harvard Business Review 65 (6): 101–9. https://hbr.org/1987/11/competing-on-the-eight-dimensions-of-quality. ↩

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

  3. 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/. ↩

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