Business Analyst Interview Questions

“I'd say a BA makes sure the team builds the right thing. Before anything gets built, I find out what problem the business is really trying to solve, who's affected, and what 'done' looks like. Then I write that down in a form everyone can use: the business can confirm it's right, developers can build from it, and testers can check against it. During delivery I answer questions, handle changes and help with testing so nothing gets lost in translation. What I don't do is decide priorities on my own, that's the product owner or sponsor, and I don't design the technical architecture. I bring the options and the trade-offs, and the right people decide.”

“The ones I use most are one-to-one interviews, group workshops, observing people at work, reading existing documents and reports, surveys, and quick prototypes or wireframes. I pick based on the situation. If I need depth from a few experts, I interview them one at a time. If several teams have to agree, I run a workshop so the disagreements surface in the room, not later. When people say 'it's simple, we just process the form', I watch them do it, because the real steps and workarounds only show up on screen. Surveys work when I need a broad view from many users. And when people can't describe what they want, a rough prototype gets better reactions than any question. Usually I combine two or three.”

“On a payroll change project, the one person who really understood the overtime rules was the payroll supervisor, and it was her busiest month. She kept cancelling. So I stopped asking for an hour. I read the policy documents and old tickets first, drew a draft process, and wrote down only the questions I couldn't answer myself, about eight of them. Then I asked for fifteen minutes at her desk at a time she chose. Because I'd done the groundwork, she mostly just corrected my draft, which is much faster for someone busy. She actually offered a second slot after that. I also spoke to two of her team for the everyday cases, so I only needed her for the tricky rules. I didn't need to escalate at all.”

“A functional requirement describes what the system does. On an expense tool I worked on, one was: the system must send a claim to the employee's line manager for approval once it's submitted. A non-functional requirement describes how well it has to do things, the qualities around the features. On the same tool: the approval screen must load within two seconds for nearly all requests at normal load, and only the claimant, their manager and finance can see a claim. The trap with non-functionals is writing 'fast' or 'secure'. I always push for a number or a condition someone can test, because otherwise nobody can say whether it's been met, and non-functionals tend to get discovered late, when they're expensive to fix.”

“A BRD, the business requirements document, answers why and what at a business level: the problem, the objectives, scope, stakeholders and high-level needs. Its readers are the sponsor and business owners, and it's what they sign off. An FRD, the functional requirements document, goes a level down into how the system has to behave: screens, rules, data, integrations, error handling. That's for designers, developers and testers. User stories come from agile work. Each one is a small need from a user's point of view with acceptance criteria, and they're detailed just before the team builds them rather than all up front. On a fixed-scope vendor project I'd write a BRD and an FRD, because the contract needs a baseline. On an agile product team I'd keep a short vision and scope page, then work in stories.”

“A use case describes how someone, the actor, uses a system to reach a goal, step by step. I include the actor, the preconditions that must be true first, the trigger, the main success flow, the alternate flows where things go a different but valid way, the exception flows where something fails, and the postconditions, meaning what's true once it's done. For 'withdraw cash' at an ATM, an alternate flow is picking a preset fast-cash amount instead of typing one, and an exception is insufficient funds or a wrong PIN. A user story is much smaller and lighter. It's a placeholder for a conversation: who wants what and why, plus acceptance criteria. I'd use a use case when the interaction is complex or high risk, and often a single use case gets broken into several stories for the backlog.”

“It's a table that links each requirement in two directions. Backwards to where it came from, the business objective or the person who asked for it, and forwards to the design, the build items and the test cases that cover it. I use it for three things. Coverage: before UAT I can show every requirement has at least one test, and that nothing's being built that no requirement asked for, which is how gold-plating gets caught. Change impact: when someone wants to change a requirement, I can see straight away which screens, stories and tests it touches. And sign-off: at the end it shows the business owner what was delivered and tested against what they asked for. On agile teams I don't keep a separate spreadsheet. Linking epics, stories and tests in the backlog does the same job with less upkeep.”

“MoSCoW sorts requirements into Must have, Should have, Could have and Won't have this time. A Must is something without which the release is pointless, unsafe or illegal. A Should is important but there's a workaround. A Could is nice if there's time, and a Won't is agreed out of this release, which is useful because it's written down. Where I've seen it go wrong is when every stakeholder labels everything a Must, so the list means nothing. What helped was asking for each Must, 'If this weren't there on day one, would we still go live?' and keeping Musts to no more than about three fifths of the effort, which is what DSDM, the method MoSCoW comes from, suggests. That leaves room to absorb surprises. Once that's in place, the conversations get honest quickly.”

“I'd start by asking what 'fast' and 'easy' mean to them in practice. Which tasks do they do most often? What's slow or frustrating today? Usually it comes down to a few specific tasks. Say it's searching for a customer record. Then fast might become: search results appear within two seconds for at least 95 out of every 100 searches at normal load. Easy might become: a new starter can find and update a customer's address without help after a short walkthrough, or the task takes no more than three screens. I'd write those down, check them with the stakeholder and with the developers for realism, and agree with the testers how they'll measure them. That turns a feeling into something we can pass or fail.”

“I'd write them in Given, When, Then form so they read like test cases. The happy path is: given I've requested a reset, when I open the link and set a valid new password, then I can sign in with it and the old one stops working. Then the edges: an expired or already used link, a password that breaks the rules, and an email address we don't recognise. That last one is interesting, because for security the screen should show the same message whether or not the account exists, so nobody can use it to check who's registered. Good criteria are testable with a clear pass or fail, describe behaviour rather than button colours, and are agreed with the team before development starts, not written after.”

“I'd say so plainly: 'I don't know that yet, and I don't want to guess.' Then I'd share what I do know and how I'll find out, for example, 'I've mapped the approval step, but I haven't looked at how refunds are handled. I'll check with the finance team and come back to you by Thursday.' Then I'd make sure I do exactly that. As a BA, my value is that people can trust what I write down. If I guess once and I'm wrong, they'll start double-checking everything I say. Admitting a gap also often helps, because the stakeholder may know the answer, or know who does, and it shows I'm careful about getting things right.”

“I'd check it against what we agreed: the requirement, the acceptance criteria, any mock-ups. If the system does what was agreed, it's not a defect, even if the user's need is real. I'd explain that to the user in plain terms and make clear I'm not dismissing it: the need still gets logged, just as a change request, so it's assessed and prioritised properly rather than squeezed in as a fix. If it's urgent, I'd flag that to the product owner. But I'd also be honest with myself. If the requirement was vague enough that both readings were reasonable, that's partly on me, and I'd say so. In triage those grey cases usually get decided by the business owner, and I record the reasoning.”

“First I'd clarify one thing: should customers who've never ordered be included? As written, they would be, so I'd confirm that's wanted. My approach is to start from the customers table and keep only those with no matching order in the window, using NOT EXISTS. It reads almost like the question, and it avoids a classic left join slip where the date filter lands in the WHERE clause and quietly changes the result. The date arithmetic varies by database, so I'd adjust that line to whatever we're using. Before sharing the result, I'd sanity-check the count against the total number of customers and spot-check a few names in the source system, because a wrong join or a time zone issue on the order date is easy to miss.”

“I started in operations at a logistics firm, handling shipment exceptions. I kept noticing that most of the mess came from the system not matching how people actually worked, so I started writing up the workarounds and taking them to the IT team. One of those write-ups turned into a small project, and the project manager asked me to own the requirements. That's when I realised I enjoy the translating part: sitting with the people who do the work, working out what they really need, and making it clear enough that a developer can build it. Since then I've done two full projects as a BA. Next, I'd like a role where I'm involved from the problem definition, not just handed a solution to document.”

“From what I've read, you run a subscription business for small clinics, and most of your growth is coming from moving customers off older on-site software onto your cloud product. That tells me a lot of the BA work here is probably migration: understanding how each clinic works today, mapping that to the new product, and spotting where the gaps are before a customer goes live. That's close to what I did on my last project, where we moved branch offices from spreadsheets to a shared system and I ran the as-is workshops. I'm also drawn to healthcare because the processes have real rules behind them, so getting the requirements right actually matters to the people at the other end.”

“On an invoicing project I documented the monthly billing run in detail but never asked about the year-end process, because nobody mentioned it and I didn't think to ask. In UAT, finance tried their year-end adjustments and there was no way to do them. We had to add two extra sprints and push the launch back, and the finance lead was rightly frustrated with me. I owned it, ran a quick session to capture exactly what year-end needed, and kept the team updated daily. What I do differently now is walk every process through a full calendar year and ask about the unusual events, like year-end, audits, peak season and exceptions, not just the normal day. I also ask 'what happens rarely but hurts when it goes wrong?' in every workshop.”

“I like to bring developers and testers in early, before a story is final, because they spot gaps I miss. A tester asking 'what if this field is blank?' in refinement saves a defect later. During the sprint, I try to be easy to reach and answer the same day. If an answer changes the requirement, I update the story straight away so we're all looking at the same thing, not a chat thread. In return I'd ask them to challenge anything that doesn't make sense rather than guess, and to tell me early when something's harder than expected, so I can go back to the business with options while there's still time. I don't mind being told a requirement is unclear. That's the cheapest time to find out.”

“I start with the obvious names, the sponsor, the people who'll use the system and their managers, and I ask each of them who else is affected or could stop this. That's how the quiet ones turn up: the compliance officer, the support team who'll take the calls, the owner of a system we feed. Then I place them on a power and interest grid. High power and high interest, like the sponsor, I manage closely with regular one-to-ones. High power but low interest, like a finance director, I keep satisfied with short updates at key decisions. High interest but low power, usually the end users, I keep informed and involve in workshops and testing. Where it's unclear who approves what, a simple RACI chart settles it. And I revisit the map, because a quiet stakeholder can get very loud the week before go-live.”

“I wouldn't say yes or no on the spot. First I'd ask what the report is for and whether they really need it on day one, or just soon. Then I'd take it to the team for a quick estimate, including testing, because 'quick' reports often need new data that isn't there yet. With that, I'd go back to the sponsor with options: we can add it but something else moves out or go-live moves, we can deliver it in the first release after go-live, or we can give them a manual extract for the first few weeks. Usually a stopgap is fine once they see the trade-off. Whatever they choose, I'd log it as a change so the scope decision is on record.”

“I'd start broad: who uses it, for what, and what other systems it feeds or reads from. Then I'd gather knowledge from every source I can. I'd sit with users while they work, go through every screen and report, and look at the data itself, because the tables often reveal rules nobody remembers, like status codes or fields that change meaning. A developer reading the code with me helps with calculations and overnight jobs that nobody sees. I'd pay special attention to the rare events, month-end, corrections, reversals, because that's where legacy systems hide logic. I'd write it all up and play it back to the users to confirm. And I'd push for comparing outputs from the old and new systems on real data before switching off, because something will still be missing.”

“In Scrum the product owner is accountable for the backlog: what's in it, what order it goes in, and what value each item delivers. Scrum doesn't name a BA role, so on the teams I've worked in the BA sits with the developers and supports that by doing the analysis underneath. I work a sprint or two ahead, breaking epics into stories, writing acceptance criteria, mapping the process or data where it's complex, and chasing the business answers before the team needs them. In refinement I walk the team through upcoming items; during the sprint I'm the person developers and testers come to with 'what should happen if'; and in the review I help check it meets the need. The line is decisions: I bring options and trade-offs, the product owner decides the order and what's in or out. On smaller teams one person may do both.”

“First I'd sit with the developers and understand what makes it big. Often it's one part, like a complex integration or an edge case that affects very few users. Then I'd go back to the business goal behind the requirement. Is there a simpler version that meets the need on day one? For example, handling the common case automatically and the rare case manually for now. I'd come back with two or three options: a smaller first slice with the rest later, dropping or delaying something else of equal size, or accepting a later date. Each option would show what the business gets and what it gives up. Then the product owner or sponsor decides. What I wouldn't do is pressure the developers to shrink their estimate.”

“For the as-is, I sit with the people who actually do the work and map what really happens, not what the procedure says, because the workarounds are usually where the problems are. I keep it in swimlanes so handoffs between teams are obvious. Then I mark the pain points: waits, rework loops, duplicate data entry, approvals that add nothing. The to-be is the redesigned version, and I walk it through with the same people to check it works in practice. In BPMN I use a small set: pools and lanes for who does what, tasks, start and end events, exclusive gateways for decisions, parallel gateways when things happen at the same time, sequence flows inside a pool and message flows between pools. More symbols than that and business readers switch off.”

“Gap analysis compares where you are with where you need to be, and lists what's missing in between. With a packaged product, I'd start by listing the business's required processes and rules, then walk through the product's standard behaviour against each one, ideally in a demo with real scenarios, not a sales deck. Every difference becomes a row: what we need, what the product does, the impact, and how big the gap is. Then each gap needs a decision. Can the business adopt the standard process? Can we configure it? Do we need a custom build, a manual workaround, or do we accept losing that feature? I push hard for adopting the standard where the process isn't a real differentiator, because every customisation costs money at every upgrade.”

“At my last company, onboarding a new supplier took around three weeks and procurement kept getting complaints. Before changing anything, I took the last few months of supplier records and measured each stage, which showed most of the time was waiting, not work. The form bounced between procurement, finance and legal by email, and each team checked things the others had already checked. I mapped the as-is with all three teams, and we agreed a to-be with one shared form, the checks run in parallel instead of in sequence, and legal review only above a risk threshold. After three months on the new process, I measured the same stages the same way, and onboarding had dropped to about a week. The rework loop from missing bank details had almost disappeared too.”

“On a claims system project, the operations lead wanted claims auto-approved under a threshold to clear the backlog, while the risk manager wanted every claim reviewed by a person. In separate conversations I asked each of them what they were really trying to protect. Operations cared about turnaround time, risk cared about fraud. Once that was clear, I pulled the historical claims data and showed that almost all fraud cases shared a few features. So I proposed auto-approval only for low-value claims without those flags, with a random sample still reviewed. I took both options to the sponsor with the data and the trade-offs, and she chose that version. Turnaround improved noticeably, and the risk manager later asked for the same approach on another product.”

“A regional manager asked me to add a new dashboard for his team, with a list of about twenty charts he'd sketched. Instead of starting on the charts, I asked what decisions he wanted to make from it and what he did today without it. It turned out the real problem was that he found out about late deliveries only after customers complained. Most of the charts wouldn't have fixed that. What he needed was an alert when a delivery was at risk, plus two or three of his charts for the weekly review. I showed him both options side by side, and he chose the alert first. He was a bit put out at the start, but once the alerts caught problems early he became one of the project's biggest supporters.”

“I'd go and talk to them to find out why it's stuck. Often the document is too long to review, or they're unsure about one section and worried that signing means they can't change their mind. So I'd offer a short walkthrough of the key decisions instead of the whole document, and suggest signing off in parts, so the team can start on what's already agreed. I'd also explain how changes will be handled after sign-off, which usually removes the fear. Meanwhile, the team could start on the parts with the least risk of change, with the assumptions written down. If it still doesn't move, I'd tell the owner openly that I'll raise it with the project sponsor, showing the date impact, rather than going around them.”

“UAT is where the people who'll use the system check it supports their real work. It's not a repeat of system testing, so I base the scenarios on end-to-end business situations, like a customer changing their address halfway through an order, rather than screen-by-screen checks. I plan the scope, who's testing and when their time is freed up, realistic test data, the environment, and the entry and exit criteria, for example no open critical defects and every high-priority scenario passed. During the run I hold a short daily triage to sort real defects from questions and change requests, and track retests. Sign-off comes from the business owner, not the BA or the delivery team, because they're accepting that it's fit for their business.”

“I'd take it seriously, because a system nobody uses has failed however well it matches the spec. First I'd sit with a few of the users and ask them to show me where it breaks down in their real day. It might be a missed requirement, like a step they do for one customer type that nobody mentioned. It might be usability, like five screens where they used to have one. Or it might be fear of change and not enough training. Each needs a different answer. I'd sort the issues into quick fixes, things that need a change request, and things that training or a process tweak solves, then take that to the sponsor so we can decide together whether we go live, delay, or go live with a fix list. I'd also look at why our elicitation missed it.”

“At my last company, the sales team was convinced that customers cancelled because of price, and they wanted a discount scheme. Before writing requirements for it, I pulled cancellation data and joined it to support tickets. Most people who cancelled had raised two or more setup tickets in their first month, and price was rarely mentioned. Before sharing, I had a data analyst check my query, because I didn't want to be wrong in front of the head of sales. Then I showed it to him privately first, framed as 'here's something we should look at together', rather than in a big meeting. He was sceptical, so we agreed to also test a better onboarding flow. Cancellations dropped for the group that got it, and the discount scheme was shelved.”

“I'd start by framing it: what's the business goal, completed applications, and how big is the drop compared with other steps? Then I'd break the data down. Is it worse on phones? For certain document types? For new versus returning applicants? Next I'd look at support tickets and error logs for that step, and talk to a handful of people who dropped out, because data shows where people leave, not why. Likely causes might be files too large for the limit, no way to photograph a document on a phone, or people simply not having the document with them. Each cause points to a different fix: raise the limit, add camera upload, or let people save and upload later. I'd rank them by impact and effort, and agree a success measure, like completion at that step, before we build anything.”