FIELD GUIDE NO. 01 · FIRST EDITION 2026

The Minimum Viable

BA Practice.

A working field guide for what a world-class business analysis practice looks like — the standards, templates, methods, and operating rhythm that separate documentation work from decision quality. Built on the IIBA BABOK® Guide v3. Tested in live transformation programs across utilities, financial services, and government.

By Trevin Nimaladasa

Edition Vol. I · First Edition · 2026

Standard Aligned to the IIBA BABOK^® Guide v3

7+8

Artefacts & Techniques

Preamble · Operating posture

Values & Mindset

Six values that hold up. Written so they can be used as a check during real work — not a poster on a wall.

BABOK UC 9.1 · Analytical Thinking & Problem Solving UC 9.2 · Behavioural Characteristics UC 9.4 · Communication Skills UC 9.5 · Interaction Skills

Decisions before delivery

We don't write requirements into a vacuum. Every BRD answers a decision someone has actually made — or names the decision still missing.

"What decision is this work enabling, and who owns it?"

Problem before solution

We hold the line, even when stakeholders want to jump ahead. The BA's first job is to slow the rush to "build."

"Are we sure we've understood the problem?"

Evidence over opinion

Every requirement has a why. Every assumption has an owner. Every "the business needs…" has a person and a source.

"Where did this requirement come from?"

Build the system that builds the system

We invest in structure that compounds. The standard: a stakeholder team writing BA-quality requirements inside a system the BA designed — not the BA writing them in isolation.

"Could a stakeholder produce this without me?"

Candour over comfort

We tell stakeholders what they need to hear, not what is easy to say. We push back on scope, on premature solutions, on undefined outcomes.

"Have I told them the uncomfortable thing?"

Outcomes over outputs

We measure ourselves by what changed in the business, not what we produced. Documents are scaffolding; the building is the outcome.

"What benefit will this requirement realise?"

A good BA does not just produce requirements. A good BA builds the structure that lets the right requirements be produced — by themselves, by stakeholders, and increasingly by AI — at consistent quality, repeatably, without heroics. The practice philosophy

Mindset standards

Five postures that distinguish a senior BA from a documentation clerk.

Hold the line.The BA is the fence between problem and solution. Pulling the team back to the problem is the BA's job, not a side activity.

Decision quality, not document quantity.The BA is accountable for what gets decided well — not what gets written prolifically.

Write for the next person.Artefacts must survive handover. If only you can read it, it isn't an artefact.

Question before refining.The BA questions whether the requirement should exist before writing it well.

"We shouldn't build this."The BA is comfortable saying it when the evidence supports it.

The thesis · Why this practice exists

Delivery vs Value.

A BA practice that produces excellent requirements for the wrong work is a practice doing harm at scale. Delivery and value are not the same thing — they're often in tension. Delivery is what gets shipped; value is what changes in how the enterprise actually works, after the project closes. The BA's most important contribution is making the distinction visible at every stage, and refusing to let the two be confused.

There is nothing so useless as doing efficiently that which should not be done at all. Peter Drucker

The Delivery Trap

Practices optimised for delivery focus on velocity and output. Features shipped. Story points completed. Sprint goals met. Release frequency increased. These metrics create the illusion of progress while the organisation moves sideways — or in the wrong direction entirely. In enterprise settings the trap shows up as: portfolios full of "completed" initiatives with no measurable operational lift; business teams stretched thinner after delivery, not relieved by it; new systems layered on top of old processes, roles, controls, and spreadsheets; benefits registers written once to secure funding, then ignored; AI bolted onto workflows that were never simplified or owned. The BA is the first profession in the chain that can stop this — or perpetuate it.

Feature factories

Teams continuously output features without validating impact or usage. The BA writes well — for work that didn't deserve to ship.

"What stops, retires, or simplifies as a result of this work?"

As-is replication

The current process gets perfectly preserved into the new system. Manual work is digitised instead of eliminated. Workarounds harden into "business rules."

"Are we transforming, or migrating dysfunction with better packaging?"

Benefits theatre

The business case names benefits to secure funding. The benefits register goes into a drawer at go-live. No one tracks whether the change actually compounded.

"Who owns the benefit twelve months after go-live?"

Success at go-live

The launch is celebrated. The town-hall email goes out. Operations quietly absorb more work. By the time anyone asks whether it worked, the team has moved on.

"What evidence — six months from now — would say this paid off?"

The Illusion Stack

In most enterprises the illusion starts long before delivery. The sequence is predictable, and each step creates a different illusion. By the time delivery begins, assumptions have hardened into commercial commitments. The BA is often handed the BRD task at step 2 — which is the moment to push back, not comply.

Step	What it produces	The illusion it creates	What value should mean here
Business Case	A funded narrative of value.	The appearance of value before leverage exists.	A named operational change with a measurable outcome, an accountable owner for the change twelve months out, and a defined kill criteria.
BRD	A documented set of requirements.	The appearance of certainty before the problem is understood.	Requirements traceable to a specific decision in the decision pack, with the decision still verifiably live and owned.
RFx	A market test of vendors against the BRD.	The appearance of choice before trade-offs are owned.	Trade-offs (speed vs correctness, build vs buy, local vs enterprise) declared in writing and accepted by the decision owner before the market is tested.
Vendor responses	Detailed proposals matching the RFx.	The appearance of capability before the problem is sharpened.	Evidence that the chosen vendor can deliver against the actual operational change, not just the RFx as written.
Contractual scope	A signed scope, schedule, and price.	The appearance of control. Scope is now contractually locked, not strategically chosen.	Scope written so that re-decision is possible without contract penalty — value is preserved when reality shifts.
Delivery	A go-live, a launch, a closure report.	The appearance of success before anything in the operating model has actually changed.	The predicted operational change is happening — old work is stopping, new behaviour is starting, the predicted leverage is appearing in the evidence.

The BA's leverage point

The earliest the BA usually enters is at the BRD step. By then, three illusions are already in place. The senior BA's job is not to write a polished BRD on top of a flawed business case — it's to surface the gap. Section §03 (the eight techniques) is the toolkit for doing that without becoming the obstacle the project routes around.

What value the BA provides — and derives

Across the six steps of the illusion stack, the senior BA delivers value into the system and pulls value back out from every stakeholder in it. This is the value exchange the practice is accountable for — not artefacts produced, not hours billed, not requirements written.

Value the BA provides to the enterprise

A separation between delivery and value at every step of the chain, defended in writing. A traceable line from the operational outcome back through the decision pack, the requirements, the contract, the build, and the adoption evidence. A practice that says "we shouldn't build this" when the evidence supports it, and "we should re-decide this" when reality shifts.

"Could a leader who's never met me read this artefact and know what we decided, why, and what would say it worked?"

Value the BA derives from stakeholders

From sponsors: the decision rules and trade-offs the BA writes against. From operators: the actual reality of work — what really happens, not what the SOP says. From SMEs: domain truth — the constraints, the dependencies, the things that have failed before. From change managers: the behaviour-change reality after go-live. From vendors: the gap between what was sold and what can be built. The BA's job is to extract these inputs cleanly, name them, and make them visible.

"What did each stakeholder give me that the artefact would be wrong without?"

The value exchange

Every artefact in this guide is both a product and a contract — the BA produces it, but the inputs come from people who own different parts of the truth. The Decision Log holds the sponsor's trade-offs. The Stakeholder Map holds the operating reality. The Assumptions register holds what nobody yet knows. None of these are the BA's opinion. The BA's job is to make the system in which the right people put the right inputs into the right artefacts — and then defend that system through delivery and adoption.

"If I disappeared tomorrow, would the practice keep producing decision-quality artefacts — or would it produce documents?"

iii

Standard alignment · IIBA BABOK® Guide v3

BABOK Alignment.

A world-class BA practice doesn't replace BABOK — it operationalises it. Six knowledge areas, fifty techniques, the requirements classification schema, and the agile / IT / business architecture perspectives all sit beneath the practice. We follow the standard. Vocabulary, tools, and right-sizing are layered on top. Every section of this guide carries a BABOK reference strip so the alignment is visible at a glance — without requiring the reader to consult the standard separately.

A note on what this is

This is not the CBAP study guide. It's not a textbook, a glossary, or a certification primer. It's a working reference for what a senior practitioner does day-to-day — informed by BABOK, but written for the operator, not the exam candidate. If you're CBAP-trained, the alignment will be obvious. If you're not, you don't need to be: the BABOK references are signposts, not prerequisites.

A note on BABOK's age

BABOK v3 was published in 2015. A lot has happened since — Generative AI, agentic systems, cloud-native architectures, the shift from project-funded delivery to product-funded teams, data mesh, the elevation of decision intelligence, the codification of change management as a peer discipline. None of this is in v3, and the standard is overdue for an update. That said: what v3 covers — knowledge areas, classification schema, techniques, perspectives, underlying competencies — still holds. The foundation is sound. This guide treats BABOK v3 as the load-bearing standard and layers the post-2015 evolution on top (AI maturity arc in §09, decision integrity through delivery in §02, dial-ups by industry in §07). Apply the standard. Don't wait for v4 to bring the rest of the practice forward.

Six knowledge areas

Tasks may be performed sequentially, iteratively, or simultaneously — BABOK does not prescribe order, only that necessary inputs are present. The practice operating sequence (§08) is the prescribed order on top of BABOK.

KA	Knowledge Area	Purpose & tasks
BAPM	Business Analysis Planning & Monitoring	Plan BA approach · Plan stakeholder engagement · Plan governance · Plan information management · Identify performance improvements.
EC	Elicitation & Collaboration	Prepare for elicitation · Conduct elicitation · Confirm results · Communicate BA information · Manage stakeholder collaboration.
RLCM	Requirements Life Cycle Management	Trace requirements · Maintain · Prioritise · Assess changes · Approve requirements.
SA	Strategy Analysis	Analyse current state · Define future state · Assess risks · Define change strategy.
RADD	Requirements Analysis & Design Definition	Specify & model requirements · Verify · Validate · Define architecture · Define design options · Analyse potential value.
SE	Solution Evaluation	Measure solution performance · Analyse performance measures · Assess solution limitations · Assess enterprise limitations · Recommend actions.

Perspectives we apply

BABOK names five perspectives — lenses for adapting the standard to context. The BA chooses the right lens for the project class. None are mutually exclusive; most transformation work blends three or four.

Agile

Continuous elicitation, iterative refinement, backlog as living requirements register, acceptance criteria written at story level.

Anchors story-level requirements work, sprint-by-sprint refinement.

Information Technology

System interfaces, data, NFRs, security. Architecture-aware specification. Applies to most enterprise transformation work.

Anchors the FUN / DAT / INT / SEC / NFR types.

Business Process Management

As-is / to-be modelling, BPMN, service journey decomposition, stage gates and enterprise delivery framework logic.

Anchors the WFL type and the process inventory artefact.

Business Architecture

Capability maps, value streams, strategic intent & portfolio sequencing. The lens for cross-program decision packs.

Anchors Strategy Analysis on portfolio & modernisation programmes.

Business Intelligence

Reporting, dashboards, analytics. Data quality and lineage requirements. The reporting lens for traceability and outcome dashboards.

Anchors the RPT type and the outcome dashboard.

Beyond the standard

Two areas the practice operates in that BABOK v3 doesn't name as perspectives — but that a senior BA can't ignore. The first is AI, which is reshaping how and by whom requirements get produced. The second is the working technique toolkit — the methods in heaviest day-to-day use, anchored in BABOK's fifty techniques but applied as a practitioner's default kit rather than a textbook list.

Extension · Not yet a BABOK perspective

AI in the practice

A maturity arc through three layers: Generative AI prompts (today), AI-assisted workflows (near-term), and agentic systems (emerging). BABOK doesn't yet name AI as a perspective — but how the BA produces requirements, and increasingly who produces them, now turns on it. The senior BA applies the same standards (evidence, classification, traceability) to AI-produced outputs as to any other source; the BA stays accountable for what enters the register.

Anchors §09 AI in the BA Practice — prompts, workflows, agents.

Techniques in heaviest use

BABOK names fifty techniques. In day-to-day practice, ten or so do most of the work. This is the senior BA's default toolkit — not the only techniques applied, but the ones reached for first, on virtually every engagement. The remaining techniques in the BABOK appendix earn their keep in specific contexts (§06 Dial-ups by Context, §07 Dial-ups by Industry name when).

Technique cluster	What it does	BABOK anchor
Workshops · Interviews · Observation	The three elicitation primitives. Workshops for consensus, interviews for depth, observation for the gap between stated and actual practice.	EC 4.1–4.3 · Elicitation
Process Modelling · Process Analysis	As-is and to-be modelling. The discipline that turns "the business" into a set of named, owned, decomposable processes — which is what makes traceable requirements possible.	RADD · Specify & Model · Functional Decomposition
Stakeholder List, Map & Personas · RACI	Naming who has decision rights, who has influence, who has interest, who needs to be informed. The discipline that prevents "the steering committee" from absorbing accountability that belongs to a named person.	BAPM 3.2 · Plan Stakeholder Engagement
Acceptance & Evaluation Criteria · Scope Modelling	How we know a requirement is done; how we know the project is in or out. Acceptance criteria written as Given/When/Then are testable. Scope modelling with paired in/out stops makes deferral and de-scoping explicit, not implied.	RADD 7.4 · Define Requirements Architecture
Decision Analysis · Risk Analysis & Management	The pair that sits under §02 Decision Integrity. Decision Analysis surfaces options and trade-offs; Risk Analysis names what could break the decision and how we'd know. Both feed the Decision Log and the Assumptions register.	SA 6.3 · Assess Risks · BAPM 3.5
Document Analysis · Data Mining · Interface Analysis	When the current state is undocumented, contested, or both. The BA reads the system, the data, the tickets, and reconstructs reality from evidence rather than memory.	EC · Elicitation techniques
Business Cases · Pre-mortem · SWOT	Strategic framing techniques. Business cases for funding decisions, pre-mortem for value risk before delivery, SWOT for option-level positioning. All three sit upstream of the BRD and feed §03 Axe-Sharpening.	SA 6.4 · Define Change Strategy
User Stories · Item Tracking · Reviews	The working-level techniques that keep the practice running day-to-day. User stories at story level, item tracking for assumptions/risks/open questions, reviews as the quality bar mechanism in the practice forum (§10).	RLCM · Maintain · BAPM 3.5

The full BABOK technique catalogue (Appendix A, fifty techniques) remains the reference. This table names what the senior practitioner reaches for first — and what the practice forum (§10) is most often critiquing the application of.

BABOK Requirements Classification Schema (§2.3)

BABOK defines four canonical levels. The fifteen-type taxonomy in this guide (§04 Classification & Naming) sits inside the Solution Requirements level — it does not replace the schema, it operationalises it.

BABOK Level	Definition	Where it lives in the practice
Business Requirements	Higher-level statements of goals, objectives, needs of the enterprise.	Problem Statement (Artefact 2) · Decision Log (Artefact 1) · Outcome statement.
Stakeholder Requirements	Needs of stakeholders that must be met to achieve business requirements.	Stakeholder & Decision-rights Map (Artefact 3) · Service / Process Inventory (Artefact 4).
Solution Requirements — Functional	Capabilities the solution must have — behaviour, information, interactions.	Practice types: FUN BIZ DAT INT WFL EXC RPT
Solution Requirements — Non-functional	Conditions under which the solution must remain effective — performance, availability, usability, security, compliance.	Practice types: PRF AVL USB SEC CMP AUD
Transition Requirements	Capabilities needed only for transition from current state to future state.	Practice types: MIG CFG · Cutover criteria · Decommissioning.

BABOK is the standard. The practice is the operating discipline. The standard tells us what to do; the practice tells us how it gets done in real organisations. The relationship

The minimum · Non-negotiable

The Foundation — seven artefacts

Every project. Right-sized to context, but never absent. Each artefact carries its purpose, a working template, and a worked example drawn from real transformation programmes.

Key artefact · The spine of decision integrity

Decision Log

Every binding decision — date, owner, rationale, constraints. Not "we agreed in standup."

Read ⌄

BABOK RLCM 5.5 · Approve Requirements BAPM 3.4 · Plan BA Information Management Tech · Decision Analysis · Decision Modelling

Purpose

Decisions are logged, not remembered. Survives team changes, disputes, audits. Operationalises the BABOK Decision Analysis technique — every binding decision captured with the alternatives considered and the constraints that bound the choice.

Template — Decision log entries

Decision log · per binding decision
Date	Decision	Owner	Rationale	Constraints binding	Revisit?
yyyy/mm/dd	decision in one line	name	why this option	reg · cost · time · data	Y / N — when
yyyy/mm/dd	…	…	…	…	…

Template — Alternatives considered

For each decision · alternatives & why not chosen
Option	Why not chosen	Evidence reviewed
Option A	specific reason	link to source
Option B	specific reason	link to source

Worked example — PPM rollout

Decision · MVP scope realignment

Decision: Realign MVP scope to 7 Must-Have backlog items, target single go-live with a fallback option for one division.
Owner: Programme Control Group (chaired by Head of Delivery).
Rationale: Vendor capacity constraints made full scope unviable; split go-live considered and rejected due to data integrity risk.
Revisit: Yes — at next governance gate.

Problem Statement

One page. The business problem in the operator's language, with evidence, owner, and what fails if we do nothing.

Read ⌄

BABOK SA · Strategy Analysis SA 6.1 · Analyse Current State SA 6.2 · Define Future State Tech · Business Cases · Root Cause Analysis

Purpose

Frames the problem before any solution conversation. Names the decision the BA is enabling. Surfaces evidence and owner. Anchors the BABOK Business Requirement before any Stakeholder or Solution Requirement is written.

Template

Problem Statement · sections
Section	Content
Problem	What is the actual business problem, in the customer's or operator's language?
Evidence	What tells us this is a real problem (not a symptom)? — tickets, complaints, audit findings, time studies, cost data.
Consequence of inaction	What happens if we do nothing in 6 / 12 / 24 months?
Problem owner	Who owns this problem? Who decides when it's solved?
Decision this work enables	What decision is this initiative answering? Who is the decision owner? What constraints bind the decision?
Outcome expected	Measurable change we expect (cycle time, error rate, FTE, $, risk). How will we know it worked? When?
Project accountability	Which outcomes is the project on the hook for? Which outcomes does the business unit own post go-live?

FormatOne page maximum. If it can't fit, the problem isn't framed yet.

Worked example — Project & Portfolio Management implementation

Problem · PPM rollout (utility sector)

Project actuals are reconciled manually across the data warehouse and the finance system, with inconsistent historical data and integration build gaps causing master data discrepancies in the new platform. Project managers cannot see live financial position and rely on finance for monthly snapshots.

Decision enabled

Whether to standardise on the new PPM platform as single source of truth for project actuals, with finance system integration as the authoritative feed — or continue parallel reconciliation. Decision owner: Head of Delivery + Finance Lead.

Stakeholder & Decision-rights Map

Who decides, who signs off, who escalates. The map that prevents committee paralysis.

Read ⌄

BABOK BAPM · Planning & Monitoring BAPM 3.2 · Plan Stakeholder Engagement Tech · Stakeholder List, Map & Personas · RACI

Purpose

Names accountability for every decision class the project will encounter. Replaces "the steering committee" with a person. The BABOK technique here is RACI extended with a constraints column — every stakeholder represents a binding constraint the BA must surface.

Template — Decision rights matrix

Decision rights · per decision class
Decision class	Accountable	Consulted	Informed	Escalation
Scope	name	name	name	name
Schedule	name	name	name	name
Budget	name	name	name	name
Solution design	name	name	name	name
Data & integration	name	name	name	name
Change & adoption	name	name	name	name
Sign-off / UAT	name	name	name	name
Go-live	name	name	name	name

Template — Stakeholder constraints map

What each stakeholder represents
Stakeholder	Role	Influence	Interest	Binding constraint they bring
name	role	H / M / L	H / M / L	regulatory · financial · capability · time · risk appetite
name	role	H / M / L	H / M / L	…

Disagreement protocolWhat do we do when stakeholders disagree? Default escalation path. Time-box for unresolved disputes (e.g. 5 working days, then escalate to programme governance).

Worked example — HR transformation programme

Decision rights · HRIS implementation

Position management design — Accountable: HR domain lead. Consulted: product owner, current-state SME. Informed: business unit leaders. Escalation: programme control group.
Requirements quality bar — Accountable: BA. Consulted: product owner. Informed: workstream leads.

Service / Process Inventory

What journeys and processes are in scope, with owners and current pain points anchored in evidence.

Read ⌄

BABOK SA · Strategy Analysis RADD · Requirements Analysis & Design Definition Tech · Scope Modelling · Process Modelling · Functional Decomposition Persp. · BPM

Purpose

Sets the scope at the journey level before drilling into requirements. Bounded by what's in, with paired stops naming what's explicitly out. BABOK technique: Scope Modelling combined with Functional Decomposition — a world-class practice always pairs in-scope with explicit out-of-scope.

Template — Process inventory

Service journeys & processes in scope
Journey / Process	Owner	In scope?	Out of scope	Current pain
journey name	name	Y / N	what's out	evidence-based
process under journey	name	Y / N	what's out	evidence-based
process under journey	name	Y / N	what's out	evidence-based

Template — Paired stops

For every "in" — what's explicitly out, or what stops?
In scope (new)	Out of scope / Stop / Replace
new capability	legacy or alternative being retired
new capability	process being decommissioned

Worked example — HR transformation programme

Service journey decomposition

A journey like Higher Duties is decomposed into phases, each phase into a discrete set of business processes, each business process into individually testable requirements. Traceability runs end-to-end — phase → process → requirement → test case — so the BA can answer "which decision is this serving?" at any level. The structure also makes it possible for stakeholders to contribute requirements directly inside it, without the BA writing in isolation.

Requirements Register

The single source of truth — for example a Confluence requirements table or a Jira backlog. Traceable end-to-end. Every line testable.

Read ⌄

BABOK RLCM · Requirements Life Cycle Mgmt RADD · Requirements Analysis & Design Definition RLCM 5.1 · Trace Requirements RLCM 5.2 · Maintain Requirements Tech · Acceptance & Evaluation Criteria · User Stories

Purpose

The traceability spine. Every requirement classified, owned, linked to acceptance criteria and test cases. This artefact is the BABOK Requirements Repository — the practice's commitment to Trace and Maintain as ongoing tasks, not one-off events.

Required fields

ID — using practice naming convention (see §04)
Type — functional, data, integration, workflow, reporting, NFR, compliance, migration, security
Epic / Phase / Process — full traceability up
Description — clear, testable, single-purpose
Acceptance criteria — Given / When / Then
Source — workshop, document, observation, regulation
Owner — single name (not "the team")
Outcome it serves — link to outcome in problem statement
Test case ID(s) — link down to verification
Status — Draft / Refined / Approved / Built / Tested / Live

Template — Register row

Requirements register · canonical fields
ID	Type	Epic / Phase / Process	Description	Acceptance Criteria	Source	Owner	Outcome	Test ID	Status
HR-FUN-…	FUN	EP / PH / BP	single behaviour	Given / When / Then	workshop · doc · regulation	name	link	TC-…	Draft → Live

Worked example — requirements stack architecture

Architecture · enterprise-grade requirements stack

Requirements table = plan / source of truth (for example in Confluence).
Tickets generated from the requirements table with AI-assisted prompts (for example into Jira).
Each ticket: PRJ-379 with full structure — Summary, Requirement Type, Value Stream, Workstream, Acceptance Criteria, DoR, DoD, Traceability, Systems Impacted, Subtasks.

Assumptions, Constraints & Open Questions

Live, dated, owned. Open questions have a due-by date — never a parking lot.

Read ⌄

BABOK BAPM · Planning & Monitoring RADD · Requirements Analysis & Design Definition RLCM 5.4 · Assess Requirements Changes Tech · Risk Analysis · Item Tracking · Assumptions Log

Purpose

Surfaces what we're assuming, what binds us, and what we still don't know — with named owners and dates so nothing rots. Pairs the BABOK Risk Analysis technique with Item Tracking; every entry has an owner and a due-by-date. The lifecycle view (below) operationalises BABOK's Assess Requirements Changes task — making assumption drift visible the moment a trigger event fires.

Template — Assumptions

Assumptions · what we're treating as true (until proven)
ID	Assumption	If wrong, impact	Owner	Validate by
AS001	statement	impact	name	yyyy/mm/dd

Template — Assumption lifecycle

An assumption isn't a static entry — it moves through states. The lifecycle column makes assumption drift visible. See §02 Decision Integrity for the discipline this template enables.

Assumption lifecycle · state & trigger event
ID	State	Trigger event for re-test	Action owner	Last reviewed
AS001	Stated	what would cause us to re-test it	name	yyyy/mm/dd
AS001	Tested → Validated	evidence reviewed	name	yyyy/mm/dd
AS002	Tested → Broken	what changed; decision impact	name	yyyy/mm/dd
AS003	Action taken	decision re-opened · constraint added · risk logged	name	yyyy/mm/dd

RuleEvery assumption gets a trigger event the day it's logged. An assumption with no defined re-test trigger is a wish.

Template — Constraints

Constraints · what binds us
ID	Constraint	Source	Workaround?	Binding for
CN001	statement	regulation · contract · technical	Y / N	decision class

Template — Open questions

Open questions · what we still don't know (with due-by)
ID	Question	Owner	Due	Blocking what?
OQ001	question	name	yyyy/mm/dd	decision · work item

Worked example — integration programme

Open question · master data design

OQ: Is team code currently used as a unique key in the integration or staging tables?
Owner: solution architect.
Blocking: rewrite of the data model backlog item. Cannot proceed with reuse of inactive team codes until validated.

Traceability Matrix (RTM)

Requirement → Test → Outcome. Auto-generated where possible. The proof the practice did its job.

Read ⌄

BABOK RLCM 5.1 · Trace Requirements SE · Solution Evaluation SE 8.1 · Measure Solution Performance Tech · Acceptance Criteria · Item Tracking

Purpose

Closes the loop. Every requirement traces to a test that proves it, and back to the outcome it serves. The single artefact most BA practices skip — and the one that separates output from accountability. Operationalises BABOK's Trace Requirements as a continuous live discipline, not a one-off compliance document.

Template — Traceability matrix

Requirement → Test → Outcome (the spine)
Req ID	Epic	Phase	Description	Test ID	Result	Outcome served	Status
HR-FUN-…	EP	PH	text	TC-…	Pass / Fail	link	status
PPM-INT-…	EP	PH	text	TC-…	Pass / Fail	link	status

Standard views the BA must be able to produce

RTM views · pre-built filters
View	Question it answers
By outcome	Which requirements serve this outcome? Are they all tested?
By epic	Coverage % of epic — which requirements still in Draft?
By NFR	Are non-functional requirements (NFR / SEC / CMP) actually being tested?
Failed tests	Which outcomes are at risk because tests are failing?
Orphans	Requirements with no linked test, no linked outcome, or no owner.

Where this lives

Tooling

Generated from the requirements stack (for example Jira → Confluence) using AI tooling and a BI layer. The dashboard is the artefact: live req-to-test-to-outcome status, visible to PMs, BAs, testers, and the steering group. No more spreadsheets.

The spine · Pre-delivery → delivery → post-implementation

Decision Integrity.

A decision made well at the framing stage is worth nothing if it doesn't survive delivery. The hardest BA work isn't writing the BRD — it's holding the line on the decision the BRD was built to enable, through scope changes, sponsor turnover, vendor pressure, go-live theatre, and the quiet erosion of "we agreed in standup." Decision integrity is the spine of the practice. It runs from the moment a decision is framed (§03) to the moment its value is verified, often twelve months after go-live.

Why this section sits at §02, not at the end

Most BA practices treat post-implementation as an afterthought — a "we'll do a PIR if time permits" appendix. That's where value dies. Decision integrity is foundational, not closing. It's the discipline that says: the decision we made at the start is the one we're accountable to at the end, and any drift between the two must be named, owned, and re-decided — never absorbed silently.

BABOK RLCM · Requirements Life Cycle Mgmt RLCM 5.3 · Prioritise Requirements RLCM 5.4 · Assess Requirements Changes SE · Solution Evaluation SE 8.1 · Measure Solution Performance SE 8.4 · Assess Enterprise Limitations SE 8.5 · Recommend Actions

Phase 1 of 3

Pre-delivery — Holding the line on decisions made

Between decision pack signed and BRD published, three things can quietly erode: the decision can drift, the assumptions underneath it can break, and the ownership can dilute. The pre-delivery discipline is to make these visible the moment they move — not at the next steering committee.

Phase ⌄

No silent re-decision

Any change to a decision recorded in the Decision Log (Artefact 1) must be re-opened explicitly — same owner, same constraints check, new entry. A decision that shifts in a corridor isn't a decision; it's drift.

"If this changed, would the original decision owner notice?"

Assumption lifecycle, not assumption list

Assumptions don't sit static — they get tested, validated, or break. Each one has a trigger event (when we'd know) and an action owner (who responds). A register of unmoved assumptions is theatre.

"Which assumption would, if it broke this week, force a decision to be re-opened?"

Decision-pack to BRD traceability

Every section of the BRD answers back to a specific decision in the pack. If a requirement doesn't trace upward to a decision, it shouldn't be in scope. Test: pick any FUN requirement at random — can you name the decision it enables?

"Which decision is this requirement serving — and is that decision still live?"

Constraint expiry dates

Constraints (regulatory, contractual, capability, time) have expiry conditions. A constraint that was binding at framing may no longer bind by BRD sign-off. Re-check the constraints column before approving the BRD.

"Are all the constraints that shaped this decision still in force?"

Phase 2 of 3

Through delivery — Decision integrity under pressure

From BRD sign-off to go-live is where decisions die quietly. Sponsors change, vendors push back, dates slip, "minor scope adjustments" accumulate. The BA's job through delivery isn't to write more requirements — it's to keep the original decision visible while the delivery machine optimises for shipping. This is also where the BA and the Change Manager work as a paired discipline, not in sequence.

Phase ⌄

Decision re-opening, not scope creep

When pressure mounts to "just add this one thing," the right move isn't a change request — it's to re-open the underlying decision. Naming the parent decision usually reveals the change as either trivial (proceed) or a different project (defer).

"Is this a scope adjustment, or a different decision wearing scope's clothes?"

Stakeholder alignment under turnover

If the sponsor, accountable owner, or named decision-rights holder changes mid-delivery, the decision is provisional until the new owner re-confirms it. Re-confirmation is a meeting and a Decision Log entry, not a forwarded email.

"Has the new owner explicitly inherited the decision, or just the project?"

Change-management pair, not handoff

The Change Manager is not the BA's successor at go-live. The pair works the same decisions: the BA tracks decision integrity in scope and design; the Change Manager tracks decision integrity in behaviour and adoption. Same decisions, different observation points.

"Who else is tracking whether this decision is still alive in the business?"

Re-decision rhythm

Build a re-decision checkpoint into the project rhythm — at each phase gate, the top three decisions get explicit "still valid / re-open / superseded" status. Without this rhythm, the next checkpoint is the post-implementation review, by which time it's too late.

"When did we last re-check the top three decisions? Should they still hold?"

Phase 3 of 3

Post-implementation — Adoption & learning loops

Go-live is a checkpoint, not a finish line. The decision made twelve months ago is now testable in operational reality. Most practices treat this as someone else's problem (operations, change, business owners) — which is precisely why the value rarely lands. Decision integrity demands that the BA stays connected to the post-implementation evidence until adoption is verified or the decision is closed off as not realised.

Phase ⌄

30 / 60 / 90-day adoption checkpoints

Three fixed checkpoints after go-live. Each one answers the same three questions: Is the new behaviour happening? Is the old behaviour stopping? Is the predicted operational change visible? Anything else is theatre.

"Six months from now, what evidence would say this paid off — and is it appearing?"

Operating-model change verification

The original decision predicted operational leverage — work that disappears, decisions that become faster, capability that becomes reusable. Verify each prediction against measurable evidence. Predictions that didn't land become inputs to the next decision pack, not silent failures.

"Which predicted change actually happened? Which one didn't?"

Adoption ≠ training (change-management pair)

Training delivers knowledge. Adoption is behaviour change measured against the decision. The Change Manager owns the adoption curve; the BA owns the link back to the original decision. If adoption stalls, the decision needs re-examining — not just the comms plan.

"Is the workforce trained, or is the workforce actually working differently?"

Learning loops back into the practice

Every post-implementation review feeds two things: the practice library (what we learned about how decisions hold, drift, or break in this organisation) and the next decision pack (what assumptions we should make differently next time). A PIR with no library update is a PIR that didn't happen.

"What did this project teach the practice that the next BA should inherit?"

Three scripts the BA can safely use through delivery

Phrases that reposition the BA as the keeper of decision integrity — not a delivery obstacle — when pressure mounts.

Script 1 · Re-open, don't drift

"I'm not blocking this. I'm asking us to re-open the decision it sits inside — so when it lands, we know what we chose, not what we drifted into."

Script 2 · Owner re-confirmation

"The original decision had a named owner. We've had a handover since. Until the new owner re-confirms, I'll treat this decision as provisional in the log."

Script 3 · Post-implementation accountability

"The decision predicted a measurable change six months out. I'd like to stay connected to the evidence until we know whether the change actually happened — not because it's my role to fix it, but because the next decision pack needs to know."

The BRD documents requirements. The Decision Log holds the decisions. Decision integrity is the discipline of making sure the two still match the day the project closes — and twelve months after. The thesis of §02

Decision hygiene · Before the BRD opens

Axe-Sharpening Before BRD.

If you have five hours to cut down a tree, spend the first four sharpening the axe. Eight techniques that must be applied before a single requirement is written — not because the BA owns the decisions, but because the BA is responsible for surfacing whether they've been made. Skip these and the BRD will document symptoms, freeze the wrong solution, and lock in low-leverage work.

BABOK SA · Strategy Analysis SA 6.4 · Define Change Strategy BAPM 3.1 · Plan BA Approach Tech · Decision Analysis · Risk Analysis · Business Cases · SWOT · Pre-mortem

Decision framing

Make the decision explicit before solutioning begins. What decision is being made? What outcome should it create? What trade-off is being accepted? Who owns it?

If the decision isn't clear, a BRD will simply add false precision.

Problem shaping

Define the problem before defining features. Who is affected? What effort, delay, or risk exists today? Why is this worth solving now?

If teams argue about solutions, the problem isn't sharp enough.

Leverage mapping

Force the compounding question early. What effort disappears permanently? What decision becomes faster? What capability becomes reusable?

If nothing compounds, a BRD will only help deliver waste efficiently.

Trade-off declaration

Kill ambiguity upfront. What are we explicitly not optimising for? Speed vs correctness? Flexibility vs simplicity? Local benefit vs enterprise reuse?

Unstated trade-offs always reappear as scope creep.

Outcome-first success criteria

Define success in operational terms, not delivery terms. What changes in behaviour? What effort is removed? What would prove this was a bad investment?

If failure isn't defined, the BRD becomes the definition of success.

Option bounding

Prevent over-engineering. Surface at least three options: do nothing · minimal viable change · structural fix. Compare them by leverage, not elegance.

If only one option is on the table, the work isn't a decision — it's a delivery.

Kill criteria

Make stopping safe. What evidence would cause us to stop? When do we reassess? Without kill criteria, sunk cost runs the project.

If there's no defined way to stop, the project will only ever be paused.

Value pre-mortem

Assume value failed twelve months from now — and ask why. Ownership gaps. Behaviour not changing. Extra work introduced. Most value failures are visible before delivery starts.

If you can't think of a way it might fail, you haven't looked.

Three scripts BAs can safely use

Phrases that reposition the BA as a decision facilitator, not a delivery obstacle — without provoking defensiveness.

Script 1 · Decision rules first

"I can document requirements, but first I need the decision rules — what do we optimise for when trade-offs appear?"

Script 2 · Ownership transparency

"If we can't name an owner for the benefit twelve months out, I'll document ownership as 'unassigned' and flag it as a value risk."

Script 3 · Capacity transparency

"If we don't confirm capacity, I'll treat dates as assumptions, not commitments."

Delivery teams finish work. Leaders decide what is worth finishing. The BA is the bridge — the practitioner who makes the difference visible before scope hardens into contract. The BA's role in axe-sharpening

Vocabulary · Shared language

Classification & Naming.

Every requirement is one of these. Every ID follows this pattern. A world-class practice uses one shared vocabulary so reviews become craft conversations against a standard, not opinion contests.

BABOK §2.3 · Requirements Classification Schema RADD · Specify & Model Requirements Tech · Functional Decomposition · Non-Functional Requirements Analysis

Requirement types

Fifteen types organised into three tiers. The seven Core types cover the bulk of any requirements register. The five Quality Attributes split out the non-functional dimensions that often get crammed into a single "NFR" bucket and lose specificity. The three Lifecycle types cover one-time work that doesn't survive into steady state. Click any type to see the must-have components, when to use it, when not to.

i Core Seven types that cover most of any register

FUN

Functional

What the system does — the behaviour, feature, or capability the user or system invokes.

Read ⌄

Definition

A capability the solution must provide. Expressed as a single observable behaviour with a clear trigger, action, and outcome. The most numerous type in any register.

Must-have components

Actor — who or what initiates the behaviour (user role, system, schedule, event)
Trigger — what causes the behaviour to occur
Action — what the system does, in plain language
Outcome — what state has changed, or what data has been produced
Acceptance criteria — Given / When / Then, written so a tester can verify pass/fail without ambiguity

Worked examples

FUN · scheduled posting

The PPM platform posts project actuals from the finance system on the 1st of each month at 02:00. AC: Given approved actuals exist for the prior month, when the schedule fires, then the platform posts entries against each project's posting account.

FUN · user-initiated action

An approver can return a leave request to the requester with mandatory comments. AC: Given a pending leave request, when the approver selects "Return," then the system requires a comment of ≥10 characters before submission.

Use FUN when

The behaviour is observable, has a single clear trigger, and produces a definable outcome.

Avoid FUN when

The behaviour is really a workflow (use WFL), a calculation rule (use BIZ), or a non-functional quality (split into NFR/PRF/AVL).

BIZ

Business Rule

A constraint, calculation, or policy the business enforces — independent of which system implements it.

Read ⌄

Definition

A statement of policy, calculation, or constraint that the business commits to. Lives independently of any specific system or workflow — multiple FUN or WFL requirements may enforce the same BIZ rule.

Must-have components

Rule statement — the constraint or formula in plain language
Source — policy doc, regulation, contract, or named owner who set it
Conditions — when the rule applies (and any explicit exceptions)
Owner — who can change the rule (not who implements it)
Linked enforcement — which FUN, WFL, or DAT requirements operationalise it

Worked examples

BIZ · calculation

Higher duties allowance = (target classification base rate − employee's current base rate) × hours acted. Source: EBA clause 14.3. Owner: HR Policy Lead.

BIZ · constraint

A purchase order over $50,000 requires two approvers, neither of whom may be the requester's direct manager. Source: Finance Delegations Policy v4.2.

Use BIZ when

The rule outlives the system, is policy-owned, and may be enforced in multiple places.

Avoid BIZ when

It's really a single-system behaviour (use FUN) or a one-off configuration value (use CFG).

DAT

Data

What data is captured, structured, stored, retained — and the rules around its lifecycle.

Read ⌄

Definition

A statement about a data element, entity, or class — its structure, attributes, validation rules, retention, and relationship to other data. Distinct from how it gets in (INT) or what's done with it (FUN).

Must-have components

Data class / entity — the named concept (e.g. Project, Forecast, Employee)
Attributes — fields, types, mandatory/optional, allowed values
Cardinality & relationships — links to other entities (1:1, 1:many, many:many)
Validation rules — format, range, uniqueness, referential integrity
Retention — how long, where, under what conditions destroyed or archived
Source of truth — which system owns the master record

Worked examples

DAT · entity definition

Forecast data class includes: forecast_id (UUID, mandatory), project_id (FK to Project, mandatory), version (enum: baseline / working / approved), period (YYYY-MM), amount (decimal, ≥ 0), created_by, created_at. Master: PPM platform.

DAT · retention

Closed project records are retained for 7 years post-closure, then archived to cold storage. Audit trail entries are retained for 10 years and not archivable.

Use DAT when

Defining what data exists, its structure, validation, or retention.

Avoid DAT when

The requirement is really about how data moves between systems (use INT) or how a report displays it (use RPT).

INT

Integration

Interface to or from another system — the contract, the trigger, the failure mode.

Read ⌄

Definition

An interface between two systems. Specifies direction, payload, trigger, frequency, error handling, and idempotency. Most projects under-specify integrations — they document the happy path and leave failure modes implicit.

Must-have components

Direction — source system → target system (and whether bidirectional)
Trigger — event-driven, scheduled, on-demand, or polling
Payload — fields, mandatory/optional, format (JSON, XML, CSV, EDI)
Frequency & volume — how often, expected message size, peak load
Idempotency — can the same message be safely retried?
Error handling — retry policy, dead-letter queue, alert thresholds, manual recovery
Routing — direct, via integration platform, via message broker
Auth — how the systems authenticate (linked to SEC)

Worked examples

INT · scheduled batch

Finance system → Data warehouse. Trigger: nightly 01:00. Payload: prior day's posted journal entries (JSON). Volume: ~50k records / night, peak 200k month-end. Idempotent on journal_id. Failure: 3 retries at 15-min intervals, then DLQ + alert to ops.

INT · event-driven

HRIS → Payroll. Trigger: employee status change event. Payload: employee_id, change_type, effective_date, new_values. Routed via integration platform — no direct point-to-point.

Use INT when

Two systems exchange data and the interface needs an explicit contract.

Avoid INT when

It's really a one-off data load (use MIG) or a UI embed (use FUN with the embed as a behaviour).

WFL

Workflow

Process logic — the routing, stage gates, approvals, and state transitions that connect functional behaviours.

Read ⌄

Definition

The logic that orchestrates a process across multiple actors, systems, or steps. WFL covers what FUN cannot — the "and then what" between behaviours, including approvals, escalations, and state transitions.

Must-have components

States — the named statuses an item moves through (e.g. Draft → Submitted → Approved → Live)
Transitions — what triggers each move, what role can perform it
Routing rules — who gets it next, based on what attributes (amount, region, complexity)
SLA / time-box — how long can a state hold before escalation
Escalation path — who picks it up if SLA breached
Audit trail — what's logged at each transition (linked to AUD)

Worked examples

WFL · approval routing

Purchase requests follow a routing tree: ≤$5k → cost centre manager; $5k–$50k → manager + finance partner; >$50k → manager + finance partner + delegated approver. SLA: 3 business days per approver, then auto-escalate to next level.

WFL · stage gates

Project stages: Initiate → Plan → Deliver → Close. Each transition requires the prior stage's deliverables marked complete and a named accountable owner. Stage gate progression auto-creates governance deliverables.

Use WFL when

The work involves states, transitions, routing decisions, or multi-actor approvals.

Avoid WFL when

It's a single-actor behaviour (use FUN) or really a calculation (use BIZ).

EXC

Exception

Edge cases, error conditions, and recovery paths — the requirements that catch what the happy path misses.

Read ⌄

Definition

How the system behaves when the happy path doesn't apply — invalid data, missing inputs, downstream system unavailable, business rule violated. Most defects in production are EXC requirements that were never written.

Must-have components

Trigger condition — exactly what makes this an exception
System response — reject, queue, fall back, degrade gracefully, halt
User feedback — what the user sees (and doesn't see — security)
Logging — what gets recorded, at what level (linked to AUD)
Recovery path — manual fix, automatic retry, escalation, or terminal
Linked happy path — which FUN / WFL / INT this is the exception for

Worked examples

EXC · invalid input

If a purchase order is submitted with a closed cost centre, the system rejects the submission and displays "Cost centre [code] is closed. Select an active cost centre." The PO remains in Draft. No notification is sent to approvers.

EXC · downstream unavailable

If the finance system is unavailable when the nightly posting runs, the platform queues entries to the staging table and retries every 30 minutes for up to 6 hours, then alerts ops. No partial posts are committed.

Use EXC when

Defining what happens when the happy path can't be followed — invalid data, system unavailable, business rule violated.

Avoid EXC when

It's a normal alternate path (write it as FUN) or a non-functional concern like uptime (use AVL).

RPT

Reporting

Outputs — dashboards, scheduled reports, regulatory returns, ad-hoc analytics.

Read ⌄

Definition

Information presented to a consumer for a decision or obligation. Specifies what's shown, who sees it, when, in what format, and what data feeds it.

Must-have components

Audience — named role(s) who consume it
Decision or obligation served — what action the report enables
Fields & calculations — what's shown, how derived
Filters & parameters — what the user can slice by
Cadence — real-time, scheduled (daily/weekly/monthly), on-demand
Format — dashboard, exportable file, regulatory submission
Source data — which DAT entities, which system of record
Refresh latency — how recent must the data be

Worked examples

RPT · operational dashboard

Live portfolio RAG view replaces the manual senior management tracker. Audience: ELT + portfolio leads. Refresh: every 15 min. Filters: division, programme, RAG status, owner. Source: PPM platform (live).

RPT · regulatory return

Monthly water quality submission to regulator. Format: prescribed XML schema. Cadence: by the 7th business day of the following month. Source: SCADA + lab data. Submission requires compliance officer sign-off.

Use RPT when

Information is being assembled and presented to a consumer for a decision or obligation.

Avoid RPT when

It's really a UI screen with system data (use FUN) or a data extract for another system (use INT).

ii Quality attributes Five types that often hide inside a single "NFR" bucket

PRF

Performance

Speed, throughput, response time. The how-fast dimension.

Read ⌄

Definition

How quickly the system responds, how much it can process, under what load. Always measurable, always anchored to a percentile and a load condition — never just "fast."

Must-have components

Metric — response time, throughput, latency, queue depth
Target — quantitative (e.g. ≤ 2s, ≥ 1000 tx/min)
Percentile — p50, p95, p99 — never an average alone
Load condition — at what concurrent users, message rate, data volume
Measurement point — server-side, network edge, browser

Worked examples

PRF · response time

Status report renders within 5 seconds at p95 for 100+ active projects, measured server-side, under a load of 50 concurrent users.

PRF · throughput

Integration platform processes ≥ 500 messages per second sustained for 1 hour at p99 latency ≤ 200ms.

Use PRF when

Setting a numeric speed or throughput target.

Avoid PRF when

The concern is uptime (use AVL) or scaling under growth (still PRF, but specify the growth condition).

AVL

Availability

Uptime, recovery, business continuity. The how-often-it's-there dimension.

Read ⌄

Definition

The proportion of time the service is reachable and functioning correctly, plus how it recovers when it isn't. Frequently confused with PRF — performance is how fast, availability is how often.

Must-have components

Uptime target — a number of nines (99.9%, 99.95%, 99.99%) and the measurement window
Service hours — 24×7, business hours, batch window
Planned downtime — windows excluded from the SLA
RTO (Recovery Time Objective) — how fast must it come back
RPO (Recovery Point Objective) — how much data loss is acceptable
Failover behaviour — automatic, manual, degraded mode

Worked examples

AVL · uptime SLA

Customer-facing portal: 99.95% uptime measured monthly, 24×7 service hours, excluding planned maintenance windows on the 2nd Sunday 02:00–06:00 local time.

AVL · recovery

Billing system: RTO 4 hours, RPO 15 minutes. Automatic failover to secondary region on regional outage detected for > 5 minutes.

Use AVL when

Setting uptime, recovery, or business continuity expectations.

Avoid AVL when

The concern is response speed (use PRF) or graceful degradation under load (mix of PRF + EXC).

USB

Usability & Accessibility

How learnable, efficient, and inclusive the experience is for the intended users.

Read ⌄

Definition

The quality of the human interaction — how quickly users learn the system, how efficiently they complete tasks, how few errors they make, and how inclusive the experience is across abilities. Tested against real users, not opinion.

Must-have components

User group — named persona, expertise level, frequency of use
Task — the specific user journey being measured
Success metric — completion rate, time-on-task, error rate, SUS score
Accessibility standard — WCAG 2.2 AA is the typical baseline
Validation method — usability test, heuristic evaluation, automated audit

Worked examples

USB · task efficiency

An infrequent user (uses the system < once a month) can submit a leave request in ≤ 90 seconds with ≥ 90% completion rate on first attempt, validated by moderated usability testing with 5+ users.

USB · accessibility

All public-facing screens conform to WCAG 2.2 Level AA. Validated by automated audit (axe / Lighthouse) plus manual review with keyboard-only and screen reader users at sign-off.

Use USB when

The requirement is about the human's experience — learnability, efficiency, error rate, inclusion.

Avoid USB when

It's a visual design preference without a user-success metric (those belong in design specs, not requirements).

SEC

Security

Authentication, authorisation, data protection, threat mitigation.

Read ⌄

Definition

How the system protects information, identities, and operations from unauthorised access, modification, or disclosure. Always written against a named threat model and a control framework — never as generic "must be secure."

Must-have components

Asset being protected — data class, transaction, identity, capability
Threat — what attack or misuse this requirement defends against
Control — auth, authorisation, encryption, monitoring, segregation of duties
Standard / framework — ISO 27001, SOC 2, NIST, internal IS policy
Verification — pen test, control audit, automated scan

Worked examples

SEC · access control

Role-based access aligned to AD/SSO group membership. The "Finance Approver" role grants permission to approve POs ≤ delegation limit; permissions are reconciled to AD groups daily, with deviations alerted to IS.

SEC · data protection

Customer PII is encrypted at rest (AES-256) and in transit (TLS 1.3+). Decryption keys are managed by the enterprise KMS with quarterly rotation. No PII is logged in application logs.

Use SEC when

Specifying a control that protects an asset against a defined threat.

Avoid SEC when

It's really an audit trail (use AUD) or a compliance obligation that drives the control (use CMP — let SEC follow).

CMP

Compliance

Regulatory, audit, contractual, or standards obligations the system must meet.

Read ⌄

Definition

An obligation external to the project — regulatory, contractual, or standards-based — that the solution must satisfy. Compliance requirements drive other types (often SEC, AUD, DAT retention) but are documented separately so the obligation is traceable to its source.

Must-have components

Source — named regulation, contract clause, or standard
Obligation — exactly what must be done or demonstrated
Penalty / consequence — what happens if not met (often a clue to priority)
Evidence required — what auditors will ask to see
Linked enforcement — which SEC / AUD / DAT requirements operationalise it

Worked examples

CMP · regulatory

RAID register fields aligned to ISO 31000 risk categories. Source: ISO 31000:2018. Evidence: register schema mapped to ISO categories, available for audit on request.

CMP · contractual

Customer data residency: all customer PII processed and stored within the same jurisdiction as the customer. Source: master services agreement clause 8.4. Evidence: data-flow map and quarterly attestation.

Use CMP when

The driver is an external obligation (regulation, contract, standard) the system must demonstrably meet.

Avoid CMP when

It's an internal policy choice (write that as BIZ) or the operational control itself (use SEC / AUD).

iii Lifecycle Three types for one-time work that doesn't survive into steady state

MIG

Migration

One-time data transition from a source system or legacy state to the new target.

Read ⌄

Definition

The one-time movement of data from a source system into the new target. Distinct from INT (which is steady-state). Migration requirements are retired at go-live + n weeks — they should never live in the steady-state register.

Must-have components

Source & target — which system, which entity, which fields
Field mapping — source field → target field, with transformation rules
Reconciliation rules — what counts as success (record count, hash, business-rule check)
Cutover sequence — what loads first, what depends on what
Rollback plan — how to revert if validation fails
Decommission criteria — when can the source be turned off

Worked examples

MIG · master data mapping

Source-to-target posting account mapping, respecting the legacy system's 100-character code-length restriction by truncating with a documented suffix scheme. Reconciled by record count + sample of 1% manually verified.

MIG · cutover sequencing

Reference data loads first, then open transactions, then closed transactions for the prior 7 years. Each stage gates on reconciliation pass before the next begins.

Use MIG when

Moving data from a source/legacy system into the target as a one-off transition activity.

Avoid MIG when

The interface persists post go-live (use INT) or it's a structural data design (use DAT).

CFG

Configuration

Setup values, parameters, and reference data that bring the system to its operational state.

Read ⌄

Definition

The one-time setup of parameters, reference data, lookup tables, and configurable values that the system needs to operate. Often misclassified as FUN — but the behaviour is generic, only the configuration is project-specific.

Must-have components

Configuration item — the named parameter, table, or value
Initial value(s) — what gets set at go-live
Owner — who can change it post go-live
Change process — how it gets changed (admin UI, request, deployment)
Linked dependencies — what behaviour or rule references the value

Worked examples

CFG · reference data

Cost centre hierarchy: 4-level structure loaded from finance master, refreshed weekly. Owner post go-live: Finance Master Data team. Change process: ServiceNow request with 48-hour SLA.

CFG · system parameter

Approval delegation limits per role: stored as a configurable table, editable by the System Admin role through the admin UI without a code change. Change requires a peer review entry in the audit log.

Use CFG when

Setting up parameters, reference data, or configurable values that bring the system to operational state.

Avoid CFG when

The configuration encodes a business policy that outlives the system (use BIZ instead).

AUD

Audit & Logging

What gets recorded, retained, and made available for forensic review or regulatory inspection.

Read ⌄

Definition

The trail of who did what, when, and to which record — captured for forensic review, regulatory inspection, or operational troubleshooting. Distinct from RPT (which is for active decisions) — AUD is for reconstruction after the fact.

Must-have components

Events captured — which actions trigger an audit entry
Fields per entry — actor, action, target, before/after, timestamp, source IP, session
Retention period — how long, where stored, immutability requirements
Access control — who can read the audit log (and who can't)
Tamper resistance — append-only, hash-chained, signed
Search & export — how an auditor retrieves a slice

Worked examples

AUD · transaction log

Every approval action logs: actor (user_id + role), action (approve/reject/return), target (request_id + version), before-state, after-state, timestamp (UTC), session_id, source_ip. Retained 10 years, append-only, accessible to the Audit role via search by date range, actor, or target.

AUD · admin actions

All admin actions on configuration tables are logged with the configuration item changed, prior value, new value, justification field (mandatory, ≥ 20 chars). Retained 7 years.

Use AUD when

Defining what actions get logged, what's retained, and how the trail is protected and queried.

Avoid AUD when

It's an operational dashboard (use RPT) or application-level logging for debugging (use NFR / observability).

Naming convention

[SYSTEM]-[TYPE]-[SCENARIO]-[USE-CASE]-[STORY-ID]

Example: HR-FUN-SJ1-HD-014 — HRIS · Functional · Service Journey 1 · Higher Duties · Story 014

Example: PPM-INT-DW-FIN-007 — PPM · Integration · Data Warehouse / Finance interface · Story 007

Example: EAM-WFL-WO-CLOSE-022 — Asset Management · Workflow · Work Order Close · Story 022

HRIS / Core HR

PPM

Project & Portfolio

EAM

Enterprise Asset

WFM

Workforce Mgmt

ERP

ERP / Finance

CRM

CRM / Sales

BIL

Billing

INT

Integration platform

Data warehouse

ITSM

IT service mgmt

Quality gates · Entry & exit

Definition of Ready / Done.

When does a requirement enter the BA's hands, and when does it leave? Both checklists must be true. No requirement crosses without a tick in every box.

BABOK RADD 7.5 · Verify Requirements RADD 7.6 · Validate Requirements RLCM 5.5 · Approve Requirements Tech · Acceptance & Evaluation Criteria · Reviews

Definition of Ready

Before refinement begins

Source identified (workshop, document, observation, regulation)
Single named requestor (not "the business")
Linked to an epic, phase, or business process
Type provisionally classified (FUN / DAT / INT / WFL / RPT / NFR / CMP / MIG / SEC)
Outcome it serves identified
No conflict with existing approved requirement
Pre-decision dependencies surfaced (decisions in Decision Log)

Definition of Done

Before handoff to build / test

Description is testable — single behaviour, no compound conditions
Acceptance criteria written as Given / When / Then
Type confirmed and classification reviewed by peer
Linked to test case ID(s)
Linked to outcome in problem statement
Owner named (single person, not committee)
Reviewed in fortnightly practice forum if non-trivial
Status moved to Approved in register

Above the foundation · Context-driven rigour

Dial-ups by Context.

The minimum is the foundation. Above it, the BA dials up rigour based on the project's risk, complexity, and stakes. Read the context, choose what to add. The skill of the senior BA is knowing what.

BABOK Persp. · Five perspectives applied by context BAPM 3.1 · Plan BA Approach SA 6.3 · Assess Risks

Context A

Regulatory / Compliance

Formal compliance traceability matrix mapped to regulator clauses
Audit-ready evidence trail for every requirement
Regulator-language alignment in acceptance criteria
Formal sign-off cadence with named approvers per regulation
Change control with regulator-impact assessment

Context B

Multi-vendor / Integration-heavy

Integration architecture register: interface inventory, payloads, error handling
Interface contracts owned jointly with Solution Architect
Paired BA / SA working pattern at requirement level
Integration routing rules documented at requirement level
Integration readiness checklist per interface; go-live dependency map

Context C

High-change / High-impact

Paired BA / Change Manager working pattern
Prosci 10-aspect Change Impact Assessment per requirement cluster
Readiness gates aligned to phase boundaries
Pilot group working with real data pre go-live
Formal training and support approach signed off

Context D

Data-heavy / Migration-led

Data class inventory with retention rules
Source-to-target field mapping with transformation logic
Data quality rules and exception thresholds
Migration load plan: sample → UAT → production
Validation and sign-off checklist per load

Context E

Strategic / Decision-led

Decision Pack as primary artefact (BRD becomes a sub-output)
Formal Options Paper for major trade-offs with NPV / risk modelling
Constraints map: regulatory, financial, capability, time
Kill criteria committed before requirements written
Outcome traceability dashboard from day one

Context F

Tactical / Small

Compress 7 artefacts into a one-page brief + register
Single-paragraph problem statement
Decision rights named in 3 lines
Don't add weight that doesn't earn its place
Foundation still applies — but minimised, not abandoned

Calibration · By industry

Dial-ups by Industry.

Project context (§06) tells you what shifts when the work is regulatory or multi-vendor. Industry context tells you what shifts when the work is in this sector. Both apply at once — a regulatory project in healthcare uses the Regulatory dial-up and the Healthcare industry shape. Each card opens to show what changes for the BA, which artefacts get heavier, and the traps to watch for. Click Read to expand.

How to read these

Industry context is a layer on top of the dial-ups in §05, not a replacement for them. A regulatory project in healthcare uses both the Regulatory dial-up and the Healthcare industry shape. Where the two conflict, industry context wins — because the regulator, vocabulary, and evidence bar are non-negotiable.

Utilities

Regulated assets, slow change cycles, high audit weight.

Read ⌄

What changes for the BA

Regulators set the baseline — pricing submissions, network performance, customer obligations. Evidence has to survive a regulatory audit, sometimes years later. Stakeholder shape is heavy on operations, asset management, and engineering. Vocabulary: SAIDI / SAIFI, RAB, price determination, network tariff. Decisions move at the pace of regulatory cycles, not sprints.

Artefacts that get heavier

Decision Log Traceability Matrix AC&Q register Compliance (CMP) requirements

Common traps

Treating compliance as a tick-box instead of a design constraint. Letting the asset register become the requirements register (it's not). Underestimating change fatigue in operations teams who've already absorbed three modernisations.

Financial Services

Regulator-dense, control-heavy, evidence-as-currency.

Read ⌄

What changes for the BA

Multiple regulators (prudential, conduct, privacy, AML) each with their own evidence bar. The artefact is the audit defence. Three lines of defence baked into governance — first line operates, second line controls, third line audits. Vocabulary: BCBS, KYC, AML/CTF, capital, conduct risk, model risk. Stakeholders include risk & compliance functions with veto rights.

Artefacts that get heavier

Decision Log Stakeholder & Decision-rights Map CMP requirements SEC requirements Traceability

Common traps

Writing for the project, not for the auditor twelve months out. Letting "the policy already covers it" replace explicit requirements. Underestimating second-line review cycles — they take longer than the build.

Healthcare

Patient safety as the baseline. Clinical workflow as the language.

Read ⌄

What changes for the BA

Patient safety overrides convenience. Clinicians are not "users" — they are accountable professionals whose workflow disruption can cause harm. Privacy regimes are unforgiving (HIPAA, GDPR, state-level health acts). Vocabulary: HL7 / FHIR, ePMA, EMR, clinical pathways, MDT, governance committees. Stakeholder shape spans clinicians, allied health, IT, and clinical informatics.

Artefacts that get heavier

Service / Process Inventory Stakeholder Map SEC requirements CMP requirements Clinical safety case

Common traps

Designing for the IT team, not the clinical team. Treating EMR integrations as standard interfaces (they aren't — they're clinical workflow). Skipping clinical informatics governance because it slows things down.

Government

Public accountability, procurement gravity, ministerial visibility.

Read ⌄

What changes for the BA

The ultimate stakeholder is the public, mediated by ministers and oversight bodies. FOI exposure means every decision could become public. Procurement frameworks shape what's possible (panels, schemes, value-for-money tests). Vocabulary: portfolio, business case methodology (e.g. 5-case model), gateway reviews, machinery of government, citizen-facing services. Governance is layered and time-consuming — but the mandate is real.

Artefacts that get heavier

Problem Statement Decision Log Stakeholder Map Business case Benefits map

Common traps

Mistaking ministerial interest for executive sponsorship — they're not the same. Designing for "the agency" without naming the citizen outcome. Underestimating the time procurement and assurance gates will absorb.

Telco

Network-economics, BSS/OSS complexity, churn-pressured product velocity.

Read ⌄

What changes for the BA

The product is the network plus the service wrapped around it. BSS and OSS layers are ageing, deeply integrated, and politically owned. Customer expectations are shaped by digital-first competitors. Vocabulary: BSS / OSS, fulfilment, assurance, charging, MVNO, SDN/NFV, plan / offer / product hierarchy. Speed-to-market matters, but so does network reliability — the trade-off is constant.

Artefacts that get heavier

Service / Process Inventory INT requirements DAT requirements NFR requirements

Common traps

Treating product as software when it's really a network capability. Letting BSS / OSS owners design the customer experience. Promising digital-first velocity on top of a fulfilment stack that can't move that fast.

Retail

Margin-thin, peak-season-driven, omnichannel as the unit of work.

Read ⌄

What changes for the BA

Decisions are made fast and in commercial terms. The peak season (whichever it is for that retailer) is the immovable date. Omnichannel — store, web, app, marketplace, fulfilment — has to behave as one. Vocabulary: SKU, gross margin, basket, conversion, omnichannel, OMS / WMS, drop-ship, last mile. Stakeholders are commercial buyers, store ops, supply chain, and digital — each with different rhythms.

Artefacts that get heavier

Service / Process Inventory DAT requirements INT requirements RPT requirements

Common traps

Building for "the customer" without naming which channel's customer. Underestimating peak. Treating store ops as a downstream consumer of decisions made in head office.

Manufacturing

Physical operations, OT/IT convergence, safety as a hard constraint.

Read ⌄

What changes for the BA

The plant doesn't stop because the project is delivering. Operational technology (OT) lives by different rules than IT — uptime, safety, decades-long asset lives. Quality and safety regimes (ISO 9001, OSHA-equivalents) are non-negotiable. Vocabulary: MES, SCADA, PLC, OEE, takt time, lean, kaizen, safety case. Stakeholders include plant managers, engineers, and union representation.

Artefacts that get heavier

Service / Process Inventory SEC requirements NFR requirements CMP requirements Cutover plan

Common traps

Treating OT as IT. Letting digital teams design changes that touch the plant floor without engineering sign-off. Underestimating the cost of a planned outage versus an unplanned one.

Higher Education

Federated decision-making, semester rhythm, student lifecycle as the spine.

Read ⌄

What changes for the BA

Decision-making is genuinely federated — faculties have real autonomy and competing priorities. The semester is the immovable rhythm. The student lifecycle (recruit, enrol, learn, graduate, alumni) is the dominant value stream. Vocabulary: SIS, LMS, CRM, academic calendar, governance committees, faculty, professional staff. Stakeholders include academics, students, professional staff, and central executive — with very different incentives.

Artefacts that get heavier

Stakeholder & Decision-rights Map Service / Process Inventory Problem Statement Change impact

Common traps

Designing for central executive without faculty buy-in (it won't land). Treating academics as users. Trying to deliver into a teaching period instead of between them.

The standards in this guide travel across industries. The shape of the work doesn't. A senior BA reads the industry first, then chooses how to apply the standard. The relationship between practice and industry

How we do the work · Sequence + methods

Methods & Sequence.

The standard operating sequence is non-negotiable. Depth flexes; order does not. Beneath the sequence, choose elicitation methods by suitability — not by habit.

BABOK EC · Elicitation & Collaboration EC 4.1 · Prepare for Elicitation EC 4.2 · Conduct Elicitation EC 4.3 · Confirm Elicitation Results Tech · Workshops · Interviews · Observation · Document Analysis · Survey

Standard operating sequence

Frame problem

Map decisions

Define outcomes

Inventory current state

Classify & elicit

Trace to tests

Validate with users

Best when…

The structure exists and stakeholders need scaffolding. The pattern: stakeholders writing BA-quality requirements inside a system the BA designed, with AI tooling (e.g. Atlassian Rovo, Microsoft Copilot) embedded in the requirements stack. BABOK · Collaborative Games · Reviews — applied with AI tooling

AI-augmented practice · From prompts to agents

AI in the BA Practice.

AI changes what the BA produces, how fast, and increasingly who produces it. The MVP is a prompt library — versioned, run inside the requirements stack, with guardrails. But prompts are the foothold, not the destination. The maturity arc runs through prompts, into AI-assisted workflows, and onward to agentic systems that take action against the requirements artefacts themselves. This section starts where the practice can be useful tomorrow, and names what's coming next.

The maturity arc

Three layers of AI integration, in increasing order of leverage and risk. Most BA practices live at layer 1 today; the practices that compound move toward layer 3 deliberately, with guardrails at each step.

Layer 1 · MVP today

Generative AI prompts

Curated prompts run on demand by the BA inside the requirements stack — drafting, classifying, refining, auditing. The BA stays the operator and editor.

What it produces: draft requirements, classification proposals, decision packs, change-impact assessments.
BA role: prompt curator, output reviewer, source-of-truth keeper.
Risk profile: low — every output passes BA review before it enters the register.
This guide covers it: 12 prompts below, versioned and ready to use.

Layer 2 · Near-term

AI-assisted workflows

AI tooling embedded in the requirements lifecycle — running automatically at defined trigger points, with the BA approving outputs rather than driving each step.

Examples: auto-classification of new requirements on save · auto-traceability suggestions when a test case is created · drift detection across the register · workshop-notes-to-decision-log pipelines.
BA role: workflow designer, exception handler, quality bar.
Risk profile: medium — needs guardrails on what's auto-actioned vs. what's queued for review.
Practice readiness: requires the foundation (§01) to already be in place — workflows that operate on a messy register multiply mess.

Layer 3 · Emerging

Agentic AI

Autonomous agents that take action against requirements artefacts on their own — opening tickets, drafting test cases, running register audits, flagging decision drift, escalating broken assumptions. The BA shifts from operator to overseer.

Examples: register-audit agents that run nightly and report quality drift · decision-drift agents that compare current scope against decision log entries · adoption-watch agents that track post-implementation evidence.
BA role: defines what agents are allowed to do, sets the rules of engagement, audits agent behaviour, holds the line on decision integrity (§02).
Risk profile: high — autonomous action against shared artefacts needs strong governance, traceability of agent decisions, and clear kill-switches.
Practice readiness: meaningful only when the operating rhythm (§10) is mature enough to keep agents within the practice's quality bar.

The trap to avoid

Mid-project health check or pre-handover audit. Sets the agenda for the practice forum.

Prompt

Audit the following requirements register against a world-class BA practice foundation. Register: [PASTE OR LINK] Check and report on: 1. COMPLETENESS — Are all 9 requirement types represented where the project would warrant them? — Any obvious coverage gaps (e.g. no NFRs, no migration requirements for a data project)? 2. CLASSIFICATION HEALTH — Distribution of types — is one type over-used (e.g. everything labelled FUN)? — Misclassifications visible in samples? 3. TRACEABILITY — % of requirements with named source — % with linked test case — % with linked outcome — Orphan requirements (no epic/phase) 4. QUALITY BAR — Sample 10 requirements at random — score against the DoD checklist — Flag any compound requirements — Flag any unowned requirements 5. RISK CALL What are the top 3 risks this register represents to delivery? What should the BA fix this week? Output: a 1-page audit summary plus a sortable issue list (Severity · Item · Fix).

Layer 2 starters — AI-assisted workflows

Once the foundation (§01) is in place and the prompt library is in regular use, these are the workflows worth introducing first. Each runs automatically at a defined trigger point with the BA approving outputs rather than driving each step. None of these are production-grade out of the box — they're starter recipes that earn their keep with iteration. Build them in whatever orchestration layer the organisation has (Atlassian automation, Power Automate, Zapier, or a custom workflow engine).

Workflow · Auto-classify on save

Type classifier on new requirements

When a requirement is saved in Draft status, the workflow runs the §04 classification prompt against the description and proposes a type (FUN / DAT / INT / WFL / RPT / etc). The BA reviews on next refinement; if accepted, the type is locked.

Trigger: Requirement status changes to Draft, or description field updated.
Foundation needed: §04 Classification & Naming. Stable type definitions in place.
Risk control: AI proposal flagged as "AI-suggested," not auto-approved. BA confirms before the type leaves Draft.
Time saved: ~3 minutes per requirement on first classification pass.

Workflow · Workshop notes → decision log

Decision-log pipeline from raw notes

After a workshop, the BA drops the raw transcript or notes into a defined folder. The workflow runs the workshop-synthesis prompt, extracts decisions made / requirements candidates / open questions / actions, and proposes Decision Log entries for review.

Trigger: File added to /workshops/[date] folder, or workshop status moved to "Synthesised."
Foundation needed: Artefact 1 (Decision Log) in active use. Workshop note discipline (named attendees, date, agenda).
Risk control: All extracted decisions enter the Decision Log with status "Proposed — pending owner confirmation." Nothing binding until the named owner confirms.
Time saved: Half a day of post-workshop synthesis becomes 30 minutes of review.

Workflow · Traceability drift detection

Orphan-requirement alert

Weekly scan of the requirements register. The workflow flags requirements with no linked test case, no linked outcome, or no named owner — and posts an actionable list to the BA's queue for the next practice forum.

Trigger: Scheduled weekly (e.g. Friday close of business).
Foundation needed: Artefact 5 (Requirements Register) with traceability fields populated. Artefact 7 (RTM) in active use.
Risk control: Flag only — never auto-close orphans. The BA decides whether to fix, defer, or de-scope.
Time saved: Catches drift weekly instead of at quarterly review, when it's already structural.

Workflow · Ticket generation

Confluence row → Jira ticket

When a requirement moves to Approved status in the Confluence register, the workflow runs the Jira-ticket prompt and generates a structured ticket draft with all fields populated. The BA reviews, then submits to Jira.

Trigger: Requirement status changes from Refined to Approved.
Foundation needed: Requirements Register fields (description, AC, source, owner, outcome) populated. Naming convention applied.
Risk control: Generated as Jira draft, not posted live. BA submits after reviewing the description and AC.
Time saved: ~10 minutes per ticket on field population.

Layer 3 starters — Agentic AI

These are emerging — most enterprises aren't here yet, and a practice should only attempt them after Layers 1 and 2 are mature. Agents differ from workflows in that they decide what to do, not just execute on a trigger. The BA shifts from operator to overseer: setting the agent's scope, defining the rules of engagement, auditing what the agent did. Each starter agent below has a clear kill-switch and an audit trail by design — without those, don't deploy.

Agent · Register audit

Nightly quality-drift agent

Runs against the full requirements register overnight. Scores each requirement against the DoR/DoD checklist, flags compound conditions, unowned items, missing AC, classification inconsistencies. Posts a morning report to the BA channel.

Agent scope: Read-only. Never modifies the register.
Foundation needed: §05 DoR/DoD in active use. Stable register schema.
Kill-switch: Single toggle disables nightly run. Agent never escalates without BA input.
Audit trail: Every flag logged with the rule that triggered it, so the BA can correct false positives in the agent's training.

Agent · Decision drift

Scope-vs-decision watcher

Compares the current scope (in-flight requirements) against the Decision Log. When a new requirement appears that doesn't trace upward to a recorded decision, the agent flags it for the BA to either map back to an existing decision, open a new decision, or de-scope.

Agent scope: Read-only on Decision Log and Requirements Register. Flags only — never moves work.
Foundation needed: §02 Decision Integrity discipline. Live Decision Log with traceable IDs.
Kill-switch: Pause toggle. False-positive feedback loop required — the agent will over-flag without it.
Audit trail: Each flag captures the requirement, the missing decision link, and the BA's resolution.

Agent · Adoption watch

Post-implementation evidence agent

Six months after go-live, the agent compares the predicted operational change (from the Decision Pack and Problem Statement) against the actual evidence — usage data, ticket volumes, process times, manual workarounds. Produces a 30/60/90-day adoption status report.

Agent scope: Read across operational systems with explicit consent. Produces report, never acts on it.
Foundation needed: §02 Decision Integrity Phase 3 in active use. Outcome metrics defined in the Problem Statement (Artefact 2).
Kill-switch: Per-project opt-in only. Never runs on a project without the original sponsor's standing approval.
Audit trail: Source data, comparison method, and conclusion logged for every metric. The report is a draft; the BA finalises and signs.

A note on building these

None of these are install-and-run. Each one needs the foundation already in place (the artefacts in §01), the operating rhythm running (§10) to catch drift, and a deliberate iteration cycle to tune the false-positive rate. The BA's job in Layer 2 and 3 is design and oversight — defining what the workflow or agent is allowed to do, what evidence is good enough to act on, and what happens when the system gets it wrong. Build the smallest version that works, run it for a quarter, then expand.

How the practice runs · Cadence

The Operating Rhythm.

Standards stay alive only if the practice runs them. Four cadences carry the foundation — each owned by named people, each with a clear purpose. Without these, the library is just a page no one opens.

BABOK BAPM 3.5 · Identify BA Performance Improvements SE 8.5 · Recommend Actions UC 9 · Underlying Competencies — practice development

Fortnightly · 60 min

Practice forum

All BAs · led by senior BA

One BA presents one artefact, the practice critiques against the foundation. Where standards are taught, refined, and made public. Quality becomes a craft conversation, not an opinion contest.

Weekly · 30 min

BA-pair clinic

Senior + junior BA · per pilot

Pairing, not policing. Senior BAs teach the standard at the artefact during real work. The strongest mechanism for transferring craft.

Monthly · 90 min

Standards review

Two senior BAs + Lead BA

What's working in the foundation? What's drifting? What dial-up is being added on the ground? Updates flow into the next quarterly version.

Quarterly · half day

Library release

Whole practice + Head of Delivery

Foundation v[next], dial-ups updated, prompt library refreshed, outcome dashboard reviewed. The library is a living thing — never a 2026 artefact.

What gets reviewed in the practice forum

A rotating rota — not a recurring lecture. Every BA presents work in progress. Reviews are against the foundation, dial-ups, and DoD — never against personal preference.

Week 1

Problem statement walkthrough

Week 3

Requirement quality drill — DoD audit

Week 5

Decision log + four-tests check

Week 7

Traceability matrix tour

Week 9

Prompt library improvements

Week 11

Cross-project standards drift

A practice that doesn't review its own work in public is a team. A team that does, is a practice. Operating principle