Dieser Blogpost ist auch auf Deutsch verfügbar

Another definition from our mini-series: This time we’ll look at the term quality.

The aim of this short post is to show how broadly people can interpret and understand the term quality – and why this leeway is highly risky in software architecture.

Let’s start with a definition:

Quality (from the Latin qualitas, state, feature, property, or condition) is the sum of all properties of an object, system, or process.[1].

Let’s restrict ourselves to all the properties of a system, and leave processes to one side.

Quality is the same as „good“

Colloquially, we use the word „quality“ as a synonym for properties or things that we consider „good“ or „excellent“. This however results in all manner of ambiguities and double meanings, the concrete meaning of which can sometimes be inferred from the context.

With regards to quality, this concrete meaning often remains unclear („implicit“) instead of being explicitly explained. What „good“ means with regard to an everyday object requires a subjective interpretation.

Let me illustrate the problem of this ambiguity with the example of audio (tones, sounds, music).

Quality of audio

Ringtones, alarms, acoustic signals made by our computers, the low-battery warning of our home phones, or even the morning alarm clock radio – tones and sounds („audio“) are everywhere in our technological world.

Fun fact: audio also comes from Latin, and means „I hear“. [2]

To get attuned, you can listen to an example below (or just carry on reading).

Teacoma-Beat audio sample

Some people talk about audio quality, or properly speaking about „high“ or „good“ audio quality.

But what do they mean by that? Have a quick think and try to define more precisely what „good audio quality“ is supposed to mean exactly.

Imagine an important person („stakeholder“) has stated „good audio quality“ as a requirement. You and your small team have a delivery commitment and have to meet this requirement.

(Please have a brief think.)

The sound sample above probably didn’t help in your thinking, unless you listened to it with stereo headphones …

Let’s address a few possible interpretations of the term „audio quality“:

Wave forms of our sound sample – left and right channels
Wave forms of our sound sample – left and right channels

Speech (generated)

Speech with (bad) space effects
Audio sample in stereo
Audio sample with echo, hall, and more bass

By now at the latest, you should be asking how our (hypothetical) development team should produce audio quality. The interpretations presented above are mostly mutually exclusive – it is impossible to fulfill all of them at the same time. And yet taken in isolation, all of them are plausible, at least in my opinion.

Stipulating the requirements of audio quality

Let’s play the role of „stakeholder“, and set the following requirements for our audio sample.

Our audio should:

While these requirements are certainly still far from perfect, they are a step in the right direction in terms of concreteness and precision – and easily verifiable for a development team. As a requirement, this is in my opinion much more appropriate than the phrase „high audio quality“.

In reality a range of stakeholders play a role, each bringing their own interpretation. Software architects must then be able to identify potential conflicts and contradictions, and resolve these with the stakeholders.

Quality in software

When already the term „audio“ subsumes this many individual features, how will it look with the much broader term „software“? In the following diagram I have collated a few terms related to the subject „quality of software“.

Terms relevant for software quality
Terms relevant for software quality

Many intelligent people have already described at length how we can make the term „quality“ more concrete or more precise. Unfortunately, a lot of this advice has not reached many development teams and product owners (and will no doubt be the subject of a future blog post).

Take a look at the article on quality storming by my colleague Michael Plöd – you will find a lot of constructive advice there.

In addition, at arc42 there is a collection of (freely available) examples of concrete quality requirements.

Thank you

Thank you for reading this far – hopefully this post will have sharpened your awareness of the importance of concrete and explicit quality requirements.

If you (or your colleagues) prefer to watch it as a video, it’s available (in German) on YouTube.

Many thanks to Matthias Deja and Joachim Prätorius for their constructive feedback.

Other posts in this „series“

If you have an IT-relevant term that you would like to have explained here, please let us know.


  1. German Wikipedia article on “Quality”  ↩

  2. German Wikipedia article on “Audio”  ↩