Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 25021: Quality Measure Elements for Software Quality
Systems and Software Engineering — SQuaRE Quality Measurement Division — Defining the Building Blocks of Quality Measurement
1. Introduction to Quality Measure Elements (QMEs)
ISO/IEC 25021 is a foundational standard within the SQuaRE (Systems and Software Quality Requirements and Evaluation) series, specifically belonging to the ISO/IEC 2502n Quality Measurement Division. Its core purpose is to define the concept of Quality Measure Elements (QMEs) and provide a rigorous framework for specifying them. A QME is defined as a measure expressed in terms of a property of a target entity and the measurement method used to quantify it, optionally including a mathematical transformation. In essence, QMEs are the atomic building blocks from which all higher-level quality measures (QMs) are constructed.
A single quality measure (QM), such as “defect density,” is typically composed of two or more QMEs. For example, defect density = (Number of defects) / (Size of software). Each of these components is itself a QME that can be reused across multiple different quality measures.
The standard replaces the earlier ISO/IEC TR 25021:2007 technical report and serves as the critical link between the legacy ISO/IEC 9126 series and the modern SQuaRE framework. By standardizing QMEs, ISO/IEC 25021 ensures that quality measurements are consistent, repeatable, and comparable across different projects, organizations, and domains. This is particularly valuable in regulated industries such as medical devices, automotive safety (ISO 26262), and avionics (DO-178C), where traceable and defensible quality metrics are mandatory.
2. The QME Specification Framework
The standard defines a comprehensive table format for specifying QMEs, organized into 14 information items grouped into four logical categories. This structured approach ensures that every QME is fully documented and unambiguous.
2.1 QME Identification and Scope
The first group covers QME identification: a unique name (typically beginning with “Number of…”), the target entity (the object being measured, such as source code, a design document, or system behavior), and the objectives and property to quantify. For example, the QME “Number of faults (of code)” targets program source code and quantifies the property “fault.”
2.2 Measurement Method Specification
The second and most substantial group defines how the QME is measured. It includes the measurement method (how data is collected and transformed), a list of sub-properties if applicable, input sources, the unit of measurement, numerical assignment rules, and the scale type (nominal, ordinal, interval, or ratio). The standard mandates that numerical rules be described from both a practitioner’s perspective (textual) and a theoretical perspective (mathematical), ensuring both practical usability and formal rigor.
| Information Item | Description | Example (Fault Count) |
|---|---|---|
| QME Name | Unique identifier for the QME | Number of faults (of code) |
| Target Entity | Object being characterized | Program source code |
| Property to Quantify | Specific attribute being measured | Fault — an incorrect step, process, or data definition |
| Measurement Method | How data is collected and valued | Code review, difference analysis of revised source |
| Unit of Measurement | Scale unit for the result | Lines of code |
| Scale Type | Mathematical scale category | Ratio |
| Life Cycle Process | When measurement applies | Software Construction, Implementation |
2.3 Application Management
The final group addresses practical management: the context of QME use (which quality characteristics it supports), the appropriate software life cycle processes, and any measurement constraints. For instance, the number of code faults may vary significantly depending on whether code is newly developed or reused, and the investigation method (review vs. inspection vs. automated analysis) will yield different results. Documenting these constraints is essential for proper interpretation.
Measurement constraints must be explicitly documented. For example, fault counts will differ between newly developed code and reused code, and between different investigation methods (review, walk-through, inspection, automated tools). Without this context, comparisons across projects are meaningless.
3. Engineering Design Insights and Practical Application
For engineering teams implementing ISO/IEC 25021, several practical insights emerge from the standard’s framework.
3.1 Reusability and Consistency
The same QME can be used by multiple quality measures across different quality characteristics. For example, “Number of faults” serves as a component in reliability measures (fault density), maturity measures (fault detection rate), and maintenance measures (fault removal rate). This reuse ensures consistency: when a single QME definition is standardized across an organization, all derived quality measures inherit that consistency. A practical recommendation is to establish an organizational QME repository, similar to a code library, where approved and validated QMEs are cataloged for reuse across projects.
3.2 Linking Measurement to Lifecycle
Each QME should be explicitly mapped to the software life cycle process(es) where actual measurement occurs. This prevents the common pitfall of specifying metrics that cannot be collected at the intended phase. For instance, the QME “Number of faults in code” is actually measurable during construction (coding and unit testing) via code review or unit testing, but can only be estimated during requirements analysis. This lifecycle-awareness is critical for planning measurement programs and resource allocation.
3.3 Scale Type Awareness
The standard categorizes scale types into nominal, ordinal, interval, and ratio. This is not a theoretical nicety but has practical consequences: ratio scales (e.g., lines of code, defect counts) permit multiplication and division, enabling meaningful derived measures like density or rate. Ordinal scales (e.g., severity ratings: critical, major, minor) only permit ranking and comparison. Engineers must select the appropriate scale type for each QME and respect its mathematical properties when computing derived quality measures. A common mistake is treating ordinal satisfaction ratings (e.g., Likert scales) as interval data and computing means, which can lead to misleading conclusions.
Establishing an organizational QME repository — analogous to a software component library — enables consistent, reusable quality measurement across all projects. Each QME is defined once, validated, and then referenced by multiple quality measures.
4. Frequently Asked Questions
Q: What is the difference between a QME and a QM (Quality Measure)?
A: A QME is a fundamental measure quantifying a single property (e.g., “Number of failures”). A QM is a derived measure that combines two or more QMEs through a measurement function (e.g., “Mean Time Between Failures” = Operating time / Number of failures). Every QM is built from at least two QMEs.
A: A QME is a fundamental measure quantifying a single property (e.g., “Number of failures”). A QM is a derived measure that combines two or more QMEs through a measurement function (e.g., “Mean Time Between Failures” = Operating time / Number of failures). Every QM is built from at least two QMEs.
Q: Can the same QME be used for both internal and external quality measures?
A: Yes. The same QME, such as “Number of faults,” can be applied in internal measures (static code analysis during development) and external measures (failures observed during testing or operation). The key difference lies in the target entity and measurement method, which must be documented accordingly.
A: Yes. The same QME, such as “Number of faults,” can be applied in internal measures (static code analysis during development) and external measures (failures observed during testing or operation). The key difference lies in the target entity and measurement method, which must be documented accordingly.
Q: How does ISO/IEC 25021 relate to ISO/IEC 25023?
A: ISO/IEC 25021 defines the QME building blocks, while ISO/IEC 25023 uses those QMEs to construct specific product quality measures for each characteristic in the quality model (e.g., reliability, usability, performance efficiency). The QMEs from 25021 are the inputs to the measurement functions defined in 25023.
A: ISO/IEC 25021 defines the QME building blocks, while ISO/IEC 25023 uses those QMEs to construct specific product quality measures for each characteristic in the quality model (e.g., reliability, usability, performance efficiency). The QMEs from 25021 are the inputs to the measurement functions defined in 25023.
Q: Is ISO/IEC 25021 applicable to Agile development?
A: Absolutely. The QME framework is lifecycle-agnostic. In Agile environments, QMEs can be applied to user stories (functional size), sprint backlogs (defect counts), and continuous integration pipelines (code quality metrics). The key is to map each QME to the appropriate Agile ceremony or artifact where measurement occurs.
A: Absolutely. The QME framework is lifecycle-agnostic. In Agile environments, QMEs can be applied to user stories (functional size), sprint backlogs (defect counts), and continuous integration pipelines (code quality metrics). The key is to map each QME to the appropriate Agile ceremony or artifact where measurement occurs.
