So why the plural?

Last month, I noted that I had a blog over 2 years ago that was cut very short. I reposted a somewhat revised version of one of the posts, Here's the other initial post, also somewhat revised, explaining why I use "Qualities" plural form.

--------------------------------------------------------------------

A lot of websites and blogs use the singular and, at the time, I was fishing around for something that wasn't already in use. One day, I was also working on something related to the ISO standard (ISO 9126) on software product quality characteristics. At one point I was writing something along the lines of "the non-functional qualities against which software can be compared" and, then, later, "these software qualities." That was even longer ago and I had the idea of using "software qualities" as a website since then.

Since I mentioned ISO 9126 and since it was the "inspiration" for the title of the original blog (and then this one), let me say a few things about this standard in case you are not familiar with it. It addresses what are usually called categories of "non-functional requirements" related to software and which are often known, for short, as the "ilities" because of how many of them end, e.g., maintainability, reliability, portability, etc.

Now you can certainly argue with how they are organized or what terms are used -- I've collected a list of over 100 such terms that I use on one slide in one presentation I give just to point out that the names are not the really important thing. However, having some sort of "model" of quality attributes seems to me to be quite valuable in considering how you plan to achieve quality in software.

Very often, non-functional requirements do find their way into formal requirements specifications, but not always. Sometimes they come up in less formal discussion. Sometimes, and this is the dangerous part, they do not come up at all as they are assumed by a customer. Well, they do come up, but usually after the customer gets their first substantive look at or experience with the software and they say, "What do you mean it doesn't....?"

Being explicit about such characteristics when the requirements are being discussed can avoid a lot of anger and frustration (not to mention cost) later on. So having a "model" that addresses the kinds of non-functional characteristics important to a specific product (or release) is a way to address them in an organized fashion. It can also demonstrate some proactiveness on your part as a software developer.

--------------------------------------------------------------------

That's what I said back then and it's still behind my thinking these days, though, as I noted in my first blog post, I've adopted a more Kano model approach to the "Qualities" ideas which covers functional and non-functional requirements expectations.