Let us first take a look at the concept of quality. Here is a contemporary who certainly wants to provoke.
«Quality stands for the outrageously exaggerated consumer expectations of goods and services.» - Prof. Querulix ©
Today, the term "excellence" is often used for "quality". Whether this trend of choosing terms is more appropriate should be decided by each individual. However, I have never heard the term software excellence in reference to software quality. Here, computer science is actually evading the current trend for once. Maybe it just doesn't sound very good; software excellence.
The term quality is not used uniformly. Subjective ideas, cultural influences and the respective reference object play a role. The medical doctor Avedis Donabedian defines quality as the degree of conformity that exists between the actual treatment and the requirements. David A. Garvin's, on the other hand, distinguishes several dimensions of quality: transcendent, product-related, user-related, value-oriented and production-related.
«Quality means less trouble with customers. It reduces the pain caused by price. Of course quality costs, but lack of quality costs more.» - Hans-Jürgen Quadbeck-Seeger©
But how do we define the quality of software. The ISO standard 25010 provides us with a system that lists the quality characteristics that should apply to software. However, I don't think it's very good that you are asked to pay for the official documents of the standard.
«Quality is the degree to which a set of inherent characteristics meets requirements.» - ISO9000
.svg?decoding=auto "ISO_Logo_%28Red_square%29"){kind=logo}
I also like to use this categorisation as a checklist when defining requirements, among other things to verify that we have thought of everything.
In the end, it does not matter whether the term quality or excellence is used. What is important is that it is taken care of and not left to chance.
Good software is characterized above all by the fact that it meets all relevant requirements. What could be more obvious than to conscientiously name these relevant requirements. My experience teaches me that mostly not the functional requirements are decisive. The non-functional quality features should be given at least as much attention - if not more.
