It always comes back to Requirements

I’m just going to say it – many people in IT don’t give enough thought to requirements. They might think they do, there may even be a document with the word “Requirements” in the title, but are they good enough for the job?

I’m sure there are erudite and exhaustive documents out there on “how to write good requirements” but I’m going to ignore all those and list my top “requirements for requirements“.

1. They must be precise

Or – they must not leave room for interpretation.

As one of my colleagues said to me the other day “they have to pretend we’re 6”. It’s really hard to write requirements to such a level of exactitude that two different readers won’t come away with two different impressions, but we really do have to aim for that.

2. They must be comprehensive

If it’s not on the requirements list it’s not in the solution. End of.

This takes discipline both in writing requirements and in delivering them. Many customers seems to think that a conversation in a meeting/over email/at the coffee shop will lead directly to additional functionality in the solution. Not unless it gets added to the requirements it doesn’t.

3. They must be testable

Requirements are the basis of both testing and solution acceptance.

I think it really helps, when writing requirements, to think “how would someone test this?”. If we can’t demonstrate we met all the requirements then how can anyone say when the work is done?

4. Business requirements are different to Solution requirements

The business requirement may be “A user account for a new starter will be provisioned by their start date without manual intervention”.

That simple sounding sentence actually contains large numbers of solution requirements which will include HR data feed, solution run schedules, provisioning logic, attribute population rules, start-date workflow, extras such as email account, home folder….

Business requirements will often un-pack to tens (even hundreds) of individual solution requirements, and yes we do need to capture them all (see points 1, 2 and 3).

Oh and by the way – if it took a couple of weeks to write the business requirements, and that’s going to turn into (say) ten times as many solution requirements… I’m not saying it will take ten times as long to write the solution requirements, but it’s certainly not going to be a small amount of effort.

In Summary

You wouldn’t get someone to come in and build a house without incredibly detailed plans, designs, and lists of requirements right down to floor coverings and taps. And we shouldn’t attempt to build complex IT solutions without that level of planning either.