What this heading covers
These are inherent measures. They read the product as built, not as used, and most of them can be collected from the repository, the build and the test suite. Modularity is about the separation of parts. Reusability is about whether an asset can be used in another context. Analysability is about the effort to diagnose a defect or a change. Modifiability is about the effort to change it. Testability is about the effort to test it. The draft gives each its own family because they fail separately: a modular product can be hard to analyse, and an analysable product can be hard to test. The measures are proxies for effort, and the draft does not set target values, so the baseline and the trend carry the meaning.
Record position: characteristic 7 of 9, carrying 5 of the 40 measure families in clause 6.
What the heading asks of a team
Inherent, not behavioural
The evidence is in the code, the dependencies and the test suite. It does not need a user, and it can be collected before release.
Effort is the underlying quantity
Analysability and modifiability are about effort. A structural count is a proxy, and the proxy needs to be validated against real change effort.
Trend beats a single value
Without a target value from the draft, the useful comparison is the product against its own past and against a sibling product.
The common confusion
Maintainability is often reported as code complexity. The five families are about effort: to analyse, to change, to test and to reuse. A structural count is a proxy that has to be validated against that effort.
The measure families in this characteristic
6.8.2Modularity measures6.8.3Reusability measures6.8.4Analysability measures6.8.5Modifiability measures6.8.6Testability measures
What to put in place before publication
- Choose the repository and build data sources for each of the five families, and record their coverage.
- Define the change and defect populations the analysability and modifiability measures use.
- Record a baseline for each measure before any refactoring, so the trend has a starting point.
- Validate at least one structural proxy against observed effort, and record the correlation or its absence.
- Keep the measures out of individual performance review, because they are properties of the product.
The test a reviewer asks
- Does each maintainability measure name its source and its collection window?
- Is at least one proxy compared with observed change effort?
Where teams usually fall short
- A cyclomatic complexity average presented as maintainability, with no link to change effort.
- Measures collected once at the start of a programme and never again, so there is no trend.
What happens next
Analysability, modifiability and testability are the three that a delivery team feels. Modularity and reusability are the two that a platform owner asks about.
Source
ISO Online Browsing Platform, free preview of ISO/IEC DIS 25000-23.2 https://www.iso.org/obp/ui#iso:std:iso-iec:25000:-23:dis:ed-1:v2:en read 22 October 2026
ISO/IEC 25010:2023, Product quality model https://www.iso.org/standard/78176.html read 22 October 2026
ISO/IEC 25023:2016, Measurement of system and software product quality https://www.iso.org/standard/35747.html read 22 October 2026