Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO/IEC 25051:2014 SQuaRE — Requirements for Quality of Ready-to-Use Software Products (RUSP)
A complete guide to quality requirements, testing documentation, and conformity evaluation for COTS and packaged software
1. Scope and Importance of ISO/IEC 25051
ISO/IEC 25051 is a critical standard within the SQuaRE series that addresses the unique challenges of evaluating Ready-to-Use Software Products (RUSP) — software packages that are sold or distributed to acquirers who have had no influence on their features or development. This includes everything from commercial off-the-shelf (COTS) software and mobile applications to cloud-based software services where the user simply downloads or accesses the product without involvement in its creation.
For product managers and quality assurance teams at software vendors, ISO/IEC 25051 is the definitive reference for what must be included in product descriptions, user documentation, and test documentation. It defines the minimum requirements for claiming quality transparency — and provides a framework for certification bodies to verify those claims.
The standard is structured around three major requirement areas:
- Requirements for Product Description — What must be stated about the software to enable informed purchasing decisions
- Requirements for User Documentation — What must be documented to enable effective use of the software
- Quality Requirements for Software — What quality characteristics the software itself must demonstrate
Additionally, the standard specifies requirements for test documentation (test plan, test description, test results) and provides instructions for conformity evaluation.
2. Key Requirements Breakdown
2.1 Product Description Requirements
The product description serves as the primary communication channel between the supplier and potential acquirers. ISO/IEC 25051 mandates that the product description must cover quality characteristics across multiple dimensions derived from ISO/IEC 25010 quality model:
| Quality Dimension | Key Requirements | Practical Examples |
|---|---|---|
| Functional Suitability | List all end-user callable functions; describe functions where critical defects may occur; state known limitations | “Supports up to 10,000 records per database”; “Automatic backup every 15 minutes” |
| Performance Efficiency | State time behavior, resource utilization, and capacity characteristics | “Minimum 4 GB RAM required”; “Supports 500 concurrent users” |
| Compatibility | Specify co-existence and interoperability with other software/hardware | “Compatible with Windows Server 2019, Red Hat Enterprise Linux 8” |
| Usability | Describe UI type, required knowledge, user error protection, and accessibility | “Web-based GUI with screen reader support”; “Requires SQL knowledge” |
| Reliability | State maturity, availability, fault tolerance, and recoverability | “99.9% uptime SLA”; “Automatic failover with less than 30 second RTO” |
| Security | Describe confidentiality, integrity, non-repudiation, accountability, authenticity | “AES-256 encryption at rest”; “RBAC with audit logging” |
| Maintainability | Describe maintenance services, monitoring capabilities, and user adaptation tools | “Quarterly patch releases”; “REST API for monitoring” |
| Portability | Specify supported platforms, installation procedure, and configuration options | “Supports Windows, macOS, and Linux”; “Silent installation available” |
Engineering insight: The most commonly overlooked requirement is 5.1.5.3 — describing all functions where the user may encounter critical defects. Software vendors often omit this because it feels like admitting weakness. However, transparently documenting known limitations actually increases trust and reduces support burden. For example, clearly stating that “the search function does not support Unicode characters in version 2.1” prevents countless support tickets.
2.2 User Documentation Requirements
The standard requires user documentation to be complete, correct, consistent, and understandable. It must cover all functions stated in the product description, provide guidance for backup and restoration, list errors that cause termination or data loss, and describe all application administration functions. Importantly, the documentation must be understandable by the end user population for which the RUSP is primarily targeted — a requirement that forces suppliers to think carefully about their audience.
2.3 Software Quality Requirements
Beyond documentation, the software itself must meet functional, performance, compatibility, usability, reliability, security, maintainability, and portability requirements. Key engineering-relevant requirements include: the software shall not lose data when used within stated limitations (5.3.5.3); the software shall have the ability to recover from a fatal error transparently (5.3.5.5); the software shall prevent unauthorized access to programs and data (5.3.6.2); and the software shall provide a means for the user to uninstall all installed components (5.3.8.3).
3. Test Documentation and Conformity Evaluation
Clause 6 of the standard specifies comprehensive requirements for test documentation. The test documentation must include a test plan (scope, pass/fail criteria, environment, schedule, risks, resources), a test description (test cases with objectives, inputs, procedures, and expected results), and test results (execution reports and anomaly reports).
Clause 7 provides instructions for conformity evaluation, which can be performed by an independent testing laboratory or an in-house laboratory independent from the supplier. The evaluation covers product description, user documentation, and software — with the option for the supplier to provide pre-existing test documentation to streamline the process.
A critical distinction: the standard explicitly states that open source software is not part of RUSP (Note 2 in Clause 1). This means that while open source software may be of high quality, ISO/IEC 25051 certification is designed for commercial/packaged software where the supplier controls the entire product definition and release process.
For suppliers preparing for ISO/IEC 25051 conformity evaluation, the single most effective preparation step is to create a traceability matrix mapping every requirement in Clause 5 to specific sections of the product description, user documentation, and test cases. This matrix serves as the backbone of the conformity evaluation and dramatically reduces assessment time.
4. Frequently Asked Questions
Q1: How does ISO/IEC 25051 relate to the older ISO/IEC 12119?
ISO/IEC 25051 replaced ISO/IEC 12119:1994 and expanded its scope. While 12119 focused primarily on testing instructions for software packages, 25051 covers the complete RUSP lifecycle including product description, user documentation, and conformity evaluation processes aligned with the SQuaRE quality model.
ISO/IEC 25051 replaced ISO/IEC 12119:1994 and expanded its scope. While 12119 focused primarily on testing instructions for software packages, 25051 covers the complete RUSP lifecycle including product description, user documentation, and conformity evaluation processes aligned with the SQuaRE quality model.
Q2: Can a SaaS product be certified under ISO/IEC 25051?
Yes. The standard explicitly states: “A software product, which a user can use anytime through Cloud Computing may be considered as RUSP.” The key criterion is that the acquirer has no influence on the product’s features.
Yes. The standard explicitly states: “A software product, which a user can use anytime through Cloud Computing may be considered as RUSP.” The key criterion is that the acquirer has no influence on the product’s features.
Q3: What if a requirement in Clause 5.3 is not applicable?
The standard allows this — Clause 6.1.4.13 requires that if any quality requirement is not applicable, the reason must be stated in the test documentation. For example, a simple calculator app may not have extensive security requirements.
The standard allows this — Clause 6.1.4.13 requires that if any quality requirement is not applicable, the reason must be stated in the test documentation. For example, a simple calculator app may not have extensive security requirements.
Q4: Does conformity to ISO/IEC 25051 guarantee software is free from defects?
No. Conformity demonstrates that the product description, user documentation, and software meet the defined requirements, and that testing has been conducted according to specified standards. It does not guarantee zero defects, but it does ensure transparency about known limitations and systematic testing coverage.
No. Conformity demonstrates that the product description, user documentation, and software meet the defined requirements, and that testing has been conducted according to specified standards. It does not guarantee zero defects, but it does ensure transparency about known limitations and systematic testing coverage.
