Business Analysis Interview Questions and Answers

Functional requirements describe what the system does: behaviours, features and business rules. Examples include calculating a discount, generating an invoice or allowing a user to reset a password.

Non functional requirements describe how well it does it: quality attributes and constraints. Examples include performance, security, availability, scalability, usability, compliance and accessibility.

Both matter, but non functional requirements are often skipped and then cause expensive problems later. A feature that works but takes ten seconds to load, fails under load, or is inaccessible is not acceptable.

They should be specific and measurable, or they cannot be tested. Instead of "the system should be fast", write "the search results page must load in under two seconds for ninety-five percent of requests at peak load".

I capture them early, include them in acceptance criteria and trace them to tests so they are verified, not assumed.

Stakeholder analysis identifies the people who affect or are affected by a change, and works out how to engage them.

I start by listing everyone: users, managers, IT, finance, compliance, suppliers and sometimes customers. Then I assess each on two dimensions: their level of interest and their power or influence over the outcome. I map them on a grid.

That produces an engagement approach. High power and high interest are key players, managed closely and involved in decisions. High power but low interest need to be kept satisfied with clear, concise updates. Low power but high interest need to be kept informed, and they are often the best source of detail. Low on both need monitoring.

I also note their attitude, supportive, neutral or resistant, and whether that changes over time. The analysis is not a one off document. I revisit it as the project and the people change.

When stakeholders cannot articulate what they want, it usually means the real problem is unclear, not that they have no needs.

I start with the problem and the outcome, not the solution. I ask about their day, what is frustrating, what takes too long and what happens when things go wrong. Concrete stories and examples reveal more than abstract questions.

Techniques I use include one to one interviews, facilitated workshops, observation or job shadowing, process mapping, document analysis and reviewing existing system reports. I ask "what would good look like?" and "how would you know it worked?"

I then play requirements back as scenarios and prototypes, because people recognise what they need when they see it far more easily than they can specify it.

I confirm understanding in writing and iterate. Silence and a quick nod often mean confusion, not agreement.

A user story is a short statement of a need from the user's perspective, usually in the form: as a role, I want a capability, so that I get a benefit. The value is in the "so that", because it explains why the story matters.

The story alone is not a specification. Acceptance criteria define the conditions that must be true for it to be considered done. I write them as concrete, testable statements, often in given when then form. For example: given an expired card, when the user checks out, then the payment is declined with a clear message.

Good criteria cover the happy path and the important edge cases, and they provoke a conversation between the business analyst, the developer and the tester rather than replacing it.

I keep stories small enough to complete in a sprint and split large ones vertically, so each delivers a slice of user value rather than a technical layer.

I model a process to create a shared, accurate picture of how work actually flows, not how people think it flows.

I start by defining the scope and boundaries, where it begins and ends, and the outcome it produces. Then I gather information through interviews, workshops and observation. Walkthroughs of real cases, rather than descriptions in the abstract, surface the exceptions and workarounds that matter most.

I map the steps, decisions, roles, systems and handoffs, using a simple notation such as BPMN or a swimlane diagram. I capture the unhappy paths too: what happens when information is missing, a system is down or an approval is rejected. I also record volumes and cycle times where available.

I validate the model with the people who do the work, because they will spot gaps immediately. The as-is model then becomes the basis for identifying delays, rework and bottlenecks, and for designing the to-be process.

Late change requests are normal. Uncontrolled late change is the problem.

First I understand the request and why it is late. There may be a genuine regulatory deadline or a real missed requirement, in which case we need to act. I assess the impact on scope, schedule, cost, quality and risk, and I make that impact explicit rather than absorbing it silently.

Then I present options: swap it for something of lower priority within the same timeline, extend the timeline, add resource, or park it for the next release. This turns the conversation from yes or no into a trade off.

The decision goes through the agreed change process with the right authority, and I document it, including who approved and why.

If late changes recur, I look at the root cause, perhaps insufficient elicitation or unclear scope, and improve the front end rather than blaming the requester.

I treat it as a prioritisation problem with an authority question, not a personality contest.

First I meet each stakeholder separately to understand their requirement and, more importantly, the underlying objective. Conflicts are often about outcomes that are not actually mutually exclusive, and sometimes reframing unlocks an option that satisfies both.

Then I bring them together with the facts: the objectives, the impact of each option, cost, timeline and risk. I make the trade offs visible so the conversation is about evidence rather than volume.

I check whether there is a documented decision making structure. If the conflict is within the same project, the sponsor or product owner should decide against agreed criteria. If it is a governance decision, I escalate with a clear options paper and a recommendation.

I document the outcome and communicate it to everyone affected, including the person who did not get their way.

Traceability means being able to follow a requirement from its origin through design, build and testing to delivery, in both directions.

Forward traceability shows that every requirement is implemented and tested. Backward traceability shows that every delivered feature can be traced to a real requirement, which exposes scope creep and gold plating.

I maintain a traceability matrix linking each requirement to its source, a design or story, acceptance criteria, test cases and status. On agile projects this can be lighter, but the principle still matters, especially in regulated environments where auditors need it.

Validation is confirming we built the right thing, as opposed to verification, confirming we built it correctly. I validate with the business through reviews, prototypes and user acceptance testing, and ideally through measurable outcomes after release.

I also check coverage. Requirements with no tests are a risk, and tests with no requirement are waste. When requirements change I update the links so the matrix stays trustworthy.