Requirements, part 3

So far, I've had a good whinge about the MoSCoW method of requirements prioritisation, and suggested the alternative method of paired comparison. In this post I'm going to talk a little about the life-cycle of a requirement and why the management of requirements is pivotal to testing and product acceptance. In a future post, I'll come back to the topic of requirements prioritisation to provide a middle ground between MoSCoW and paired comparison.

 First, let's revisit the method of achieving quality I put forward in a previous post.

It's probably time to add a few more specifics around this, and that in turn will provide an entry point into several subsequent posts.

1. Requirements - this is the subject of this post and (at time of writing) two others besides. The scope of this activity extends to the elicitation, prioritisation, specification and management of the requirements
2. The QRA will be the topic of a subsequent post. For those impatient to get to grips with this, read Rex Black's material here. In short it's an analytic approach to prioritising the testing effort with a view to minimising risk
3. Development and implementation - we will get to this at some future point. As project manager you should be planning, directing and controlling this activity.
4. Testing - a big big topic but I'll endeavour to distil some valuable points during the course of future posts. I'm a big fan of V-Model development and sowing test activities throughout all development activities. Crucially; every development activity has a corresponding test activity. I would also keep in mind IEEE 829, a standard approach to test plan management. Links here and here Plenty more to come on this topic.
5. Defects have a management life-cycle all of their own. This is to ensure that efforts to resolve the defects are suitably prioritised, that defects when resolved are confirmed as fixed and a whole host of other activities. I'll post a couple of articles on this in the future.
6. Lastly the quality log. Technically, it is not strictly required however, in isolation the defect log (a component of defect management) paints an overly bleak picture. (Try having a defect log of 600 things which don't work - it doesn't make for happy project boards either). Incidentally, it helps too with product acceptance as opposed to the defect log (recording things which don't work) it provides a central repository encompassing all the things that do work.

So with this all said, let's focus on the role requirements play at each stage above. First, there's the requirements themselves. The QRA cannot be produced without a clearly understood set of requirements and do please note that this tool is sometimes crucial in placating legitimate stakeholder anxieties. Undoubtedly it is possible to start development and implementation activities without a detailed requirements specification. Doubtless too, this is one of the principal causes of project failure. You can certainly build something, but you cannot achieve quality without a clear understanding of what is required. Testing specifically is the activity of identifying defects and defects are defined as requirements that haven't been met. You cannot test a system if you don't know what the requirements for that system are. Defect management - the process of managing defects through the defect life-cycle cannot be undertaken without a detailed understanding of requirements.

So at every stage of this activity, requirements are playing a principal role. I think that'll probably suffice in terms of the 'big picture'. I have endeavoured to provide a solid basis upon which to build in future posts. These will include posts on how I typically approach the prioritisation of requirements, an explanation of the QRA, a complete review of the defects management life-cycle and more besides.