What Is the Business Analysis Life Cycle? Stages, Outputs and a Worked Example

What the business analysis life cycle means

The business analysis life cycle is a simple way to describe the order of BA work on a change. It starts before anyone talks about a solution, with a clear view of the problem. It ends after release, when someone checks whether the change actually helped. In between, the analyst finds the right people, learns what they need, writes requirements, supports the team building the solution and helps test it.

There is no single official version. Professional bodies such as IIBA describe business analysis as a set of knowledge areas and tasks rather than one fixed sequence, and many companies use their own stage names. The seven stages below are a practical teaching model. They match what most beginners will see on real projects, whatever the labels are.

Thinking in stages helps you in two ways. First, you always know what output you should be producing right now. Second, you can spot when a project skips a stage, for example when a team starts building before anyone has agreed the problem. If you want the wider picture of the role, read what a business analyst does.

The seven stages, with purpose and outputs

1. Understand the problem

Purpose: agree what is wrong, why it matters and what success looks like. Ask what happens if nothing changes. Outputs: a problem statement, a business case or a short opportunity note, high-level scope (what is in and what is out) and SMART objectives that can be measured later.

2. Identify and analyse stakeholders

Purpose: find everyone who is affected by the change or can influence it, and decide how to work with each group. Outputs: a stakeholder list, a power/interest grid, a RACI matrix for key decisions and a simple communication plan.

3. Elicit needs

Purpose: understand how work is done today and what people need, using interviews, workshops, observation and document review. Outputs: interview and workshop notes, an AS-IS process model, a list of pain points and open questions, and confirmed summaries sent back to stakeholders.

4. Analyse and document requirements

Purpose: turn raw needs into requirements that are clear, testable and prioritised. Outputs: business, functional and non-functional requirements, either in a BRD or as user stories in a backlog, acceptance criteria, a TO-BE process model and a priority order such as MoSCoW.

5. Support design and delivery

Purpose: keep the build aligned with the real need. The analyst answers developer questions, splits or refines stories, checks data and integration details and handles changes. Outputs: refined stories, field mappings or data notes, a decision log and updated requirements when something changes.

6. Test and go live

Purpose: confirm the solution does what was agreed and that people are ready to use it. Outputs: UAT test cases written from acceptance criteria, a requirements traceability matrix, triaged defects, a sign-off record, training or guidance notes and a go-live checklist.

7. Evaluate value after release

Purpose: check whether the objectives from stage 1 were met, using real data. This is often called benefits realisation. Outputs: a short benefits review comparing results with the baseline, lessons learned and new backlog items for the gaps you found.

How it looks in agile versus plan-driven projects

The stages are the same in both styles. What changes is how often you go through them and how much you write down before building starts.

In a plan-driven project (often called waterfall), the stages run mostly once and in order. You finish elicitation and requirements, get a formal sign-off on a document such as a BRD, then hand over to design and build. Testing comes near the end. This suits work with fixed rules, contracts or heavy regulation, where changing course late is expensive.

In an agile project, stages 1 and 2 still happen up front, but in a lighter form. Stages 3 to 6 then repeat in every sprint for a small slice of the product. You elicit and refine a few stories, the team builds them, and they are tested and shown in a review. Stage 7 also happens more often, because each release gives you real feedback. Requirements live in a backlog and are allowed to change.

Many real projects are hybrid. A bank might write a formal business case and sign off scope like a plan-driven project, then deliver the software in sprints. Your job is to recognise which stage you are in, whatever the method is called.

Worked example: an expense claims app at a fictional company

Tealbrook Logistics, a fictional company, pays staff back for work expenses using paper forms. Employees wait an average of 10 working days for their money, and the finance team spends hours chasing missing receipts. Nadia, the business analyst, follows the life cycle from start to finish. The team works in two-week sprints.

1. Understand the problem. Nadia writes the problem statement: paper claims are slow and often incomplete. The SMART objective is to cut average reimbursement time by 50%, from 10 to 5 working days, within three months of go-live. Scope: a mobile claim form and approval flow. Out of scope: changes to the payroll system.
2. Stakeholders. She maps employees, line managers, the finance team, payroll and IT on a power/interest grid. Helena, the finance director, is the sponsor and decision maker.
3. Elicitation. Nadia interviews finance staff and runs a workshop with managers. The AS-IS process shows that most delay comes from managers approving small claims by hand, often days later.
4. Requirements. The team agrees a key rule: claims with a total claim value under ₹500 are approved automatically, and all other claims go to the line manager. Nadia writes this as a user story with acceptance criteria (shown below) and the product owner orders the backlog.
5. Delivery. Over three sprints the team builds the form, the approval rule and the finance view. Nadia answers questions from Mei, the lead developer, and records decisions in a decision log.
6. Test and go live. In week 12, Riya runs final UAT from the acceptance criteria and finds a defect in the approval rule (see the dialogue). It is fixed and retested, Helena signs off and the app goes live.
7. Evaluate value. Three months later, average reimbursement time is 6 working days. That is a 40% reduction, not the 50% target. Nadia finds that claims of ₹500 or more still wait for managers who approve once a week, so she adds a manager reminder feature to the backlog.

Feature: Automatic approval of small expense claims

  Scenario: Claim with a total value under the limit
    Given an employee submits a claim with one receipt of ₹450
    When the claim is saved
    Then the claim status is Approved

  Scenario: Several receipts with a total over the limit
    Given an employee submits a claim with two receipts of ₹300 each
    When the claim is saved
    Then the claim total is ₹600
    And the claim is sent to the line manager for approval

Notice how each stage fed the next. The objective from stage 1 gave Nadia a baseline to measure in stage 7. The acceptance criteria from stage 4 became Riya's test cases in stage 6, which is why the defect was easy to prove. For more on writing criteria like these, see acceptance criteria and Gherkin examples.

Common mistakes at each stage

Most problems on projects trace back to a stage that was skipped or rushed. Here is one typical mistake per stage, and what to do instead.

1. Understand the problem: jumping straight to a solution, such as we need an app, without agreeing the problem or a measurable goal. Keep asking why until you reach the business impact.
2. Stakeholders: talking only to managers and missing the people who do the work every day, or forgetting groups like IT security and customer support.
3. Elicitation: writing down what people say without checking it. Send a summary back, ask them to confirm, and look at real data or documents where you can.
4. Requirements: writing vague requirements such as the system should be fast or easy to use. If a tester cannot check it, it is not finished.
5. Support delivery: disappearing once the build starts. Developers fill gaps with guesses, and decisions made in chat are lost. Stay available and keep a decision log.
6. Test and go live: treating UAT as a formality, testing only the happy path, or forgetting to train users. Test edge cases and boundary values, such as an amount exactly at a limit.
7. Evaluate value: never measuring results after release, or having no baseline to compare against. Record the starting numbers in stage 1 so that stage 7 is possible.

A related mistake is thinking the stages only move forward. Even in a plan-driven project, a finding in testing can send you back to requirements. That is normal. The life cycle is a guide, not a rule that stops you from going back.

Quick checklist: have you covered each stage?

Use this before you move a piece of work forward. If you cannot tick an item, you may be skipping part of the life cycle.

Reading about the stages is a good start, but the life cycle makes most sense when you produce each output yourself. Try taking one small, familiar problem, such as a slow approval at your college or workplace, and write a problem statement, a stakeholder list and three user stories for it.

Frequently asked questions