26 July 2005

Classify requirements to separate the whys from the hows

By Andrew Clifford

Identifying which requirements are really driving IT change gives the clarity needed to define small, simple projects that focus on meeting true business need.

Last week I wrote about IT demand side management and the need to separate the whys from the whats and the hows.

I want to share with you a requirements classification approach I have used to make this separation.

Traditionally requirements classification has involved labelling requirements as critical or non-critical; or low, medium or high. But this is a supply-side view of requirements. It specifies what has to be met, and what can be dropped if time or money run short. Before that value judgement can be made, you need to make sure you have a list of requirements that really reflects business need.

To illustrate, I was working on a project to select a product information system for a retailer. It had gathered a list of 700 requirements. This was little more than a collection of wish lists from various stakeholders.

The list of requirements was unmanageable, so I did three things: removed duplicate requirements; classified the requirements; and then split the requirements by functional area.

The classification wasn't an attempt to say how important the requirements were, but only what sort of requirements they were. My classification was something like this:

The really important split is to understand the primary drivers (needed to make decisions on the project), the secondary requirements (needed as an input to design if the project goes ahead), and the rest (which don't really matter).

From the list of 700 requirements, my initial analysis found 80 primary drivers, of which 30 were in scope for the project we were considering. This was obviously a much easier list of requirements to work with.

I wanted to do a bit more work, to understand the value of those 30 or so requirements, to get down to a core of critical drivers. But I never got the chance. I presented my interim analysis to the project sponsor, and he cancelled the project there and then. The requirements classification gave him the clarity he needed to see that the project, as it was constituted, could not deliver him value.

This little piece of work was one my biggest successes. It helped the company save millions of pounds simply by stating clearly what the project was about.

Most projects I've seen fail to make these distinctions in their requirements, leaving them to struggle to meet numerous requirements that are not important. I'd love to hear about your experiences, and whether you think we need to use this type of classification more.