"We want a new system." It sounds like a clear brief, but it isn't. Which problem must that system solve? For whom? And what does "done" look like? The craft of business analysis is to look past the requested solution to the real need behind it — the question behind the question.
Why this makes the difference
A misunderstood question is the most expensive mistake in a project, and the hardest to undo. Build or buy on the basis of vague wishes and the problem only surfaces at delivery — when changing it costs the most. Sharp analysis up front is not a delay; it is the cheapest insurance there is.
From wish to workable requirement
Business analysis translates what people say they want into what they need — into requirements a supplier or development team can actually act on. A few recurring building blocks:
- As-is and to-be: how does the process run now, and how should it run? The difference is your scope.
- Requirements and user stories: testable requirements — not "the system must be user-friendly", but what that concretely means.
- Prioritisation: not everything matters equally. What is a must, what is nice-to-have?
Standards as a frame, not a straitjacket
For structure we lean on the common standards — BABOK (the IIBA body of knowledge) and IREB for requirements engineering, with BPMN to map processes. But standards are a tool, not a goal. The result is always in plain language: a few sharp choices everyone at the table understands.
The bottom line
Good business analysis costs a few weeks up front and saves months at the back. Whoever has the question behind the question sharp chooses better software, builds fewer wrong things, and delivers something that actually fits.
This article is general information, not legal or organisational advice for your specific situation.