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 / 15 completed
1 / 15
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 / 15
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 / 15
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 / 15
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 / 15
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.
6 / 15
Sarah, the Lead Developer, leaves a comment on your code review: 'This function is too slow. Can you optimize it?' What's the BEST initial response to address her concern while gathering more information?
This scenario tests your ability to respond professionally during a code review. Simply accepting the feedback without understanding the context isn't ideal. Asking for clarification demonstrates active listening and a desire to understand the root cause of the concern, allowing you to propose targeted solutions rather than making assumptions.
7 / 15
Mark, during a Slack discussion about a new feature, states: 'The API needs to return all user data – name, email, address, phone number.' What type of requirement is this primarily?
This question assesses understanding of requirement types. While it involves data, Mark's statement reflects a *business* need – what information the stakeholders require to interact with the system. It's not purely about technical details like API responses (which is a *technical* requirement) or performance (a *non-functional* requirement).
8 / 15
You're drafting the description for a Pull Request to implement user authentication. You include the following: 'As a user, I want to be able to log in with my email address and password.' What's the most important element missing from this description to ensure it's truly actionable?
This question probes your understanding of user story completeness. While the description captures a *what* (the desired outcome), it lacks the *how* and *why*. Good PR descriptions need acceptance criteria – specific conditions that must be met for the feature to be considered complete and tested.
9 / 15
During a standup meeting, David says: 'We're working on implementing the new payment gateway integration.' What question should you ask *immediately* to delve deeper and ensure alignment?
Standup updates often lack detail. This question tests your ability to follow up proactively. Asking about milestones and dependencies demonstrates a BA's commitment to ensuring the project stays on track and avoids potential roadblocks – it moves beyond simply accepting the update.
10 / 15
You've received conflicting requirements from two stakeholders regarding a new reporting dashboard: Stakeholder A wants all available metrics displayed, while Stakeholder B only needs key performance indicators (KPIs). Which approach best addresses this situation?
This scenario tests your ability to manage conflicting requirements. Simply ignoring them or arbitrarily prioritizing one isn't effective. The best approach is to actively engage with both stakeholders, exploring options and potentially implementing a phased approach that addresses their needs incrementally.
11 / 15
Sarah, the Lead Developer, leaves a comment on your code review: 'This function is too slow. Can you optimize it?' What's the BEST initial response to address her concern while gathering more information?
This scenario tests your ability to respond professionally during a code review. Simply accepting the feedback without understanding the context isn't ideal. Asking for clarification demonstrates active listening and a desire to understand the root cause of the concern, allowing you to propose targeted solutions rather than making assumptions.
12 / 15
Mark, during a Slack discussion about a new feature, states: 'The API needs to return all user data – name, email, address, phone number.' What type of requirement is this primarily?
This question assesses understanding of requirement types. While it involves data, Mark's statement reflects a *business* need – what information the stakeholders require to interact with the system. It's not purely about technical details like API responses (which is a *technical* requirement) or performance (a *non-functional* requirement).
13 / 15
You're drafting the description for a Pull Request to implement user authentication. You include the following: 'As a user, I want to be able to log in with my email address and password.' What's the most important element missing from this description to ensure it's truly actionable?
This question probes your understanding of user story completeness. While the description captures a *what* (the desired outcome), it lacks the *how* and *why*. Good PR descriptions need acceptance criteria – specific conditions that must be met for the feature to be considered complete and tested.
14 / 15
During a standup meeting, David says: 'We're working on implementing the new payment gateway integration.' What question should you ask *immediately* to delve deeper and ensure alignment?
Standup updates often lack detail. This question tests your ability to follow up proactively. Asking about milestones and dependencies demonstrates a BA's commitment to ensuring the project stays on track and avoids potential roadblocks – it moves beyond simply accepting the update.
15 / 15
You've received conflicting requirements from two stakeholders regarding a new reporting dashboard: Stakeholder A wants all available metrics displayed, while Stakeholder B only needs key performance indicators (KPIs). Which approach best addresses this situation?
This scenario tests your ability to manage conflicting requirements. Simply ignoring them or arbitrarily prioritizing one isn't effective. The best approach is to actively engage with both stakeholders, exploring options and potentially implementing a phased approach that addresses their needs incrementally.
What does "Business Analyst Interview Questions — Best-Answer Practice" cover?
Practice answering common Business Analyst interview questions in professional English. 5 exercises on requirements elicitation, functional vs NFRs, conflicts, completeness, and use cases.
How many questions are in this interview set?
This set has 15 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.