Business Analysis: Turning a Vague Request Into Something Buildable

Someone asks for a dashboard. Six months later there is a dashboard, and the problem they had is unchanged.

That is the failure business analysis exists to prevent. Not writing documents — establishing what the organisation actually needs before anyone spends money building the wrong thing correctly.

Ask about the problem, not the feature#

When a stakeholder requests a specific solution, they have already done an analysis in their head and given you the conclusion. The analysis is the valuable part, and it is invisible.

So ask what they would do with it.

"We need a dashboard." — What would you look at first? — "Which claims are about to breach SLA." — What do you do when you see one? — "Reassign it to someone with capacity." — How do you find out about breaches today? — "I don't, usually. A customer complains."

The requirement was never a dashboard. It was: a supervisor must be able to see claims approaching breach in time to act. That might be a dashboard. It might be an alert, which would be cheaper and work better because nobody has to remember to look.

Three questions turned a feature request into a problem statement — and left the solution space open.

Requirements that can be tested#

If you cannot write the test, the requirement is not finished.

"The system should be user-friendly" cannot pass or fail, so it will never be verified, so it is not a requirement. It is a hope. Same for robust, scalable, intuitive, fast.

A requirement that works has five parts:

And two rules: one need per requirement (anything containing "and" usually needs splitting, because half can pass while half fails), and never renumber — withdrawn requirements are marked withdrawn, because downstream documents reference the numbers.

Our BRD template uses exactly this structure.

BRD, FRD, SRS — the distinction that confuses everyone#

A BRD naming database fields has skipped two documents and locked in a solution before the problem was agreed. A BRD too vague to test has not done its job either.

The line: describe the outcome precisely, leave the mechanism open.

Not every project needs all three. A small change might need one page. The distinction matters because conflating them is how solutions get decided by whoever wrote the document first.

Finding what nobody tells you#

Stakeholders describe the process as it is supposed to work. The real one differs, and the differences are requirements.

Watch the work. Sit with someone doing the job. You will see the spreadsheet they maintain on the side, the report they export and manually correct, the field they use for something other than its label. Every workaround is an unmet requirement.

Ask what goes wrong. "What happens when it fails?" surfaces exception handling, which is where most missed requirements live and where most rework originates.

Ask who else touches this. Processes cross departments; the person who described it usually knows only their section.

Find the shadow systems. The Access database from 2019 that one team depends on. It exists because something the official system does not do is needed.

Traps that produce shelfware#

Writing for approval rather than use. A document optimised to get signed is vague where it matters, because vagueness is easier to approve.

Group workshops as the only technique. They produce agreement in the room and disagreement afterwards. Walk requirements back to stakeholders individually.

Everything is a Must. MoSCoW works only if "Must" is genuinely constrained. If everything is critical, nothing is, and the first schedule pressure makes the prioritisation decision for you.

No out-of-scope section. Guarantees a scope dispute later. It is the cheapest control available.

Missing non-functionals. Performance, availability, retention, auditability, accessibility. These surface late and are expensive to retrofit.

Silence as sign-off. "No response by Friday means approved" produces approvals that evaporate the moment something goes wrong.

Traceability#

Every requirement should trace forward to a design, a test and a result. This sounds like bureaucracy and it answers two questions that otherwise cannot be answered:

Why does this feature exist? — and what breaks if we remove it?

Maintain it as you go. Retrofitting a traceability matrix at UAT is painful and usually incomplete.

FAQ#

What is the difference between a business analyst and a product owner?#

Overlapping. A BA typically focuses on eliciting and specifying requirements, often across departments and existing processes. A product owner typically owns prioritisation and value for a product over time. Small organisations combine them; the skills differ more than the titles suggest.

Do agile teams need business analysis?#

Yes — the work does not disappear because the document is shorter. Someone still has to find out what is actually needed, whether that lands as a BRD or as a well-written story with acceptance criteria. Teams that skip the analysis build the wrong thing faster.

How detailed should requirements be?#

Detailed enough to be testable, no more. If you can write the acceptance criteria, you are detailed enough. If you are specifying screen layouts in a BRD, you have gone too far.

What if stakeholders disagree?#

Escalate to the named decision-maker for that area — which is why naming one per area matters. Do not average conflicting requirements into something that satisfies nobody, and do not let the loudest voice decide by default.

How do we handle changing requirements?#

Expect them. Baseline what is agreed, then change it through a visible process where every addition names what it displaces. The problem is never change; it is change absorbed silently until the date is missed.

Who signs off requirements?#

The named decision-maker per area, explicitly and in writing. Sign-off by silence is not sign-off, and you will discover that during UAT.

What is the most common cause of rework?#

Requirements that were not testable, so nobody noticed they were ambiguous until someone built one interpretation and the business expected another. Writing acceptance criteria at the same time as the requirement prevents most of it.

What else is coming for Business Analysis