In this article
  1. The role
  2. Requirements
  3. Agile and user stories
  4. Process and analysis
  5. Estimation and money
  6. Data and stakeholders
  7. Sources

The role

What does a business analyst do?

A business analyst works out what a business needs and recommends a solution. The International Institute of Business Analysis (IIBA) defines business analysis as enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders (IIBA, Business Analysis Body of Knowledge (BABOK) Guide page). In practice that means talking to the people affected, writing clear requirements and checking that what is built meets them.

Why it is asked: it checks that you describe the job as problem-solving, not note-taking. Related reading: program manager interview questions: the complete guide.

How does a business analyst differ from a project manager and a product owner?

A project manager owns delivery: scope, schedule, budget and risk. A product owner owns the value of the product and the order of its backlog; the Scrum Guide says the Product Owner is one person, not a committee (Scrum Guide, 2020). A business analyst owns understanding the need and the requirements, and often supports both. Titles overlap between employers.

Why it is asked: role boundaries are where teams collide. Read the full explanation: project manager interview questions.

What is a stakeholder, and how do you analyse them?

A stakeholder is anyone affected by a change or able to influence it, such as users, sponsors, operations, legal and support. List them, then sort by influence and interest: keep high-influence, high-interest people closely involved, and keep others informed at a lower cost. Revisit the list, because the people who matter change as a project moves.

Why it is asked: missed stakeholders are a common cause of late requirement changes. Related reading: behavioural interview questions.

Requirements

What is a requirement, and what is the difference between functional and non-functional requirements?

A requirement is a stated need that a solution must meet. A functional requirement says what the system does, such as "a customer can reset a password". A non-functional requirement says how well: speed, security, availability, accessibility. Non-functional requirements are the ones most often forgotten and the costliest to retrofit.

Why it is asked: it tests whether you think beyond features. Related reading: program manager interview questions: the complete guide.

How do you elicit requirements?

Combine methods: interviews for depth, workshops to resolve conflicts, observing people do the work, reading existing documents and data, and prototypes to test understanding. Use more than one source, because what people say they do and what they do often differ. Confirm back what you heard in writing.

Why it is asked: it reveals your method for finding the real need. Related reading: how to answer interview questions.

What is the difference between a BRD, an FRD and an SRS?

A business requirements document (BRD) states the business goals and needs. A functional requirements document (FRD) describes what the system must do to meet them. A software requirements specification (SRS) is the detailed technical statement used by developers and testers. Names and scope vary by company, so ask which template the team uses, and note that agile teams often replace them with a backlog.

Why it is asked: it tests familiarity with documents and their purpose. Related reading: program manager interview questions: the complete guide.

How do you prioritise requirements?

Rank by value to the business, cost, risk and dependencies, then agree the order with the people who decide. MoSCoW is a simple scheme that sorts items into must have, should have, could have and will not have this time. Whatever the method, write down the criteria so the decision is not a negotiation by volume. Prioritising before building keeps scope tied to agreed criteria.

Why it is asked: there is never enough time to build everything. Read the full explanation: product management interviews.

What is a requirements traceability matrix?

A requirements traceability matrix links each requirement to its source need and to the tests that prove it, so gaps are visible. In an illustrative matrix of five requirements where tests exist for four, coverage is 80% and the untested requirement is flagged for action.1 A requirement should trace from a stated need to a test that proves it, and the matrix also shows what a change touches.

Why it is asked: it shows that you can prove completeness. Related reading: program manager interview questions: the complete guide.

How do you handle changing requirements?

Expect change and manage it openly. Assess the impact on scope, cost and schedule, get the decision from the accountable person, update the documents and tell everyone affected. The Agile Manifesto values responding to change over following a plan, which does not mean ignoring the plan (Agile Manifesto, 2001).

Why it is asked: it tests control without rigidity. Read the full explanation: project manager interview questions.

Five stages from eliciting needs to acceptanceRow flow of five stages from need to acceptance: elicit needs, write requirements, prioritise, build and test, then accept.Elicit needsWriterequirementsPrioritiseBuild andtestAcceptDiagram: Interview Clozo, CC BY 4.0 ·interview.clozo.ai/blog/business-analyst-interview-questions.html
Every requirement should trace from a stated need to a test that proves it.CC BY 4.0 — source: Business analyst interview questions on requirements, user stories and agile
Text description of the diagram
  • A requirement should trace from a stated need to a test that proves it.
  • Prioritising before building keeps scope tied to agreed criteria.

Knowing it is half the job. Saying it is the other half.

Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.

Start Free Trial →

Agile and user stories

What is a user story, and what makes a good one?

A user story is a short statement of a need from the user's point of view, such as "as a customer I want to reset my password so I can regain access". Bill Wake's mnemonic says a good story is independent, negotiable, valuable, estimable, small and testable (INVEST) (Wake, 2003).

Why it is asked: stories are the daily output of an agile analyst. Related reading: program manager interview questions: the complete guide.

What are acceptance criteria, and how are they written?

Acceptance criteria are the conditions a story must meet to be accepted. A common format is Given, When, Then: Given sets the starting context, When names the action or event, and Then states an outcome that can be observed from outside the system (Gherkin reference). Each criterion should be testable with a clear yes or no.

Why it is asked: vague criteria cause rework. Related reading: program manager interview questions: the complete guide.

What is the difference between a use case and a user story?

A use case describes a full interaction between an actor and a system, with a main flow and alternative flows, in more detail and often more formally. A user story is a short placeholder for a conversation, with acceptance criteria added as detail is agreed. Use cases suit complex regulated flows; stories suit incremental delivery.

Why it is asked: it tests whether you can choose the level of detail. Related reading: program manager interview questions: the complete guide.

What is the difference between agile and waterfall?

Waterfall plans and completes phases in order: requirements, design, build, test, release. Agile delivers in short cycles and adapts as it learns; its manifesto values working software over comprehensive documentation and customer collaboration over contract negotiation (Agile Manifesto, 2001). Choose by how stable the requirements are and how costly change is.

Why it is asked: it tests judgment, not loyalty to one method. Read the full explanation: project manager interview questions.

What are the roles and events in Scrum?

The Scrum Team has three accountabilities: Developers, a Product Owner and a Scrum Master. The events are the Sprint, which lasts one month or less, Sprint Planning, the Daily Scrum of 15 minutes, the Sprint Review and the Sprint Retrospective (Scrum Guide, 2020). A business analyst usually helps refine the Product Backlog.

Why it is asked: many analyst roles sit inside Scrum teams. Read the full explanation: Scrum Master interview questions.

What is a backlog, and what is the Definition of Done?

A backlog is an ordered list of what the product needs; the Scrum Guide calls it the Product Backlog. The Definition of Done is the formal quality standard an Increment must meet, and work that does not meet it returns to the backlog (Scrum Guide, 2020). Acceptance criteria belong to one story; the Definition of Done applies to all.

Why it is asked: confusing the two is common. Read the full explanation: Scrum Master interview questions.

Process and analysis

How do you model a business process?

Draw the as-is flow with the people involved, then mark delays, handoffs and rework before designing the to-be flow. Business Process Model and Notation (BPMN) is the standard flowchart-like notation, maintained by the Object Management Group (OMG), intended for people who design, manage and realise processes (OMG, BPMN 2.0, December 2010). Validate the diagram with the people who run the process.

Why it is asked: it tests structured thinking about work. Related reading: program manager interview questions: the complete guide.

What is a gap analysis?

A gap analysis compares the current state with the target state and lists what is missing in people, process, data or technology. For each gap, record its impact and options. It turns "we want to improve" into a list a team can prioritise and cost.

Why it is asked: it is the standard bridge between problem and solution. Related reading: program manager interview questions: the complete guide.

How do you find the root cause of a problem?

Ask why repeatedly until you reach something you can change, the "five whys" method, and cross-check with data instead of opinions. A cause-and-effect diagram groups possible causes by people, process, tools and inputs. Test the suspected cause: if you remove it, does the problem go away?

Why it is asked: fixing symptoms wastes budget. Related reading: how to answer interview questions.

Estimation and money

How would you justify a project financially?

Compare costs with benefits over time, adjusting for the time value of money. In an illustrative case, a one-off outlay of 100 thousand currency units returning 40 thousand a year for four years, discounted at 10%, has a net present value of about 26.79 thousand; simple payback is 2.5 years and discounted payback about 3.0 years.1 Net present value above zero means the benefits outweigh the cost at that rate.

Why it is asked: analysts support business cases. Related reading: product management interview questions.

How do you estimate effort when you are unsure?

Give a range, not a single number. A three-point estimate uses an optimistic, a most likely and a pessimistic value: with 4, 6 and 14 days the weighted expected value is (4 + 4 × 6 + 14) / 6 = 7 days, against 8 for the plain average.1 State the assumptions and update as you learn.

Why it is asked: it tests honesty about uncertainty. Related reading: project manager interview questions.

Data and stakeholders

What SQL does a business analyst need?

Enough Structured Query Language (SQL) to answer your own questions: select and filter rows, join tables, group and summarise, handle missing values, and use window functions for ranking and running totals. Check the row count after every join, because a join on a non-unique key silently multiplies rows.

Why it is asked: data access separates analysts who wait from those who answer. Read the full explanation: SQL interview questions: the complete guide.

How do you measure whether a project succeeded?

Agree success measures before the work starts: a named metric, its baseline, a target and a date. Compare after release, and look for side effects on neighbouring metrics. A feature that raises one number while harming another has not clearly succeeded.

Why it is asked: it ties delivery to outcomes. Read the full explanation: data analyst interview questions.

Tell me about a time you handled a conflict between stakeholders.

Use the situation, task, action, result (STAR) structure: the situation and the two positions, your action, and the result. Strong answers show that you clarified the underlying goals, put facts on the table, agreed criteria and recorded the decision. Say what you would do differently. Keep it about the work, not personalities.

Why it is asked: analysts live between competing needs. Read the full explanation: the STAR method for behavioural interviews.

Key takeaways
  • Define the job as finding the need and recommending a solution, not recording requests.
  • Write requirements that are testable, traced to a need and ordered by agreed criteria.
  • Know the vocabulary of agile: story, acceptance criteria, backlog, Definition of Done.
  • Support recommendations with numbers: net present value, payback, a range estimate.
  • Tell stakeholder stories in a structured way: situation, action, result.

Sources

  1. A Guide to the Business Analysis Body of Knowledge (BABOK Guide) — International Institute of Business Analysis (page undated; read 2026-10-24), 24 Oct 2026
  2. Manifesto for Agile Software Development — The Agile Manifesto authors (year only), 1 Jan 2001
  3. The Scrum Guide (2020) — Ken Schwaber and Jeff Sutherland (November 2020), 1 Nov 2020
  4. Gherkin reference — Cucumber (page undated; read 2026-10-24), 24 Oct 2026
  5. INVEST in Good Stories, and SMART Tasks — Bill Wake, 17 Aug 2003
  6. Business Process Model and Notation (BPMN) 2.0 — Object Management Group (December 2010), 1 Dec 2010