Why requirements are not waiting to be collected, how to build an initial backlog from scratch, who to talk to, how to prioritise it, and how long the work really takes.
The requirements myth
“Have you got the requirements yet?” is a well-intended but misguided question anxious stakeholders ask when faced with an urgent need to deliver some kind of system, unrealistic deadlines and the desire for progress. If only the requirements were complete, then the real work could commence, goes their thinking.
Unfortunately, software requirements aren’t necessarily known in advance, they aren’t located in the heads of the stakeholders, and they aren’t solicited in back-to-back Zoom meetings, nor are they lying in hallways waiting to be collected like eggs from a chicken coop. Equally, going around saying “Tell me what you want” is a pretty terrible approach and certainly won’t provide the answers needed or hoped for. You wouldn’t need to hire a business analyst if it really was this easy.
Requirements gathering isn’t a simple linear process, and unfortunately, it often can’t be planned and executed in a deterministic manner. Sure, you can schedule two weeks of stakeholder interviews on a project plan, and you will find out a heap of stuff, but you may not get the answers you need to build the kind of software the business demands, and users want. Interestingly, IT system builds often represent a deep, unmet organisational need and there is immense value in accurately clarifying and surfacing it.
The secret sauce
Time with users is the most significant factor in gathering good software requirements. Adequate time to develop a relationship, build trust, listen intently, ask questions and hear feedback. Adequate time to see how users work, to understand the daily pressures of the environment they work in, and what other tools they use. Adequate time to understand the competitive landscape, the needs of the business and the opportunities to do better or differently.
With a keen eye and an inquiring mind, you start to understand the real user needs and, with luck, suggest features they may not even know to ask for. The magic starts to happen at this point. Software requirements follow: a written hypothesis of the user needs, to be built and then tested.
Better software requirements are about the right conversations, happening at the right time, to the right level of detail, and with decision-making delegated to the lowest possible level. The successful translation between ‘business’ and ’technology’ depends on behaviours not artefacts, and that’s the mindset shift that needs to be made.
Building the initial backlog
Quickly capturing enough of an initial backlog for the early sprints demonstrates progress, aligns developers and allows work to commence. Everyone starts to feel better. The risk of rework and the ability to pivot is considered when compiling the initial backlog, given the high chance of this early work being off the mark. Importantly, commencing development secures the time and remit to commence the real work of understanding deeper organisational needs through immersion in day-to-day interactions with users and stakeholders over time.
When you are replacing an existing system rather than building something new, the discovery problem changes shape: the requirements are buried in software nobody documented and habits nobody wrote down. Techniques for recovering them, including reverse-engineering current behaviour, shadowing users, extracting rules from code, are covered in recovering undocumented requirements.
Who are the stakeholders?
Time with users is where the magic happens, but users are not the only people with a stake in what gets built. Whoever pays for the system, whoever is accountable for it, whoever has to operate or support it, and whoever is affected downstream all hold a legitimate claim on the requirements. Miss one of them early and you tend to find out late, usually when a near-finished feature collides with a constraint nobody mentioned.
Identify stakeholders deliberately. Ask who funds the work, who signs it off, who relies on its outputs, and who would notice if it stopped. Operations, compliance, security and finance rarely come to the user interviews, yet they each carry needs that quietly shape the build. The earlier they are surfaced, the cheaper they are to satisfy.
Stakeholders will also want different, sometimes contradictory things. The sales team wants speed, support wants reliability, finance wants control, and the user just wants to get their job done. This is normal and it is your job to surface the conflict rather than paper over it, because an unspoken disagreement does not disappear — it resurfaces as rework. Make the competing needs explicit, get them in front of the people who can weigh them up, and let the trade-off be a decision rather than an accident.
Requirement decisions should be taken at the lowest sensible level. Escalating every disagreement to a steering committee is slow and disempowering; deciding everything yourself does not scale and is usually wrong. Push each call down to the person closest to the work who can reasonably own its consequences, and reserve escalation for the genuine cross-cutting trade-offs that no single team can settle.
How do you prioritise the backlog?
Not everything in the backlog matters equally, and pretending otherwise is how teams end up building the easy things first and the important things never. Prioritisation is the act of deciding what to build next, and the only honest answer is the most valuable or riskiest work first: the items that deliver the most to users, or that retire the most uncertainty about whether the rest of the plan even holds together.
Think in terms of value against effort. A small change that unlocks a lot is obvious; a large change that delivers little is easy to defer; the interesting decisions sit in between and are matters of judgement, not arithmetic. Beware false precision here. Scoring every item to two decimal places gives the comforting appearance of objectivity, but the inputs are estimates and the ranking is only ever as good as the conversation behind it. A rough, well-argued order beats a precise, poorly-reasoned one.
Above all, do not let the backlog be sorted by who shouts loudest. The most senior voice in the room is not a proxy for the most valuable feature, and a prioritisation that simply reflects internal politics will deliver software that serves the organisation’s hierarchy rather than its users. Keep returning to value and risk, make the reasoning visible, and revisit the order as you learn. The backlog is a living thing, and early priorities set with thin information should change as that information improves.
How long does requirements gathering take?
A good rule of thumb is that for every three to five developers, you need one full-time business analyst to take care of the requirements. The business analyst spends a month of effort preparing the software requirements, for every month of software development the team performs. This is a 20% overhead.
The software requirements work needs to commence ahead of the development, but just enough to get the developers started. Avoid the temptation to define all the requirements in advance. Instead, most of the software requirements should be worked on in parallel with software development, incorporating learnings and emergent requirements as they become known.
The 20% overhead rule of thumb is only a heuristic, but it’s held up well over the years. Mileage will vary; more complex products and bigger development teams require greater coordination; simpler products and smaller teams require less.
Gathering is only the start. Once you have a prioritised backlog, the requirements still have to be written down clearly enough for developers to work unblocked.