---
name: business_analysis
description: "Run business analysis for a proposed change end to end: stakeholder analysis with a power-interest grid and RACI, requirements elicitation with matched techniques, a business requirements document with numbered testable requirements, user stories that pass INVEST with Given-When-Then acceptance criteria, a requirements traceability matrix, and gap analysis between current and future state. Use when someone asks for a BRD, requirements for a change or project, stakeholder analysis, user stories, acceptance criteria, a traceability matrix, or a gap analysis. For one named sales account plan use account_planning; for product prioritisation alone use a prioritisation skill."
---

# Business Analysis

## Purpose

Business analysis turns a proposed change from a request into an agreed, testable set of requirements that a delivery team can build against and a sponsor can approve or reject on evidence.

The method here follows two established references. The IIBA BABOK Guide v3 organises the work into six knowledge areas: Business Analysis Planning and Monitoring, Elicitation and Collaboration, Requirements Life Cycle Management, Strategy Analysis, Requirements Analysis and Design Definition, and Solution Evaluation. ISO/IEC/IEEE 29148:2018 sets the quality bar for each requirement: necessary, implementation free, unambiguous, consistent, complete, singular, feasible, traceable, and verifiable.

The deliverable is a package, not a single document: a stakeholder register with an engagement plan, elicitation records, a business requirements document (BRD), user stories with acceptance criteria where agile delivery applies, a traceability matrix, and a gap analysis with a closing plan. Ship the parts the change needs, but never ship a BRD with no traceability or a story list with no acceptance criteria.

Scope rule: the BRD states what the business needs and why, in business language. The moment a sentence describes a screen layout, a database, or a technical method before it states a business result, that sentence belongs in solution design, not in the BRD.

## Workflow

### 1. Frame the change before eliciting anything

Write down, in half a page: the need (the problem or opportunity, in the sponsor's terms), the change proposed, the context (teams, systems, rules, and deadlines that bound it), and the value claimed, with a baseline and a target if anyone can name one. Use the BABOK core concepts as a check: change, need, solution, stakeholder, value, context. If value has no baseline, record that as an open question with an owner. Do not invent a baseline to make the case look finished.

Decide the approach in the same pass: predictive (BRD first, sign-off, then build), adaptive (stories refined in cycles, BRD kept thin), or a mix. Record the decision and who made it. The approach sets how much of steps 4 and 5 you do up front.

### 2. Analyse stakeholders

Follow `references/stakeholder-analysis.md`. Identify stakeholders from four directions: who sponsors and funds it, who uses the result daily, who must approve or comply, and who can block or be harmed by it. ISO/IEC/IEEE 29148 lists examples that teams forget: operators, maintainers, trainers, suppliers, accreditors, and regulatory bodies.

For each stakeholder or group record: role, interest in the change, power to affect it, current stance (supporter, neutral, opponent, unknown), what they need from the analysis, and how you will engage them. Plot power against interest:

- High power, high interest: manage closely. Involve them in decisions, not just updates.
- High power, low interest: keep satisfied. Brief, high-level updates. Do not bury them in detail.
- Low power, high interest: keep informed. They often surface risks and workarounds first.
- Low power, low interest: monitor. Light updates, revisit if their interest moves.

Add a RACI for the key decisions and deliverables: Responsible does the work, Accountable owns the decision (exactly one per item), Consulted gives input before, Informed hears after. Run the checks in the reference file: no decision with two Accountables, no approver found only at sign-off time, no affected user group with no route into elicitation.

### 3. Plan and run elicitation

Follow `references/elicitation-checklists.md`. Pick techniques by the information you need, not by habit:

- Interviews: depth from one person, conflicting views held separately, sensitive topics.
- Workshops: shared decisions, conflict resolved in the room, prioritisation.
- Document analysis: what the current process claims to be, rules already written down.
- Observation: what the work actually is, workarounds no one mentions in interviews.
- Surveys or questionnaires: breadth across a large or spread-out group, with no follow-up depth.
- Prototyping: requirements people cannot state in the abstract, especially screens and flows.
- Focus groups, brainstorming, interface analysis, and reverse engineering: use when the reference file's conditions fit.

For every session: prepare an agenda tied to specific questions, confirm results back to participants in writing, and compare results across sources. Where two sources disagree, record the conflict as an open issue with an owner. Never average a conflict away in the notes. Elicitation is done when each in-scope area has at least two independent sources or one source plus a signed confirmation, and the open issues list names an owner and a due date for every gap that remains.

### 4. Write the business requirements document

Use `references/brd-template.md` as the skeleton. Required sections: document control, executive summary, background and current state, objectives, scope (in, out, deferred), stakeholders, business requirements, non-functional requirements, assumptions and constraints, risks, success measures, and approval.

Write each business requirement as one singular statement with these fields:

- ID: BR-001, BR-002, and so on. IDs never change and are never reused.
- Statement: one need, one verb, in business terms. Split any statement joined by "and" that carries two needs.
- Source: the stakeholder, document, or regulation it came from.
- Rationale: why it matters, tied to an objective.
- Priority: MoSCoW (see step 6).
- Acceptance criterion: how completion will be verified, stated as a measurable result.
- Owner: the stakeholder who can confirm it is met.
- Dependencies and status.

Apply the 29148 quality check to every requirement before review: necessary, implementation free, unambiguous, consistent with the rest, singular, feasible, traceable, verifiable. A requirement that fails verifiable gets rewritten or cut, not softened with words like "appropriate" or "timely" left unmeasured.

### 5. Write user stories where delivery is iterative

Use `references/user-stories.md`. Format: As a [role], I want [capability], so that [outcome]. The role comes from the stakeholder register, the outcome names the value, and neither half may be blank or generic.

Test each story against INVEST: Independent, Negotiable, Valuable, Estimable, Small enough to finish inside one iteration, Testable. Split stories that fail Small using the patterns in the reference file: by workflow step, by business rule variation, by data variation, or by acceptance criterion.

Write acceptance criteria in Given-When-Then form: Given a stated context, When an action happens, Then an observable outcome follows. Rules:

- One behaviour per criterion. Cover the main success case, the main failure cases, and any business rule limits (amounts, dates, permissions).
- Use numbers where the business has a real limit. Replace "fast", "easy", and "user-friendly" with the measured result the stakeholder will accept, or mark the value as an open question for that stakeholder.
- Keep criteria in business language. "The system returns a 200 status" is a technical check, not an acceptance criterion.
- Three to eight criteria per story is a working range. More than that usually means the story needs splitting.

### 6. Prioritise with MoSCoW and protect the Must line

MoSCoW comes from DSDM and sorts every requirement or story into exactly one bucket:

- Must have: the change fails or is not viable without it.
- Should have: important, painful to miss, but a workaround exists for a time.
- Could have: desirable, first to drop when time or budget tightens.
- Won't have this time: agreed out of scope for this round, recorded so it stops reappearing as a surprise.

Apply the test in order: if dropping it kills viability, legality, or safety, it is a Must. If not, ask whether a workaround exists. DSDM guidance plans for no more than about 60 percent of estimated effort on Must Haves and keeps a pool of Could Haves, often around 20 percent, as contingency. Treat those shares as a planning guide, not a law. If Must effort runs well above 60 percent, report the risk plainly: the plan has no room to absorb a surprise, and something labelled Must needs re-testing against the viability question.

### 7. Build the traceability matrix

Use `references/traceability-matrix.md`. One row per requirement, tracing backward to its source (objective, stakeholder need, or regulation) and forward to where it is satisfied and proved: design element, build item or story, test case, and verification result.

ISO/IEC/IEEE 29148 defines the traceability matrix as a table that links requirements to their origin and traces them through the life cycle. Use it for three jobs: coverage (every requirement has a design and a test, every test points at a requirement), impact analysis (when one requirement changes, the linked rows show what else moves), and audit (a reviewer can follow need to proof without asking anyone).

Run the bundled checker on the requirements and matrix files before any review:

```bash
python3 ~/workspace/skills/business-analysis/bin/ba_check.py --requirements requirements.csv --rtm rtm.csv
```

Fix every error it reports. Treat its warnings as findings to resolve or record, not noise.

### 8. Run gap analysis between current and future state

Use `references/gap-analysis.md`. Document the current state from evidence (process records, volumes, times, error rates, system behaviour observed), not from how the process is supposed to work. Define the future state in the same measurable terms as the objectives in the BRD. Then compare capability by capability across five views: process, people and skills, information and data, systems and tools, and rules and policy.

For each gap record: the capability, current state evidence, future state target, the size of the gap in numbers where numbers exist, root cause if known, the action that closes it, an owner, and whether the gap is closed by this change, by a separate action, or accepted. Sequence the closing actions into transition steps that the business can actually absorb. A gap with no closing action and no explicit acceptance is an unfinished analysis.

### 9. Validate, get approval, and manage changes

Validate requirements with the stakeholders who own them: walk the BRD and stories back to the people who supplied the needs and confirm the written version still says what they meant. Keep verification (is each requirement well formed) separate from validation (is this the right requirement). Both need doing, and they catch different faults.

Get sign-off from the approval authority named in step 2, recorded with a date and a version. After sign-off, changes go through a short impact routine: trace the affected rows in the matrix, assess cost, risk, and effect on Must items, get the Accountable stakeholder to approve or reject, and update the BRD, stories, and matrix in the same pass. A change applied to only one of the three is how traceability dies.

## Output Contract

Deliver, in the workspace or document store the team already uses:

1. Framing note: need, proposed change, context, value claim with baseline and target or open questions.
2. Stakeholder register: role, interest, power, stance, engagement approach per stakeholder, plus the power-interest plot and a RACI for key decisions.
3. Elicitation record: techniques used, sources per topic, confirmed results, conflicts and open issues with owners and due dates.
4. BRD following `references/brd-template.md`, with every requirement carrying ID, statement, source, rationale, MoSCoW priority, acceptance criterion, owner, dependencies, and status.
5. User stories with Given-When-Then acceptance criteria, where iterative delivery applies.
6. Traceability matrix in the format in `references/traceability-matrix.md`, with the checker output clean of errors.
7. Gap analysis table with closing actions, owners, and transition sequence.
8. Approval record: who approved which version, when, and any conditions.

A worked example of items 4 to 7 for one small change lives in `references/worked-example.md`. Copy its shapes, not its content.

## Operating Rules

- Verify before writing: every number, date, rule, and limit in a requirement comes from a stakeholder, a document, or a regulation named in the source field. If no source exists, write it as an open question. Never fill a gap with a plausible figure.
- Keep business requirements implementation free. Name the business result and the business rule. Leave screens, fields, and technology choices to solution design unless a real constraint fixes them, in which case record the constraint and its source.
- One requirement, one need. Split compound statements. Use one ID per need and never reuse an ID after a requirement is retired.
- Treat unknown stance as work, not as consent. A stakeholder who has not responded has not agreed.
- Record Won't Have items in the BRD. Scope that lives only in meeting memory returns as scope creep.
- Keep the matrix current or say it is stale. A traceability matrix that lags the BRD gives false confidence, which is worse than no matrix.
- Report MoSCoW honestly. If everything is a Must, say prioritisation has not happened yet and run the viability test again with the sponsor in the room.
- Do not present estimates, benefits, or timelines as facts when they are judgements. Label them as estimates with a basis and an owner.
- Stop and escalate when: two Accountable stakeholders claim the same decision, a Must requirement has no owner willing to confirm it, a legal or regulatory source cannot be obtained, or the sponsor will not name what is out of scope. Analysis cannot fix a decision no one will make.