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.
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.