Business Analyst Interview Questions

I start by understanding the problem they are trying to solve, not the solution they think they want. If a stakeholder says "I need a new report", my first question is "what decision will that report help you make?" I use a mix of techniques depending on the stakeholder: structured interviews for senior decision-makers, process walkthroughs for operational staff, and workshop facilitation when requirements span multiple teams. I document what I hear in user stories and feed them back for validation, because stakeholders often discover gaps or conflicts when they see their requirements written down. I also surface the "nice to have" versus "must have" distinction early, because scope creep almost always comes from conflating the two.

Conflicting requirements are almost always a sign of conflicting priorities, not a documentation problem. I make the conflict explicit: I write both requirements down side by side and show each stakeholder why they are in tension. This often surfaces assumptions that neither party had articulated. I then facilitate a decision about which requirement takes priority, based on business impact and strategic alignment, and document that decision with the rationale. If the conflict cannot be resolved at the stakeholder level I escalate to the appropriate decision-maker with a clear summary of the trade-off and a recommendation. I avoid trying to satisfy both requirements through technical compromise, because that usually produces a system that does neither well.

I use a layered approach. At the highest level I capture the business case and objectives. Below that I document functional requirements as user stories with acceptance criteria, and non-functional requirements separately. I maintain a requirements traceability matrix to show which system features map to which business requirements, which is essential for change impact assessment when scope shifts. I version-control all requirements documentation and communicate changes formally. I also do a requirements review with the development team before sign-off to catch anything ambiguous or technically problematic.

AI has become useful at several points in my BA workflow. For requirements documentation, I use it to convert rough stakeholder notes into structured user stories and acceptance criteria: the format comes out right, though I always validate the logic against what the business actually said. For process mapping, I have used AI to help identify gaps or redundancies by describing a process in plain text and asking for an analysis, which surfaces things I might not have spotted. For ad hoc data work, I use it to help write and debug SQL queries or Python scripts, which saves time on the technical side of one-off analysis. For presenting findings to non-technical stakeholders, I use AI to help simplify and structure complex information into language that lands clearly in meetings. Where I am more cautious is anything requiring deep domain knowledge of our specific systems and legacy processes: the model does not have that context, so I do not treat its outputs as authoritative on system-specific questions.

During a requirements workshop for a new customer portal, I mapped the current process end to end and noticed that two teams were separately maintaining the same customer data in different systems with no synchronisation between them. Neither team had flagged it because each assumed the other was the system of record. I brought both teams together with the process map and documented the data inconsistency as a core problem to solve. The final solution included a data consolidation step that neither team had put in scope. Without it the portal would have displayed conflicting information depending on which team had last updated their record. Spotting this saved a significant rework cycle after go-live.

Midway through a six-month CRM implementation, the business acquired a smaller company and needed the new system to accommodate the acquired company's processes, which were materially different from the original requirements. I ran a rapid impact assessment: identified which current requirements were unaffected, which needed modification, and which new requirements needed adding. I presented this to the project sponsor as a structured change request with an estimate of additional time and cost. They chose to extend the timeline by six weeks and adjust the scope. I then re-facilitated requirements sessions to incorporate stakeholders from the acquired company. The project delivered on the revised plan.

I encountered this with a development team that had been burned by prescriptive requirements documents that constrained their technical decisions without adding value. I changed my approach: instead of handing over lengthy specifications, I ran short joint sessions to explore requirements together, making it explicit that solution design was theirs. I focused on the "what" and the "why" and stayed out of the "how". I also moved to shorter user stories with clear acceptance criteria rather than narrative documents, which the team found far more useful for sprint planning. Within two months, developers were proactively including me in design conversations.

I use process models at different levels of abstraction depending on the audience. For senior stakeholders I use high-level swimlane diagrams to show who does what and where hand-offs occur. For operational teams I go deeper with flows that capture decision points, exceptions, and system interactions. I use BPMN notation when the organisation has a standard, or simpler flowchart notation when the audience is not technically trained. The key value of a process model is making tacit knowledge explicit: I almost always find steps people do but did not mention, or assumptions that differ between people performing the same process. I use the current-state model as a foundation for designing the future state.

I write acceptance criteria in a Given-When-Then format or as a checklist of testable conditions. Every criterion must be independently verifiable: someone not involved in writing the requirement should be able to look at the system and say definitively whether it passes or fails. "The system should be fast" is not acceptance criteria; "the page loads within 2 seconds on a 4G connection for 95% of requests" is. I also make sure acceptance criteria cover edge cases and failure paths, not just the happy path. This matters because ambiguous criteria are the primary cause of disputes between business and development at the end of a sprint.

Data analysis shows up in several ways. In discovery I analyse existing data to understand the current state: volumes, data quality, and patterns that challenge stakeholder assumptions. During requirements definition I document data requirements: what data each function needs, where it comes from, and what transformations are required. I use data to validate assumptions: if a stakeholder says "most customers do X", I try to verify that before building a requirement around it. I use SQL for structured queries and Excel for ad hoc analysis, and I work closely with data architects to ensure my data requirements are feasible.