Top 10 business analyst interview questions

A business analyst helps an organisation solve problems and seize opportunities by understanding the business need, working out what a solution must do, and making sure the delivered solution provides value. Day to day that means identifying stakeholders, eliciting and documenting requirements, mapping current and future processes, analysing data, clarifying questions for developers, supporting testing and UAT, and managing changes. The BA is the bridge that makes sure business and technical teams understand each other, so the team builds the right thing.

1. Understand the context and goal: the business problem, objectives, success metrics and scope.
2. Identify stakeholders (power/interest grid, RACI).
3. Choose elicitation techniques: interviews, workshops, observation, document analysis, surveys, prototypes.
4. Ask open and probing questions, including exceptions and edge cases; use the 5 Whys.
5. Document: BRD/FRD or user stories with acceptance criteria, process models and wireframes.
6. Validate: walk stakeholders through the documented requirements and get sign-off; resolve conflicts with the sponsor.
7. Manage: keep requirements traceable and handle changes through a clear process.

Back it with an example from a project.

• BRD (business requirements document): what the business needs and why: business problem, objectives, scope, stakeholders, high-level requirements, assumptions, constraints and success criteria. Written in business language for sponsors and stakeholders.
• FRD (functional requirements document): how the system should behave to meet those needs: detailed functional requirements, business rules, use cases, screen behaviour, data and integration requirements, and non-functional requirements. Written for the delivery team (developers, testers).

The BRD comes first; each functional requirement should trace back to a business requirement. In agile teams, much of this lives as epics and user stories with acceptance criteria instead of long documents.

User story: As a bank customer, I want to withdraw cash from an ATM using my debit card so that I can get money quickly without visiting a branch.

Acceptance criteria:

1. Given a valid card and correct PIN, when I request an amount in multiples of ₹100 within my balance and daily limit, then the ATM dispenses the cash, debits my account and offers a receipt.
2. Given I enter a wrong PIN three times, then the card is blocked for the day and I see a message to contact the bank.
3. Given I request more than my available balance, then the ATM shows "Insufficient funds" and doesn't debit my account.
4. Given the ATM has insufficient cash, then it shows a clear message and suggests a lower amount.
5. Given the cash isn't dispensed due to a machine error, then my account is not debited, or is automatically reversed within the regulatory time limit.

Mention non-functional needs too: response time, security (PIN encryption) and accessibility.

"I try to understand why they're resistant: are they too busy, worried about the change's impact on their team, or feeling left out of decisions? I meet them one-on-one, listen, and connect the project to their goals and pain points. I make it easy for them to contribute (short, well-prepared sessions, drafts to react to instead of blank questions), keep them informed, and credit their input. If they still block progress, I document the impact on timelines and escalate respectfully to the sponsor. For example, a branch operations head kept skipping workshops; when I showed how the new process would cut their team's manual reconciliation by 2 hours a day, they became one of our strongest supporters."

Change is normal; uncontrolled change is the problem.

1. Understand the change and the reason (new regulation, a misunderstood need, a new opportunity).
2. Assess impact on scope, timeline, cost, other requirements, testing and risk (the traceability matrix helps).
3. Discuss options with stakeholders and the project manager or product owner: include it now, trade it for something else, or defer it.
4. Get approval through the change control process (or backlog prioritisation in agile).
5. Update the documentation, communicate it to the team and update test cases.

In agile, changes are welcomed through backlog refinement, but changing a sprint's committed work mid-sprint is avoided unless it's critical.

User acceptance testing is the final testing phase, where business users verify that the solution meets their needs in realistic scenarios before go-live.

BA's role: define UAT scope and entry/exit criteria, help write test scenarios based on requirements and acceptance criteria, prepare test data, train and support users during testing, triage defects (a real bug vs a change request vs user error), track defect resolution with the team, report progress and obtain formal sign-off. A smooth UAT is the result of clear requirements from the start.

• Process models: flowcharts and BPMN swimlane diagrams for as-is and to-be processes.
• UML: use case diagrams (actors and goals), activity diagrams, sequence diagrams for system interactions, class diagrams.
• Data: entity-relationship diagrams and data dictionaries.
• Wireframes/mock-ups to clarify screens (Balsamiq, Figma).
• Context diagrams to show the system's boundaries and external entities.

Tools: Visio, Lucidchart, draw.io, Miro; Jira and Confluence for backlogs and documentation; Excel and SQL for data analysis. Choose the model that best communicates with the audience: a swimlane for business users, a sequence diagram for developers.

MoSCoW sorts requirements into:

• Must have: essential; without it the solution fails or isn't legal/viable.
• Should have: important but not vital for this release; workarounds exist.
• Could have: nice to have; included if time permits.
• Won't have (this time): agreed out of scope for now; recorded for the future.

It makes trade-offs explicit and manages expectations. Pitfalls: everything becoming a "Must", so I'd test with "What happens if we launch without this?" Combine it with value-vs-effort analysis and business objectives.

1. Clarify: current time (say 5 days) and target (same day), customer segments, channels (branch, app), regulatory constraints (KYC).
2. Map the as-is process: application → document collection → KYC verification → approval → account creation → welcome kit, with time and hand-offs at each step.
3. Find bottlenecks with data: for example, 60% of the time is waiting for manual document verification; 20% of applications are reworked due to missing documents.
4. Root causes: paper documents, manual checks, unclear checklists, sequential approvals.
5. Options: digital onboarding with e-KYC/video KYC, auto-validation of documents with clear upfront checklists, rules-based auto-approval for low-risk cases, parallelising steps, instant virtual debit cards.
6. Recommend and estimate: benefits (time, cost, conversion), costs and risks (compliance, fraud), phased rollout.
7. Measure: account opening time, drop-off rate, rework rate, cost per account, customer satisfaction.