As explained before quality is subjective. That’s why a definition of Software Quality must be quite abstract to be widely acceptable. My favorite definition is an extension of Juran’s "fitness for use" ([DeJ2016]) and maps to the one in the book The Nature of Software Development ([Jef2015]):
Software Quality is the combination of:
Fitness for use is relevant for the end-user and fitness for operation for the operations teams. They are external views and match the Jeffries’s term well-tested. Fitness for change is the internal view of the organization maintaining the system and corresponds to the Jeffries’s term well-designed.
Those three fitnesses need to be balanced, but the definition is too high-level to be useful. To make it more tangible I suggest to link the relevant quality attributes of the system [to be] defined by the software architect to the three fitnesses.
While the quality attributes might still be too abstract, they are linked to concrete quality attribute scenarios.
When planning changes of the system the model helps to keep the quality of the system in balance and even allows to adjust the balance when circumstances change.
Revisiting my Software Quality definition criteria the suggested definition & model:
-
are simple: because the number of elements to consider is managable
-
work intuitively: stakeholders (e.g. developers) can represent their interests (e.g. fitness for change) while everybody keeps the overview to make conscious decisions
-
and are flexible: linking the system specific quality attributes tailors the model to the system context
References
-
[DeJ2016]: Juran’s Quality Control Handbook by Joseph A. DeFeo & Joseph M. Juran
-
[Jef2015]: The Nature of Software Development by Ron Jeffries