Minimal IT logo and link to home page
Research, training, consultancy and software to reduce IT costs
Home | About | Newsletter | Contact
Previous | Next Printer friendly
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:

  • Primary drivers. Reasons for having a system, in this case such things as storing product information.
  • Secondary requirements. These are significant aspects of the solution, but not reasons to have the solution. For example, limiting access to the data to only those people who are authorised.
  • Solutions. Many of the requirements were ideas on how a solution should be built, such as how data should be kept synchronised with other systems.
  • Reasonable expectation. Many of the requirements were rather banal, such as "ability to maintain data".
  • Unspecific, unclear, out of scope, or not required.

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.

Next: How to check that IT is worthwhile

Subscription

Subscribe to RSS feed

Latest newsletter:
Magical metadata

We use the term "metadata-driven" to describe IT solutions in which functionality is defined in data. Taking this to the extreme can provide unparalleled levels of speed, simplicity and versatility.
Read full newsletter

System governance

System governance helps you implement high-quality systems, manage existing systems proactively, and improve failing systems.

Find out more