Gathering requirements properly
By Redaktion techport.ai, IT-Beratung · Last updated on
The most expensive sentence in IT projects is: that is not how we imagined it. It gets said during testing, which is exactly the point where changes cost most. The cause almost never lies in poor work. It lies in requirements gathered as a collection of wishes rather than a description of what has to work at the end.
A good requirement is testable. You can determine whether it is met without debating intentions. That sounds obvious and in practice it is the difference between a project with an acceptance and a project with a renegotiation.
How you notice it
- Requirements sit as keywords in a spreadsheet and every point is important.
- Testing raises questions that were already asked in the workshop.
- The vendor says it was not in scope, and both sides are right.
- There is no person who decides what applies in case of doubt.
Why this happens
Requirements are usually gathered from the people who run the process daily, and they describe it as it runs today, including the workarounds that arose from limitations of the old system. At the same time the translation into a form a vendor can quote and a developer can build is missing. On top of that comes the understandable tendency to write down everything ever wished for, because nobody wants to take responsibility for a deletion.
How we go about it
- Process before function. We start with the workflow rather than a function list: who does what, in which order, with which information, and where waiting times and errors arise today. From that workflow we derive what a system has to be able to do.
- Formulate requirements testably. We write every requirement so that its fulfilment can be established, with trigger, expected result and special cases. Added to that are the non-functional points that cause the most disputes later: response times, volumes, permissions, logging, availability.
- Prioritise and let someone decide. We weight into must, should and could, with a named person per department who is allowed to make that call. Without that role every requirement becomes a must and the prioritisation becomes worthless.
- Allow changes in an orderly way. We set up a simple procedure by which new requirements during the project are assessed, costed and decided deliberately. Not every change is bad, but every change has to be visible.
What you gain
- Offers that are comparable because they rest on the same basis.
- An acceptance based on criteria rather than impressions.
- Fewer renegotiations because less is left open.
From our projects
When we derive requirements from the process rather than from a collection of wishes, a substantial share of the original points regularly falls away. The most common reason: they describe workarounds that exist only because the old system could not do something. The second most common: they are special cases occurring once a year for which a manual solution is cheaper than a permanent function. Those deletions are uncomfortable while they feel like sacrifice, and straightforward as soon as the effort per requirement becomes visible.
Häufige Fragen
How detailed do requirements have to be?
Detailed enough that a vendor can quote bindingly and a tester can check fulfilment. For standard software the level of the workflow with its relevant special cases is usually enough. For custom development you additionally need field and rule level, because there nobody has a standard as a fallback.
Who should own the requirements?
Someone from the department who knows the process and is allowed to decide, supported by someone who makes the wording testable. If IT writes the requirements alone they become technical. If the department writes them alone they stay untestable. The two roles together produce a document you can work with.
Let us talk about Gathering requirements properly
In a thirty minute first call we work out where your biggest lever sits and whether we are the right people for it.
Further reading
Back to the field Build and Buy