Business Analyst Interview
Questions and answers (2026)

A business analyst (BA) is the bridge between the business and the technical team. The BA understands what the business needs, turns it into clear requirements, and makes sure the delivered solution solves the actual problem.

Day-to-day tasks:

• Talk to stakeholders and gather requirements.
• Document them as a BRD, FRD, user stories or use cases.
• Work with developers and testers through the delivery cycle.
• Support UAT and confirm the solution meets the business need.
• Manage changes and priorities as the project moves.

The BA does not write code and does not make the final business decision — the BA makes sure the right decision gets made with the right information.

SDLC (Software Development Life Cycle) is the structured process of building software: requirements, design, development, testing, deployment and maintenance.

The BA is most active in the requirements phase — gathering, analysing and documenting what needs to be built. The BA also stays involved in design reviews, supports testers during testing, and helps with UAT and training at deployment.

In Agile, the BA (often called a Product Owner or Product Analyst) works continuously across every sprint rather than only in a single phase.

Both approaches are used in Indian IT. Regulated domains such as banking and insurance often mix them — Waterfall for compliance sign-off, Agile for the build.

• Interviews — one-to-one with a stakeholder. Good for depth, slow for coverage.
• Workshops — a group session with all key stakeholders. Fast for resolving conflicts, needs a strong facilitator.
• Observation — watching the user do the work. Catches things they forget to mention.
• Surveys and questionnaires — good for a large user base, weaker on detail.
• Document analysis — reading existing process docs, SOPs and past BRDs.
• Prototyping — showing a mock-up and asking for feedback. Often the fastest way to confirm a requirement.
• Focus groups — a moderated discussion with a representative user group.

Good BAs combine two or three methods. Interviews plus observation is the classic pairing.

Simple way to remember: the BRD says what the business needs, the FRD says how the system should behave, and the SRS is the formal engineering version that combines both.

A user story is a short description of a feature from the user's point of view. It focuses on the value the user gets, not on the technical implementation.

As a <role>,
I want <feature>,
so that <benefit>.

Example:

As a registered customer,
I want to reset my password by email,
so that I can regain access to my account.

A good story also has acceptance criteria — the conditions that must be true for the story to be accepted.

Acceptance criteria are the conditions a user story must satisfy to be considered complete. They tell the developer what to build and the tester what to test.

The most common format is Given-When-Then:

Given the user is on the login page
When  they enter a registered email and the correct password
Then  they are redirected to the dashboard
And   a session is created

Given the user is on the login page
When  they enter a registered email and the wrong password
Then  an error message "Invalid credentials" is shown
And   the user stays on the login page

Write one set of criteria for the happy path and additional sets for each meaningful error path.

MoSCoW is a simple way to prioritise requirements into four groups:

• Must have — the release fails without this. Non-negotiable.
• Should have — important but not critical. There is a workaround if it slips.
• Could have — nice to have. Included only if time and budget allow.
• Won't have — explicitly out of scope for this release. Recorded so it does not get raised again.

MoSCoW is most useful when stakeholders disagree about priorities. The BA facilitates the discussion and documents the outcome.

Use a use case when the interaction has many alternate flows and the team wants a single reference. Use user stories when the team is delivering in small increments and wants to iterate with the user.

A stakeholder is anyone who affects or is affected by the project — sponsors, end users, developers, testers, compliance, operations and sometimes customers.

Ways to identify them:

• Read the project charter and org chart.
• Ask the sponsor "who else needs to be involved?"
• Map the process end-to-end and note who touches each step.
• Check for regulatory or audit functions that must sign off.
• Ask "who will say no if this goes wrong?" — that person is a stakeholder.

A RACI matrix is a table that maps tasks or decisions to four roles:

• R — Responsible: the person who does the work.
• A — Accountable: the person who is finally answerable. There should be exactly one A per task.
• C — Consulted: the person who must be asked before the decision.
• I — Informed: the person who must be told after the decision.

BAs use RACI to remove ambiguity — who approves the requirement, who just needs to know. A one-page RACI at the start of a project prevents a lot of arguments later.

Gap analysis compares the current state ("as-is") with the desired future state ("to-be") and identifies what is missing.

Typical gaps:

• Process gap — a step is manual but should be automated.
• System gap — the current tool does not support the required feature.
• Data gap — the required data is not captured or is in the wrong format.
• Skill gap — the team does not have the training to run the new process.

The output is a list of gaps with a proposed action for each. It feeds directly into the requirements and the project plan.

A change request is a formal request to modify an agreed requirement, scope or deliverable. It should always be documented — even in Agile, where the "change request" is effectively a new backlog item.

Steps a BA takes:

1. Log the request in the change register or the backlog.
2. Assess the impact — effort, cost, timeline, risk and dependencies.
3. Present the impact to the change board or product owner.
4. Get a decision — approve, defer or reject.
5. Update documents — BRD, stories, RTM, plan.
6. Communicate the change to everyone affected.

UAT (User Acceptance Testing) is the final validation before go-live, where the business users confirm the solution meets their requirements.

The BA's role in UAT:

• Prepare the UAT plan and the test scenarios based on requirements.
• Coordinate the business users and schedule the sessions.
• Provide test data and environment support.
• Log, triage and prioritise the defects raised during UAT.
• Track sign-off and document any open issues for the go-live decision.

A requirements traceability matrix (RTM) maps each requirement to its design, code, test cases and defects. It shows that every requirement was delivered and tested.

Why BAs use it:

• Proves coverage — no requirement was missed.
• Prevents scope creep — every new item must trace back to an approved requirement.
• Supports audit and compliance — regulated domains require it.
• Helps with impact analysis when a requirement changes.

In Agile, the RTM is often replaced by linking user stories to test cases in JIRA — the principle is the same.

SWOT stands for Strengths, Weaknesses, Opportunities and Threats. It is a simple strategic-analysis tool used at the start of a project or a business case to understand the situation before making a recommendation.

• Strengths — internal advantages. Example: an existing loyal customer base.
• Weaknesses — internal gaps. Example: manual processes that do not scale.
• Opportunities — external openings. Example: a new regulation that requires the feature you already have.
• Threats — external risks. Example: a competitor launching the same feature first.

The BA uses it to frame the business case — not as a deliverable on its own.

Before the workshop:

• Define the objective — what must be decided by the end?
• Invite the right people — decision-makers, not just observers.
• Send a pre-read — current process, problem statement, open questions.

During the workshop:

• Start with the objective and the ground rules.
• Walk through the as-is process, then the to-be.
• Capture issues and requirements in a visible place — a whiteboard or a shared document.
• Park off-topic discussions in a "parking lot".
• Close with a summary of decisions and actions, and confirm next steps.

After the workshop:

• Circulate the minutes and the action list within 24 hours.
• Get written confirmation on the requirements discussed.

Step by step:

1. Listen to both sides separately. Understand the underlying business need, not just the stated want.
2. Look for the common goal. Most conflicts are about tactics, not objectives.
3. Assess impact. What does each option cost in time, effort and risk?
4. Bring them to a joint discussion. Present the options with the trade-offs. Let them hear each other's reasoning.
5. Escalate if needed. If no agreement is possible, the sponsor or product owner makes the call — document the decision and the rationale.

Never silently drop one stakeholder's requirement. That is how projects fail at UAT.

Scope creep is the slow addition of small requirements that were not in the agreed scope. Each addition looks harmless; together they blow the timeline and the budget.

How to control it:

• Baseline the scope in writing and get it signed off.
• Route every change through the change process — no exceptions, even for "small" items.
• Quantify the impact — "adding this costs two weeks and pushes the release date".
• Offer a trade-off — "we can add this if we drop X or delay Y".
• Keep a visible backlog of deferred items so nothing is forgotten.
• Communicate the current scope status in every project update.

BPMN (Business Process Model and Notation) is a standard visual language for modelling business processes. It is understood across teams and tools, so the same diagram can be read by business and technical people.

Basic elements:

• Events — circles. Start, intermediate and end events.
• Activities — rounded rectangles. A task or a sub-process.
• Gateways — diamonds. Exclusive (XOR), inclusive (OR) and parallel (AND) paths.
• Sequence flows — solid arrows. The order of activities.
• Message flows — dashed arrows. Communication between pools.
• Pools and lanes — rectangles and their subdivisions. Who does what.

A BPMN diagram replaces three pages of prose when you need to explain a process with branches and hand-offs.

Check the story against INVEST:

• I — Independent: can be delivered without another story.
• N — Negotiable: the "how" is open until the team discusses it.
• V — Valuable: delivers something the user or business cares about.
• E — Estimable: the team has enough information to size it.
• S — Small: fits comfortably in one sprint.
• T — Testable: acceptance criteria are clear enough to test.

As a registered customer,
I want to reset my password by email,
so that I can regain access to my account.

Given I am on the "Forgot password" page
When  I enter a registered email and submit
Then  a reset link is emailed to that address
And   the link expires after 30 minutes

Given I am on the "Forgot password" page
When  I enter an email that is not registered
Then  the same success message is shown (no user enumeration)

Non-functional requirements are the ones most often missed. A BA who asks about performance, security and availability in the first meeting saves the team a painful late-stage fix.

A wireframe is a low-fidelity sketch of a screen — boxes, labels and layout, without colour or final visuals. It confirms what goes on the screen and where.

A prototype is clickable and interactive. It shows the flow between screens and can be used for usability testing.

The BA typically uses wireframes to confirm requirements with the business, and leaves high-fidelity prototypes to a designer. Tools: Balsamiq, Figma, draw.io.

A KPI (Key Performance Indicator) is a measurable value that shows whether a business objective is being met.

A good KPI is SMART — Specific, Measurable, Achievable, Relevant and Time-bound. Example: "Reduce average order processing time from 4 hours to 30 minutes within 90 days of go-live".

The BA defines KPIs at the start of the project so the post-go-live review can confirm the solution delivered value. Without a KPI, "success" becomes an opinion.

BAs use SQL to pull data for analysis and to validate requirements against the actual data.

-- How many orders per region this quarter?
SELECT region, COUNT(*) AS orders
FROM orders
WHERE order_date >= '2026-07-01'
GROUP BY region
ORDER BY orders DESC;

-- Average order value by customer segment
SELECT c.segment,
       AVG(o.amount) AS avg_order_value
FROM orders o
JOIN customers c ON c.id = o.customer_id
GROUP BY c.segment;

-- Customers who have not ordered in the last 90 days
SELECT c.id, c.email, MAX(o.order_date) AS last_order
FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
GROUP BY c.id, c.email
HAVING MAX(o.order_date) < CURRENT_DATE - INTERVAL 90 DAY;

Focus on SELECT with WHERE, GROUP BY, JOIN, aggregate functions and HAVING. You rarely need to write INSERT or UPDATE as a BA.

Excel is the BA's daily tool for data analysis and quick models.

• VLOOKUP and INDEX-MATCH — bring data from one sheet into another.
• SUMIFS and COUNTIFS — aggregate by one or more conditions.
• Pivot tables — summarise thousands of rows in seconds.
• Conditional formatting — highlight outliers, duplicates and KPIs.
• Data validation — restrict input to a dropdown list.
• Charts — a clean line or bar chart for a stakeholder update.

BAs who can pivot and lookup quickly save the team hours of ad-hoc data requests.

JIRA is a project management tool from Atlassian used to track backlogs, sprints, user stories, bugs and issues.

How a BA uses JIRA:

• Writes and maintains user stories in the backlog.
• Adds acceptance criteria to each story.
• Prioritises the backlog with the product owner.
• Attaches wireframes, process flows and requirement documents to the story.
• Tracks stories through sprints, reviews completed work, and closes items that meet the criteria.
• Uses JIRA reports — burndown, velocity — to flag risks to the team.

Confluence is the companion tool — BAs use it for the BRD, meeting notes and process documentation, and link those pages to the stories in JIRA.

A requirement is complete when it is unambiguous, testable, traceable and agreed.

Checklist for each requirement:

• Is there a single, clear interpretation? Would two developers build the same thing?
• Is there a testable acceptance criterion?
• Does it trace back to a business objective?
• Have the relevant stakeholders confirmed it in writing?
• Are the edge cases documented — empty input, invalid input, maximum value?
• Is it free of solution-specific language ("must use a dropdown") unless the solution is genuinely fixed?

Every functional requirement should trace to at least one business requirement. If it does not, the feature adds cost without adding value — a sign of scope creep.

Step by step:

1. Check the reason. Are they too busy, do they not understand the project, or do they disagree with it?
2. Adapt the communication. A 15-minute call may work better than an hour-long workshop. Ask for a specific decision, not general feedback.
3. Escalate through the sponsor. If the stakeholder is critical to sign-off, the sponsor needs to enforce the engagement.
4. Document the impact. Note in the project log — "requirement X is unconfirmed because stakeholder Y did not respond by date Z".
5. Fall back to a reasonable default. If no answer is possible, document the assumption you will proceed on and get it confirmed later.

Never stall the project waiting for one person. Document the assumption and move.

Phase 1 — Elicit. Identify stakeholders, plan the elicitation, run interviews and workshops. Capture raw requirements in a register.

Phase 2 — Analyse. Check for conflicts, gaps and dependencies. Prioritise with MoSCoW or a value/effort grid. Confirm feasibility with the technical team.

Phase 3 — Specify. Write the BRD and FRD, or the user stories with acceptance criteria. Get written sign-off from the business.

Phase 4 — Validate. Walk the requirements through with testers and developers. Identify any ambiguity or missing edge cases.

Phase 5 — Manage change. Log every change request, assess impact, get a decision, update the documents and the RTM.

Phase 6 — Trace and close. Confirm every requirement was delivered and tested. Document lessons learned for the next project.

The BA owns the requirements register throughout — it is the single source of truth for what was asked, what was agreed and what changed.

Step by step:

1. Get the business cases. Ask each unit to state the value of their priority — revenue, cost saving, compliance or risk reduction.
2. Quantify. Where possible, translate to a common measure — rupees, hours saved or risk exposure.
3. Present the trade-offs. Put all the requests on one page with their value and effort. Let the sponsor see the whole picture.
4. Recommend a sequence. The BA does not decide priorities — the sponsor does. But the BA can recommend the order that delivers the most value earliest.
5. Document the decision. Record who chose which priority and the rationale, so it does not get reopened next month.
6. Communicate the deferral. Tell the units whose items moved down why, and when they will be revisited.

Digital transformation means redesigning processes and systems, not just replacing tools. The BA's role spans five areas.

• Current state analysis. Document the as-is process, the systems in use and the pain points.
• Future state design. Work with the business to design the to-be process. Identify what can be automated and what stays manual.
• Gap analysis. List what is missing — process, data, system, skill.
• Change impact. Assess who is affected and how. Work with change management on training and communication.
• Benefits tracking. Define the KPIs upfront and measure them after go-live.

The biggest risk in transformation is focusing on the tool and forgetting the process and the people. The BA keeps the focus on the outcome.

A baseline is the frozen, agreed set of requirements at a point in time — usually at the end of the design phase or the start of a sprint cycle.

Managing it:

• Version every requirement document. Use version numbers and change history.
• Get formal sign-off from the business on each baseline.
• Require a change request for any modification after the baseline.
• Assess the impact on effort, timeline and cost for each change.
• Get a decision from the change board or product owner — approve, defer or reject.
• Update the RTM and inform everyone affected.

Without a baseline, there is nothing to measure scope creep against. The baseline is the BA's strongest defence of the plan.

Before the sprint:

• Refine upcoming stories with the team. Answer questions, clarify acceptance criteria, split stories that are too large.

During the sprint:

• Be available for quick clarifications — a five-minute conversation beats a written email thread.
• Review in-progress work against the acceptance criteria.
• Flag scope changes to the product owner, not to the developers directly.

After the sprint:

• Demo completed stories to stakeholders and capture feedback.
• Review defects raised in testing to confirm they are genuine.
• Log new backlog items for anything deferred or discovered.

Three levels:

1. Delivery metrics. Was the project delivered on time, on budget and to scope? How many defects escaped to production?
2. Business metrics. The KPIs defined at the start — reduced processing time, increased conversion, reduced cost. Compare before and after.
3. Adoption metrics. Are the users actually using the new feature? Login counts, usage rates and support tickets all show whether the change stuck.

Share the results in a post-implementation review. It closes the loop with the sponsor and provides evidence for the next business case.

In smaller Agile teams, one person often does both. In larger organisations, the BA supports the product owner — the BA writes the detail, the PO makes the value decisions.

A strong business case answers five questions:

1. What is the problem or opportunity? State it in business terms, not technical terms.
2. What are the options? Present at least three — do nothing, a minimal fix, and a full solution.
3. What does each option cost and deliver? Effort, cost, timeline, expected benefit.
4. What are the risks? Delivery risk, adoption risk, regulatory risk.
5. What is the recommendation? A clear recommendation with the reasoning and the assumptions.

Quantify the benefits where possible. Even a range is better than "it will improve efficiency". A business case without numbers rarely gets funded.

Step by step:

1. Start with the problem, not the solution. Ask "what is going wrong today?" instead of "what do you want built?".
2. Use observation and prototyping. Show a mock-up and let the stakeholder react. People find it easier to respond to something visible.
3. Look at the existing data. Volumes, error rates and timings reveal what is actually happening.
4. Interview the end users, not just the managers. The people doing the work often know the pain points best.
5. Break the problem into smaller pieces. Deliver the first piece and iterate based on feedback.
6. Document assumptions clearly. Where there is no clarity, state the assumption and confirm it in the next review.

Practical approaches:

• Single requirements register. One shared repository for the whole program, not one per team.
• Cross-team refinement. A regular session where BAs from each team review each other's stories.
• Dependency mapping. Track which team's story depends on another team's deliverable. Review weekly.
• Common glossary. One definition of "customer", "order" and "active user" across all teams.
• Interface contracts. Document the APIs and data exchanged between teams — the BA supports this with the architects.
• End-to-end process owner. One person accountable for the end-to-end flow, so no gap falls between teams.

Most program-level failures are integration failures — requirements that were clear inside one team but not agreed across teams. The BA's job is to catch that early.

Step 1 — Understand the constraint. Is it a hard technical limit, a time limit, or a preference? Ask for the specific reason.

Step 2 — Separate the requirement from the solution. "The user must see the balance in real time" is a requirement. "Using a websocket" is a solution. Alternative solutions may meet the requirement.

Step 3 — Work with the developer to find options. What is the closest achievable behaviour? What is the trade-off in cost or performance?

Step 4 — Take the options back to the business. Explain the constraint in plain language and the compromise required.

Step 5 — Document the decision. If the business accepts the compromise, note it in the requirement. If not, the requirement is a project risk for the sponsor.

Step 1 — Thank them and log the request. Do not reject it immediately — understand it first.

Step 2 — Ask "what problem does this solve?" The stated requirement may hide a different, simpler need.

Step 3 — Assess the impact with the team. Even a "small" change affects testing and release readiness.

Step 4 — Present the trade-off to the sponsor. Adding this now either delays the release or replaces something else in scope.

Step 5 — Get a decision. If added, update documents and the RTM. If deferred, log it for the next release and tell the stakeholder when it will be reviewed.

Never add scope silently. Scope creep starts with "small" changes.

Step 1 — Understand the workflow behind each request. Different workflows often need different screens, not one compromised screen.

Step 2 — Identify the common requirements — data, actions, validations. These form the shared base.

Step 3 — Identify the differences. Can they be handled with role-based views, configurable fields or a filter default?

Step 4 — Facilitate a joint session if needed. Present both workflows and the impact on cost and maintenance.

Step 5 — Recommend the option with the best cost-benefit, and let the sponsor decide if there is still disagreement. Document the decision.

Step 1 — Confirm it is a genuine gap, not a misunderstanding. Read back the original requirement and the acceptance criteria to the business user.

Step 2 — Assess the impact. Is it a critical gap that blocks go-live, or a usability improvement that can wait?

Step 3 — Log it as a defect or a change request with the impact assessment.

Step 4 — Escalate to the sponsor with the options — fix now with a delay, fix after go-live, or accept a workaround.

Step 5 — After the decision, update the requirements document, the RTM and the test cases. Do a lessons-learned review to see how the gap was missed in elicitation.

Step 1 — Quantify the gap. How many story points or days of work are left vs available?

Step 2 — Present the options honestly to the sponsor:

• Reduce scope — deliver the must-haves only.
• Extend the deadline — deliver everything but later.
• Add resources — bring in more people, accepting the onboarding cost.
• Split delivery — release in two phases.

Step 3 — Recommend the option with the least business risk. In most cases, a reduced scope on time beats a full scope that is late.

Step 4 — Get a written decision and update the plan, the scope baseline and everyone affected.

Step 5 — Do not silently reduce quality to hit the date. That is how production defects get created.

Step 1 — Talk to the people who built it and the people who use it. Capture the current functionality and the pain points.

Step 2 — Reverse-engineer the current system. Walk through the screens, read the database schema, and look at the actual data flows.

Step 3 — Document the as-is state. Even a rough process flow and a screen list is progress.

Step 4 — Validate the as-is with the business. Ask "is this how it works?" — the answer often reveals undocumented rules.

Step 5 — From the as-is, build the requirements for the next change. Do not try to recreate the historical BRD — focus on what is needed now.

Step 1 — Clarify the actual decision. Often the technical choice has a business implication — cost, performance, security or vendor lock-in.

Step 2 — Present the options with their business impact. "Option A costs more to run but scales better; option B is cheaper but has a limit of X users."

Step 3 — Bring in the architect or tech lead for the technical recommendation.

Step 4 — Take the business decision to the sponsor if it affects cost or the project plan.

Step 5 — Document the decision and the reasoning. It will be needed in code review and audit.

The BA does not decide technical questions alone — the BA makes sure the decision considers the business impact.

Step 1 — Request a handover meeting with the outgoing sponsor and the incoming one.

Step 2 — Prepare a one-page project brief — objective, scope, current status, key decisions made, open risks and pending decisions.

Step 3 — Walk through the key documentation. Focus on what has been agreed and why, not on every detail.

Step 4 — Introduce the new sponsor to the other key stakeholders and the team.

Step 5 — Ask the new sponsor for confirmation on the current scope and priorities. A new sponsor may have different priorities — better to know now than to be surprised at the next steering committee.

Step 1 — Make the edge case concrete. Give the business a specific example and ask what should happen.

Step 2 — Propose a default behaviour based on similar rules elsewhere in the system. Confirm it with the business.

Step 3 — Document the assumption in the requirement and the acceptance criteria.

Step 4 — Mark the item as "needs confirmation by <date>" and follow up.

Step 5 — If confirmation does not come, proceed with the documented assumption and flag it as a residual risk for the sponsor.

"Handle it sensibly" is not a requirement. The BA's job is to make it one.

Step 1 — Confirm the audience. Is the BRD for internal approval, for a vendor, or for compliance? Each has a different level of detail.

Step 2 — Talk to the sponsor first. Get the business objective, the scope and the success criteria in writing.

Step 3 — Run one or two workshops with the key stakeholders to gather the high-level requirements. Do not try to detail everything in week one.

Step 4 — Write the BRD sections — background, objectives, scope (in and out), stakeholders, high-level requirements, assumptions, constraints, risks and success metrics.

Step 5 — Circulate a draft for a 48-hour review. Get sign-off and baseline the document.

Step 6 — Move to the FRD and user stories with the detailed requirements.

1. Document control
   - Version, author, reviewer, approval date, distribution list

2. Executive summary
   - One paragraph on why the project is needed and what it will deliver

3. Business background
   - Current returns process, pain points, volumes, cost of handling

4. Business objective
   - Reduce average returns processing time from 5 days to 2 days
   - Reduce returns-related support tickets by 30%

5. Scope
   - In scope: online returns for domestic orders placed on the website
   - Out of scope: marketplace seller returns, international orders

6. Stakeholders
   - Customer service head (sponsor), operations manager, IT delivery lead,
     warehouse team, finance

7. High-level requirements
   - BR-01: Customer can initiate a return from the order history page
   - BR-02: Return is approved or rejected within 24 hours
   - BR-03: Refund is processed automatically on receipt of the item
   - BR-04: Customer receives email and SMS updates at every stage

8. Assumptions
   - Payment gateway supports partial refunds
   - Warehouse has barcode scanning in place

9. Constraints
   - Must integrate with the existing order management system
   - Release must happen before the festive season

10. Risks
    - Integration delays with the payment gateway
    - High return volume during festive season may stress the workflow

11. Success metrics
    - Average processing time (target: under 2 days)
    - Refund accuracy rate (target: above 99%)
    - Returns-related support tickets (target: 30% reduction)

12. Approval
    - Sponsor, business head, IT head

A BRD is not a template to fill in — it is a structured argument for the project. Every section either states the business need or proves the business need. Interviewers want to see that reasoning, not the section headers.

As a customer who has returned an item,
I want the refund to be processed automatically when the warehouse receives it,
so that I do not have to follow up for my money.

Given the warehouse has marked a returned item as "Received"
When  the return is approved in the system
Then  a refund is initiated to the original payment method
And   the order status changes to "Refund initiated"
And   an email and SMS are sent to the customer

Given the refund fails at the payment gateway
When  the gateway returns an error
Then  the order status changes to "Refund failed"
And   an alert is raised for the finance team
And   the customer is notified that the refund is under review

Given a partial return (1 of 2 items)
When  the return is received and approved
Then  only the amount for the returned item is refunded
And   the order status is set to "Partially refunded"

Note how each story has a happy path and error paths. Interviewers look for the error paths — that is where most candidates stop too early.

1. Initiate. The customer logs in and selects "Return" on a delivered order within the return window.

2. Select items and reason. The customer picks the item(s) and a reason from a dropdown — wrong size, damaged, not as described, changed mind.

3. Auto-approval check. The system approves the return if the order is within the window and the reason is on the auto-approve list. Otherwise it is routed to a customer-service agent.

4. Return label. An email and SMS with the return label and pickup details is sent to the customer.

5. Warehouse receipt. The warehouse scans the returned item and updates the status to "Received".

6. Quality check. The warehouse team verifies the item matches the return request and is in resalable condition.

7. Refund initiation. The system triggers the refund to the original payment method and updates the order status.

8. Customer notification. Email and SMS are sent confirming the refund amount and expected credit timeline.

9. Reconciliation. The finance team reconciles the refund against the payment gateway report daily. Any mismatch is investigated.

In an interview, mention the branch points — approval vs rejection, partial vs full return, refund success vs failure. That is what a BPMN diagram would show as gateways.

Business question: which products are being returned most often? This drives quality checks with the supplier.

SELECT
    p.product_name,
    COUNT(o.order_id)  AS total_orders,
    COUNT(r.return_id) AS total_returns,
    ROUND(
        100.0 * COUNT(r.return_id) / COUNT(o.order_id),
        2
    ) AS return_rate_pct
FROM orders o
JOIN products p      ON p.product_id = o.product_id
LEFT JOIN returns r   ON r.order_id   = o.order_id
WHERE o.order_date >= '2026-01-01'
GROUP BY p.product_name
HAVING COUNT(o.order_id) >= 50
ORDER BY return_rate_pct DESC
LIMIT 5;

product_name         total_orders  total_returns  return_rate_pct
------------------------------------------------------------------
Wireless Earbuds X2           220            46           20.91
Running Shoes Pro             180            31           17.22
Ceramic Coffee Mug            310            41           13.23
Cotton Bedsheet Set           145            18           12.41
LED Desk Lamp                 260            29           11.15

The HAVING clause matters — without a minimum order threshold, a product with 1 order and 1 return shows a 100% return rate and misleads the business.

Note: MySQL 8 and PostgreSQL support LIMIT. SQL Server uses TOP instead. Always mention this in an interview if the company uses SQL Server.