Mostly harmless, conspicuously useful

The Hitchhiker's Guide to Becoming a Business Analyst

A business analyst bridges business needs and technical solutions by eliciting requirements, modeling processes, and validating outcomes, which is a perfectly reasonable arrangement until you remember that the stakeholder knows exactly what they want and will tell you immediately after you build it. You learn to translate "the system should be better" into requirements that are unambiguous until engineering begins, process maps that describe the process as it actually runs rather than as the policy imagines it, and gap analyses that identify the gap between what was requested and what was funded. The requirements document is a document the business signs and engineering interprets, and the gap between those two readings is where most projects actually live. This guide travels from observing one stakeholder interview to setting analysis practice across an organisation, with practical stops at elicitation, process modeling, documentation, solution evaluation, and the recurring discovery that a process mapped is a process that has been photographed, not a process that has been improved. The grand objective is a solution that meets the need and the budget; the daily evidence is usually a requirement that a developer can build, a model that a stakeholder recognises, and a gap analysis that fails to surprise anyone except the sponsor, who has learned not to be surprised by their lack of surprise.

Things to recognise

• A requirement described as a solution describes a thing the stakeholder already imagined; the underlying need is usually larger, smaller, or adjacent, and building the solution verbatim is the fastest way to deliver the wrong thing on time.
• Stakeholder lists carry hidden maintenance cost: each name must be interviewed, informed, consulted, and eventually disappointed, so a list that grows without pruning becomes a museum of opinions no one revisits.
• Confirm the need, the affected stakeholder, and the evidence before writing the requirement, because a correct requirement for the wrong need is still impressively wasteful and surprisingly persistent.

Take the useful exit

Level 1 · Novice

Listen to the stakeholder before writing the requirement they will disown

You observe interviews, workshops, and meeting notes without committing scope, learning how a sentence beginning "the system should just" can end in a programme of work.

You begin with read-only artifacts: interview notes, workshop summaries, current-state process diagrams, existing requirement documents, a glossary the project maintains, and a stakeholder list expressing recent opinions about recent needs. Requirements elicitation is drawing out real needs through interviews, workshops, and observation, while stakeholder communication keeps business and technical audiences aligned in their own language. You review these with developers, testers, project managers, and an experienced analyst so that everyone can trace how a vague wish becomes a written requirement before anyone writes a line of code whose acceptance criteria is still "you know what I meant."

Suppose a stakeholder reports that "the new system should be faster." In an elicitation review, you read the interview notes and find that "faster" means three different things to three different people: the screen loads faster, the batch finishes before the morning meeting, and the approval arrives before the deadline. You draft a set of measurable needs, list the jobs each satisfies, and note that none of the three mentioned the other two. One brisk notes summary is an anecdote with good posture, not a requirement; but it prevents the team from commissioning a performance overhaul for a job that one stakeholder performs twice a year with a perfectly good email.

Words from the spaceship manual, translated

Requirements elicitation: The practice of drawing out real needs through interviews, workshops, observation, and document review, before deciding what to build. It is the practice of finding out what is wanted, which is faster and cheaper than building something and then asking.
Stakeholder: A person affected by, accountable for, or interested in the outcome of a change. The term is useful precisely because it avoids naming who, and dangerous for exactly the same reason.
Need: A statement of what a stakeholder requires the solution to achieve, expressed in measurable terms. A need that mentions a button is a solution in a costume, and a need that no one can measure is an opinion with a heading.
Current-state diagram: A model of how a process runs today, drawn from observation rather than policy. It describes the process as it is, not as the documentation claims, and the gap between the two is the first requirement.