Requirements, part 1

In a recent post, I proposed an approach to quality, through the elicitation of requirements, the development of a quality risk analysis, design and delivery activities, testing and the use of the defect and quality logs to record and track progress. I could only touch briefly on each component within the bounds of a reasonably sized blog post, but I said I come back to the topic.


Here's two lines that tell you why you need to be very alert around the topic of requirements.

I can't promise you its linear (in fact, for the cost of defect resolution - I know its not) but you get the picture. Most defects are introduced at the requirements elicitation, scoping and design phases and the cost of resolving them increases radically as the project progresses.There are a couple of articles here and here to support this chart.




Before I make a start on anything useful on the topic of requirements, I'm going to take some time to critically review the MoSCoW method of prioritising requirements.


You can read the basics on Wikipedia - there's not much point in me reproducing it here. 


Sounds eminently sensible doesn't it? Must have, Should have, Could have and Won't have. Get the stakeholders in a room, elicit the requirements, prioritise with MoSCoW. What could possibly go wrong?


Well first, you'd better explain to stakeholders that "won't have" doesn't really mean won't have. It means "wont have this time". And I've never really understood what that means. I know that if you really have a requirement not to have something (say heat output not greater that 50 BTUs) then you have to put it in the Must NOT have pigeon hole along with all the other must haves. By the way, you'll likely have quite a few other Must haves. That's another shortcoming of MoSCoW. While it does prioritise requirements, it's a very coarse tool providing really only 3 gradations of priority.


Your stakeholders are pretty much going to want their requirements in either the "Must have" or "Should have" categories. Must have describes a requirement that must be satisfied in the final solution for the solution to be considered a success. "Should have" represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.*


* From Wikipedia


So you can see from the points here that probably at least 50% of your requirements will likely be ascribed a Must have or Should have status. If any one of those requirements isn't met, you're looking at having to assign the corresponding defect a status of 'critical' i.e. can't hand over while it remains unresolved. Quite how you prioritise your defect resolution activities at this juncture is anyone's guess. Almost all your defects are critical and are ranked with the same priority.


It is also, on its own, very arbitrary. Why is this requirement a "Must have"? "Because I say it is" is likely to be the extent of it. Other approaches might look at cost of non-compliance, stakeholder satisfaction if delivered, a business use case or other factor(s)  to support its status as a critical requirement. Not so MoSCoW, though admittedly it doesn't necessarily preclude it. Even if you do factor in a rationale, you still only have a very coarse yardstick to appraise the relative importance of requirements.


I'll leave the elicitation of requirements, their management, tracking and a host of other points for other posts. But requirements have to be prioritised in almost all instances (more on this too) and in conclusion to the points above that prioritisation should be; finely graded, evidence based, unambiguous and tailored to your specific needs.


In the mean time - some additional reading on the topic here. I couldn't put it better myself, so I won't try.