A business analyst interview can explore how you understand a need, work with stakeholders, clarify requirements and evaluate a proposed change. Memorising definitions helps less when you cannot apply them to a realistic example or explain the limits of your experience.
This guide provides fourteen practice questions with original answer approaches and a fictional case. They are not leaked employer questions, a universal interview sequence or a scoring guarantee. Read the vacancy to identify the responsibilities and tools relevant to the role in India.
Editorially revised on 8 October 2026. Cases and sample approaches below are fictional teaching material.
Use terminology with purpose
IIBA’s requirements and designs guidance distinguishes business, stakeholder, solution and transition requirements; solution requirements include functional and nonfunctional aspects. It also explains requirements as representations of needs and designs as representations of solutions.
Use those distinctions to ask better questions, not to force every organisation into the same document template. The remaining practice examples are original applications of general analysis reasoning, not reproduced IIBA cases or an official certification assessment.
Fourteen questions and practical answer approaches
1. How would you clarify an unclear request?
State the need, affected people and desired outcome before assuming a feature. Ask what happens today, which problem matters and how success would be assessed. Identify uncertainties and arrange confirmation with the relevant people. Avoid claiming you would simply implement the first requested solution.
2. What is the difference between a requirement and a design?
Explain the need-versus-solution distinction, then give a bounded example. In a fictional appointment process, users might need to identify available slots; one proposed design might be a calendar view. The calendar is an option to evaluate rather than proof that the need has been understood fully.
3. How do you identify stakeholders?
Consider who uses, funds, maintains, approves or is affected by the change. Explain how you would check for missing perspectives. A stakeholder list should serve the actual initiative rather than become a long collection of job titles unrelated to the problem.
4. What if two stakeholders disagree?
Clarify their needs and constraints separately. Document the disagreement, compare its effect on the outcome and involve the appropriate decision owner. Do not imply that the analyst always has authority to choose the final priority or that agreement can be guaranteed.
5. How would you prioritise requirements?
Ask about value, urgency, dependencies, effort and constraints, then use the agreed decision process. A method can organise discussion, but a label alone does not decide the outcome. Explain who approves priorities and how changes will be recorded.
6. What makes a requirement clear enough to review?
Describe the expected behaviour or quality, its context and the conditions under which it applies. Identify ambiguous terms such as fast or easy. Confirm that relevant stakeholders understand the statement consistently. The exact documentation format depends on the team and initiative.
7. How would you discuss functional and nonfunctional needs?
Use a fictional booking flow: creating a booking describes a capability, while an agreed response-time condition describes a quality under specified circumstances. Do not invent a universal response-time target. Ask which conditions, workload and measurement make a quality requirement meaningful.
8. Why does traceability matter?
Explain how a need connects to requirements, solution elements and checks. If something changes, those relationships help identify affected work. In an interview, show a small example rather than claiming that every team must use a particular traceability tool.
9. How would you examine an existing process?
Identify the start and end, participants, handoffs, decisions and exceptions. Compare the documented process with what authorised participants describe or demonstrate. Do not presume every delay has the same cause. Record assumptions and gaps before proposing changes.
10. How would you approach a data discrepancy?
Check definitions, source, time period, filters, missing values and duplicates. Confirm what the metric is intended to count before comparing totals. If access is restricted, work through the authorised process. Do not download confidential data into a personal tool to make the exercise easier.
11. What if the role includes SQL?
Read the actual tool requirement and describe your experience accurately. For a sample exercise, clarify the tables, keys, expected output and how duplicates or missing values should be handled. Explain the logic and check the result. Knowing syntax does not establish domain expertise by itself.
12. How would you handle a late change?
Clarify the reason, identify affected requirements and work, assess options and follow the agreed approval process. Record the decision and update relevant information. Avoid promising that every change will be accepted without affecting time or cost.
13. How do you help evaluate a delivered solution?
Compare behaviour with agreed requirements and the original need. Identify what evidence is available, what remains uncertain and which limitations matter. A feature being delivered does not automatically mean it produced the intended business outcome.
14. Tell us about relevant analysis work you have done.
Choose a real task and explain context, your responsibility, actions, outcome and limitations. A fresher can use an accurately labelled academic or supervised example. Distinguish your contribution from the team’s work and quantify only when the measurement is defensible.
Work through a fictional booking case
Suppose a small training centre reports confusion about available appointments. The initial suggestion is to add a calendar screen. Before selecting that design, clarify who books appointments, how availability is recorded and where the confusion occurs.
Ask whether the issue involves outdated information, competing bookings, unclear permissions or another cause. Identify the people who maintain availability and those who use it. Record the current process and exceptions rather than assuming a screen alone fixes the problem.
A fictional need might be to help authorised staff identify bookable slots consistently. An example capability could be checking availability before confirming a booking. Any performance or access conditions need agreement and a way to check them; do not insert arbitrary numbers solely to make the requirement appear specific.
Prepare a small case worksheet
| Item | What to explain |
|---|---|
| Need | The problem and why it matters |
| Stakeholders | Who is affected and who decides |
| Current state | What happens now, with uncertainties |
| Requirements | Capabilities and qualities to confirm |
| Options | Possible changes and tradeoffs |
| Checks | How agreed behaviour and outcomes would be examined |
| Limits | Assumptions, access restrictions and unanswered questions |
This is an original practice aid. The fictional case provides no real customer data or measured business outcome. Use it to demonstrate reasoning, then prepare your own truthful examples for questions about experience.
Check your claims and delivery
Practise explaining one case aloud without reading a paragraph. Ask a partner to identify the need, your role and the next decision. If those remain unclear, simplify the answer and show the missing connection.
Use the technical skills evidence guide to audit tool claims and the achievement answer guide to check personal ownership. For broader opening questions, use common HR interview questions.
Frequently asked questions
Does every BA role require SQL? Follow the vacancy. Tool requirements differ; do not claim a universal rule from a single job description.
Can a fresher use a college project? Yes, when its context, contribution and limitations are accurate. Do not present practice work as a commercial client engagement.
Should I memorise these answers? Use the questions to practise reasoning and evidence. Adapt to what the interviewer actually asks rather than reciting an unrelated script.