Business analyst interviews test how you gather requirements, handle disagreeing stakeholders, and turn ambiguity into something a team can build. Below are the most common questions with model answers. Junior: core theory, definitions, and simple practical cases.
A functional requirement says what the system does — the user can reset a password. A non-functional says how well — within two seconds, for ten thousand concurrent users, accessible to a screen reader. Non-functional requirements are the ones that get left out and then cause a rewrite, because they constrain architecture rather than behaviour.
That you can say unambiguously whether it is met. "The page should load fast" is not testable; "the page renders in under two seconds on a 3G connection" is. The test is whether two people reading it would build the same check — if they would not, the requirement is a wish.
A user story names who wants something and why, in one sentence, and exists to start a conversation rather than to replace one. Acceptance criteria are the conditions that make it done, written so that a developer and a tester agree in advance. A story without criteria is where scope disagreements come from.
A business requirement is the outcome the organisation wants — reduce support calls about billing. A solution requirement is what the system must do to get there. Confusing them is how a project delivers exactly what was asked for and does not move the number anyone cared about.
Interviews for depth with one person, workshops when several stakeholders must agree in the room, observation for how work is really done rather than how it is described, and document analysis for rules already written down. Observation is the underused one, because what people say they do and what they do differ more than they realise.
A use case describes an interaction in steps, including alternative and exception flows — it is complete. A user story is a placeholder for a conversation and is deliberately not. Use cases suit regulated or complex flows where the exceptions matter; stories suit iterative work where the detail emerges.
In a real interview you speak under pressure. Cam asks these same questions, scores every answer, and shows exactly what to fix.
Practice a Junior Business Analyst interview →