ISO/IEC 9126

ISO/IEC 9126 Software engineering — Product quality was an international standard for the evaluation of software quality. It has been replaced by ISO/IEC 25010:2011.[1]

ISO 9126 quality (en)
The quality criteria according to ISO 9126

The fundamental objective of the ISO/IEC 9126 standard is to address some of the well known human biases that can adversely affect the delivery and perception of a software development project. These biases include changing priorities after the start of a project or not having any clear definitions of "success". By clarifying, then agreeing on the project priorities and subsequently converting abstract priorities (compliance) to measurable values (output data can be validated against schema X with zero intervention), ISO/IEC 9126 tries to develop a common understanding of the project's objectives and goals.

The standard is divided into four parts:

  • quality model
  • external metrics
  • internal metrics
  • quality in use metrics.


The quality model presented in the first part of the standard, ISO/IEC 9126-1,[2] classifies software quality in a structured set of characteristics and sub-characteristics as follows:

  • Functionality - "A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs."
  • Reliability - "A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time."
  • Usability - "A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users."
  • Efficiency - "A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions."
    • Time behaviour
    • Resource utilization
    • Efficiency compliance
  • Maintainability - "A set of attributes that bear on the effort needed to make specified modifications."
    • Analyzability
    • Changeability
    • Stability
    • Testability
    • Maintainability compliance
  • Portability - "A set of attributes that bear on the ability of software to be transferred from one environment to another."
    • Adaptability
    • Installability
    • Co-existence
    • Replaceability
    • Portability compliance

Each quality sub-characteristic (e.g. adaptability) is further divided into attributes. An attribute is an entity which can be verified or measured in the software product. Attributes are not defined in the standard, as they vary between different software products.

Software product is defined in a broad sense: it encompasses executables, source code, architecture descriptions, and so on. As a result, the notion of user extends to operators as well as to programmers, which are users of components such as software libraries.

The standard provides a framework for organizations to define a quality model for a software product. On doing so, however, it leaves up to each organization the task of specifying precisely its own model. This may be done, for example, by specifying target values for quality metrics which evaluates the degree of presence of quality attributes.

Internal Metrics

Internal metrics are those which do not rely on software execution (static measure).

External metrics

External metrics are applicable to running software.

Quality-in-use metrics

Quality-in-use metrics are only available when the final product is used in real conditions. Ideally, the internal quality determines the external quality and external quality determines quality in use.

This standard stems from the GE model for describing software quality, presented in 1977 by McCall et al., which is organized around three types of quality characteristic:

  • Factors (to specify): They describe the external view of the software, as viewed by the users.
  • Criteria (to build): They describe the internal view of the software, as seen by the developer.
  • Metrics (to control): They are defined and used to provide a scale and method for measurement.

ISO/IEC 9126 distinguishes between a defect and a nonconformity, a defect being "The nonfulfilment of intended usage requirements", whereas a nonconformity is "The nonfulfilment of specified requirements". A similar distinction is made between validation and verification, known as V&V in the testing trade.


ISO/IEC 9126 was issued on December 19, 1991.

On June 15, 2001, ISO/IEC 9126:1991 was replaced by ISO/IEC 9126:2001 (four parts 9126-1 to 9126-4).

On March 1, 2011, ISO/IEC 9126 was replaced by ISO/IEC 25010:2011 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - System and software quality models. Compared to 9126, "security" and "compatibility" were added as main characteristics.


ISO/IEC then started work on SQuaRE (Software product Quality Requirements and Evaluation), a more extensive series of standards to replace ISO/IEC 9126, with numbers of the form ISO/IEC 250mn. For instance, ISO/IEC 25000 was issued in 2005, and ISO/IEC 25010, which supersedes ISO/IEC 9126-1, was issued in March 2011. ISO 25010 has eight product quality characteristics (in contrast to ISO 9126's six), and 31 subcharacteristics.[3]

  • "Functionality" is renamed "functional suitability". "Functional completeness" is added as a subcharacteristic, and "interoperability" and "security" are moved elsewhere. "Accuracy" is renamed "functional correctness", and "suitability" is renamed "functional appropriateness".
  • "Efficiency" is renamed "performance efficiency". "Capacity" is added as a subcharactersitic.
  • "Compatibility" is a new characteristic, with "co-existence" moved from "portability" and "interoperability" moved from "functionality".
  • "Usability" has new subcharacteristics of "user error protection" and "accessibility" (use by people with a wide range of characteristics). "Understandability" is renamed "appropriateness recognizability", and "attractiveness" is renamed "user interface aesthetics".
  • "Reliability" has a new subcharacteristic of "availability" (when required for use).
  • "Security" is a new characteristic with subcharacteristics of "confidentiality" (data accessible only by those authorized), "integrity" (protection from unauthorized modification), "non-repudiation" (actions can be proven to have taken place), "accountability" (actions can be traced to who did them), and "authenticity" (identity can be proved to be the one claimed).
  • "Maintainability" has new subcharacteristics of "modularity" (changes in one component have a minimal impact on others) and "reusability"; "changeability" and "stability" are rolled up into "modifiability".
  • "Portability" has "co-existence" moved elsewhere.

A maintainability model for software quality

A maintainability model for software quality

See also


  1. ^ Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality model
  2. ^ Software engineering — Product quality — Part 1: Quality model
  3. ^ ISO/IEC 25010:2011 : Systems and software engineering -- Systems and software Quality Requirements and Evaluation (SQuaRE) -- System and software quality models
  • Scalet et al., 2000: ISO/IEC 9126 and 14598 integration aspects: A Brazilian viewpoint. The Second World Congress on Software Quality, Yokohama, Japan, 2000.

ISO/IEC JTC 1/SC 7 Software and systems engineering is a standardization subcommittee of the Joint Technical Committee ISO/IEC JTC 1 of the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC), that develops and facilitates standards within the field of engineering of software products and systems. The international secretariat of ISO/IEC JTC 1/SC 7 is the Bureau of Indian Standards (BIS) located in India. is the Indian government’s web portal for citizens. It presents information resources and online services from government sources, accessible from a single point. It is also known as the National Portal of India.This is the official portal of the Indian Government, designed, developed and hosted by National Informatics Centre (NIC), an S&T Organisation of the government of India under the aegis of the Department of Electronics and Information Technology, Ministry of Communications & Information Technology.The portal has been developed as a Mission Mode Project under the National E-Governance Plan of the government. The objective is to provide a single window access to the information and services such as passport, driving licenses, company registration etc. being provided by the Indian government for the citizens and other has sections for people living abroad, business persons, government employees, senior citizens and children. The portal is also useful to foreign citizen and researchers searching for information on India. It provides details of the people occupying high offices in India, the work completed by ministries, press releases, demographics, tourism, and cultural links to Union, State, District and local level official websites and is the most comprehensive portal about the government of India with links to 6,700 government websites. The website also has a feature that customizes the content displayed, based on a user’s individual profile and preferences. It is accessible by disabled people and users of handheld devicesThe portal has an average of around eight lakh (8,00,000) website visitors per month. While most of these visitors are from India, around 28 per cent come from outside India.


In a labor market increasingly dictated by skills, individuals need to develop and demonstrate learnability — the desire and ability to quickly grow and adapt one’s skill set — in order to stay relevant and succeed.

List of International Organization for Standardization standards, 9000-9999

This is a list of published International Organization for Standardization (ISO) standards and other deliverables. For a complete and up-to-date list of all the ISO standards, see the ISO catalogue.The standards are protected by copyright and most of them must be purchased. However, about 300 of the standards produced by ISO and IEC's Joint Technical Committee 1 (JTC1) have been made freely and publicly available.

List of system quality attributes

Within systems engineering, quality attributes are realized non-functional requirements used to evaluate the performance of a system. These are sometimes named "ilities" after the suffix many of the words share. They are usually Architecturally Significant Requirements that require architects' attention.


In engineering, maintainability is the ease with which a product can be maintained in order to:

correct defects or their cause,

repair or replace faulty or worn-out components without having to replace still working parts,

prevent unexpected working condition,

maximize a product's useful life,

maximize efficiency, reliability, and safety,

meet new requirements,

make future maintenance easier, or

cope with a changed environment.In some cases, maintainability involves a system of continuous improvement - learning from the past in order to improve the ability to maintain systems, or improve reliability of systems based on maintenance experience.

In telecommunication and several other engineering fields, the term maintainability has the following meanings:

A characteristic of design and installation, expressed as the probability that an item will be retained in or restored to a specified condition within a given period of time, when the maintenance is performed in accordance with prescribed procedures and resources.

The ease with which maintenance of a functional unit can be performed in accordance with prescribed requirements.

Non-functional requirement

In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.Broadly, functional requirements define what a system is supposed to do and non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of "system shall do ", an individual action or part of the system, perhaps explicitly in the sense of a mathematical function, a black box description input, output, process and control functional model or IPO Model. In contrast, non-functional requirements are in the form of "system shall be ", an overall property of the system as a whole or of a particular aspect and not a specific function. The system's overall properties commonly mark the difference between whether the development project has succeeded or failed.

Non-functional requirements are often called "quality attributes" of a system. Other terms for non-functional requirements are "qualities", "quality goals", "quality of service requirements", "constraints", "non-behavioral requirements", or "technical requirements". Informally these are sometimes called the "ilities", from attributes like stability and portability. Qualities—that is non-functional requirements—can be divided into two main categories:

Execution qualities, such as safety, security and usability, which are observable during operation (at run time).

Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.

Nonconformity (quality)

In quality management, a nonconformity (sometimes referred to as a defect) is a deviation from a specification, a standard, or an expectation. Nonconformities can be classified in seriousness multiple ways, though a typical classification scheme may have three to four levels, including critical, serious, major, and minor.While some situations allow "nonconformity" and "defect" to be used synonymously, some industries distinguish between the two; a nonconformity represents a failure to meet an intended state and specification, while a defect represents a failure to meet fitness for use/normal usage requirements. This can be seen in the international software engineering standard ISO/IEC 25010 (formerly ISO/IEC 9126), which defines a nonconformity as the nonfulfillment of a requirement and a defect as the nonfulfillment of intended usage requirements.

Service Measurement Index

The Service Measurement Index is a framework designed to "measure the relative goodness of an IT Service".

Software bug

A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways. The process of finding and fixing bugs is termed "debugging" and often uses formal techniques or tools to pinpoint bugs, and since the 1950s, some computer systems have been designed to also deter, detect or auto-correct various computer bugs during operations.

Most bugs arise from mistakes and errors made in either a program's source code or its design, or in components and operating systems used by such programs. A few are caused by compilers producing incorrect code. A program that contains a large number of bugs, and/or bugs that seriously interfere with its functionality, is said to be buggy (defective). Bugs can trigger errors that may have ripple effects. Bugs may have subtle effects or cause the program to crash or freeze the computer. Other bugs qualify as security bugs and might, for example, enable a malicious user to bypass access controls in order to obtain unauthorized privileges.

Some software bugs have been linked to disasters. Bugs in code that controlled the Therac-25 radiation therapy machine were directly responsible for patient deaths in the 1980s. In 1996, the European Space Agency's US$1 billion prototype Ariane 5 rocket had to be destroyed less than a minute after launch due to a bug in the on-board guidance computer program. In June 1994, a Royal Air Force Chinook helicopter crashed into the Mull of Kintyre, killing 29. This was initially dismissed as pilot error, but an investigation by Computer Weekly convinced a House of Lords inquiry that it may have been caused by a software bug in the aircraft's engine-control computer.In 2002, a study commissioned by the US Department of Commerce's National Institute of Standards and Technology concluded that "software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $59 billion annually, or about 0.6 percent of the gross domestic product".

Software quality

In the context of software engineering, software quality refers to two related but distinct notions:

Software functional quality reflects how well it complies with or conforms to a given design, based on functional requirements or specifications. That attribute can also be described as the fitness for purpose of a piece of software or how it compares to competitors in the marketplace as a worthwhile product. It is the degree to which the correct software was produced.

Software structural quality refers to how it meets non-functional requirements that support the delivery of the functional requirements, such as robustness or maintainability. It has a lot more to do with the degree to which the software works as needed.Many aspects of structural quality can be evaluated only statically through the analysis of the software inner structure, its source code, at the unit level, the technology level and the system level, which is in effect how its architecture adheres to sound principles of software architecture outlined in a paper on the topic by OMG. But some structural qualities, such as usability, can be assessed only dynamically (users or others acting in their behalf interact with the software or, at least, some prototype or partial implementation; even the interaction with a mock version made in cardboard represents a dynamic test because such version can be considered a prototype). Other aspects, such as reliability, might involve not only the software but also the underlying hardware, therefore, it can be assessed both statically and dynamically (stress test).

Functional quality is typically assessed dynamically but it is also possible to use static tests (such as software reviews).

Historically, the structure, classification and terminology of attributes and metrics applicable to software quality management have been derived or extracted from the ISO 9126-3 and the subsequent ISO 25000:2005 quality model, also known as SQuaRE. Based on these models, the Consortium for IT Software Quality (CISQ) has defined five major desirable structural characteristics needed for a piece of software to provide business value: Reliability, Efficiency, Security, Maintainability and (adequate) Size.

Software quality measurement quantifies to what extent a software program or system rates along each of these five dimensions. An aggregated measure of software quality can be computed through a qualitative or a quantitative scoring scheme or a mix of both and then a weighting system reflecting the priorities. This view of software quality being positioned on a linear continuum is supplemented by the analysis of "critical programming errors" that under specific circumstances can lead to catastrophic outages or performance degradations that make a given system unsuitable for use regardless of rating based on aggregated measurements. Such programming errors found at the system level represent up to 90% of production issues, whilst at the unit-level, even if far more numerous, programming errors account for less than 10% of production issues. As a consequence, code quality without the context of the whole system, as W. Edwards Deming described it, has limited value.

To view, explore, analyze, and communicate software quality measurements, concepts and techniques of information visualization provide visual, interactive means useful, in particular, if several software quality measures have to be related to each other or to components of a software or system. For example, software maps represent a specialized approach that "can express and combine information about software development, software quality, and system dynamics".

Software testing

Software testing is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include the process of executing a program or application with the intent of finding software bugs (errors or other defects), and verifying that the software product is fit for use.

Software testing involves the execution of a software component or system component to evaluate one or more properties of interest. In general, these properties indicate the extent to which the component or system under test:

meets the requirements that guided its design and development,

responds correctly to all kinds of inputs,

performs its functions within an acceptable time,

it is sufficiently usable,

can be installed and run in its intended environments, and

achieves the general result its stakeholders desire.As the number of possible tests for even simple software components is practically infinite, all software testing uses some strategy to select tests that are feasible for the available time and resources. As a result, software testing typically (but not exclusively) attempts to execute a program or application with the intent of finding software bugs (errors or other defects). The job of testing is an iterative process as when one bug is fixed, it can illuminate other, deeper bugs, or can even create new ones.

Software testing can provide objective, independent information about the quality of software and risk of its failure to users or sponsors.Software testing can be conducted as soon as executable software (even if partially complete) exists. The overall approach to software development often determines when and how testing is conducted. For example, in a phased process, most testing occurs after system requirements have been defined and then implemented in testable programs. In contrast, under an agile approach, requirements, programming, and testing are often done concurrently.


Squale (Software Quality Enhancement) is an open-source platform that helps monitoring software quality for multi-language applications. It currently supports Java out-of-the-box, and can also analyse C/C++ and Cobol code with an adapter to McCabe tool. Squale is distributed under the terms of the LGPL v3 licence.

Squale is partially funded by the French FUI (Fonds unique interministériel ), labeled by the Systematic Paris-Region competitive cluster and supported by its FLOSS group.

ISO standards by standard number
IEC standards
ISO/IEC standards

This page is based on a Wikipedia article written by authors (here).
Text is available under the CC BY-SA 3.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.