(continuation from ‘How can we define “quality”?’ blog post)
So, then it follows that “Software Quality” is the trait or character of a software that is subjective to different person or group of people.
That is why it’s very important for a software project to have a requirement specification that everyone in the development team is clear of (though not necessarily agreed of) so that there will be less (it’s unavoidable) confusion along the software development lifecycle.
Because different group of people will always different understanding of what the same software should have.
The end users usually prefer good user interface, ease of use, less number of steps in a process, and fast response. The stakeholders usually prefer fast software delivery, cheap software cost, and zero faults. The developers usually prefer good software practice implementation, decoupled system, and simple requirements.
Quickly looking at these differences, we can see that they can conflict with each other, and thus a balance must be made between them.
Windows from business perspective is a very successful product, thus it can also be said that it has a very high economic quality, disregarding what the computer geeks (me included) may say about it’s stability quality.
In reality, we cannot satisfy everyone, and in fact, trying to satisfy everyone is a recipe for a disaster.
Thus, I think it’s always good to identify who are the target of the software first, see what are the requirements that need to be prioritized, and satisfy these requirements.
Since software, being “soft”, have the advantage to be modified as the priority of the requirements change, this also means that a high quality software doesn’t always guaranteed to have the same high quality in the subsequent release, and also the opposite.