Business Analysis — Frequently Asked Questions
Practical answers for analysts — separating needs from solutions, handling conflicting stakeholders, how much documentation, working in agile teams, and what makes requirements survive delivery.
The craft#
What is the analyst actually for?#
Making sure the thing that gets built addresses the problem the business has. That sounds obvious and is the job in full: most delivery failures are not engineering failures, they are cases where the wrong thing was built competently.
The work is understanding the current process honestly, separating need from requested solution, and writing it down so a delivery team can act without guessing.
How do we separate a need from a solution?#
Ask what decision the person is trying to make, or what task they are trying to complete. Someone asking for a dashboard is telling you they cannot see something. Someone asking for a new field is telling you information is missing at a particular moment.
Record the requested solution too — people feel unheard otherwise, and their suggestion is often informed by knowledge you do not have. Just do not mistake it for the requirement.
What single question yields the most?#
"What do you keep in a spreadsheet outside the system, and why?"
Shadow systems mark exactly where the official process fails. They are built by the people who do the work, they are unglamorous, and they are the most accurate documentation of real requirements in most organisations.
How do I find requirements nobody mentions?#
Ask about exceptions and about failure. "Walk me through the last time this went wrong." The happy path is what people describe; the exceptions are where the effort goes and where the defects land.
Also ask about volumes and period-end. A process that works fine for ten cases a day and collapses at month-end is a requirement nobody stated.
Stakeholders#
Two stakeholders want contradictory things. What do I do?#
Record both, make the conflict explicit, and take it to whoever owns the decision. Do not resolve it quietly in favour of whoever is more senior or spoke most recently.
A conflict is information about competing business priorities. Surfacing it is the analyst's job; deciding it is not.
What if the people I need are too busy to meet me?#
Reduce the ask and bring something to react to. People who cannot find an hour for open questions will often find fifteen minutes to correct a draft that is wrong.
Reacting is easier than generating. A rough process diagram with deliberate gaps gets more correction than a blank page gets contribution.
What if I only get access to managers, not the people doing the work?#
Say plainly that requirements from managers describe the process as it is supposed to work, and that the difference between that and reality is where projects go wrong. Then ask for one hour with one practitioner as a specific, small request.
If it remains impossible, record it as a project risk. It is one.
Documentation#
How much should I write?#
Enough that a delivery team can build without guessing, and no more. The test is not length — it is whether every requirement can be proved in one sentence and whether someone absent from the conversations could read it and understand.
Long documents get approved rather than read, which hides their contradictions.
BRD, FRD, SRS — do we need all three?#
Only where the risk justifies it. Many projects are well served by one document covering business intent and system behaviour, with engineering detail in the technical design.
The rule worth keeping: intent and behaviour must both be written somewhere, and it must be obvious which is which. See BRD, FRD and SRS.
How do I keep requirements current during delivery?#
Accept that they will change and make changing them cheap. A document requiring a formal process for a clarification will simply stop being updated, and its authority transfers to whatever the team believes.
Keep a decision log alongside it. Half the value of requirements work is the record of what was considered and rejected — otherwise the same question reopens every few months.
Working in agile teams#
Is there still an analyst role in agile delivery?#
The work exists; the artefacts differ. Someone still has to understand the domain, talk to users, surface the exceptions and write things down so they survive.
The trap is assuming stories replace documentation. Stories are ephemeral and get closed. In six months nobody reads a closed story, but somebody will need to know what the eligibility rule is and why.
Who writes acceptance criteria?#
The analyst and the team together, before the work starts. Written solely by the analyst they tend to miss technical edge cases; written solely by the team they tend to describe what is convenient to build.
How detailed should a story be?#
Detailed enough that the team can start and knows what "done" means. The conversation matters more than the text — but the outcome of the conversation needs to be recorded somewhere durable if it established a rule.
Getting better#
What distinguishes a strong analyst?#
Asking the question everyone else read past. The willingness to say "I do not think that is the real problem." And writing that is short, specific and testable.
Domain knowledge helps and is the easiest of these to acquire. The others are the job.
What is the most common mistake?#
Documenting what stakeholders asked for rather than what they need, and doing it thoroughly. The result is a well-structured, well-reviewed document that specifies the wrong system — and because it is thorough, it is convincing.