Business Analyst interview questions and answers

A business requirements document explains what the business needs and why: the problem, objectives, scope and high-level requirements, written for business stakeholders and sponsors. A functional requirements document describes how the system should behave to meet those needs, such as screens, rules, validations and workflows, and is mainly for designers, developers and testers. A software requirements specification is usually the most detailed, covering functional and non-functional requirements, interfaces and constraints, often owned by the IT team. In practice, companies merge or rename these, and in agile teams much of the detail lives in user stories with acceptance criteria instead.

I use the format: as a type of user, I want a capability, so that I get a benefit. For example, as a branch manager, I want to download the daily cash report as Excel, so that I can reconcile it with the vault count. I check it against INVEST: independent, negotiable, valuable, estimable, small and testable. Then I add acceptance criteria in Given, When, Then form, such as given I am a branch manager, when I click Download, then an Excel file with today’s transactions for my branch only is downloaded. I also note edge cases, like holidays with no transactions.

I choose based on who has the knowledge and how they work. One-to-one interviews suit senior stakeholders and sensitive topics. Workshops work when several departments must agree on a process. Observation or job shadowing is best for operational work, because people often skip steps they do without thinking. Document analysis of existing forms, reports and policies gives me a base before meeting anyone. Surveys help when users are many and spread out, like branch staff. Prototypes or wireframes help when people cannot describe what they want but can react to something. On a claims project, shadowing found three manual workarounds nobody had mentioned.

For an invoice approval process, I would first map the current flow with the people who do it, using swimlanes for each role in BPMN or a simple flowchart. I capture steps, handoffs, systems, volumes and time taken, including exceptions. Then I mark pain points such as duplicate data entry, approvals waiting in email, and rework loops. For the to-be design, I remove steps that add no value, automate rule-based checks like matching invoice to purchase order, and set approval limits so small invoices skip senior approval. I validate the to-be with the same users, then list the gaps that become requirements for the system.

I move the discussion from opinion to criteria. I often use MoSCoW: must have, should have, could have and will not have this time. A must have means the release fails or is illegal without it. To decide, I ask what happens if this item is delayed by one release, how many users it affects, and whether it supports the project objective or a compliance need. For larger backlogs I score value against effort with the team. In one loan origination project, using these questions moved half of the must-haves to should-haves, and the business agreed because they set the criteria themselves.

A requirements traceability matrix is a table that links each requirement to its source, its design element, the code or user story that implements it and the test cases that verify it. It is useful in three ways. It shows that every requirement has been built and tested before go-live. It helps impact analysis, because when a requirement changes I can see which designs and tests are affected. And it prevents scope creep, since any feature without a linked requirement stands out. In regulated work like banking or pharma, auditors often ask for it. I usually keep it in Jira links or a simple spreadsheet.

A user story is short and meant to start a conversation. It works well in agile teams who talk daily and refine details in sprints. A use case is more detailed: actor, preconditions, main flow, alternative and exception flows, and postconditions. I prefer use cases when the interaction has many paths or rules, such as a fund transfer with limits, OTP failures and beneficiary checks, or when the build is outsourced and the vendor needs a complete written specification. Sometimes I combine them: user stories in the backlog, with a use case attached for the complex ones.

I would select from the customers table and use NOT EXISTS against orders. Something like: SELECT c.customer_id, c.name FROM customers c WHERE NOT EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.customer_id AND o.order_date >= CURRENT_DATE - INTERVAL 90 DAY). The exact date function differs by database. I prefer NOT EXISTS to NOT IN because NOT IN gives no rows if the subquery returns a null customer_id. I would also clarify the requirement first: does a cancelled order count, and should new customers who signed up recently but never ordered be included?

First I clarify the change and the reason behind it, because sometimes the real need can be met another way. Then I check impact on the affected user stories, business rules, screens, integrations, reports and data, using the traceability matrix. I ask the developers and testers for effort and look at what in the current sprint would be displaced. I also check whether it affects compliance or other teams. Then I take a short summary to the product owner with options: swap it into this sprint, take it next sprint, or reject it. Unless it is urgent, I avoid changing a sprint that is already running.

Non-functional requirements describe how well the system must work rather than what it does. Examples I have written for a customer portal: search results must load within two seconds for 95 percent of requests at peak load; the system must support 500 concurrent users; passwords must be stored hashed and accounts locked after five failed attempts; the portal must work on the latest two versions of Chrome, Safari and Edge and on mobile screens; and it must be available 99.5 percent of the time outside a planned maintenance window. Each one must be measurable, otherwise nobody can test it.

I start planning before development ends. I agree the UAT scope, entry and exit criteria and who will test from each department. I write business scenarios based on real cases rather than system steps, for example processing a return for a damaged item bought with a coupon, and prepare test data with the QA team. During UAT I run a short daily call, triage defects with the product owner into must-fix and later, and keep a dashboard of passed, failed and blocked scenarios. Sign-off comes from the business owner against the exit criteria, not from IT declaring it done.

On a customer onboarding system for an NBFC, sales wanted minimal fields so agents could onboard quickly, while risk wanted full income and address verification upfront. I first wrote down both sets of requirements with the reason behind each. Then I brought both teams together with data: drop-off rates on the current form and the number of loans later flagged for missing documents. We agreed on a two-step flow, a short form to start, and full verification before disbursement, not before application. Both heads signed off. Drop-offs fell and risk got complete files before money went out.

On an HR leave system, I wrote that leave balance should be calculated monthly. I took this from a policy document and did not confirm it with the payroll team. During UAT, payroll pointed out that some employee groups accrue leave quarterly under their contracts. The fix took two extra weeks. I owned it in the defect review. Since then I validate every business rule with the person who applies it in daily work, not only with the policy owner, and I add a sample calculation with real numbers to each rule so users can spot mistakes before development starts.

Two months after joining as a trainee BA, I was put on a project for a logistics client, and I knew nothing about freight. In the first week I read their process documents, made a glossary of terms like consignment note, proof of delivery and freight forwarder, and asked the client to let me sit with their booking team for a day. I drew the end-to-end shipment process and checked it with an operations supervisor. By the third week I was running requirement sessions myself. The glossary became part of the project onboarding pack for new team members.

A regional sales head wanted forty extra columns added to the new CRM dashboard because his old Excel report had them. I asked him to walk me through how he used the report each week. It turned out he used eight columns regularly, and the rest were there because nobody had removed them. I proposed the eight in the dashboard, with a detailed export for rare cases. He was not convinced at first, so we agreed to try it for one month. At the end he asked for only one more column, and the dashboard stayed fast and readable.

In my first sprint as a junior BA, developers pushed back during refinement on a story about discount rules for a retail app. They asked what happens when two coupons apply and whether discounts apply before or after tax. I had not thought about those cases. I thanked them, took the questions to the product owner, and came back the next day with a decision table showing every combination with expected results. The developers estimated it easily after that. Now I write decision tables for any rule with more than two conditions, and I review stories with one developer before refinement.

When we replaced paper job cards with a tablet app at a vehicle service centre chain, senior mechanics resisted because they found typing slow. I spent a day in one workshop and saw that most entries were repeated parts and labour codes. We changed the app to use pick-lists and photos instead of typing, and I asked two respected senior mechanics to test early versions. Their suggestions went into the release, and they demonstrated the app to others at the rollout. Usage at the pilot centres reached almost every job card within a month, and we used the same approach for other centres.

I have spent three years as a BA on lending and payments projects, so I understand onboarding, credit checks and repayment flows. Your company builds software for cooperative banks, which have older processes and very different users from private banks. I read your case study on moving a cooperative bank’s loan process from paper to digital, and that is exactly the kind of process redesign I enjoy. I also like that your BAs work directly with bank staff on site, not only through an account manager. I think my banking background and field approach would help me contribute quickly.

My current CTC is ₹9.5 lakh with three years of BA experience in banking projects, including SQL and Jira-based agile delivery. For this role, which includes client-facing work and leading UAT, I am looking for ₹12 to 13 lakh. There is some room to negotiate depending on the variable component, certification support and the learning opportunities in the role. I would like to understand the full structure before finalising, but I want to be clear that the role matters more to me than a small difference in the number.

I can code, and I built a small inventory app for my college canteen as a project. But the part I enjoyed most was not the coding. It was sitting with the canteen staff, understanding why stock ran out, and deciding what the app should do. I also enjoy writing and explaining things clearly. A BA role uses both: understanding the business problem and translating it for developers. My technical background will help me talk to developers and write realistic requirements. I have started learning SQL and process mapping, and I would like to build domain knowledge in one industry over the next few years.