Have you ever asked yourself (or a colleague) how detailed the requirements should be? It is a question I get asked frequently, and one I ask myself quite often. The correct answer is: “it depends”. In this post I hope to provide some answers that are a bit more actionable than “it depends”. Here are some considerations to help you work out the correct level of detail.
What is the next step?
The ‘right’ level of detail largely depends on what the requirements will be used for, i.e. what the next step in the process is. Obvious? Sure, but nevertheless often overlooked. Some examples of requirements uses are:
- as input for the initial business case & subsequent go/no-go decision;
- as a basis for COTS software selection;
- to make a size estimate based with function point analysis;
- as a guideline for yourself when designing an app;
- to discuss with the product owner before the next sprint;
- to provide to external parties as part of an EU public online tender;
- as input to a test strategy workshop.
Looking at the above list, it is clear that they don’t all call for the same level of detail.
Who will use this?
In a similar way to “what is the next step?” the right level of detail may vary depending on who is going to use these requirements. How much or how little does that person know about the business domain? How much time is (s)he going to be prepared to spend on reading and understanding your requirements? Does (s)he have a different cultural background, and if so: how does that affect the way they interpret your requirements?
When is this needed?
One great thing about Agile is the renewed focus on just-in-time delivery of requirements. Requirements change, so if you write them down long before the solution is needed there is a chance that the requirement has changed before the solution is delivered. The more detailed the requirement, the more likely this is. It is sensible to delay writing the details until they are actually needed.
There is catch to this: when you think you need the details may not be when you actually need them! Details sometimes come with nasty surprises (e.g. unanticipated complexity, significant architectural impact, etc.). Why do you think someone coined the phrase “The devil is in the detail”?
Do the stakeholders care?
If you are getting into some nitty gritty details and wondering if these are relevant requirements or just arbitrary solution suggestions, congratulate yourself: you should be! That doesn’t mean they aren’t needed, it just means you are right to want to check. Try to find out if the stakeholders care about those details. If they do (I mean, if they really do care), then you are probably still specifying requirements rather than solution suggestions.
For example, if the stakeholder is requesting a specific colour you may think that is trivial or irrelevant, but perhaps the colour is required to comply with a standard.
What is the impact of too little detail?
Too much detail is sometimes the result of fear: fear that you’ll get a ‘solution’ that meets the requirements, but doesn’t meet your needs. This is a valid concern, yet the remedy can be worse than the disease. To overcome the fear you might ask yourself: if I leave out further details in this area of requirements, what could go wrong? Is that bad? Is it worse than spending an extra couple of days writing detailed requirements?
A large fear of getting the wrong solution could be an indication that you don’t trust your supplier. Is that fair on your supplier? If yes, why not select a different supplier, or a different way of working together?
Consider the rationale
There are many more considerations that can help determine the right level of detail for your requirements, but the ones in this post should be a good starting point. I’d like to wrap up with a technique that I sometimes use when reviewing requirements. It doesn’t help avoid too detailed requirements being written, but it can help remove them before the people in the next step of the process have to deal with them.
The technique is quite simple: find a suspiciously detailed requirement and ask why that requirement is needed. (As an alternative, if the requirement has a rationale, then use that as the answer to the why-question.) Next, consider what would happen if you replace the requirement with the answer to the why-question. If that is sufficiently detailed, then it is probably better than the original requirement.
I won’t go into more detail here, but if this raises any questions please contact me!