Business Analyst Interview Questions and Answers: 60 Questions from Easy to Hard
This guide is for freshers in India aiming for a first business analyst role, and for working BAs, developers, testers and consultants moving into business analysis at IT services firms, product companies, banks and other businesses. It has 60 questions with model answers in three levels: the basics every fresher must know, real-world questions for people with 1 to 4 years of experience, and senior questions on stakeholder politics, prioritisation, data and business cases. Topics include elicitation, BRD and FRD, user stories, use cases, BPMN, gap analysis, MoSCoW, Scrum, UAT, change requests, SQL and ROI, plus two typical case questions. Answer each question aloud before reading the model answer, then take the mock test to check yourself.
- 60 questions, 3 levels
- Updated
- CoreHRx Jobs
- 423 open Business Analysis jobs
What business analyst interviews cover
- The BA role and stakeholders: what a BA does day to day, stakeholder analysis, RACI and handling conflicting demands.
- Requirements work: elicitation techniques, functional and non-functional requirements, BRD, FRD and SRS documents, and traceability.
- Agile delivery: user stories, acceptance criteria, backlog refinement, Scrum events and how a BA works with the Product Owner.
- Analysis tools: BPMN process models, use cases, gap and root cause analysis, wireframes, and prioritisation methods such as MoSCoW, RICE and WSJF.
- Data and money: basic SQL to check data, UAT and change requests, business cases with ROI, payback and NPV, and usually one open case question.
How to prepare (freshers and experienced)
- Freshers: learn the core terms in your own words, then practise writing one user story with acceptance criteria, one use case and one process map for an everyday app.
- Pick a process you know well, such as college admission or ordering food, and model its as-is and to-be versions; interviewers often ask you to walk through one.
- Practise SQL with SELECT, WHERE, GROUP BY and joins on a small sample dataset until you can write a query without notes.
- Experienced BAs: prepare three or four project stories with numbers: the problem, your role, the stakeholders, what you delivered and the measured result.
- Revise how to calculate ROI, payback and NPV and how to score features, because case rounds often include a quick calculation.
Common mistakes and interview-day tips
- Do not jump to a solution in a case question; first ask about the goal, the users and how success will be measured.
- Avoid textbook definitions with no example. One short story from a project or internship is worth more than a perfect definition.
- Show that you write testable requirements: give numbers, roles and conditions instead of words like fast, easy or user-friendly.
- Be honest about tools. Say which ones you have used on real work and which ones you only know from practice.
- Think aloud and give your answer a structure, for example understand, analyse, recommend, so the interviewer can follow your reasoning.
Business Analysis interview questions: Easy questions (freshers)
20 questions1. What does a business analyst do, and how is the role different from a project manager?
A business analyst works out what the business really needs and turns it into clear, agreed requirements that a delivery team can build and test. That means understanding the problem, talking to stakeholders, modelling processes, writing requirements and checking that the delivered solution solves the original problem. A project manager owns how and when it is delivered: scope, schedule, budget, people and risks. Put simply, the BA answers what and why, the PM answers how, when and at what cost. In small teams one person may do both, but the focus stays different.
2. Who is a stakeholder, and how do you identify the stakeholders on a new project?
A stakeholder is anyone who affects the project or is affected by its outcome: the sponsor paying for it, end users, their managers, IT and support teams, compliance, vendors and sometimes customers. To find them, start with the sponsor and ask who uses, approves, supports or is impacted by the process, then follow the process end to end and note every role that touches it. Org charts and past project documents help. A common mistake is listing only the people who asked for the system and missing groups such as audit or support, who later block go-live.
3. What is a power-interest grid, and how do you use it for stakeholder analysis?
It is a two-by-two grid that places each stakeholder by how much power they have over the project and how interested they are in it. High power and high interest people, such as the sponsor, are managed closely and involved in decisions. High power, low interest people are kept satisfied with short, focused updates. Low power, high interest people, often end users, are kept informed and consulted for detail. The rest are monitored. Positions change during a project, so revisit the grid: a CFO with low interest becomes very interested once the budget overruns.
Low interest High interest
High power Keep satisfied Manage closely
(CFO, IT head) (sponsor, ops head)
Low power Monitor Keep informed
(other branches) (branch staff, users)4. Which requirement elicitation techniques do you know, and when would you use each?
Interviews give depth from one person, such as a department head. Workshops bring several stakeholders together to agree scope or settle conflicts quickly. Observation, or job shadowing, shows how work really happens, which often differs from what people describe. Surveys reach many users, for example 300 branch staff, but give shallow answers. Document analysis of existing forms, reports and policies gives a base before meetings. Prototypes help when users cannot say what they want until they see it. Good BAs combine two or three techniques instead of relying on interviews alone.
5. What is the difference between functional and non-functional requirements? Give examples.
A functional requirement says what the system must do, for example 'the system shall let an HR executive approve or reject a leave request' or 'the app shall send an OTP to the registered mobile number'. A non-functional requirement says how well it must do it: performance, security, availability, usability, scalability or compliance, for example 'the leave list shall load within 2 seconds for 500 concurrent users'. Both must be testable. A frequent mistake is skipping non-functional requirements and discovering at go-live that the system is too slow or fails a security audit.
6. What is the difference between a BRD, an FRD and an SRS?
A BRD, or business requirements document, describes the business need: the problem, objectives, scope, stakeholders and high-level business requirements, for the sponsor and business readers. An FRD, or functional requirements document, explains what the system must do to meet those needs, feature by feature, with business rules, for the delivery team. An SRS, or software requirements specification, is the fullest specification, covering functional and non-functional requirements, interfaces and constraints. Names and contents vary by company, so ask which template the team uses.
7. What makes a requirement well written? Improve a vague one.
A good requirement has one clear meaning, is complete, testable and feasible, and traces back to a business need. 'Fast and easy to use' fails because two people read it differently and a tester cannot pass or fail it. The better version gives a measurable target, splits two ideas into two requirements and gives each an ID so it can be traced to design and tests. Use 'shall' for mandatory items, avoid words like user-friendly, quickly or etc., and describe what is needed, not how the developers should build it.
Weak : The report should be fast and easy to use.
Better:
REQ-REP-04 The branch sales report shall load within
3 seconds for any date range up to 31 days.
REQ-REP-05 A user shall be able to filter the report by
branch and date range and export it to Excel.8. What is a user story, and what format is it written in?
A user story is a short description of a feature from the point of view of the person who needs it, written to start a conversation rather than replace one. The usual format is: as a role, I want a capability, so that I get a benefit. The so-that part matters because it tells the team the value and lets them suggest a simpler solution. A story is not complete without acceptance criteria. A common mistake is writing technical tasks as stories, such as 'as a developer I want a database table', which have no user value.
As a branch manager
I want to see pending loan applications older than 3 days
So that I can follow up before the customer drops off9. What are acceptance criteria, and how do you write them in Given-When-Then form?
Acceptance criteria are the conditions a story must meet before the product owner accepts it as done. They set the boundary of the story and become the basis for tests. Given-When-Then states the starting context, the action and the expected result, which makes each criterion concrete and testable. Cover the main path and the important unhappy paths, like an expired coupon. Keep criteria about behaviour the user can see, not about how it is built. A typical mistake is writing only the happy path, so the expired case gets built differently from what the business wanted.
Story: As a customer I want to apply a coupon at checkout.
Given my cart total is Rs 1,500 and coupon SAVE200 is active
When I apply SAVE200
Then the total becomes Rs 1,300
Given coupon SAVE200 expired yesterday
When I apply SAVE200
Then I see "This coupon has expired" and the total is unchanged10. What is a use case? Explain actors, the main flow and alternate flows.
A use case describes, step by step, how an actor interacts with a system to reach a goal. An actor is a role outside the system: a person such as a customer, or another system such as a payment gateway. The main flow, also called the basic flow or happy path, is the usual sequence when everything goes right. Alternate flows cover other valid ways to reach the goal, and exception flows cover errors such as a failed payment. Preconditions and postconditions state what must be true before and after. Use cases suit complex interactions where step-by-step detail matters.
11. What is BPMN, and what are its basic elements?
BPMN, Business Process Model and Notation, is a standard notation for drawing business processes so that business and IT read a diagram the same way. Its core elements are events drawn as circles (start, intermediate and end), activities drawn as rounded rectangles, gateways drawn as diamonds for decisions and parallel paths, and sequence flows drawn as solid arrows. Pools represent participants such as organisations, and lanes split a pool by role or department. Message flows, drawn as dashed lines, run between pools. Most BA diagrams need only this small subset.
12. What is the difference between an as-is and a to-be process model?
The as-is model shows how the process works today, including workarounds, manual steps, delays and handoffs. The to-be model shows how it should work after the change. You build the as-is first so everyone agrees on the starting point and the pain points become visible, for example a purchase approval that waits two days for a signature. Comparing the two shows what has to change in people, process and system. A common mistake is drawing the as-is from the official policy instead of watching real work, which hides the problems the project should fix.
13. What is gap analysis? Give a simple example.
Gap analysis compares the current state with the desired future state and lists what is missing in between, so you can plan the changes needed. For example, a Coimbatore textile exporter tracks orders in spreadsheets today and wants customers to see order status online. The gaps include no central order database, no customer login and no rule for updating the status at each production stage. Each gap becomes a requirement, a process change or a training need. Be specific: better reporting is not a gap, but no daily stock report by warehouse is.
14. How does MoSCoW prioritisation work?
MoSCoW sorts requirements into four groups for a given release. Must have items are essential: without them the release is pointless, illegal or unsafe. Should have items are important, but the release still works without them, perhaps with a workaround. Could have items are nice to have and are the first to drop when time runs short. Won't have this time items are agreed to be out of this release, which manages expectations. The two letter o's only make the word easy to say. The usual mistake is letting stakeholders mark almost everything as Must, which makes the method useless.
15. What are the Scrum roles and events, and where does a business analyst fit?
The 2020 Scrum Guide defines three accountabilities: the Product Owner, who orders the product backlog and maximises value; the Scrum Master, who helps the team use Scrum well; and the Developers, who build the increment. The events are the Sprint itself, Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. Scrum has no separate BA role, so a BA usually works inside the team or supports the Product Owner by refining backlog items, writing acceptance criteria and clarifying business rules. In many service companies the BA also acts as a proxy Product Owner.
16. What is a product backlog, and what happens in backlog refinement?
The product backlog is an ordered list of everything that might be needed in the product, with the most valuable and best-understood items at the top. Backlog refinement is the ongoing work of adding detail to items, splitting large ones, writing acceptance criteria, estimating and re-ordering, so the next few sprints have items ready to pull in. The Scrum Guide treats it as an ongoing activity, not a formal event, though many teams hold a regular session. As a BA, prepare items before that session so the team spends the time on questions, not on reading the story for the first time.
17. What is UAT, who performs it, and how is it different from system testing?
User acceptance testing is the final check where business users confirm that the system supports their work and meets the agreed requirements before go-live. Business users or their representatives perform it, while the BA usually plans scenarios, prepares data, supports users and tracks defects. System testing is done by the QA team to verify the system works as specified, including edge cases and technical behaviour. UAT asks a different question: does it work for the business in realistic situations? Starting UAT before system testing is stable wastes users' time on basic bugs.
18. Why should a business analyst know SQL? What does this query return?
SQL lets a BA check data directly: validate a requirement against real numbers, size a problem, test a report or investigate a UAT defect without waiting for a developer. This query keeps only paid orders, groups them by city and adds them up. It returns Pune with 3 paid orders and revenue 2550, then Indore with 1 paid order and 650. Surat does not appear because its only order was cancelled, and the pending Indore order is left out. A common slip is forgetting the WHERE filter, which would count cancelled and pending orders as revenue.
orders
order_id city amount status
101 Pune 1200 PAID
102 Indore 800 PENDING
103 Pune 450 PAID
104 Surat 2000 CANCELLED
105 Indore 650 PAID
106 Pune 900 PAID
SELECT city, COUNT(*) AS paid_orders, SUM(amount) AS revenue
FROM orders
WHERE status = 'PAID'
GROUP BY city
ORDER BY revenue DESC;19. What is the difference between a wireframe, a mockup and a prototype?
A wireframe is a low-detail layout showing what goes where on a screen, usually in grey boxes, to agree on content and structure. A mockup adds the visual design: colours, fonts, images and realistic content, so stakeholders see how it will look. A prototype is clickable and shows how it behaves, such as moving from the cart to the payment screen. Use wireframes early, because they are cheap to change and keep the discussion on content, not colour. A BA uses them to confirm requirements; the visual design usually belongs to a UI or UX designer.
20. What is ROI, and how do you calculate it for a project?
Return on investment shows how much a project earns back relative to its cost. Here a Jaipur retail chain spends Rs 20 lakh on a stock system that saves Rs 7.5 lakh a year for four years, a total benefit of Rs 30 lakh. ROI = (30 - 20)/20 x 100 = 50 percent over four years, and the cost is recovered in about 2.7 years. Always state the period, because 50 percent over four years is very different from 50 percent in one year. Simple ROI ignores when the money arrives, which is why larger business cases also use NPV.
Cost (software, setup, training) : Rs 20 lakh
Net benefit per year, for 4 years : Rs 7.5 lakh
Total benefit over 4 years : Rs 30 lakh
ROI = (total benefit - cost) / cost x 100Ready to check yourself? Take the free Business Analysis mock test
Business Analysis interview questions: Medium questions (1-3 years)
20 questions21. What is a RACI matrix, and how do you use it on a project?
A RACI matrix maps each activity or deliverable to who is Responsible for doing the work, who is Accountable for the outcome and gives final approval, who is Consulted before decisions and who is Informed afterwards. As a BA I build it early, so sign-offs and reviews do not get stuck later. The key rule is exactly one A per row; two accountable people means nobody is. Too many C entries slow everything down, so consult only those whose input changes the result. Agree the matrix with stakeholders, then use it to chase approvals.
Activity Sponsor BA Dev lead Ops head QA
Approve scope A R C C I
Write requirements I A/R C C C
Sign off requirements A R I R I
Plan UAT I A/R I C C
Go-live decision A C C R C22. Two senior stakeholders give you conflicting requirements. How do you handle it?
First I check that the conflict is real by restating both requirements and the reason behind each. Often the goals fit together: in a Bengaluru fintech the sales head wants faster loan approvals and the risk head wants fewer bad loans, so automatic approval for low-risk profiles with manual review for the rest may satisfy both. I bring them together with data, such as approval times and default rates, and present options with their impact. If they still disagree, the decision goes to the sponsor, and I record it. A BA facilitates the decision and never quietly picks a side.
23. How do you prepare for and run a requirements workshop?
Before it, I agree a clear objective with the sponsor, invite only people who can contribute or decide, share an agenda and background, and read the existing documents so I do not waste their time on basics. During it, I state the goal and ground rules, use visuals such as a process map on a whiteboard, ask open questions first and closed ones to confirm, park off-topic points and keep a visible list of decisions and open questions. Afterwards I send notes within a day with decisions, actions, owners and dates. Without that follow-up, people remember different outcomes.
24. A stakeholder says the new system must be user-friendly and fast. How do you turn that into a usable requirement?
I ask questions until the words become measurable. For fast: which screen or action, how many users at the same time, on what network, and what response time is acceptable, giving for example 'the claim status page loads within 2 seconds on a 4G connection'. For user-friendly: who the users are and which task they struggle with today, giving for example 'a new agent can register a claim without training in under 5 minutes'. I confirm each target with the stakeholder and check feasibility with the tech team. A vague requirement left in the document becomes an argument at UAT.
25. What is a requirements traceability matrix (RTM), and why is it useful?
An RTM links each requirement to its source and to the design items and test cases that cover it. Forward traceability shows every requirement has been built and tested; backward traceability shows every feature exists because of a real requirement, which stops gold-plating. In this example BR-02 has no test case, a gap to close before UAT, and FR-01.2 has a failed test. The RTM also speeds up impact analysis: when a requirement changes, you see at once which designs and tests are affected. It is only useful if someone keeps it up to date.
Req ID Requirement Design Tests Status
BR-01 Customer can track order FD-3.2 TC-11,TC-12 Passed
FR-01.1 Show status at each stage FD-3.2.1 TC-11 Passed
FR-01.2 SMS on dispatch FD-3.4 TC-15 Failed
BR-02 Daily stock report FD-4.1 (none) Not tested26. A user story is too big for one sprint. How do you split it?
I split it vertically, so each smaller story still delivers something a user can use and test, instead of splitting by technical layer such as database, API and screen. Useful patterns are by workflow step, by business rule, by data variation, simple case before complex case, and happy path first with exceptions later. In this example the policyholder can register a claim in the first sprint even before uploads exist. Each split story gets its own acceptance criteria. A common mistake is splitting into front-end and back-end stories, which delivers nothing usable until both are done.
Epic: As a policyholder I want to file a motor insurance
claim online
Split by workflow step:
1. As a policyholder I want to register a claim with my policy
number and accident date
2. As a policyholder I want to upload photos and documents
3. As a policyholder I want to track my claim status
Split by rule or data variation:
4. Handle cashless claims at network garages (later sprint)27. What is the INVEST checklist? Show a story that fails it and fix it.
INVEST says a good story is Independent of others where possible, Negotiable in its details, Valuable to a user or the business, Estimable by the team, Small enough to finish in a sprint and Testable with clear criteria. The weak story fails almost every check: no real role, no clear capability, no value and nothing to test. The fixed story names a role, a specific action and the benefit, so the team can estimate it and write acceptance criteria, for example for an unreadable barcode. Use INVEST as a quick review during refinement, not as a rigid gate.
Weak : As a user I want the system to be better so that it
is good.
Fixed: As a warehouse supervisor I want to scan a parcel barcode
to mark it dispatched, so that customers see the update
without manual entry.28. What goes into a use case specification, and what is the difference between include and extend?
A specification has an ID and name, actors, preconditions, the main flow, alternate and exception flows, postconditions and business rules. Each step is an actor action or a system response. Include is used when a base use case always reuses a common piece of behaviour, such as Authenticate user inside several use cases; the arrow points from the base to the included one. Extend adds optional or conditional behaviour at a defined point, such as Apply discount code extending Checkout; the arrow points from the extension to the base. Mixing them up is a classic slip.
Use case : UC-07 Apply for leave
Actors : Employee (primary), Leave system
Pre : Employee is logged in; leave balance is loaded
Main flow:
1. Employee selects leave type and dates
2. System shows days requested and remaining balance
3. Employee submits the request
4. System sends it to the reporting manager
Alternate: 2a. Dates include a holiday - system leaves it out
Exception: 3a. Balance too low - system blocks submit with a message
Post : Request is saved with status Pending29. How do you find the bottleneck in a process? Analyse this loan approval flow.
Measure both the work time and the waiting time at each step, because delays usually sit in the waits and handoffs, not in the work. Here the total work is 2 hours, but the lead time is 50 hours, because 48 hours are spent waiting. Process cycle efficiency is 2/50 = 4 percent. Making the credit officer faster saves little; replacing the courier with scanned uploads removes 24 hours, nearly half the lead time. I draw this as a swimlane diagram so every handoff between branch, hub and manager is visible. Use real timestamps, not people's estimates.
Step Work time Wait before next step
1 Branch checks documents 0.5 h 24 h (courier to hub)
2 Credit officer review 1.0 h 16 h (queue)
3 Manager approval 0.25 h 8 h (in inbox)
4 Disbursement 0.25 h -30. How do you do root cause analysis? Show the 5 Whys on a real problem.
Root cause analysis looks past the symptom to the cause that, once fixed, stops the problem coming back. The 5 Whys asks why repeatedly, each answer backed by evidence, until you reach a cause you can act on; five is a guide, not a rule. Here the obvious fix, hiring more finance staff, would only treat a symptom, while the real cause is an approval rule nobody revisited. For problems with several causes, a fishbone diagram groups possible causes under headings such as people, process, system and policy before you test each with data. Never stop at a person to blame.
Problem: refunds take 6 days on average against a 3-day promise.
Why 1: Refunds wait for approval by the finance team.
Why 2: Finance approves refunds only in one daily batch.
Why 3: Every refund above Rs 500 needs a manual approval.
Why 4: The Rs 500 limit was set years ago to stop agent fraud.
Why 5: No one reviewed the rule after fraud checks were automated.
Root cause: an outdated approval rule, not slow finance staff.31. How does a weighted scoring model help prioritise features? Score these two features.
Agree the criteria and their weights with stakeholders first, score each feature on every criterion, multiply each score by its weight and add up. Bulk upload scores 0.4 x 9 + 0.3 x 7 + 0.2 x 4 + 0.1 x 6 = 7.1, and dark mode scores 0.4 x 3 + 0.3 x 9 + 0.2 x 10 + 0.1 x 8 = 6.7, so bulk upload comes first. Without weights dark mode would win, 30 points to 26, which shows why the weights matter. Fixing the weights before anyone scores stops people from adjusting numbers to favour their own feature.
Criterion Weight Bulk upload Dark mode
Revenue impact 40% 9 3
User demand 30% 7 9
Ease (low effort) 20% 4 10
Risk reduction 10% 6 832. What is RICE scoring? Which of these two features scores higher?
RICE scores an idea from four estimates: how many users it reaches in a period, how much it helps each of them, how confident you are in those estimates, and the effort in person-months. Feature A scores 4,000 x 2 x 0.8/4 = 1,600. Feature B scores 10,000 x 0.5 x 1.0/2 = 2,500, so B ranks higher despite its lower impact, because it reaches more users for half the effort. The confidence factor penalises guesses. The score feeds the discussion; it is not a verdict, and a regulatory or strategic item can still go first.
A Smart reminders B One-tap reorder
Reach (users/qtr) 4,000 10,000
Impact (0.25 to 3) 2 0.5
Confidence 80% 100%
Effort (person-mo) 4 2
RICE = Reach x Impact x Confidence / Effort33. What is the difference between the Definition of Ready and the Definition of Done?
The Definition of Done is the team's shared standard for when an increment is complete, for example code reviewed, tested, acceptance criteria met and documentation updated; the Scrum Guide requires one. The Definition of Ready is a team practice, not part of the Scrum Guide, listing what a backlog item needs before the team takes it into a sprint, such as a clear story, acceptance criteria, known dependencies and an estimate. The BA does much of the work that makes items ready. Treat Ready as a checklist, not a wall; a very strict one turns agile back into waterfall handoffs.
34. What does a business analyst do during a sprint, and how is that different from the Product Owner?
The Product Owner decides what goes into the backlog, its order and what is accepted, because they are accountable for product value. The BA helps the PO and the team decide well: analysing needs, breaking epics into stories, writing acceptance criteria and business rules, and checking the result against the need. During a sprint the BA is usually one or two sprints ahead preparing items, joins planning to answer questions, supports testers, and captures feedback at the review. The BA advises on priority, but the PO makes the final call.
35. How do you plan UAT, and how do you write a UAT scenario?
I plan UAT from the business processes, not the screens: list the real tasks users perform, write end-to-end scenarios with realistic data, and agree entry and exit criteria with the sponsor. Each scenario states who does it, the data, the steps at business level and the expected outcome. I arrange the environment and test data, brief the users, sit with them during testing, log defects with steps and screenshots, and run a daily triage. Sign-off is given against the exit criteria. A common mistake is handing users the QA test cases, which test the system, not their work.
ID Scenario Data Expected
UAT-04 Branch user books a two- KYC complete Loan created,
wheeler loan, 20% down EMI schedule shown
UAT-05 Same loan, customer has KYC pending Blocked with
no PAN on record 'PAN required'
Entry: system test passed, no open critical defects, UAT data loaded
Exit : priority scenarios passed, no open critical or high defects,
business sign-off recorded36. How do you handle a change request, and does it differ between waterfall and agile?
I log the change with who asked and why, then do an impact analysis: which requirements, designs, tests, timelines and costs it affects, using the traceability matrix. I present options, such as do it now, defer it or swap it for something of equal size, to whoever owns the decision; in waterfall that is often a change control board plus a contract change, in agile it is the Product Owner. In agile the change normally goes into the backlog for a later sprint, not the current one, unless the PO agrees the sprint goal still holds. Never accept a change informally in a corridor.
37. Find the customers who have never placed a paid order. Why does query 2 return nothing?
Query 1 returns Meera and Kabir. A LEFT JOIN keeps every customer; where no paid order matches, the order columns are NULL, so filtering on o.order_id IS NULL leaves the customers without a paid order. Meera has only a cancelled order and Kabir has none. Query 2 returns no rows because the status test sits in WHERE: a row would need status PAID and a NULL order id at the same time, which is impossible. Conditions on the right-hand table of a LEFT JOIN belong in the ON clause. Check such results against a quick manual count before sharing them.
customers(id, name): 1 Asha, 2 Ravi, 3 Meera, 4 Kabir
orders(order_id, cust_id, status):
101 1 PAID, 102 2 PENDING, 103 1 PAID,
104 3 CANCELLED, 105 2 PAID
-- query 1
SELECT c.name FROM customers c
LEFT JOIN orders o ON o.cust_id = c.id AND o.status = 'PAID'
WHERE o.order_id IS NULL;
-- query 2
SELECT c.name FROM customers c
LEFT JOIN orders o ON o.cust_id = c.id
WHERE o.status = 'PAID' AND o.order_id IS NULL;38. What is a data mapping document, and what goes into it for a data migration?
A data mapping document lists, for every target field, the source field, the transformation rule, default values, validation and what happens to bad records. It is the contract between the business, developers and testers. The BA drives the business rules, such as how to split names or treat a missing city, and gets the data owners to approve them. Profile the source by counting blanks, duplicates and invalid values, because real data always breaks assumptions; a two-digit year needs a century rule. Plan reconciliation too, such as matching record counts and totals after each run.
Source (old CRM) Target (new system) Rule
cust_name first_name, last_name Split on the last space;
review one-word names
mob mobile Keep last 10 digits;
reject if not 10 digits
dob (DD/MM/YY) date_of_birth Convert to YYYY-MM-DD;
agree the century rule
city_code city_id Look up city master;
else Unknown + flag39. How do you use wireframes to validate requirements with stakeholders?
I sketch low-fidelity wireframes as soon as I understand the main tasks, then walk stakeholders through a realistic scenario, such as a branch officer searching for a customer and updating the address, instead of just showing screens. That reveals missing fields, steps in the wrong order and unclear rules early, when a change costs minutes. I annotate each screen with rules, validations and data sources and link it to requirement IDs. I keep wireframes grey so the talk stays on content and flow, not colours. Never treat approval of a pretty mockup as approval of every rule behind it.
40. What is the payback period? Calculate it for this project and say what it misses.
The payback period is the time a project takes to earn back its initial cost from its net benefits. Cumulative benefits reach Rs 17 lakh after year 3, so Rs 1 lakh is still to recover, and year 4 brings Rs 8 lakh. Payback = 3 + 1/8 = 3.125 years, about 3 years and 1.5 months, assuming benefits arrive evenly through the year. It is easy to explain and shows how long money is at risk, but it ignores everything after payback and the time value of money. That is why NPV is used alongside it.
Initial cost : Rs 18 lakh
Year : 1 2 3 4
Net benefit : 4 6 7 8 (Rs lakh)
Cumulative : 4 10 17 25Ready to check yourself? Take the free Business Analysis mock test
Business Analysis interview questions: Hard questions (experienced)
20 questions41. A senior stakeholder keeps sending requests straight to the developers, bypassing the process. How do you handle it?
I treat it as a stakeholder problem, not a rule violation. First I find out why they bypass the process; often it is too slow or they feel unheard. I meet them privately, show the effect of the side requests with facts, such as two missed sprint goals and untested changes in production, and offer a faster route, like a weekly slot with the Product Owner to review their items. I agree with the team lead that developers redirect such requests to the backlog. If it continues, I escalate to the sponsor with data. The proper route must be easier than the shortcut.
42. Users cannot explain how they do their job, or describe it differently from how they actually work. How do you get the real requirements?
Much expert knowledge is tacit: people do it without thinking and leave steps out when asked. So I combine techniques. I observe the work in context, for example sitting with claims processors at a Kochi insurer for a day, ask them to think aloud, and collect the real artefacts they keep on the side, such as notes and spreadsheets, which reveal hidden rules. I test my understanding by walking through real past cases and showing a quick prototype. Exceptions matter most, so I ask about the last unusual case they handled, then validate the documented process with the users.
43. How do you write measurable non-functional requirements? What does 99.9 percent availability allow?
Each NFR needs a metric, a target, the conditions and how it will be measured, otherwise nobody can test it. In a 30-day month, 99.9 percent availability allows about 43.2 minutes of unplanned downtime, while 99.5 percent allows 3.6 hours, so the step from 99.5 to 99.9 can change the architecture and the cost. Use percentiles for performance, such as 95 percent of requests, because averages hide slow outliers. Agree what is excluded, such as planned maintenance. Ask what an hour of downtime costs the business; that turns a wish for 100 percent into a sensible, funded target.
NFR-01 Availability: 99.9% per calendar month, measured at the
load balancer, excluding announced maintenance windows
NFR-02 Performance : 95% of search requests return within 1.5 s
with 2,000 concurrent users
NFR-03 Security : lock the account after 5 failed logins
within 15 minutes44. How much documentation does a BA need in agile compared with a fixed-price waterfall project?
Enough to cover the real risk, and no more. On a fixed-price contract the signed requirements define scope and money, so a baselined specification with sign-off and formal change control protects both sides. In agile with an engaged product owner, stories, acceptance criteria, a few process models and a glossary are usually enough, because conversation and working software replace long documents. Complex business rules, integrations, data definitions and regulatory needs need detail in both. Keep these as living documents, because stale documents mislead more than missing ones.
45. How do you express a complex business rule as acceptance criteria? Use a decision table.
When a rule has several conditions, I list every combination in a decision table so nothing is left to guesswork. Three yes-or-no conditions give 2 x 2 x 2 = 8 rules, and each column becomes one acceptance criterion and one test case. Writing the table often exposes cases the stakeholders never considered, such as what a non-member gets on a small order during a festive sale. Here the rule turns out to be simple, 5 percent for each condition met, which the business can confirm in one line. Columns with the same result can sometimes be merged, but only after checking.
Discount rule (assumed for this example)
R1 R2 R3 R4 R5 R6 R7 R8
Gold member Y Y Y Y N N N N
Order >= Rs 2,000 Y Y N N Y Y N N
Festive sale on Y N Y N Y N Y N
Discount 15% 10% 10% 5% 10% 5% 5% 0%46. When would you use use cases instead of, or alongside, user stories?
User stories are small and value-focused, good for planning and conversation, but they do not show the whole flow or how the stories fit together. Use cases describe a complete interaction with all alternate and exception paths, which suits complex workflows, integrations and regulated processes where a missed path is costly, such as a refund involving a bank and a payment gateway. I often write a use case or a process model for the big picture, then derive stories from its flows: one for the main path and others for the important alternates. The deciding factor is the risk of missing paths.
47. In BPMN, what is the difference between exclusive, parallel and inclusive gateways, and what goes wrong if you pick the wrong one?
An exclusive gateway, a diamond with an X or no marker, sends the flow down exactly one path based on a condition, like approve or reject. A parallel gateway, a diamond with a plus, starts all paths together, and its join waits for all of them, like a credit check and a background check running at once. An inclusive gateway, a diamond with a circle, takes every path whose condition is true. Joining parallel paths with an exclusive gateway is a typical bug: the next step starts as soon as the first check finishes, and again when the second one arrives.
48. You are implementing a packaged ERP or SaaS product. How do you run a fit-gap analysis and decide whether to customise?
I map the to-be processes against the product's standard features, ideally by running the client's real scenarios in a demo, and classify each requirement as fit, fit with configuration, gap with a workaround, or gap needing a customisation or add-on. For each gap I ask whether it is a real legal or competitive need or just how things were done before. Customisations add cost to every upgrade, so the default is to adapt the process unless the gap is regulatory or truly differentiating. I record each decision with its reason and owner, because these choices get questioned months later.
49. What is WSJF, and how does it rank these features?
Weighted Shortest Job First puts first the work that loses the most value by waiting, relative to its size. The cost of delay here is the sum of business value, time criticality and risk reduction, all relative scores. UPI autopay scores 26/8 = 3.25, regional languages 24/13 = about 1.85, and the KYC re-check 31/5 = 6.2. So the KYC re-check goes first even though it has the lowest business value, because an audit deadline makes delay costly and the job is small. The scores are relative, so compare only items scored together by the same group.
Feature Business Time Risk reduction/ Job
value criticality opportunity size
UPI autopay 8 13 5 8
Regional languages 13 3 8 13
KYC re-check (audit) 5 13 13 5
Cost of delay = value + time criticality + risk reduction
WSJF = cost of delay / job size50. Stakeholders mark 90 percent of the requirements as Must have. What do you do?
When nearly everything is a Must, the release has no buffer and any slip breaks the deadline. I go back to the definition: a Must is something without which the release is pointless, illegal or unsafe, and I test each item by asking what happens if it is missing and whether a workaround exists. A widely used guideline from the DSDM approach keeps Must items to about 60 percent of the planned effort, leaving room in Should and Could. Showing cost also helps: if the Must list needs 14 weeks against a 10-week deadline, stakeholders have to choose. I record their choices; I do not impose mine.
51. Case question: a Pune manufacturing firm wants to automate its manual vendor invoice approval. How would you approach the first two weeks?
I would start with the sponsor to agree the goal and how success is measured, for example approval time down from 12 days to 3 and no late-payment penalties. Next I map the stakeholders: accounts payable, purchase, plant heads, the finance controller, IT and audit. I observe the current process, collect sample invoices, count volumes and exceptions such as price mismatches against the purchase order, and draw the as-is process with time at each step. From that I list pain points, a draft to-be process, business rules and open questions, and review them before any tool is chosen.
52. The backlog has 210 story points left and the last four sprints delivered 28, 32, 30 and 26 points. How do you forecast the finish, and what are the risks?
At the average velocity of 29, the work needs 210/29 = about 7.2, so 8 sprints. The best and worst recent sprints give a range: 210/32 is about 6.6, so 7 sprints, and 210/26 is about 8.1, so 9 sprints. I would report 7 to 9 sprints, that is 14 to 18 weeks, rather than one date. Risks: the backlog usually grows as people learn, holidays such as Diwali cut capacity, and story points are relative estimates for this team only. Never compare velocity across teams or set it as a target, because teams then inflate their points.
Remaining work : 210 story points
Last 4 velocities : 28, 32, 30, 26 (average 29)
Sprint length : 2 weeks53. A week before go-live, UAT throws up 40 issues. How do you handle it?
First I triage every issue with the business and tech leads: is it a real defect against an agreed requirement, a change request disguised as a defect, a training or data issue, or a duplicate? Often many are not defects. Real defects get a severity based on business impact. Then we compare the list with the exit criteria, for instance no open critical defects and high ones only with an agreed workaround. I give the sponsor clear options, such as go live with listed workarounds, go live in phases, or delay, each with its risk. Change requests go to the backlog.
54. A change request asks the billing system to support a new tax slab and a different rounding rule. How do you do the impact analysis?
I start from the traceability matrix and the data flow to find everything that touches tax: masters, calculations, invoices, credit notes, reports, the general ledger and integrations such as e-invoicing. For each area I note the impact, the effort and any decision needed, such as which rule applies to orders placed before the effective date. Rounding changes are risky because totals can differ by a rupee from the old system and fail reconciliation. I get finance to confirm the rules with worked examples, size the regression testing, and present cost and schedule before the change is approved.
CR-118: new tax slab and rounding to the nearest rupee
(rates come from the tax master; none hard-coded)
Area Impact Effort
Tax master New slab with effective date, history Low
Invoice calc Rounding moves from line to total Medium
Invoice PDF New rounding-off line Low
Reports, GL Rounding account mapping Medium
Open orders Which rule for orders placed before
the effective date? Decision
Tests Regression of RTM-linked cases Medium55. Before a migration you must find duplicate customer records and keep only the latest one. Write the SQL.
ROW_NUMBER numbers the rows inside each group with the same mobile number, newest first, so row 1 is the record to keep and anything above 1 is an older duplicate. The query returns ids 1, 5 and 6: the older Asha, Meera and Ravi records. The id in the window's ORDER BY breaks ties when two records share a date, so the result is repeatable. As a BA I would not simply delete these. The business must agree the matching rule, since one family mobile may belong to two real customers, and decide how details such as addresses from older records are merged.
customers_raw
id name mobile updated_at
1 Asha Rao 9000000001 2025-01-10
2 Asha R. 9000000001 2025-03-02
3 Ravi Kumar 9000000002 2025-02-15
4 Meera Shah 9000000003 2025-01-20
5 Meera Shah 9000000003 2025-01-05
6 Ravi Kumar 9000000002 2024-12-30
SELECT id, name, mobile FROM (
SELECT *, ROW_NUMBER() OVER (
PARTITION BY mobile
ORDER BY updated_at DESC, id DESC) AS rn
FROM customers_raw
) t
WHERE rn > 1
ORDER BY id;56. How do you define a KPI such as conversion rate precisely? What does this query show?
A KPI definition must state the numerator, the denominator, the time window, the filters and the data source, otherwise two teams report two numbers under one name. Here the same data gives 50 percent conversion per user, 2 of 4 users ordered, but about 33.3 percent per session, 2 orders in 6 sessions. Both are correct; they answer different questions, so the definition must say which one. The 100.0 matters: in SQLite, PostgreSQL and SQL Server an integer divided by an integer gives an integer, so 2/4 would return 0. Keep KPI definitions in a glossary owned by the business.
sessions(user_id, placed_order), one row per session:
(1, 0) (1, 1) (2, 0) (3, 0) (3, 0) (4, 1)
SELECT
COUNT(DISTINCT CASE WHEN placed_order = 1 THEN user_id END)
* 100.0 / COUNT(DISTINCT user_id) AS user_conv_pct,
SUM(placed_order) * 100.0 / COUNT(*) AS session_conv_pct
FROM sessions;57. What are the risks of prototyping, and how do you choose between a throwaway and an evolutionary prototype?
The main risk is that a polished prototype looks finished, so stakeholders expect go-live in weeks and forget the work behind it: security, integrations, data and error handling. Another is that users approve screens without discussing the business rules. A throwaway prototype is built fast to learn and is then discarded, which suits unclear requirements. An evolutionary prototype is built properly and grown into the product, which suits stable, well-understood areas. Say clearly which kind it is and record the rules as requirements.
58. Compare two options using NPV at a 12 percent discount rate. Why can ROI and NPV point to different choices?
NPV discounts each future year's benefit to today's value and subtracts the investment; a positive NPV means the project earns more than the 12 percent the money could earn elsewhere. Option A gives an NPV of about Rs 10.75 lakh and option B about Rs 9.49 lakh, so A creates more value. Yet B looks better on simple ROI, 73 percent against 60 percent, and pays back faster, in about 2.3 years against 2.5. ROI is a ratio that ignores scale and timing, while NPV measures total value created. If capital is limited, B may still win, so present both with the assumptions.
Rs lakh Year 0 Year 1 Year 2 Year 3 Year 4
Option A (build) -50 20 20 20 20
Option B (SaaS) -30 13 13 13 13
Discount rate 12%; benefits arrive at the end of each year.59. How do you test a business case with sensitivity analysis? Apply it to these two options.
Sensitivity analysis changes one key assumption at a time to see how fragile the decision is. At plan, A has an NPV of about Rs 10.75 lakh and B about Rs 9.49 lakh. If benefits come in 20 percent lower, A drops to about Rs -1.40 lakh while B stays positive at about Rs 1.59 lakh. A breaks even only while benefits stay above about Rs 16.46 lakh a year, so a fall of about 18 percent wipes out its value. Benefit estimates are usually the weakest numbers, so I ask the benefit owner to sign them off and present base, worst and best cases.
Option A (build): Rs 50 lakh now, then Rs 20 lakh a year for 4 years
Option B (SaaS) : Rs 30 lakh now, then Rs 13 lakh a year for 4 years
Discount rate 12%; test: benefits come in 20% below plan60. Case question: a food delivery app's order conversion fell from 12 percent to 9 percent last month. How would you investigate?
First I check the data: did the definition, tracking or a release change, since a broken tracking tag can look like a fall. Then I size it: 3 percentage points is a 25 percent relative drop. Next I segment by platform, app version, city, new versus repeat users and each funnel step, from menu view to cart to payment, to find where it happens. If it is concentrated, say Android payment failures after a release, the cause is close. I also check outside factors like competitor offers, festivals or heavy rain. Then I test hypotheses with data and recommend fixes with expected impact.
Practice questions for November 2026
New every month3 questions from the Business Analysis mock test, the way they appear in it. A new set comes on the 1st of every month. Pick your answer, then open it.
-
In a SIPOC diagram, what does the C stand for?
- Costs
- Controls
- Constraints
- Customers
Show the answer
Answer: Customers. SIPOC lists Suppliers, Inputs, Process, Outputs and Customers. It gives a one-page, high-level view of a process and its boundaries before the BA draws the detailed step-by-step model.
-
A project costs Rs 10 lakh now and returns Rs 4 lakh at the end of each of the next 3 years. At a 12% discount rate, what is its NPV, and what does it mean?
- -Rs 1.46 lakh, so it does not meet the 12% hurdle
- -Rs 0.39 lakh, so it does not meet the 12% hurdle
- Rs 0.39 lakh, so it just meets the 12% hurdle
- Rs 2 lakh, so it clearly meets the 12% hurdle
Show the answer
Answer: -Rs 0.39 lakh, so it does not meet the 12% hurdle. PV of the inflows at 12% = 3.57 + 3.19 + 2.85 = 9.61 lakh, below the Rs 10 lakh cost, so NPV = -Rs 0.39 lakh. The simple sum of Rs 12 lakh hides that later rupees are worth less, which is why a business case discounts them.
-
DSDM guidance suggests that Must haves take no more than about 60% of the effort in a timebox. Why?
- Testing must always take the remaining 40% of the effort in every timebox
- Developers may spend only 60% of their working time on coding under the DSDM rules
- The Shoulds and Coulds then act as a buffer that can be dropped if estimates slip
- A timebox with more Musts than that is extended by 40% automatically
Show the answer
Answer: The Shoulds and Coulds then act as a buffer that can be dropped if estimates slip. If Musts fill the whole timebox, any slip means failure. Keeping Musts to roughly 60%, with Shoulds and Coulds making up the rest, gives contingency: lower priorities are dropped and the Musts still land on time.
Ready to apply?
There are 423 open jobs asking for Business Analysis on CoreHRx right now. Create a free profile once and apply with it.