The ISO what?
For quite some time now, I had been assuming that that the ISO/IEC list of software quality attributes is pretty much common knowledge, at least amongst the architect/analyst crowd. It turns out I was wrong. After a first hint in this direction a few weeks ago, I started asking around to see if folks had ever heard of the list. Despite some deficiencies in my sampling methodology (which pretty much entailed asking folks about it whenever I happened to think of it), the 100% blank stare response rate pretty much settled that question. At least it gave me something other than the fully trusted GAC to blog about… 😉
Momma and Poppa Bear
For those of you who might care about such things, this quality attribute stuff comes out of the software and system engineering sub-committee (SC 7) of the joint ISO/IEC tecnical committee on information technology (JTC 1). The relevant published standard is ISO/IEC 9126, which currently ships in 4 parts, all of which are listed under (surprise!) the standards published by JTC 1/SC 7. If you want to buy copies of these beasties, you might want to check the list of international member stores rather than buying directly from the ISO mother-ship and letting your credit card company profit off a conversion from Swiss francs.
What if I don’t have buckets of money to spend on this stuff?
OK, time for a small confession. I’ve never forked over money for the full standards either. My bad, although I do keep hoping to eventually work on a project that would merit it. In the meantime, I’m still using the quality attribute list even though I’m blissfully ignorant of the full methodology outlined in the standards, and there’s no reason you can’t do the same. The simple fact is that many/most of us don’t work on applications that are likely to merit the full methodology anyway, and development of such applications usually tends to be supported by QA teams that get paid to worry about this stuff on a full-time basis. 😉
If you want to get a copy of the quality attributes list without shelling out the big bucks, a good place to start is Wikipedia. Unfortunately, the Wikipedia list doesn’t include descriptions of the subcharacteristics, but you can pick those up from the EAGLES-I report. One thing to watch out for is that these lists are not all-inclusive. For example, since both are based on the 1991 release of ISO 9126, they are missing some subcharacteristics that appear to have been added in the ISO/IEC 9126-1:2001 release. At least a partial list of these can be seen at http://www.hostserver150.com/usabilit/tools/r_international.htm#9126-1. Also, you should keep in mind that the list was never meant to be exhaustive, and you may find that you need to make your own additions. For example, I like to add an “accessibility” subcharacteristic under “usability” since, even though it’s sort of implied under “operability”, I want to make sure that it gets considered in its own right when using the list.
So what the heck is this thing good for anyway?
So, now that you’ve got the list, what are you going to do with it? Obviously, it’s not suitable as a guideline for everything that ought to be done in any given piece of software. If you tried to fully implement the whole kit and kaboodle in any single application, you would probably still be working on the beast when the heat death of the universe eventually rolls around.
Personally, I like use the list more or less as a checklist of things to discuss with the client during the requirements gathering phase of a project. Ideally, I like to run through at least two rounds of such discussion, preferably in meetings attended by all the key decision makers on both the business and technical sides. The first round takes place at the beginning of the requirements gathering process and, while it can help identify non-functional requirements with major project impacts, it is intended mainly to familiarize the business-side folks with the quality attibutes so that they can consider them as they develop their functionality wish lists. The final (or as final as can be) decisions around the quality attributes would be made at the second round of discussions, which would take place towards the end of the requirements gathering process, once at least the broad strokes of the functional requirements are presumably known.