5 exercises — choose the best-structured answer to common BA interview questions. Focus on requirements vocabulary, stakeholder communication, and analytical thinking.
Structure for Business Analyst interview answers
Ask about goals, not features: requirements come from outcomes, not specifications
Name the technique: traceability matrix, MoSCoW, use case, acceptance criteria
Show balance: BAs bridge business and technical — speak both languages
Quantify: NFRs must be measurable, not aspirational
0 / 5 completed
1 / 5
The interviewer asks: "How do you elicit requirements from stakeholders who are unsure of what they need?" Which approach is most effective?
Option A is the strongest: it names four specific techniques (structured interviews, process walkthroughs, prototyping, workshops), gives the concrete question reframe ("what problem are you trying to solve?" not "what do you want?"), explains why outcomes work better than specifications, and gives a second concrete redirecting question (success in six months). Option D identifies a real insight — prototyping unlocks feedback — but presents it as a single technique rather than a diverse toolkit. Option C is solid and mentions user stories with acceptance criteria — good BA vocabulary. Option B is correct but vague. The key insight in Option A: ask about outcomes and pain points, not features — stakeholders are better at describing problems than solutions.
2 / 5
The interviewer asks: "What is the difference between functional and non-functional requirements?" Choose the most complete answer.
Option A is the strongest: it defines both terms precisely, gives concrete examples of each (password reset for functional; 200ms response time, 99.9% uptime, encryption, 10k concurrent users for NFRs), uses the professional synonyms (quality attributes, NFRs), and adds the important principle: they must be testable, not aspirational. The "must be testable" principle separates experienced BAs from beginners — saying "the system should be fast" is useless; "under 200ms for 95th percentile" is a requirement. Option C is good and mentions acceptance criteria for both — a professional best practice. Option D's characterisation of functional requirements as "what users can see and do" is incomplete — some functional requirements are internal to the system. The key differentiator: give a quantified example for NFRs and state they must be measurable.
3 / 5
The interviewer asks: "How do you handle conflicting requirements from multiple stakeholders?" Which answer best demonstrates BA maturity?
Option A is the best: it diagnoses the conflict type first (often apparent, not real), explains the documentation process (position + rationale), describes a facilitated workshop to surface underlying goals, and handles genuine conflicts with an options analysis — explicitly noting the BA role is to inform decisions, not advocate for positions. The distinction between apparent and genuine conflicts is a mature BA insight. Option D also identifies the "find the goal behind the requirement" approach — this is the correct technique and shows experience. Option C is correct on escalation with options analysis but doesn't mention the workshop or conflict type investigation. Option B is good on process but too brief. Key principle: most conflicts are superficial — dig for the business goal; for real conflicts, provide options analysis, not advocacy.
4 / 5
The interviewer asks: "How do you validate that your requirements are complete?" Choose the most thorough answer.
Option A is the most complete: it lists five validation techniques, names the specific artefact (traceability matrices), introduces MoSCoW to distinguish in-scope from explicitly out-of-scope, and ends with the mature meta-observation that requirements are never truly "done" — only "risk-acceptable." Option C flags implied requirements — an often-forgotten validation dimension and a mark of an experienced BA. Option D mentions explicit out-of-scope documentation — also excellent because it prevents scope creep. Option B is correct but lacks specific techniques. The MoSCoW reference in Option A is the differentiator: completeness is relative to risk — you need to define what's explicitly NOT required, not just what is.
5 / 5
The interviewer asks: "What is the difference between a use case and a user story?" Which answer is most accurate?
Option A is the strongest: it gives the formal definition of use cases with their key elements (preconditions, main flow, alternative flows, postconditions), correctly identifies the methodology context (UML), gives the user story template format, names its Agile origin, and — most importantly — contextualises user stories as conversation starters, not complete specifications. This last point is a key Agile insight that separates experienced BAs from those who treat user stories as requirements documents. Option C accurately explains both and uses correct terminology (actors, alternative paths). Option D is accurate but the "Scrum" vs "enterprise" framing is an oversimplification. Option B gives the wrong impression that use cases are exclusively Waterfall. Key insight: user stories are intentionally incomplete — they prompt conversation; the details live in the acceptance criteria and verbal discussion.