Talk to an engineer
Whether you have a full brief or only a rough idea, send it over. Every inquiry goes straight to our team.
Send us a message
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.
