Business Analyst Interview Questions and Answers

A business analyst (BA) connects the business and the technical team. They understand a business problem. They turn it into clear requirements that can be tested. They make sure the final solution really solves the problem.

Typical work:

• Ask stakeholders what they need, through interviews, workshops, and watching the work.
• Analyse and write down requirements (user stories, use cases, process models).
• Find gaps, risks, and conflicts early, and suggest options with trade-offs.
• Help developers and testers with questions, and help run UAT (user acceptance testing).
• Track changes and keep every requirement linked to a business goal.

A BA owns the quality of the analysis. The value is not in taking notes. The value is in asking why, questioning assumptions, and recommending a solution.

What they are checking: Do you see the role as analysis and advice, not just writing documents?

They record requirements at different levels, for different readers.

In practice, a BRD explains why the project is needed. An FRD describes what the solution does. An SRS is the detailed agreement that developers build from and testers check against. Many agile teams replace all three with a backlog of user stories and a short vision document.

What they are checking: Can you place each document in the right level of requirements?

Elicitation means drawing requirements out of stakeholders. Common techniques:

• Interviews: one to one. Good for depth and sensitive topics.
• Workshops (JAD sessions): group sessions that align many stakeholders quickly.
• Observation (job shadowing): watch the real work to find steps that people forget to mention.
• Document analysis: read existing manuals, reports, and policies.
• Surveys and questionnaires: reach many people at low cost.
• Prototypes and wireframes: let users react to something they can see.
• Brainstorming and focus groups: collect ideas.
• Reverse engineering of an old system.

Use a mix. Interviews plus observation usually show the gap between what people say and what they do.

What they are checking: Do you know many techniques, and can you match them to situations?

A user story is a short description of a need from the user's point of view: "As a <role>, I want <goal>, so that <benefit>."

A good story follows INVEST:

• Independent: can be built without depending on another story.
• Negotiable: details are discussed, not fixed.
• Valuable: gives value to a user or the business.
• Estimable: the team can size it.
• Small: fits within a sprint.
• Testable: has clear acceptance criteria.

Example story: "As a patient, I want to reschedule an appointment online, so that I do not need to call the clinic". The story starts a conversation. It is not a full specification.

What they are checking: Do you know INVEST and the "so that" part?

Acceptance criteria are the specific conditions a story must meet to be accepted. You can test each one. They remove doubt about what "done" means.

They are often written in Given/When/Then form:

• Given a registered user is on the login page
• When they enter a valid email and password
• Then they land on the dashboard

Add negative cases and edge cases too. A wrong password shows an error and does not say which field was wrong. After five failed attempts the account locks for 15 minutes.

Good criteria are pass or fail. They cover the normal path, errors, and limits. You can turn them directly into test cases.

What they are checking: Can you test your criteria, and do they include negative cases?

Functional requirements describe what the system does. Non-functional requirements describe how well it does it.

• Functional: "The system shall let a user reset a password using an emailed link."
• Non-functional (quality attributes): performance (page loads in under 2 seconds) and security (data encrypted at rest). Others are availability (99.9% uptime), scalability, usability, compliance (audit logging), and maintainability.

People often forget non-functional requirements. Then they cause the most costly rework. So a BA should ask about them directly and make them measurable.

What they are checking: Do you capture quality needs, not just features?

MoSCoW sorts requirements into four groups:

• Must have: without it the release fails, or it is illegal or unsafe.
• Should have: important, but there is a workaround for now.
• Could have: nice to have. Include it if time allows.
• Won't have (this time): agreed to be out of scope for this release.

Tips: keep Musts to about 60% of the effort, so there is room for risk. Agree on the groups with stakeholders in a workshop. Write down the Won't haves so expectations are clear. Other methods include value vs effort, Kano, and weighted scoring.

What they are checking: Do you know prioritisation words, and can you use them?

In Waterfall, the BA gathers detailed requirements up front and gets them signed off. Then design, build, and test follow in phases. Change is formal and costly.

In Agile, the BA works all the time with the product owner and the team. They refine the backlog and write user stories. They clear up details just in time and support each sprint review.

The BA skills are the same: elicitation, analysis, and communication. Only the rhythm and the documents change.

What they are checking: Can you adapt to different ways of delivering projects?

INNER JOIN returns only the rows that have a match in both tables. LEFT JOIN returns all rows from the left table, plus the matching rows from the right. Where there is no match, the right side is NULL.

A user directly uses the solution. A stakeholder is anyone who is affected by the project or can influence it. This includes sponsors, regulators, support teams, and users.

Scope creep is uncontrolled growth of scope after the baseline is agreed. It usually comes from small requests that nobody records.

A flowchart shows the steps and decisions of a process in order. A swimlane diagram is a flowchart split into lanes, one lane for each role, team, or system. It shows who does each step and where the hand-offs happen.

The as-is model shows how the process really works today, including workarounds. The to-be model shows the better process after the change.

A RACI matrix assigns each task or deliverable to roles:

• Responsible: does the work.
• Accountable: owns the result and signs off (only one per item).
• Consulted: gives input before the work.
• Informed: is told afterwards.

A business rule is a policy or limit of the organisation. It exists whether or not there is a system. Example: "a refund over 500 needs manager approval". A requirement is what the system must do or support. Example: "the system shall send refunds over 500 to the manager approval queue".

• Wireframe: a simple layout sketch that shows structure and flow, with no styling.
• Mock-up: a static, detailed visual design with colours, fonts, and real content.
• Prototype: an interactive model that users can click through to test the flow.

Unit testing (developers, one component). Integration testing (components together). System testing (end to end, against the requirements). Regression testing (old features still work). Performance and security testing. User acceptance testing (business sign-off).

User Acceptance Testing (UAT) is the final test phase. Business users confirm that the solution meets their needs before go-live.

BA role:

• Help define the UAT scope and scenarios from the requirements and acceptance criteria.
• Write or review test cases in business language.
• Arrange users, test data, and the environment.
• Sort defects: a real defect, a change request, or a misunderstanding.
• Track results and get formal sign-off.

UAT is not for finding every bug. That is QA's job. UAT checks that the solution fits real business processes.

What they are checking: Do you know how UAT differs from QA testing?

A BA should be able to read data and answer questions. Use SELECT, WHERE, ORDER BY, GROUP BY with aggregates, HAVING, JOINs, and simple subqueries. Writing data (INSERT, UPDATE, DELETE) is usually left to developers.

Example: total claim amount per provider for 2025, only for providers above 100000:

SELECT p.provider_name, SUM(c.amount) AS total_amount
FROM claims c
JOIN providers p ON p.provider_id = c.provider_id
WHERE c.service_date >= '2025-01-01' AND c.service_date < '2026-01-01'
GROUP BY p.provider_name
HAVING SUM(c.amount) > 100000
ORDER BY total_amount DESC;

Use SQL to check requirements against real data, find duplicates and nulls, and check reports.

What they are checking: Do you have practical data skills, not just theory?

A use case describes how an actor (a user or another system) interacts with the system to reach a goal. It includes the main flow, other flows, and exceptions. A user story is a short statement of a need, with acceptance criteria.

An RTM is a table that links each requirement to its source (a business goal). It also links forward to design, development, test cases, and release. It proves that every requirement is covered. It also shows that every test or feature has a reason to exist.

Gap analysis compares the current state (as-is) with the wanted state (to-be). It finds what is missing to get there.

Steps:

1. Define the wanted future state and the success measures.
2. Document the current state (process, systems, skills).
3. List the gaps.
4. Suggest actions, rank them, and estimate the effort.

I document a process by interviewing the people who do it. I walk through real examples. Then I draw it as a flow with clear owners and decisions.

The product backlog is the ordered list of everything that might be built: features, fixes, and technical work. The product owner owns the order.

Verification checks that requirements are well written. Validation checks that they are the right requirements.

A good requirement is one clear statement that you can test, with a measurable result. For example: "The system shall show search results within 2 seconds for 95% of queries."

A want is a proposed solution ("add an export button"). A need is the real problem behind it ("finance must reconcile weekly figures without typing the data again"). If you take wants literally, the solution is often poor.

A practical BRD includes:

• Executive summary and the business problem.
• Objectives and success measures (KPIs).
• Scope: what is in and what is out.
• Stakeholders and their roles.
• Current state and wanted future state.
• Business requirements and business rules, with priorities.
• Assumptions, limits, and dependencies.
• Risks and how to reduce them.
• Cost-benefit or a summary of the business case.
• Glossary and approvals.

I check the change against everything it touches before anyone approves it.

1. Understand the request and the business reason.
2. Use the traceability matrix to find the affected requirements, designs, tests, and interfaces.
3. Estimate the effect on effort, cost, and schedule with the technical team.
4. Find the...

The product owner owns the product vision and the backlog priorities. They make the value decisions. The BA analyses the problem, gathers and writes down the details, and helps the team understand and deliver.

These are requirement levels in the BABOK view.

• Business requirements: high-level goals of the organisation. Example: reduce claim processing time by 30%.
• Stakeholder requirements: needs of specific groups or roles that must be met to reach the business goal. Example: claims adjusters need one view of the...

A DFD shows how data moves through a system: external entities, processes, data stores, and data flows. A context diagram is the top-level (level 0) DFD. It shows the system as one process, with its external entities, and it shows the system boundary.

I ask them to explain it back in their own words. I walk through examples and acceptance criteria. I use models or prototypes together with text. Before development, I hold a three amigos session (BA, developer, tester), so questions come up early. I stay available during the sprint. Reviewing test cases against the requirement is another good check, because testers read requirements very literally.

Root cause analysis finds why a problem happens, so the fix removes the cause and not just the symptom. Techniques:

• The 5 Whys: ask why many times.
• The fishbone (Ishikawa) diagram: group causes by people, process, system, data, and environment.
• Pareto analysis: find the few causes behind most of the effect.

I keep documents small but alive. I use user stories with acceptance criteria in the backlog tool, a short product vision, and a decision log. I add process or data models where they help. I use visuals (wireframes, flow diagrams) and examples instead of long text. I keep details close to the story and update them...

I treat it as an analysis problem. I bring a recommendation, not just a complaint to the sponsor.

1. Clarify each position. Separate the real need from the proposed solution. Often the needs fit together even when the solutions do not.
2. Check each position against the business goal and success measures. Measure the...

First I find out why. It could be a new business need, a missed requirement, or just a preference. Then I run an impact analysis using the traceability matrix. I check which requirements, designs, and tests change. I check the effect on effort, schedule, cost, and risk.

I make my case with evidence. Then I support the decision. First I make sure I understand their reasons and the problem behind the request. Then I bring analysis: user data or research, cost and complexity, risk, conflict with other priorities, and the likely effect on the business goal. I suggest simpler options that meet the same need. I also suggest a cheap test, such as a prototype or a limited release, to check the idea.

First I find the cause. It may be unclear first requirements, a changing business situation, or a stakeholder who was not involved enough. Then I do these things:

• Confirm the baseline again and show the agreed change process.
• Ask for each change to come with a reason and business value, and run an impact analysis....

I compare the behaviour with the approved requirement and acceptance criteria.

• If the system does not behave as written, it is a defect. It goes to the development team by severity.
• If it behaves as written but the user wants something different, it is a change request. It needs an impact analysis.
• If the requirement was unclear or missing, it is a requirements gap. I own the fix of the document. After that it is handled as a defect or a change, depending on what was agreed.

I ask questions until it is concrete. Who uses it, and which decision does it support? Which metrics and definitions? Which data sources? How fresh must the data be? Who may see what? What do they do today, and what is the pain? What does success look like?

I make the criteria clear and use data. With stakeholders I agree on the goals and a scoring method (MoSCoW, weighted scoring on value, effort, risk, and urgency, or value versus effort). I measure value where I can (revenue, cost saving, compliance deadline). I get effort estimates from the team. I check...

Use the STAR structure and focus on your own analysis:

• Situation: the business problem and its measurable pain (for example, orders took 5 days to process).
• Task: your role and the goal.
• Action: how you collected data, interviewed stakeholders, and modelled the as-is process. Then how you found the root cause, compared options, and recommended one. Include any conflict you solved.
• Result: the measured outcome (cycle time down to 2 days, errors cut by 40%) and what you learned.

I make it easier for them and escalate through the right channel. I send short, specific questions with options, not open requests. I book short, fixed time slots. I use existing documents and data to prepare a draft that they can correct. People react to a draft faster than they write from scratch. I find a delegate...

I go back to the real need. I work with the architect or lead developer to understand the limit and the cost. Then I offer alternatives: a simpler version that gives most of the value, delivery in phases, a ready-made product, or a manual workaround for now. I show the cost, benefit, and risk of each, with a recommendation, to the stakeholder and get a decision. Saying "it cannot be done" without options is not useful.

I would not stay silent, and I would not argue from opinion. A BA is accountable for the quality of the analysis. So I bring a recommendation backed by evidence.