Business analyst interviews test how you gather requirements, handle disagreeing stakeholders, and turn ambiguity into something a team can build. Below are the most common questions with model answers.
Every question comes with a model answer you can compare yours against.
Functional requirements describe what the system must do — a user can reset their password, an invoice can be exported. Non-functional requirements describe how well it must do it: response time, concurrent users, availability, security, accessibility. Non-functional requirements are the ones teams forget to write down and the ones most likely to force an architectural rewrite when discovered late.
A user story follows "as a role, I want an action, so that a benefit" — the last clause matters most because it captures why, which lets the team propose better solutions. Acceptance criteria define done in testable terms, often in Given-When-Then form covering the happy path, edge cases, and errors. A story without criteria is an invitation for three people to interpret it three ways.
Interviews go deep on one person's perspective, workshops surface conflict between stakeholders early, observation reveals what people actually do rather than what they say, document analysis captures existing rules, and prototypes get concrete feedback that abstract discussion never produces. The choice depends on how well the domain is understood — the less certain the problem, the more you lean on observation and prototypes.
Make the conflict explicit rather than quietly picking a side: document both positions, the reasoning behind each, and the trade-off. Then bring the stakeholders together with data — usage numbers, cost, risk — and get a decision from whoever owns the outcome. The failure mode is resolving it privately, because the losing stakeholder discovers it at delivery and the work gets rejected.
MoSCoW sorts requirements into Must have, Should have, Could have, and Won't have this time. Must items are the ones without which the release has no value; Won't is the most useful category because it makes exclusions explicit and stops silent scope creep. A common discipline is capping Must at around sixty percent of capacity so there is room for what discovery inevitably reveals.
A use case diagram shows which actors interact with which system capabilities — good for scoping conversations with business stakeholders. A sequence diagram shows the ordered messages between components over time and is aimed at developers designing an interaction. Activity and BPMN diagrams sit between them for process flow, and a state diagram is the right tool when an entity has a lifecycle such as an order or a claim.
A BRD captures business needs and objectives in business language — the why. An FRD translates those into specific system behaviours — the what. An SRS is the full specification including functional and non-functional requirements, constraints, and interfaces, often for a technical audience. Many Agile teams replace all three with a product backlog plus lightweight supporting documents, keeping formal specs only where compliance requires them.
The strongest signal is the questions asked during refinement — silence usually means the team has not engaged rather than that everything is clear. Practical checks are having a developer restate the story in their own words, reviewing acceptance criteria with QA before development starts, and using a prototype or example mapping session to surface hidden assumptions. Anything discovered here is far cheaper than after implementation.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Business Analyst interview →