Business analyst interview questions, with worked answers

How to use these questions

Read the short answer and say it out loud. That is your first thirty seconds. Then read the full answer and pick two or three points to add, with an example from your own work: the people, the process, what you found and what changed. Interviewers want a method and a real example, not a list of techniques.

What a business analyst is expected to know

• Requirements: finding out what people need, through interviews, workshops and observation, and writing it so it can be built and tested.
• Processes: mapping how work is done today and how it should be done, often in BPMN, a standard way of drawing processes.
• Agile delivery: user stories with acceptance criteria in JiraAsked in 18% of business analyst ads (as of 5 Nov 2026).Write clear stories with acceptance criteria and keep the backlog tidy; Confluence for the documents., refinement with the team, and AgileAsked in 12% of business analyst ads (as of 5 Nov 2026).Work in short cycles with a team: requirements written as stories, refined and accepted sprint by sprint. and ScrumAsked in 12% of business analyst ads (as of 5 Nov 2026).Know the roles and meetings; many business analysts help the product owner keep the backlog ready. ways of working.
• Data: reading dataAsked in 8% of business analyst ads (as of 5 Nov 2026).Read data to size a problem, check a claim, and measure the result of a change. to size a problem and check a result, with SQLAsked in 25% of business analyst ads (as of 5 Nov 2026).Answer your own questions from the data: joins, filters and counts, without waiting for a developer., ExcelAsked in 14% of business analyst ads (as of 5 Nov 2026).Analysis, simple models, data checks and the comparison tables that support a decision. or dashboards in Power BIAsked in 14% of business analyst ads (as of 5 Nov 2026).Build or read dashboards that show whether a change worked; common in Microsoft-heavy companies. or TableauAsked in 2% of business analyst ads (as of 5 Nov 2026).Another common dashboard tool; reading and building simple dashboards is often enough..
• People: stakeholder managementAsked in 16% of business analyst ads (as of 5 Nov 2026).Find everyone a change affects, learn what each needs, and keep them informed and on side. and clear communicationAsked in 27% of business analyst ads (as of 5 Nov 2026).Clear writing (requirements, process maps, decisions) and running a workshop people leave agreed., in a room and in writing.
• Systems: how the business systems of your sector work, such as SAPAsked in 14% of business analyst ads (as of 5 Nov 2026).Many analysts work on SAP processes: finance, purchasing, sales; know the modules your area uses. or SalesforceAsked in 4% of business analyst ads (as of 5 Nov 2026).Common in sales and service projects: how its objects and processes fit the business., and how they exchange data.
• Law and trust: personal data under GDPRAsked in 9% of business analyst ads (as of 5 Nov 2026).EU data protection: what personal data a process uses, why, for how long, and who must agree. (EU) and similar laws: what a process may keep and for how long.

Finding out what is needed

How would you gather requirements for a new system that replaces an old one?

What they check: a clear method that finds the real needs, not only a copy of the old system.

Short answer: "I start from the business goal and the people affected. I learn how the work is done today by watching and asking, then run workshops to agree what must change. I write the requirements as user stories with acceptance criteria, get them reviewed by users and the team, and keep a list of open questions until each is answered."

The full answer, in six steps:

1. Goal and scope. Why are we replacing it, and what would success look like: lower cost, fewer errors, faster work? Write down what is in and out of scope.
2. Stakeholders. List everyone affected: the people who use it every day, their managers, IT, finance, legal, and the customers who see the results.
3. Today's process. Watch people work, read the old system's screens and reports, and map the process. People often use the old system in ways nobody wrote down.
4. Workshops. Bring the right people together to agree the new process and the requirements, group by group. Separate what they need from how they are used to doing it.
5. Write it down. Requirements as user stories (as a role, I want something, so that a benefit) with acceptance criteria, plus the rules that apply everywhere, such as speed, security and access.
6. Check and agree. Walk through the stories with users and the team, add examples, and get them signed off or accepted into the backlog.

A weak answer: "I ask the users what they want and write it down." People ask for the old system with new colours; the analyst's job is to find the need behind it.

Follow-up: "Users want every feature of the old system." Ask how often each is used and what happens without it; data from the old system often shows that many are never used.

How do you run a requirements workshop?

What they check: that you prepare, keep the room on track, and leave with decisions.

Short answer: "I agree the goal and the people beforehand, send a short agenda, and prepare a draft to react to, such as a process map. In the room I keep to the goal, make sure quiet people speak, write decisions where everyone can see them, and park side topics. Afterwards I send the decisions and the open questions within a day."

The full answer: A workshop is a working meeting where the people affected shape the requirements together. Invite those who know the work and those who decide; too many people and nothing gets decided. A draft gets better reactions than a blank page. Use simple techniques: walk through the process step by step, ask "what happens if...?" for each exception, and vote when there are too many ideas. End with a clear list: what we agreed, what is open, who answers it by when.

A weak answer: "I invite everyone and see what comes up." Follow-up: "One senior person talks over everyone." Thank them, then go round the room by name, or ask for ideas in writing first so every voice counts.

Two departments want opposite things from the same system. What do you do?

What they check: that you can handle conflict between stakeholders with facts and fairness.

Short answer: "I meet each side alone to understand what they need and why, then bring them together around the shared business goal, with the facts: cost, risk, who is affected. Often both needs can be met another way. If not, I take the choice to the person who owns the decision, with the options written down."

The full answer: Conflicts are often about solutions, not needs. Sales wants a field to be optional so orders go in fast; finance wants it required so invoices are right. The shared goal is correct invoices without slowing sales, so the field can be filled in later, before invoicing. A stakeholder map, showing who is affected and who decides, tells you whom to involve. The analyst does not decide; the analyst makes the decision easy and visible.

A weak answer: "I go with the more senior department." Follow-up: "The decision owner will not decide." Write down the cost of waiting each week, and agree a date with them.

Processes and analysis

A process takes far too long. How do you find out why and fix it?

What they check: that you measure first, find the real cause, and fix it with the people who do the work.

Short answer: "I map the process as it really is, measure how long each step and each wait takes, and find where the time goes. Usually it is waiting and handovers, not the work itself. Then I agree changes with the people involved, try them on a small scale and measure again."

The full answer, in five steps:

1. Define the problem in numbers. How long does it take now, how long should it take, and for which cases?
2. Map the current process. Walk through it with the people who do it, as it is, not as the manual says. Draw it in BPMN or as simple boxes and arrows.
3. Measure. Use data from the systems where you can, for example time stamps per step, with SQLAsked in 25% of business analyst ads (as of 5 Nov 2026).Answer your own questions from the data: joins, filters and counts, without waiting for a developer. or ExcelAsked in 14% of business analyst ads (as of 5 Nov 2026).Analysis, simple models, data checks and the comparison tables that support a decision.. Separate working time from waiting time.
4. Find the cause. Look for waits, rework, handovers, approvals nobody needs, and data typed twice. Ask "why?" until you reach a cause you can change. LeanAsked in 0% of business analyst ads (as of 5 Nov 2026).Remove waste from a process: waiting, rework, handovers; common in operations and banking. calls these things waste.
5. Change and check. Agree the new process, try it with one team, measure, then roll it out with training and updated documents.

A weak answer: "We buy a tool to automate it." Automating a bad process makes it fail faster.

Follow-up: "The cause is another department's approval step." Show them the data, ask what risk the step protects against, and look for a lighter way to cover that risk.

What is a gap analysis, and when do you use one?

What they check: that you know the technique and use it to make decisions, not documents.

Short answer: "A gap analysis compares where we are with where we want to be: today's process or system against the target, step by step. The gaps become the list of changes, each with its size and value. I use it when choosing a new system or planning a large change."

The full answer: List the target capabilities, meaning what the business must be able to do, and rate each today: done well, done poorly, or not at all. For a new system, rate each option against the same list; a standard package may cover most needs if the process changes a little. Each gap gets a way to close it: change the process, configure the system, build something, or accept it. That turns a large wish list into choices with costs.

A weak answer: "It is a document that lists the differences." Follow-up: "The package covers most needs but not one important one." Check whether the process can change, whether a small extension covers it, and what the gap costs if left open.

How do you use data in your analysis?

What they check: that you back opinions with numbers, and can get the numbers yourself.

Short answer: "I use data to size a problem before we spend money on it, to check claims such as 'this happens all the time', and to measure whether a change worked. I can write simple SQL and build a quick dashboard, and I work with data analysts for anything bigger."

The full answer: In a workshop someone says customers complain about delivery. Data turns that into a number: how many orders are late, for which regions, since when. With SQL you can join orders and complaints yourself. A simple chart in Power BIAsked in 14% of business analyst ads (as of 5 Nov 2026).Build or read dashboards that show whether a change worked; common in Microsoft-heavy companies. shows the pattern to people who do not read tables. Before a change, agree the measure of success and its starting value, so the result can be checked later.

A weak answer: "The data team handles the numbers." Follow-up: "The data says one thing and the users say another." Check both: the data may miss part of the process, or the users may remember the worst cases. Look at a few real cases together.

How do you know a change delivered what it promised?

What they check: that you follow up after go-live instead of moving on.

Short answer: "Before the change, I agree with the business owner what success looks like and measure the starting point. A few weeks or months after go-live, I measure again, talk to the users, and report the result honestly, including what did not work, with the next steps."

The full answer: This is often called benefits realisation: checking that the benefits in the business case arrived. Pick a few measures you can get easily, such as handling time, errors or cost per case. Separate the effect of the change from other things that moved at the same time, such as a busy season. If the result is weak, find out why: people may be working around the new process, which a short visit shows at once.

A weak answer: "Once it is live, the project is done." Follow-up: "Users have gone back to their old spreadsheets." Find out what the new system does not give them, and fix that or train them.

Requirements in agile teams and testing

What makes a good user story and good acceptance criteria?

What they check: that your stories can be built and tested without guessing.

Short answer: "A good story says who needs what and why, is small enough to finish in a sprint, and can be tested. Acceptance criteria say exactly when it is done, with examples, including what happens when something goes wrong."

The full answer: The form is "as a role, I want something, so that a benefit". The why matters most, because it lets the team find a better solution. INVEST is a checklist for stories: independent, negotiable, valuable, estimable, small and testable. Acceptance criteria are often written as given, when, then: given a customer with an unpaid invoice, when they order, then they see a payment reminder. Write the unhappy paths too: missing data, no permission, a system that is down.

A weak answer: "The system shall be user-friendly." That cannot be built or tested. Follow-up: "The story is too big for one sprint." Split it by steps of the process, by user type, or by simple case first and exceptions later.

How do you prioritise requirements when there is not enough time for all of them?

What they check: a method linked to the goal, and the courage to say what will not be done.

Short answer: "I rank them by value to the business goal against effort and risk, with the product owner or the business owner, who decides. MoSCoW helps: must have, should have, could have, will not have this time. The must-haves have to be truly needed for go-live, not just wanted."

The full answer: For each requirement ask: what happens if we go live without it? If the answer is "we break the law" or "we cannot do the work", it is a must. Laws and contracts come first; then the items that bring the most value for the effort. Dependencies change the order: some items are needed before others. Write the will-not-haves down and share them, so nobody is surprised later.

A weak answer: "Everything is a must have." Follow-up: "A director insists their item is a must." Ask what happens without it on day one, and offer a workaround or a date for the next release.

How do you support user acceptance testing?

What they check: that you link testing to the requirements and help the business decide whether to go live.

Short answer: "In user acceptance testing, real users check that the system supports their work before go-live. I turn the requirements into test scenarios with the users, plan who tests what and when, prepare test data, track the defects, and give a clear picture so the business can decide to go live."

The full answer: UAT is not a second round of the developers' tests; it checks the whole process with realistic cases, including exceptions. Each scenario links to a requirement, so you can show what is covered. Sort defects by how bad they are for the business, and agree beforehand what must be fixed before go-live. Train the testers briefly, and be in the room or on call while they test.

A weak answer: "The users test it when they have time." Follow-up: "Users find many things that were never in the requirements." Sort them: real gaps go to the backlog with a priority; wishes go to the next release; and learn why the gap was missed.

A requirement changes late in the project. How do you handle it?

What they check: that you accept change but make its cost visible.

Short answer: "I find out why it changed and what it affects: other requirements, the design, tests, the date and the cost. I show that to the person who decides, with options, and once it is decided I update the requirements and tell everyone affected."

The full answer: Traceability, linking each requirement to its designs and tests, makes the impact quick to see. In an agile team a change usually means reordering the backlog; in a fixed-price or phased project it goes through a change request, a formal decision on scope, time and money. Either way, keep a short history of what changed, why and who agreed, because six months later someone will ask.

A weak answer: "We just add it." Or: "Requirements are frozen, so no." Follow-up: "The change is a new law." Then it is a must; find what else can move to make room.

How do you write requirements for two systems that must exchange data?

What they check: that you can specify an interface clearly enough for two teams to build it apart.

Short answer: "I describe what data moves, in which direction, when and why: the fields, their meaning and format, which system owns each one, how often it is sent, and what happens when something fails or a value is missing. Both teams review it before anyone builds."

The full answer: Systems often talk through an API, an agreed way for one program to ask another for data, such as a REST APIAsked in 1% of business analyst ads (as of 5 Nov 2026).Know what an API is, so you can write requirements for systems that exchange data.. The analyst does not design the API but writes the business side: a data mapping table from source field to target field, the rules for each, examples with real values, and the error cases. Agree who is the master for each piece of data, for example the customer address, so two systems do not overwrite each other.

A weak answer: "The developers will work it out between them." Follow-up: "The two systems use different codes for the same country." Add a mapping rule and name who keeps the list up to date.

How do you capture requirements for personal data in a process?

What they check: that privacy is part of the requirements from the start.

Short answer: "For each personal field I ask why we need it, who may see it, how long we keep it, and how it is deleted. In the EU, GDPR requires a lawful reason for each use and lets people ask for their data, so I write those as requirements with the data protection officer, not as an afterthought."

The full answer: Keep a simple list of the personal data the process uses: the field, the purpose, the legal reason, who has access, the retention period. Under GDPR (EU), a new process that handles sensitive data may need a data protection impact assessment, a written check of the risks. Write acceptance criteria for access rights and deletion, so they are tested like any other feature.

A weak answer: "Legal will check it before go-live." Follow-up: "Marketing wants to keep every customer's data forever." Ask what they use it for, and agree a period that covers that use.

Scope, business cases and leading analysts

These questions come up for senior and lead business analysts and for business architect roles.

How do you build a business case for a change?

What they check: that you can link a change to money, risk and strategy, honestly.

Short answer: "A business case says what problem we solve, the options including doing nothing, the costs and benefits of each over a few years, the risks, and a recommendation. I build the numbers with finance and the business owners, and I state my assumptions so they can be challenged."

The full answer: Benefits come in kinds: money saved, money earned, risk reduced, and obligations met, such as a law. Be careful with soft benefits like "staff time saved": say what that time will be used for. Show a range, not one number, and the point where the case stops working. A senior analyst also checks the case later: did the benefits arrive? That is how trust is built for the next one.

A weak answer: "The benefits are obvious." Follow-up: "Finance says your savings are too optimistic." Use their figures, show the result, and see whether the case still holds.

As a lead business analyst, how do you keep the analysis consistent across many teams?

What they check: for lead roles, setting standards and helping other analysts do good work.

Short answer: "I agree a few shared standards: how we write stories and acceptance criteria, how processes are drawn, where documents live, and a shared glossary of business terms. I review work, pair with newer analysts, and run a regular meeting where analysts show their work and learn from each other."

The full answer: Inconsistent requirements cost time when teams depend on each other. A glossary stops two teams meaning different things by "customer" or "order". Templates make the right way the easy way. As a mentor, I give feedback on real work, not on theory, and I let analysts lead workshops early with support. I also plan the analysis work with project and product leads, so analysts are not spread across too many teams.

A weak answer: "Each analyst works their own way." Follow-up: "An experienced analyst refuses the templates." Ask what is wrong with them, improve them together, and keep the few rules that matter.

What does a business architect do that a business analyst does not?

What they check: for business architect roles, thinking across the whole organisation, not one project.

Short answer: "A business analyst works on one change or project. A business architect looks at the whole company: what it must be able to do, which processes and systems support each part, and which changes matter most for the strategy. They help leadership choose and order projects."

The full answer: The main tool is a capability map, a list of what the business must be able to do, such as "manage customer orders", independent of who does it or which system. Laying projects, systems and costs over it shows duplicates, gaps and where to invest. Business architects work with enterprise architects on the technology side, and with strategy and finance on the priorities.

A weak answer: "It is a more senior business analyst." Follow-up: "Two projects are building the same capability." Show it on the map, with the costs, and bring the project owners together to agree one.

Your CV for these questions

Every answer above is easier when your CV already says it, because the interviewer asks about what is on it. Put one line under each job for each of these, in the words the ads use:

Then score your CV against a real job: you will see which of these the job needs and which your CV does not prove yet.