OK, so once you have defined the quality activities required for each deliverable, you are now in a position to start identifying quality requirements for the deliverables – hardware, software, documents, scripts.
This is where many projects really fall down – of those that made it this far 😉
I’ve written about ISO9126 before, but it’s important to start off with just the basics and build a foundation. This includes both customer and staff expectations.
It’s really an education process – making sure everyone has a common understanding of the quality activities and how to define and use quality requirements.
ISO9126 defines many potential attributes and when projects try to use it they often attempt to use all of them (the ‘ilities’).
But defining them all without having the process and quality infrastructure in place, you end up with:
a) a mess that no one understands
b) a complex specification that no one understands or cares about
c) a mess that causes chaos during scoping, testing and more
So instead, just define a few quality requirements for your most critical deliverables.
Software – reporting module 0 level 1 defects, <15 level 2 defects
Document – specification 0 level 1 defects, < 20 level 2 defects
But you might say “whoa! Defects remaining in the specification? Are you crazy?!”
Well, no. In many projects we may not have time to get all known defects corrected – particularly if they’re not vital to the functioning of the product.
Once you have defined these basic defect measures, check with the team, the sponsor, customers and any other stakeholders. Remember it’s an education process and people are often not used to this.
Once you have defined and agreed the defect levels, ensure that you have the activities and the checks built into the schedule. No use having defect levels but no tasks or time to manage them.
By the way, remember to define what defect levels mean – a level 2 might be different between a document, script and source code. Don’t get hung up on severity versus criticality – this is a semantic argument and doesn’t add value to your project. Just make sure you are consistent in your use.
If you define defect levels as quality requirements, you’ll find a better understanding and gain more visibility into what customers actually want.
We’ll cover more sophisticated quality requirements (e.g. maintainability, understandability) next time.
PS these quality requirements/attributes are often called “non-functional” requirements.