ISO/IEC 25010:2023: ISO/IEC 25010:2023 – Tutorial (about 60 minutes)

ISO/IEC 25010:2023 is the international product quality model for software and other ICT (information and communication technology) products. It gives teams a shared checklist of nine quality characteristics, each broken into subcharacteristics, so that "quality" stops being a vague wish and becomes something that can be specified, designed for, tested and evaluated. Product owners, architects, testers, acquirers, auditors and safety and security engineers use it to write better quality requirements and acceptance criteria. After this tutorial you will be able to name and explain all nine characteristics, turn them into measurable requirements for a real product, and explain how the model fits with the rest of the SQuaRE family and with other standards.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is ISO/IEC 25010:2023, the second edition, published in November 2023 by ISO and IEC through Joint Technical Committee ISO/IEC JTC 1, Subcommittee SC 7 (Software and systems engineering). Its full title is "Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – Product quality model". Together with the first editions of ISO/IEC 25002 (quality models overview and usage) and ISO/IEC 25019 (quality-in-use model), it cancels and replaces ISO/IEC 25010:2011. The 2023 edition is published and current; no replacement edition had been announced when this course was checked. Like every ISO and IEC standard it is subject to periodic systematic review, so watch the ISO catalogue entry for its status. The name in the course title, "ISO/IEC 25010:2023", is therefore the edition taught here. Verified 2026-10-29 against the ISO catalogue listing and the official preview of the standard (title page, foreword, scope and table of contents), which shows the second edition dated 2023-11.

A note on copyright: the standard is a paid, copyrighted document. This tutorial explains it in its own words, using only the widely published characteristic names; buy the standard if you need its exact wording for a contract or audit.

Who it is for: software and systems engineers, architects, testers and test managers, product owners and business analysts, quality assurance staff, procurement and vendor managers, security and safety engineers, and anyone who must write, review or accept "non-functional" requirements. No earlier contact with ISO standards is assumed.

Prerequisites: none. A basic idea of how software is specified, built and tested will help you link the examples to your own work.

Learning objectives. After this course you will be able to:

Explain why a product quality model is useful and what ISO/IEC 25010:2023 covers and does not cover.
Name the nine product quality characteristics and describe their subcharacteristics in plain words.
Describe what changed from the 2011 edition, including the new safety characteristic and the renamed characteristics.
Distinguish product quality from quality in use and explain how the two models relate.
Turn the model into prioritised, measurable quality requirements, verification activities and acceptance criteria for a real product.
Explain how products are evaluated against the model and why there is no management-system style certificate for ISO/IEC 25010 itself.
Relate the model to neighbouring standards such as ISO/IEC 25019, 25012, 25030, 25040, ISO/IEC/IEEE 29119 and ISO 9001.

Lesson 1 – Origins, purpose and scope

Why a quality model is needed

Ask five people what makes software "good" and you will get five answers. A user talks about how easy it is to use, an operations engineer about uptime, a security officer about data protection, a developer about clean code, and a finance manager about running costs. All of them are right, and that is exactly the problem: if nobody writes these expectations down in a common language, some of them will be forgotten until the product is in production.

A quality model solves this by giving everyone the same map of what quality can mean. It breaks the broad idea of quality into named characteristics and smaller subcharacteristics. During requirements work, the team walks through the map and asks which parts matter for this product and how much. During design and testing, the same map tells them what to build in and what to check. During acceptance, it tells the buyer what to evaluate. Because it is an international standard, suppliers and customers in different countries share the same terms.

A short history

The idea is older than most of today's software. Researchers in the 1970s, notably James McCall and Barry Boehm, published hierarchical quality models that split quality into factors and criteria. In 1991 ISO and IEC published ISO/IEC 9126, which gave the world a common software quality model with six characteristics. In 2001 its first part was revised, and the other parts added measures for internal quality, external quality and quality in use.

From 2005 onwards these documents were reorganised into a larger family called SQuaRE – Systems and software Quality Requirements and Evaluation – numbered ISO/IEC 25000 to 25099. ISO/IEC 25010:2011 replaced the 9126 model. It contained two models in one document: a product quality model with eight characteristics, and a quality-in-use model describing the outcome of using the product.

The 2023 revision did three big things. First, it split the old document: ISO/IEC 25010 now holds only the product quality model, the quality-in-use model moved to the new ISO/IEC 25019, and general guidance on using quality models moved to the new ISO/IEC 25002. Second, it widened the target from software to many kinds of ICT products and information systems, including hardware, firmware, data and communication parts. Third, it updated the characteristics themselves to reflect modern practice: safety became a characteristic of its own, usability and portability were renamed, and several subcharacteristics were added, renamed or split. Lesson 3 covers the changes in detail.

What the standard covers

The standard defines a product quality model for ICT products and software products. A "product" here is an ICT product that forms part of an information system; its components can include subsystems, software, firmware, hardware, data and communication infrastructure. The model is a reference: it lists the qualities a product can have so that they can be specified, measured and evaluated throughout the product's life, by developers, acquirers, quality assurance and control staff and independent evaluators alike.

The scope lists typical uses: eliciting and defining requirements, checking that a requirements set is complete, setting design objectives, setting testing objectives, defining quality control criteria, defining acceptance criteria and establishing measures for all of these. The standard does not prescribe a development process, a test technique or a document template.

What the standard does not cover

It does not tell you which characteristics matter for your product or what target values to set. Those choices depend on your stakeholders and context.
It does not define the measures themselves. Measurement is the job of the quality measurement division of SQuaRE (the ISO/IEC 2502n documents).
It does not describe the outcome of using the product in a real context, such as user satisfaction or freedom from harm. That is quality in use, now in ISO/IEC 25019.
It is not a management system standard. There is no set of "shall" requirements for an organisation and no organisation-level certificate.
It has no normative references: it can be read and applied on its own, although it is designed to work with the rest of SQuaRE.

Where it sits in the SQuaRE family

SQuaRE is organised into divisions, each handling one job in the quality story. ISO/IEC 25010 belongs to the quality model division and is aligned with ISO/IEC 25002 in the quality management division. Figure 1 shows the divisions and how they build on each other (the management division supports all the others, and the extension division adapts the models to new technologies): the models say what quality means, the measurement division says how to measure it, the requirements division says how to specify it, and the evaluation division says how to judge a product against it.

Figure 1 – The SQuaRE divisions: quality models such as ISO/IEC 25010 feed measurement, requirements and evaluation.

Lesson 2 – Key concepts and vocabulary

The standard has its own vocabulary, and many arguments about quality are really arguments about words. The terms below are explained in plain language; they are not the standard's official definitions.

Quality model – an agreed structure of named characteristics, and how they relate, that people use as a common frame when they write quality requirements and judge quality. ISO/IEC 25010 is one such model; ISO/IEC 25019 and ISO/IEC 25012 are others.
Product quality – the degree to which a product satisfies the stated and implied needs of its stakeholders, looked at through properties of the product itself (its code, design, data, hardware and behaviour) rather than through the effects of using it.
Quality characteristic – one of the nine top-level categories of product quality, such as reliability or security. Each one is broad enough to group related concerns.
Subcharacteristic – a narrower aspect of a characteristic, such as availability within reliability. Subcharacteristics are where specification usually becomes concrete.
Quality property – an inherent, measurable property of the product that contributes to a subcharacteristic. Examples are mean response time, the share of input fields that are validated, or the number of components that depend on a given module.
Quality measure – a defined way of putting a number on a property, for example "percentage of planned functions that are implemented". The 2502n documents, especially ISO/IEC 25023, provide example measures.
Quality measure element (QME) – a basic measured quantity, such as a count of failures or an elapsed time, from which quality measures are calculated.
Stakeholder – any person or organisation with an interest in the product: users, operators, maintainers, acquirers, developers, regulators, and the public who may be affected by an information system without ever touching it.
Stated and implied needs – stated needs are written down in requirements; implied needs are expectations nobody wrote down but everyone assumes, such as "the app will not lose my data". Good use of the model surfaces implied needs before they become complaints.
Quality in use – the effect that using the product has on its stakeholders in a specific context, such as whether users reach their goals, whether anyone is harmed and whether stakeholders accept the result. It is defined in ISO/IEC 25019.
Context of use – the users, tasks, equipment and physical, social and organisational environment in which a product is used. The same product can be excellent in one context and unsuitable in another.
Target product – the specific product, or part of an information system, that you are specifying or evaluating. Being precise about it avoids blaming the product for a problem in its environment.
Quality requirement – a requirement that a product must meet a given level of a quality characteristic or property, ideally with a measure and a target value. ISO/IEC 25030 explains how to build them.
Acceptance criteria – the conditions a product must meet to be accepted by a customer or user; in practice, the quality requirements that will be checked at hand-over or before release.

Product quality versus quality in use

The single most important distinction in this course is between the product and the outcome. Product quality describes what the product is: its properties, observable when you inspect it or run it under test conditions. Quality in use describes what happens when real stakeholders use it in a real context. A fast, secure, well-designed product can still fail in use if it was built for the wrong tasks or the wrong users. Equally, users may be satisfied for a while with a fragile product until it breaks.

The two models are connected by cause and effect. Good product quality is a means of achieving good quality in use; it does not guarantee it. Clause 5 of the standard describes this relationship. In practice you start from the desired outcome (quality in use), work backwards to the product properties that make it likely, build and test those properties, and then check the outcome again in real use. Figure 2 shows this chain.

Figure 2 – Product quality is a means to quality in use: needs drive outcomes, outcomes drive product properties, and real use feeds back.

Internal and external views

Older material also speaks of internal properties, measured without running the whole product (code structure, static analysis results), and external properties, observed when it runs (response times, failure rates). The SQuaRE measurement division still gives example measures for both internal and external properties. Internal measures are available early, before the whole product runs, so teams use them as early warning signs for external behaviour.

Lesson 3 – Structure of the standard and the nine characteristics

The document

ISO/IEC 25010:2023 is a short document. Clause 1 states the scope, clause 2 notes that there are no normative references, and clause 3 holds the terms and definitions, including the definition of every characteristic and subcharacteristic. Clause 4 presents the product quality model: 4.1 explains its structure and 4.2 explains its targets, meaning the kinds of products and system parts it can be applied to. Clause 5 explains the relationship to the quality-in-use model. Four informative annexes follow: Annex A compares the model with the 2011 product quality model, Annex B gives an example of mapping the model to the concept of dependability, Annex C explains how the model is used for measurement, and Annex D looks at quality from the perspectives of different stakeholders.

The model itself is a simple two-level hierarchy: nine characteristics, each divided into subcharacteristics, forty subcharacteristics in total. Figure 3 shows the nine characteristics; the sections below explain each one and its subcharacteristics in plain words.

Figure 3 – The nine characteristics of the ISO/IEC 25010:2023 product quality model.

1. Functional suitability

Does the product do the right things, and do them correctly? This characteristic is about the functions the product provides, measured against stated and implied needs.

Functional completeness: the set of functions covers all the tasks and objectives that were specified.
Functional correctness: the functions give correct results with the precision required (a tax calculator that rounds wrongly fails here).
Functional appropriateness: the functions actually help users accomplish their tasks, without unnecessary steps or missing shortcuts.

2. Performance efficiency

How well does the product perform relative to the resources it uses, under stated conditions?

Time behaviour: response times, processing times and throughput rates.
Resource utilization: the amounts and types of resources used, such as CPU, memory, storage, network and energy.
Capacity: the maximum limits the product can handle, such as concurrent users, transactions per second or database size.

3. Compatibility

Can the product work alongside and together with other products?

Co-existence: it can share an environment and resources with other products without harming them, for example by not exhausting a shared database connection pool.
Interoperability: it can exchange information with other systems and actually use the information exchanged, which needs agreed formats and meanings, not just a working connection.

4. Interaction capability (formerly usability)

How well can the intended users interact with the product to complete their tasks? The new name stresses interaction with any kind of ICT product, not only a screen-based application, and leaves the word "usability" to the quality-in-use model in ISO/IEC 25019, where it describes an outcome of use.

Appropriateness recognizability: users can tell whether the product suits their needs, for example from its first screen or its description.
Learnability: users can learn to use it within a reasonable time.
Operability: it is easy to operate and control.
User error protection: it prevents users from making errors, or helps them recover, such as confirmation before deleting data.
User engagement: it presents functions and information in an inviting, motivating way (replacing the narrower "user interface aesthetics").
Inclusivity: people of diverse backgrounds, such as different ages, abilities, cultures and languages, can use it.
User assistance: it supports people with the widest range of characteristics and capabilities in reaching their goals, for example through assistive-technology support. Together with inclusivity it replaces the former "accessibility" subcharacteristic.
Self-descriptiveness: it makes its own capabilities and the way to use them obvious, without users needing a manual.

5. Reliability

Does the product perform its functions under specified conditions for a specified period?

Faultlessness: it operates without faults during normal operation (replacing the 2011 subcharacteristic "maturity").
Availability: it is operational and accessible when needed.
Fault tolerance: it keeps working as intended despite hardware or software faults.
Recoverability: after an interruption or failure it can recover the affected data and return to the desired state.

6. Security

Does the product protect information and data and defend against attack, so that people and systems get only the access appropriate to their authorisation?

Confidentiality: data is accessible only to those authorised.
Integrity: the system prevents unauthorised changes to data or programs.
Non-repudiation: actions or events can be proven to have taken place, so they cannot later be denied.
Accountability: actions can be traced to a unique entity, such as a user account.
Authenticity: the identity of a subject or resource can be proven to be the one claimed.
Resistance: new in 2023 – the product keeps operating while under attack from a malicious actor, for example by throttling a flood of requests instead of collapsing.

7. Maintainability

How effectively and efficiently can the intended maintainers modify the product to correct, improve or adapt it?

Modularity: it is made of components so that a change to one has minimal impact on others.
Reusability: parts can be used in more than one system or in building other parts.
Analysability: maintainers can assess the impact of a change, diagnose causes of failures and find the parts to change.
Modifiability: it can be changed without introducing defects or degrading existing quality.
Testability: test criteria can be set and tests run effectively to check whether those criteria are met.

8. Flexibility (formerly portability)

Can the product be adapted to changes in its requirements, contexts of use or system environment? The new name captures more than moving software between platforms.

Adaptability: it can be adapted to different or evolving hardware, software, operating or usage environments.
Scalability: new in 2023 – it can handle growing or shrinking workloads, or adjust its capacity to cope with variability.
Installability: it can be installed and uninstalled successfully in a given environment.
Replaceability: it can replace another product for the same purpose in the same environment.

9. Safety (new in 2023)

Under defined conditions, does the product avoid states in which human life, health, property or the environment is endangered? Safety was previously treated mainly as an outcome in quality in use; making it a product characteristic recognises that software increasingly controls physical things such as vehicles, medical devices, machines and buildings.

Operational constraint: the product keeps its operation within safe parameters or states when a hazard is encountered.
Risk identification: it can identify sequences of events or operations that could expose people, property or the environment to unacceptable risk.
Fail safe: on failure it can automatically move to a safe operating mode or revert to a safe condition.
Hazard warning: it warns of unacceptable risks so that operators or internal controls can react in time.
Safe integration: it stays safe during and after integration with other components.

What changed from 2011

Annex A of the standard compares the two editions. The table below summarises the main differences in plain words.

Area	ISO/IEC 25010:2011	ISO/IEC 25010:2023
Document scope	Product quality model and quality-in-use model in one document	Product quality model only; quality in use moved to ISO/IEC 25019, usage guidance to ISO/IEC 25002
Target	Mainly software products and computer systems	Widened to many types of ICT product and information system
Number of characteristics	Eight	Nine (safety added)
Usability	Usability, including accessibility and user interface aesthetics	Interaction capability, with inclusivity, user assistance, user engagement and self-descriptiveness
Portability	Portability: adaptability, installability, replaceability	Flexibility: the same three plus scalability
Reliability	Maturity, availability, fault tolerance, recoverability	Faultlessness replaces maturity
Security	Five subcharacteristics	Resistance added
Performance efficiency	Time behaviour, resource utilization, capacity	Same three subcharacteristics

If your templates still list "usability" and "portability", they follow the 2011 edition; when you update them, check that safety and the new subcharacteristics are not silently missing.

Lesson 4 – How it works in practice

A checklist, not a recipe

The model is most valuable when used early, as a structured conversation. Its nine characteristics act as a prompt list: for each one, the team asks whether it matters for this product, why, how much, and how they will know. Teams who skip this step tend to leave quality to a single line such as "the system shall be fast and secure", which cannot be designed for, tested or accepted.

Not every characteristic deserves equal attention. A batch data pipeline has little user interaction; a hospital infusion-pump controller has major safety concerns; a public website has strong inclusivity needs. The model does not rank characteristics, and it does not ask you to address all forty subcharacteristics. It asks you to make a conscious decision about each one, and to record why low-priority items were set aside. This is called tailoring.

The typical workflow

Figure 4 shows a workflow that many organisations follow when they apply the model, combining ISO/IEC 25010 with its sister standards for requirements (ISO/IEC 25030), measures (ISO/IEC 25023) and evaluation (ISO/IEC 25040).

Figure 4 – A practical workflow for applying the product quality model, from stakeholders to acceptance and back.

Identify stakeholders and the context of use. List who uses, operates, maintains, buys, regulates or is affected by the product. Annex D of the standard is a reminder that each group sees quality differently: an end user cares about interaction capability, an operator about availability and recoverability, a maintainer about analysability.
Screen all nine characteristics. Run a short workshop. For each characteristic and its subcharacteristics, ask: what could go wrong here, and who would suffer? This is the step where implied needs surface.
Prioritise and record trade-offs. Characteristics pull against each other. Stronger encryption costs processing time; extra confirmation dialogs protect users from errors but slow experts down; heavy abstraction can help modifiability while hurting time behaviour. Write down which characteristic wins when there is a conflict, and why.
Write measurable quality requirements. Each important subcharacteristic becomes one or more requirements with a condition, a measure and a target, for example "under 2,000 concurrent users, 95 % of search requests complete within 1.5 seconds". Architecture methods often express these as quality attribute scenarios: a stimulus, the environment, and the expected response with a measurable response measure.
Choose measures and target values. Use or adapt measures from ISO/IEC 25023 or your own catalogue. Decide the minimum acceptable value, the planned value and how the measurement will be taken.
Design for quality. Architects pick tactics for each priority: redundancy and health checks for availability, caching for time behaviour, modular boundaries for modifiability, input validation and rate limiting for security and resistance, watchdogs and safe states for fail safe behaviour.
Verify. Map each characteristic to verification activities: functional tests for functional suitability, load and stress tests for performance efficiency and capacity, integration tests for interoperability, usability tests with representative users for interaction capability, failover and recovery drills for reliability, penetration tests and threat modelling for security, static analysis and code review for maintainability, installation and scaling tests for flexibility, and hazard analysis with fault injection for safety.
Evaluate and decide acceptance. Compare measured values against targets and make a documented acceptance decision.
Monitor in operation. Production telemetry, incident reports and user feedback show whether the product quality delivered the intended quality in use. New findings feed the next round of requirements.

Roles and artefacts

No single role owns quality. Typically a product owner or business analyst leads the stakeholder and prioritisation work; an architect owns the design tactics and the trade-off record; testers and quality engineers own the verification plan and the measures; security and safety specialists own their characteristics; and the acquirer or customer owns the acceptance decision. Useful artefacts include a quality requirements specification (or a set of non-functional backlog items), a characteristic-to-test traceability matrix, the trade-off decisions log, and an evaluation report.

Using the model in Agile and DevOps teams

The model fits iterative work well. Teams can add a short "quality characteristics check" to backlog refinement, express quality requirements as acceptance criteria on user stories or as global constraints in the definition of done, and automate as many checks as possible in the delivery pipeline. Static analysis gates support maintainability; automated performance smoke tests support time behaviour; dependency and vulnerability scanning support security; infrastructure tests support installability and scalability. The model's job is to make sure the pipeline checks the qualities stakeholders actually care about, not only the ones that are easy to automate.

Lesson 5 – Assessment, certification and compliance

Is there an ISO/IEC 25010 certificate?

Not in the way most people expect. ISO/IEC 25010 is a reference model, not a requirements standard. It contains no "shall" statements that an organisation could be audited against, so there is no accredited management-system certification for it in the way there is for ISO 9001 or ISO/IEC 27001. A supplier that claims to be "ISO 25010 certified" as an organisation is using the phrase loosely, and you should ask what exactly was evaluated, by whom and against which targets.

What can be evaluated is a product. A product evaluation compares the measured quality of a specific product version, in a specified context, against quality requirements that were derived from the model. That evaluation can be done by the developer (first party), by the acquirer (second party) or by an independent evaluator (third party). A small number of third-party schemes, run by certification bodies working with evaluation laboratories, issue product certificates for selected characteristics such as functional suitability or maintainability, based on the SQuaRE evaluation and measurement standards. Such a certificate is about one product and the characteristics evaluated, not about the organisation, and its value depends on the scheme's rules and the targets used.

How a product evaluation works

ISO/IEC 25040 describes how quality evaluation is done. Its current edition, ISO/IEC 25040:2024 ("Quality evaluation framework"), replaced the 2011 edition, widened the targets to ICT products, data and IT services, and describes four kinds of evaluation: for suitability to a specific use, for qualification against a quality standard, for conformity to requirements, and for suitability to a market. Its process reference model has five stages, which in broad terms work like this:

Define the evaluation: agree its purpose, the target product and its boundary, the stakeholders, and which characteristics and subcharacteristics from ISO/IEC 25010 are in scope.
Design the evaluation: select quality measures, set target values and agree the decision criteria for each measure and for the overall result.
Plan the evaluation: arrange activities, environments, tools, data, people and schedule.
Execute the evaluation: take the measurements, compare them with the criteria and record the results.
Conclude the evaluation: review the results, write the evaluation report and handle the evaluation data.

Older material still shows the 2011 stage names (establish requirements, specify, design, execute, conclude); the idea of deciding how you will judge before you measure is unchanged.

From characteristic to number

Annex C of ISO/IEC 25010 explains how the model is used for measurement, and Figure 5 shows the hierarchy. You cannot measure "reliability" directly. Instead you choose a subcharacteristic such as availability, identify product properties that drive it, define quality measures for those properties (for example, the proportion of scheduled operating time that the system was actually available), and calculate each measure from quality measure elements such as total scheduled time and total downtime, collected by a defined measurement method. The results are then compared with target values and rolled up, using rules agreed in advance, into a judgement about the subcharacteristic and the characteristic.

Figure 5 – How a characteristic becomes measurable: subcharacteristic, property, quality measure, measure elements and a decision against a target.

Two practical points matter here. First, the standard does not define rating levels or pass marks; the evaluator and the stakeholders set them, ideally before measuring, so that the result is not argued after the fact. Second, the decision rules matter as much as the measurements. Is the product acceptable if eight of nine priority targets are met but the safety target is missed? Most organisations treat some characteristics, often safety and security, as "must pass" and allow trade-offs only among the rest.

Compliance and contracts

In practice, "compliance with ISO/IEC 25010" usually means that requirements were structured with the model, that the test strategy covers the relevant characteristics, or that an evaluation report shows how the product scored against model-based requirements. Regulations rarely mandate the model directly, but sector rules on safety, accessibility, security and data protection map neatly onto its characteristics.

Lesson 6 – Worked example: a city transit ticketing system

The situation

MetroLink, a medium-sized city transport authority, is replacing its ticketing system. The new system has four parts: a passenger mobile app, ticket gates in stations that accept phone tickets and bank cards, a back-office platform that calculates fares and settles payments, and an operator console for station staff. MetroLink will buy the system from a supplier under a five-year contract and wants quality requirements in the tender that the supplier must prove at acceptance. The quality lead structures the work around ISO/IEC 25010:2023.

Step 1 – Stakeholders and context

The team lists stakeholders: daily commuters, occasional tourists who do not speak the local language, elderly and disabled passengers, station staff, the operations centre, the finance department, the bank that processes card payments, the supplier's maintenance team, the city's accessibility office and the rail safety regulator. The context includes rush hours with very high gate traffic, underground stations with poor mobile coverage, and gates that physically control the movement of people.

Step 2 – Screening the nine characteristics

In a half-day workshop, the team walks through each characteristic. Some findings:

Functional suitability: fare caps and transfer discounts must be calculated correctly every time; a wrong fare is both a customer complaint and a finance problem.
Performance efficiency: a gate must open fast enough that queues do not form at rush hour; the back office must cope with the morning peak.
Compatibility: gates must interoperate with bank card payment schemes and with the regional rail operator's tickets; the app must co-exist with other wallet apps on passengers' phones.
Interaction capability: tourists must recognise quickly whether the app is for them; elderly passengers and screen-reader users must be able to buy tickets; the gate must make it obvious where to tap.
Reliability: gates must keep working if the network drops, and recover cleanly after power cuts.
Security: payment data must stay confidential; fare records must not be altered; the system must keep operating during bot attacks on the app's API.
Maintainability: fare rules change every year and must be updated without a code release; the city wants to be able to change supplier one day.
Flexibility: the system must scale for special events and new lines, and run on the app stores' future operating system versions.
Safety: gates must not close on a passenger, must open in an emergency evacuation and must fail into a safe state if their controller fails.

Step 3 – Priorities and trade-offs

The team rates each characteristic as critical, high or normal. Safety, functional correctness and security are rated critical, because failures there harm people, money or trust. Reliability, performance efficiency and interaction capability are high. Compatibility, maintainability and flexibility are normal for launch but high for the five-year contract. Two trade-offs are recorded. First, when the network is down, gates will accept phone tickets using locally stored validation data, accepting a small fraud risk to protect availability and passenger flow; the security team agrees limits on how long offline mode can last. Second, in an evacuation, safety overrides every revenue rule: all gates open.

Step 4 – Measurable requirements

The team turns priorities into requirements. The table shows a sample; the numbers are MetroLink's own choices, not values from the standard.

Characteristic / subcharacteristic	Requirement (condition, measure, target)	Verification
Functional suitability / correctness	Across a reference set of 5,000 journey scenarios, every calculated fare matches the published fare rules	Automated scenario tests against an independent fare oracle
Performance efficiency / time behaviour	At the gate, 99 % of valid taps open the gate within 400 ms, including at peak load	Gate bench tests and a station pilot with timestamps
Performance efficiency / capacity	Back office processes 3 times the busiest recorded hour without degraded response	Load test with recorded traffic profiles
Interaction capability / user assistance	Ticket purchase can be completed with common screen readers and meets the city's accessibility rules	Accessibility audit and tests with disabled users
Interaction capability / inclusivity	App available in the city's five most common visitor languages; first-time users buy a ticket unaided in under 3 minutes in 90 % of trials	Moderated usability test with tourists and elderly users
Reliability / fault tolerance	Gates keep validating tickets for at least 8 hours without network connection	Network cut drill in a test station
Security / resistance	Under a simulated bot attack, legitimate ticket purchases still succeed at 95 % of normal rate	Penetration test and traffic replay with rate limiting
Maintainability / modifiability	Annual fare changes are configured by MetroLink staff without a software release	Change exercise during acceptance
Flexibility / scalability	Back-office capacity can double within one hour for special events	Scaling drill in the staging environment
Safety / fail safe and hazard warning	On controller failure, gate moves to open state; obstruction detected stops closing; staff console warns of gate faults within 5 seconds	Hazard analysis, fault injection tests, regulator review

Step 5 – Tender and design

The tender asks bidders to answer each requirement with a design approach and evidence. One bidder relies on cloud-only ticket validation, so the panel scores it lower on fault tolerance: it cannot meet the offline requirement. The model has turned an architectural difference into a clear, comparable gap.

Step 6 – Verification and acceptance

At acceptance, an independent test team runs the planned evaluations. Results: all critical targets are met; the time-behaviour target is met in the lab but missed by 60 ms at one station in the pilot because of an old network switch. Using the evaluation's target-product boundary, the team traces the problem to MetroLink's own network rather than the gate product, and the acceptance board approves the product with an action for MetroLink to replace the switch. The inclusivity test shows that tourists struggle with one payment screen; the supplier fixes it before go-live, and the test is repeated.

Step 7 – Operation and feedback

After launch, MetroLink monitors availability, fare complaints, gate opening times and accessibility feedback. Six months in, complaints show that passengers with large luggage are slowed by gate width, a quality-in-use issue that no product requirement covered. It feeds the next requirements round, and the team adds a context-of-use item for luggage. The lesson the team records is that the model helped them think about every characteristic, but only real use reveals whether the chosen targets produced the outcome they wanted.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 25010 rarely works alone. It is the vocabulary that many other standards, methods and tools build on. The table compares it with its closest neighbours.

Standard or framework	What it is about	How it relates to ISO/IEC 25010:2023
ISO/IEC 9126 and ISO/IEC 25010:2011	Earlier software quality models	Direct predecessors; 2023 keeps their hierarchical idea and updates names and coverage (Annex A maps the changes)
ISO/IEC 25019	Quality-in-use model	Describes outcomes of use for stakeholders; product quality is the means, quality in use the effect
ISO/IEC 25002	Overview and usage of quality models	Explains how to choose and combine SQuaRE models; aligned with 25010
ISO/IEC 25012	Data quality model	A sister model for data held in systems; use both when data is a major part of the product
ISO/IEC 25023 and the 2502n division	Quality measures	Provide example measures for the characteristics that 25010 defines
ISO/IEC 25030	Quality requirements framework	Explains how to turn the model into quality requirements
ISO/IEC 25040	Quality evaluation framework (2024 edition)	Explains how to evaluate a product against requirements based on the model
ISO/IEC 25059	Quality model for AI systems	Extends the SQuaRE models with properties that matter for AI, such as robustness and transparency
ISO/IEC/IEEE 29119	Software testing	Testing processes and techniques; 25010 supplies the quality characteristics that test strategies target
ISO/IEC/IEEE 12207 and 15288	Software and system life cycle processes	Provide the processes (requirements definition, verification, validation) in which the model is used
ISO 9001	Quality management systems	Manages the organisation's processes; 25010 helps set product quality objectives and review criteria within them
ISO/IEC 27001	Information security management systems	Organisation-level security management; 25010 security subcharacteristics express product-level security requirements
IEC 61508, ISO 26262 and other safety standards	Functional safety in specific sectors	Prescribe safety processes and integrity levels; 25010 safety names the product property but does not replace them

Three relationships worth remembering

Process versus product. ISO 9001, ISO/IEC 33000 process assessment and maturity models such as CMMI look at how an organisation works. ISO/IEC 25010 looks at what it delivers. The introduction to ISO/IEC 25010 itself notes that SQuaRE can be used together with ISO 9001 and the ISO/IEC 33000 family, for example to support setting quality goals and design review, verification and validation: process standards help an organisation work consistently, and the product quality model helps it define quality goals and review criteria for what it produces.

General model versus specialised models. When much of a product's value lies in its data or in AI components, ISO/IEC 25012 (data quality) and ISO/IEC 25059 (AI systems) add characteristics that the general product model does not cover in depth. Use them together with ISO/IEC 25010, not instead of it, so that the general characteristics are still screened.

Safety and security specialists. Adding safety and resistance to the model does not make ISO/IEC 25010 a safety or security standard. A medical device, a car or a railway system still needs its sector's safety standard and risk management process, and an organisation still needs a proper security management system. The model's contribution is to make sure safety and security appear in the same requirements conversation as performance and usability, so trade-offs are visible.

Common pitfalls and best practices

Common pitfalls

Treating the model as a form to fill in. Writing a line for each of forty subcharacteristics without discussing priority produces long documents and no decisions.
Vague targets. "The system shall be user-friendly and highly available" cannot be designed for, tested or accepted. Every important requirement needs a condition, a measure and a target.
Ignoring trade-offs. Maximising every characteristic at once is impossible. Unrecorded trade-offs are later decided by accident, often by whoever is under the most deadline pressure.
Using outdated templates. Templates still based on 2011 or 9126 may miss safety, resistance, scalability, inclusivity and self-descriptiveness.
Confusing product quality with quality in use. Passing all product tests does not prove that real users in a real context reach their goals safely and are satisfied.
Only measuring what is easy. Automated code metrics are cheap, so maintainability gets heavy attention while interaction capability and safety get little.
Accepting "ISO 25010 certified" at face value. Without the scope, measures, targets and evaluator, such a claim means little.

Best practices

Start from stakeholders and context. Derive priorities from who is affected and how, and record the reasoning.
Screen all nine, deepen a few. Make a conscious decision on every characteristic, then invest detail in the critical ones.
Write requirements as scenarios with numbers. State the condition, the measure, the target and how it will be measured.
Agree decision rules before measuring. Decide which targets are must-pass and how results roll up, before the evaluation starts.
Trace requirements to verification. Keep a matrix from each characteristic to the tests, reviews and analyses that cover it, and automate checks in the pipeline where possible.
Close the loop with operations. Use production monitoring and user feedback to test whether product targets produced the desired quality in use, and adjust.
Pair the model with specialist standards. Use sector safety standards, security frameworks and accessibility rules for depth; use 25010 for completeness and a shared vocabulary.

Summary and key takeaways

ISO/IEC 25010:2023 (second edition, ISO/IEC JTC 1/SC 7) is the current SQuaRE product quality model; with ISO/IEC 25002 and 25019 it replaced the 2011 edition.
The model has nine characteristics – functional suitability, performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility and safety – divided into forty subcharacteristics.
The 2023 edition added safety, renamed usability to interaction capability and portability to flexibility, and added resistance, scalability, inclusivity, user assistance, user engagement, self-descriptiveness and faultlessness.
Product quality describes properties of the product; quality in use, now in ISO/IEC 25019, describes the effects of using it. The first is a means to the second.
The model is a reference for specification, design, testing and acceptance; it does not set targets, define measures or prescribe a process.
Practical use means screening all characteristics, prioritising, recording trade-offs and writing measurable requirements with targets.
Products, not organisations, are evaluated against model-based requirements, using the ISO/IEC 25040 process and measures from the 2502n division; there is no management-system certificate for 25010.
The model works best alongside process standards, testing standards and specialist safety and security standards.

Reflection questions

Pick a product you work on. Which three of the nine characteristics matter most to its stakeholders, which matter least, and how would you justify those choices to a sceptical manager?
Find one vague quality statement in a real requirements document or backlog. Rewrite it as a measurable requirement with a condition, a measure, a target and a verification method.
Describe one trade-off between two characteristics that your team has faced. How was it decided, and how would recording it explicitly have changed the outcome?
Does your product have any safety relevance, even indirect, such as controlling a device or giving advice that people act on? Which of the five safety subcharacteristics would apply?
Think of a product that passed its tests but disappointed users. Which part of the gap was product quality and which was quality in use, and what would you measure differently next time?