Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 25030:2019 — SQuaRE — Quality Requirements Framework
Framework for defining, using, and governing quality requirements for systems, software products, and data
1. The Quality Requirements Framework Defined by ISO/IEC 25030
ISO/IEC 25030:2019 provides the definitive framework for defining, using, and governing quality requirements for systems, software products, and data within the SQuaRE series. This second edition significantly expands on the 2007 original, extending its scope from software to complete ICT systems, including data and IT services. The standard addresses a fundamental engineering challenge: quality requirements are often vague, subjective, and unverifiable, leading to systems that fail to meet stakeholder expectations despite conforming to their written specifications.
The standard categorizes quality requirements into three distinct types: Quality in Use Requirements (QIURs), which specify required quality levels from the stakeholders’ perspective during actual use; Product Quality Requirements (PQRs), which define quality levels required from the ICT product viewpoint; and Data Quality Requirements (DQRs), specifying quality levels for data associated with the product. This three-tier structure ensures comprehensive coverage from user experience through technical implementation.
When beginning a new project, start with QIURs before defining PQRs and DQRs. Understanding how users will interact with the system in their specific context of use provides a solid foundation for deriving meaningful technical quality requirements.
| Quality Requirement Type | Target Entity | Quality Model Source | Quality Measure Source | Primary Users |
|---|---|---|---|---|
| QIUR | Information system (including users and environment) | ISO/IEC 25019 (Quality-in-use model) | ISO/IEC 25022 | Primary users, Secondary users |
| PQR | ICT product (software, hardware, communication facilities) | ISO/IEC 25010 (Product quality model) | ISO/IEC 25023 | Developers, Testers, Acquirers |
| DQR | Data within the ICT product | ISO/IEC 25012 (Data quality model) | ISO/IEC 25024 | Data owners, Data managers |
2. The Seven-Step Process for Defining Verifiable Quality Requirements
ISO/IEC 25030 defines a rigorous seven-step process for quality requirements definition, aligned with the stakeholder needs and requirements definition processes of ISO/IEC/IEEE 15288. The steps progress from defining target entities through selecting quality characteristics, stating requirements, prioritizing, specifying with measurable criteria, analyzing for conflicts, and managing requirements throughout the lifecycle.
Step 5 is particularly critical: specifying quality requirements using quality measures and their required criteria. Each requirement must include a target entity, selected characteristic, quality goal with conditions, quality measure, target value, and acceptable range of values. This transforms vague statements like “the system should be fast” into verifiable specifications such as “the login function (target entity) shall have a response time (quality measure) of less than 2 seconds (target value) under normal load conditions (condition).”
The most common failure in quality requirements engineering is skipping Step 6 (analysis). Quality requirements inevitably conflict — security versus usability, performance versus maintainability. Explicit trade-off analysis using the inter-relationship matrices provided in Annex G is essential for finding the right balance.
The standard provides comprehensive guidance on deriving quality requirements from higher-level needs through iterative and recursive processes. For large-scale systems, QIURs at the information system level are decomposed into PQRs for constituent ICT products, which in turn decompose into technical PQRs for individual software components and DQRs for associated data. Traceability must be maintained bidirectionally throughout this decomposition hierarchy.
3. Engineering Insights for Quality Requirements Governance
Successful implementation of ISO/IEC 25030 requires organizational commitment beyond mere documentation. The standard identifies critical success factors including stakeholder identification and involvement, risk-based prioritization of quality requirements, and continuous traceability maintenance throughout the product lifecycle. Quality requirements are inherently more stable than functional requirements, but they can change — security requirements need updating when new functionality is added, and interoperability requirements must be reconsidered when the environment changes.
Organizations that adopt the ISO/IEC 25030 framework report significantly reduced rework costs. By catching quality requirement gaps and conflicts during the requirements phase rather than during testing, the cost of defect correction is reduced by orders of magnitude.
The standard’s approach to quality requirements trade-offs (Clause 6.5.5) provides a systematic method for resolving conflicts between competing quality characteristics. For instance, Annex G provides an inter-relationship matrix showing that security often negatively impacts usability and performance efficiency, while maintainability can positively influence reliability through improved testability. Engineers can use these relationships to make informed design decisions and negotiate stakeholder priorities.
For organizations implementing agile methodologies, ISO/IEC 25030 quality requirements can be integrated into user stories as acceptance criteria. Each quality characteristic (security, performance, usability) becomes a “definition of done” condition that must be verified before story completion. This embeds quality thinking into the development workflow rather than treating it as a separate phase.
Q1: How does ISO/IEC 25030 differ from ISO/IEC 25030:2007?
A: The 2019 edition extends from software to complete ICT systems, adds an explicit seven-step process for quality requirements definition, clarifies the derivation of PQRs/DQRs from QIURs, and provides extensive new annexes with practical examples including trade-off analysis and traceability.
A: The 2019 edition extends from software to complete ICT systems, adds an explicit seven-step process for quality requirements definition, clarifies the derivation of PQRs/DQRs from QIURs, and provides extensive new annexes with practical examples including trade-off analysis and traceability.
Q2: Can ISO/IEC 25030 be used with agile development?
A: Yes. Quality requirements should be defined as acceptance criteria within user stories. The seven-step process can be applied at the release level with refinement at each sprint, maintaining traceability through the product backlog.
A: Yes. Quality requirements should be defined as acceptance criteria within user stories. The seven-step process can be applied at the release level with refinement at each sprint, maintaining traceability through the product backlog.
Q3: What is the relationship between ISO/IEC 25030 and ISO/IEC/IEEE 15288?
A: ISO/IEC 25030 is fully aligned with the stakeholder needs and requirements definition processes and system requirements definition processes of ISO/IEC/IEEE 15288, providing the quality-specific elaboration of these generic requirements processes.
A: ISO/IEC 25030 is fully aligned with the stakeholder needs and requirements definition processes and system requirements definition processes of ISO/IEC/IEEE 15288, providing the quality-specific elaboration of these generic requirements processes.
Q4: How do I handle trade-offs between conflicting quality requirements?
A: Use the inter-relationship matrix (Annex G) to identify potential conflicts, prioritize requirements based on stakeholder importance and risk, and negotiate acceptable target values that balance competing concerns.
A: Use the inter-relationship matrix (Annex G) to identify potential conflicts, prioritize requirements based on stakeholder importance and risk, and negotiate acceptable target values that balance competing concerns.
