Requirements gathering
Requirements gathering is the process of establishing what a piece of software must do, for whom, and how anyone will know it worked. It produces a written, prioritised and testable description of scope, and it is the activity that most determines whether later estimates hold.
Also known as: Requirements capture, Requirements elicitation, App brief, Business analysis
Last reviewed
Why requirements gathering matters
Software rarely fails because something was built badly. It fails because the wrong thing was built correctly, and that is decided during requirements. A misunderstanding here propagates through design, build and testing, and gets more expensive to correct at every stage.
It is also what makes a quote trustworthy. A supplier pricing a vague brief is pricing their own interpretation, so two quotes for the same idea are not comparable. Written, prioritised requirements turn a range into a number and make competing suppliers answerable to the same scope.
How requirements gathering works
Good requirements come from watching work happen, not only from asking about it. People describe the process as it is supposed to run; the exceptions, workarounds and spreadsheets only appear when you sit with them while they do it.
The output is usually a mix: user types and what each may see and do, the jobs each needs to complete, the systems involved, the rules that constrain the work, and acceptance criteria saying how each item will be judged done. Prioritisation is not optional — an unprioritised list of 80 requirements is a wish, and the first question any estimate forces is which 20 come first.
Requirements gathering vs a specification
A specification is the document. Requirements gathering is the work of finding out what belongs in it, and the two are frequently confused in a way that causes trouble.
Being handed a completed specification is not the same as having had requirements gathered. Most specifications we receive are accurate about the intended process and silent about the exceptions, because the author knew their own work too well to notice them. A supplier who accepts a specification without doing their own elicitation is deferring the discovery to the build, where it becomes a change request.
When you do it
Requirements gathering happens before estimating and before design, and it recurs — each release refines the next. It normally sits inside a bounded engagement rather than standing alone: on our Quickstart App Planning engagements the process typically completes within 3 to 6 weeks and produces the scope and estimate you then build against. A broader discovery phase wraps the same activity in feasibility checks and a build-or-not recommendation.
Revisit the list after the first release rather than treating it as settled. Real usage reorders priorities more reliably than any workshop, and the requirements that survive contact with users are the ones worth building next.
Requirements gathering: common questions
The people who do the work, not only the people who manage it. Managers describe the intended process; the staff running it know the exceptions and workarounds, which is usually where the real requirements hide. Include whoever will have to approve the budget, so priorities are agreed by someone who can set them.
It helps a great deal, but a supplier should still do their own elicitation. Specifications tend to be accurate about the intended process and silent about exceptions, because the author knows the work too well to notice them. Accepting one unquestioned defers those discoveries into the build as change requests.
Detailed enough to be testable and prioritised, and no more. Each item should say who needs it, what it does and how you will know it works. Specifying implementation detail this early removes options the build might need, and tends to date faster than the underlying requirement.
Want to talk about your project?
Tell us what you’re trying to achieve and we’ll map the fastest credible path.