How do you elicit requirements from stakeholders who do not know exactly what they want?

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?" This reframes the conversation from feature to outcome. 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 the form of use cases or user stories and feed them back for validation, because stakeholders often discover gaps or conflicts when they see their requirements written down. I also try to surface the "nice to have" versus "must have" distinction early, because scope creep almost always comes from conflating the two.

How do you handle conflicting requirements from different stakeholders?

Conflicting requirements are almost always a sign of conflicting priorities, not a documentation problem. My first step is to make the conflict explicit: I write both requirements down side by side and show each stakeholder why they are in tension. Often this 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.

Walk me through how you document and manage requirements on a project.

I use a layered approach. At the highest level I capture the business case and objectives: why are we doing this and what does success look like? Below that I document functional requirements as user stories or use cases with acceptance criteria, and non-functional requirements such as performance, security, and scalability constraints separately, because they are often forgotten until late. 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 rather than updating silently, because stakeholders who discover undocumented changes lose trust quickly. I also do a requirements review with the development team before sign-off to catch anything that is ambiguous or technically problematic.

Tell me about a time you identified a problem that stakeholders had not noticed.

During a requirements workshop for a new customer portal, I mapped the current process flow end to end and noticed that two teams were separately maintaining the same customer data in different systems, with no synchronisation process 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, not an afterthought. The final solution included a data consolidation step that neither team had put in the original scope. Without it the portal would have displayed conflicting information to customers depending on which team had last updated their record. Spotting this saved a significant rework cycle after go-live.

Describe a project where requirements changed significantly during delivery. How did you handle it?

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 to be added from scratch. I presented this to the project sponsor as a structured change request with an estimate of additional time and cost, not as a problem but as a decision they needed to make. They chose to extend the timeline by six weeks and adjust the scope of the original phase rather than defer the acquisition requirements. I then re-facilitated the requirements sessions to incorporate the new stakeholders from the acquired company. The project delivered on the revised plan.

How have you built relationships with technical teams who saw BA involvement as overhead?

I encountered this early in my career with a development team that had been burned by overly prescriptive requirements documents that constrained their technical decisions without adding value. I changed my approach: instead of handing over a 40-page specification, I started running short joint sessions to explore requirements together, and I made it explicit that the solution design was theirs. I focused on the "what" and the "why" and stayed out of the "how". I also started delivering shorter, more focused user stories with clear acceptance criteria rather than narrative requirements documents, which the team found much more useful for sprint planning. Within two months, developers were proactively including me in design conversations because they found the collaboration useful rather than obstructive.

How do you use process modelling in your work?

I use process models at different levels of abstraction depending on the audience and purpose. For senior stakeholders I use a high-level swimlane diagram to show who does what and where hand-offs occur. For operational teams I go deeper with a more detailed flow that captures 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 that people do but did not mention, or assumptions that differ between people who perform the same process. I also use the current-state model as a foundation for designing the future state, so the gap between the two becomes the actual project scope.

How do you write acceptance criteria, and why does it matter?

I write acceptance criteria in a Given-When-Then format or as a checklist of testable conditions, depending on what the team uses. The key principle is that every criterion must be independently verifiable: someone who was not involved in writing the requirement should be able to look at the system and say definitively whether it passes or fails. Vague criteria like "the system should be fast" are not acceptance criteria; "the page should load 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 acceptance criteria are the primary cause of disputes between business and development at the end of a sprint. Precise criteria make testing objective and sign-off clean.

How do you approach data analysis as part of the BA role?

Data analysis shows up in my work in several ways. In the discovery phase, I analyse existing data to understand the current state: what volumes are we dealing with, what does the data quality look like, and are there patterns that challenge the assumptions stakeholders have about their processes? During requirements definition, I document data requirements: what data does each function need, where does it come from, and what transformations are required? I also use data to validate assumptions: if a stakeholder says "most customers do X", I try to verify that with actual transaction or behavioural data before building a requirement around it. I use SQL for structured queries and Excel for ad hoc analysis. I also work closely with data architects and data engineers to make sure my data requirements are feasible and do not create downstream problems.

Business Analyst

Business Analyst interviews test your ability to bridge the gap between business problems and technical solutions. Interviewers want to see that you can elicit and document requirements with precision, translate complex processes into clear specifications, and communicate equally well with stakeholders and developers. This guide covers the questions that come up most often and the answers that distinguish analysts who drive real change from those who produce documents that end up ignored.

For general interview preparation tips, read our guide to common interview questions.

Common Business Analyst Interview Questions

Behavioral Interview Questions for Business Analyst Roles

Technical Questions for Business Analyst Candidates

What Hiring Managers Look for in Business Analyst Interviews

The best Business Analysts are intellectually curious and comfortable sitting in ambiguity. Probe for how they handle stakeholders who cannot articulate what they need: the answer reveals whether the candidate is a facilitator or a scribe. Ask specifically about how they have handled scope changes and requirement conflicts; these situations are unavoidable on real projects. Watch for whether they distinguish between requirements and design: strong BAs define the "what" and leave the "how" to the technical team.

Questions to Ask Your Interviewer

→How does the BA role interact with product management here: where does one end and the other begin?
→What methodologies does the team use, and how much agility is there to adapt them to the project?
→How are requirements prioritisation decisions made, and who has final say on scope?
→What does a typical project look like from initial brief to go-live?
→What are the biggest gaps or challenges in the current requirements process?

Practice These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free during beta. No commitment.

Related Roles