ISO/IEC 25010: the map of what “quality software” actually means

In a project meeting, someone says: "the software has to be quality." Everyone nods. Nobody argues. And that is the problem: each person nodded while thinking of something different. One pictured it not crashing. Another, it loading fast. Another, it being understandable with no manual. The word "quality" made them believe they agreed when in fact they were not even talking about the same thing.

ISO/IEC 25010 exists to end that confusion. It is not a rule that forces anything on you: it is a vocabulary. It breaks down that slippery thing we call "quality" into eight concrete characteristics, each with its own name. And once something has a name, it stops being opinion and starts being measurable.

01 · the problemWhy "quality" on its own settles nothing

The short answer: because "quality" is an empty container that each person fills with their own priority. Sales fills it with "it should look good," infrastructure with "it should hold up under load," support with "nobody should call." All three are right and none of them understands the others.

ISO/IEC 25010 is part of the SQuaRE family (System and Software Quality Requirements and Evaluation), the ISO/IEC 250xx series of standards devoted to defining and evaluating software quality [1]. Its central contribution is a product quality model: instead of one word, eight characteristics. And each characteristic breaks down into even more concrete subcharacteristics. So instead of asking for "quality," you can ask for "a response time under 200 ms with 500 concurrent users," which is a sentence a team can actually work with.

Quality is not up for debate. You name it, and only then do you measure it.

The standard does not say every piece of software must excel at all eight. It says something more useful: here are the eight, choose which ones matter in your context and at what level of demand. A pacemaker and a mobile game do not share priorities, and that is exactly as it should be.

02 · the mapThe eight characteristics, in plain everyday language

These are the eight characteristics of the product quality model according to ISO/IEC 25010 [1]. I translate them into questions anyone can grasp.

1. Functional suitability. Does it do what it is supposed to do? This is the question of whether the functions exist, are correct, and cover what the user needs. A "save" button that does not save fails here, even if it is beautiful and fast.

2. Performance efficiency. Does it do it using reasonable resources? This covers response times, memory and CPU usage, and capacity under load. It is not "just be fast," but fast relative to the resources it consumes.

3. Compatibility. Does it get along with everything else? It measures whether the system coexists with others in the same environment without getting in the way (coexistence) and whether it exchanges information with them (interoperability). Your app that exports to a format nobody else can read fails here.

4. Usability. Do people understand and use it without suffering? It gathers whether it can be learned with no manual, whether it protects against errors, whether it is accessible. A powerful system nobody manages to operate has a real usability problem, not a design whim.

5. Reliability. Can you trust that it will keep working? It speaks to maturity (it rarely fails), availability (it is there when needed), fault tolerance, and the ability to recover. It is the difference between "it worked in the demo" and "it works on Tuesday at 3 in the morning."

6. Security. Does it protect information and access? It covers confidentiality, integrity, authenticity, and that actions are logged. Here it is not about the system working, but about it not working for whoever should not have it.

7. Maintainability. Can you change it without breaking everything? It measures how modular it is, how easy it is to test, modify, and reuse. Code nobody dares to touch for fear of what might break fails here, even if it works today.

8. Portability. Can you move it somewhere else? It speaks to adapting to new environments, installing painlessly, and replacing another system. Software tied to a single machine or a single vendor has little portability.

03 · real-world useDo not chase all eight: choose which ones matter in your context

Here is the most common mistake, and also the most expensive: believing that a good product must score high on all eight characteristics at once. No. Chasing all eight equally is the recipe for spending three times as much and standing out in none. The standard is a menu, not a mandatory to-do list.

The question worth asking is: in this product, for this user, which characteristic is non-negotiable and which can stay at "good enough"? A payment system puts security and reliability above everything, and will accept a usability that is correct but not dazzling. A prototype meant to validate an idea prioritizes functional suitability and usability, and can afford mediocre efficiency because it will never see real load.

This is exactly how we use the model at Qirava: not as a checklist to pass, but as the board where a product conversation becomes honest. Before writing a test case, before fighting over a date, we put the eight characteristics on the table and decide, out loud, which two or three this product cannot fail at. The rest gets attention, but is not chased to perfection.

That act of choosing is what separates a team that "wants quality" from one that knows which quality it wants. The first argues endlessly because nobody defined the word. The second points at the map, singles out three boxes, and says: here. Everything else is negotiable.

Choosing what to excel at is a product decision, not a surrender on quality.

The next time someone asks for "quality software," do not nod. Ask which of the eight. Turning a vague word into a concrete choice is, probably, the cheapest and most valuable QA work you can do in the entire project.