A vague spec is cheap at the start and expensive at the end: everyone reads it their own way, and the budget ends up paying for the difference. Business analysis turns an idea into an agreement that the client, designer, developer and tester all understand in the same way. Here is what a business analyst does, and what goes into a specification that genuinely protects your money and your timeline.
In short
- A vague spec leaves room for different interpretations, and each one later turns into rework, a dispute or a missed deadline.
- A business analyst clarifies goals, users and scenarios, writes the requirements, sets priorities and defines acceptance criteria.
- Prototypes, user stories and a clear process for changes keep the scope and the budget under control.
Why a vague spec is expensive
Take a typical line from a specification: "A website with a customer account area". The client pictures order history, saved addresses and one-click repeat payment. The developer estimates a password login and a profile page. Both honestly believe they've agreed.
The gap comes to light at the demo, when most of the work is already done. Now there are two bad options: pay extra for the "obvious" features, or launch a product that doesn't do what the business was counting on. On a fixed-price project, this becomes a dispute about what was agreed. On a time-and-materials basis, the budget simply grows without anyone noticing.
Vagueness is almost never bad intent. Each side fills the gaps with its own assumptions, and nobody checks them before development starts.
What a business analyst actually does
A business analyst translates between the language of business and the language of development. They ask the awkward questions early, when an answer costs an hour of conversation rather than a week of rework. Their work usually comes down to six steps:
- Goals. Find out which business problem the product solves and how you will know it works: more enquiries, less manual work, a new sales channel.
- Users. Identify who will use the product, for example customers, managers and administrators, and what each of them wants.
- Scenarios. Describe the user scenarios: how a customer finds a product, places an order, returns it.
- Requirements. Turn the scenarios into functional requirements (what the system does) and non-functional ones (how fast, how secure, on which devices).
- Priorities. Rank them, for example with the MoSCoW method: Must have, Should have, Could have and Won't have this time.
- Acceptance criteria. For each requirement, write down the conditions under which it counts as done.
What a good spec contains
A good spec doesn't have to be long, but it does have to be unambiguous: two people who read the same point picture the same result. It usually includes:
- Project goal and scope: what is included and, just as important, what isn't.
- User roles and what each one is allowed to do.
- Scenarios and user stories for each role.
- Functional and non-functional requirements, with priorities.
- Integrations with payment systems, a CRM or delivery services, and who is responsible for each.
- Acceptance criteria for every feature.
- A prototype of the key screens.
The "out of scope" section is often underrated. It heads off many disputes at the end of a project, because the answer to "wasn't this supposed to be included?" is already in writing.
Prototypes and user stories: agree before you build
Text is easy to read in different ways; a screen is much harder to misread. That's why requirements are best tested with two tools.
A user story describes a feature from a person's point of view: "As a customer, I want to save my basket so that I can finish the order on my phone later". This format keeps the focus on value rather than technical details, and it immediately suggests how to check the result.
A prototype is a clickable mock-up of the screens with no real code behind it. The client "walks through" the product before development and spots gaps that text hides: an extra step at checkout, a missing button, an unclear order status. Changing a prototype costs far less than reworking finished code.
How to manage change and protect the budget
Changes during a project are normal: the business learns and the market moves. The problem isn't change but change that nobody has assessed. Small "could you also add" requests pile up, and this effect is known as scope creep.
The protection is simple. The agreed spec becomes the baseline, and every new idea goes through a change request. It is written down and assessed for time, cost and impact on the deadline, and the client decides whether to add it, swap it for something of lower priority or move it to the next phase. MoSCoW priorities help here: a new must-have can replace a could-have, so the budget doesn't grow.
This is how business analysis protects the budget and timeline from three sides. Estimates rest on a clear scope, everyone knows what "done" means, and work is accepted against criteria rather than impressions.
Checklist
- Define the project goal and how you will check that it has been met.
- Describe all the users and their key scenarios.
- Prioritise the requirements, for example with the MoSCoW method.
- Write acceptance criteria for every feature.
- Approve a clickable prototype of the key screens before development starts.
- Record what is out of scope.
- Agree on how changes will be assessed and approved.
How we do it at IANKO
We start every project with the "find the purpose" stage, led by our Business Analyst together with our Project Manager. They clarify your goals, describe the users and scenarios, and write prioritised requirements and acceptance criteria. Our designers turn these into a prototype you approve before any code is written, and later our QA engineers and testers check the product against those same criteria. We assess every new idea during the project and agree it with you separately, so the budget doesn't grow unnoticed.
The bottom line
A good spec isn't bureaucracy. It's an agreement that everyone on the project understands in the same way, and every hour of business analysis at the start reduces the risk of rework, disputes and overruns at the end. Before asking how much the product will cost, agree exactly what will be built.