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 in use metrics.
The quality model presented in the first part of the standard, ISO/IEC 9126-1,
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."
Portability - "A set of attributes that bear on the ability of software to be transferred from one environment to another."
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 are those which do not rely on software execution (static measure).
External metrics are applicable to running software.
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.
"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".