Software and systems product quality

A useful quality claim tells a reader which product, users and conditions it concerns. A laboratory application, industrial controller and consumer service can need very different evidence even where all contain software. ISO/IEC 25010 provides a product quality model for ICT and software products. The model helps structure requirements and evaluation; it does not give every product a universal score or pass threshold. The technical task is to turn relevant quality properties into measures and decisions appropriate to the product’s intended use.

The licensed ISO Open Data scope describes the model as a reference for specifying, measuring and evaluating product quality throughout the lifecycle. Its product context can include software, firmware, hardware, data and communications elements of an ICT product. This is broader than a list of coding defects. The same scope identifies uses in requirements, design objectives, testing, quality control and acceptance. Those uses still require the organization to identify what will be measured and why the result supports the decision.

Selected records: ISO/IEC 25010:2023 (edition 2, publication record 2023-11-15). The selected 2023 edition defines a product quality model with nine characteristics. It should not be described using an unchanged account of the earlier edition or treated as the entire set of quality-in-use references. Related measurement and evaluation documents have their own designations. A quality plan needs the selected model version and the actual measures used to make decisions. The records were checked on 19 October 2026 in ISO Open Data.

For a business application, a requirements team can connect an important user task to a defined operating scenario and acceptance measure. A test then identifies the release, configuration, data and environment used to evaluate that requirement. A change in scale, network conditions or supported devices can change the evidence needed. The model helps check the breadth of the quality discussion, while the project’s requirements and risks determine the particular evaluation programme. The record should preserve that link instead of reporting only a composite quality percentage.

NIST SSDF Version 1.1 provides secure development recommendations aimed at reducing software vulnerabilities. It addresses a connected but narrower question than a complete product quality evaluation. Use of a development framework is not evidence that every delivered feature meets performance or usability needs. Sector regulation and procurement contracts may add specific software obligations; those sources require separate review. ISO/IEC 25010 is not, by itself, a government authorization route or a universal certification scheme for software products.

Is the evaluated product version fixed and reproducible? Can each acceptance decision be traced to a stated requirement, selected measure and representative operating scenario? Are workload, data, dependencies and test limitations recorded? A model-based assessment also needs to explain omitted quality concerns and the reason they do not apply. Where users rely on a service rather than a packaged release, the operating configuration and ongoing measurements matter. A catalogue of model characteristics is only the beginning of an evaluation, not its result.

The finding is that a quality model improves the structure of a technical question without answering it automatically. A product can perform well under one workload and poorly under another, or satisfy a development-process control while missing an essential user need. This reference does not calculate a quality rating, endorse a scoring formula or assert that all model characteristics carry the same weight. A defensible conclusion requires a defined context, appropriate measures and evidence that the selected evaluation actually represents the claim being made.

Information security management concerns organizational controls; AI management systems addresses governance where AI is provided or used. Test evidence assessment helps connect a quality assertion to the product version, scenario and measured outcome. The distinctions matter when an evaluation report combines an organizational certificate, development-process evidence and product test results under a single broad claim about software quality.

Official sources and selected bibliographic facts were checked on 19 October 2026. The model’s bibliographic identity and public scope come from licensed ISO Open Data. This page does not reproduce its taxonomy or reconstruct protected standard text. NIST is cited for a separate development-security subject. ISO metadata is attributed to the iso_deliverables_metadata dataset under ODC-By 1.0. The explanation and examples are original NCQM analysis. Send a correction request identifying the reference, statement and supporting official evidence.