Requirements Gathering: Turning a Wish List into a Scope

9 Oct 20262 min read

How raw requests become a scope that can be built, estimated and checked, without losing what the business actually needs.

Requirements Gathering: Turning a Wish List into a Scope

Almost every project begins as a list: features someone would like, phrased as they occurred to them. The list is not wrong, but it is not yet a scope, and the gap between the two is where projects go over budget.

Separate the need from the proposal

"We need a dashboard" is a proposal. The need underneath might be "we cannot tell which products are selling this week". When you write down the need, better and cheaper proposals often appear, including some that need no software at all. This one step is worth more than any amount of detail added afterwards.

Write the workflow, not the screen

Describe who does what, in what order, and what they need to know at each step. Screens fall out of that description almost mechanically, and the edge cases, exceptions and hand-offs become visible while they are still cheap to discuss.

Ask the awkward questions early

What happens when the record is missing? When two people edit at once? When the payment fails, the item is out of stock, the user has no permission, the network drops? Which of these matter, and what should happen? Deciding these in writing during requirements is the single largest source of savings available to a project.

Define done

For each requirement, a sentence describing how someone will know it works: a case that can be entered, an output that can be produced, a condition that can be checked. Requirements without a definition of done become debates at the end.

Mark the boundaries

What the first version will not do, which systems are out of scope, what is assumed to exist already. The excluded list protects the schedule and gives both sides an objective reference for change.

Keep it short and current

One document, written plainly, updated when decisions change. Nobody reads forty pages, so nobody notices when page thirty-one contradicts page twelve.

How we do it

Discovery and planning at Black Origin IT exist to produce exactly this: a scope with needs, workflows, edge cases and definitions of done, before design begins.

Starting from a wish list? Send us a project description and we will turn it into a scope.