Requirements Engineering
By putting the system in place, the stakeholders wrote really good requirements — without the BA.
The BA's job was to put the system in place. This guide is how.
Foundations
What requirements engineering is, what makes a requirement worth the name, and what this guide assumes about your context and tools.
What requirements engineering is — and why it matters
Most projects don't fail because the requirements are missing. They fail because the requirements are present but unworkable: compound, untestable, untraceable, orphaned, or held in someone's head.
A requirement is a contract between intent and delivery. When that contract is well-written, the project becomes scrutable: anyone can see what is being built, why, who owns it, and how we will know it is done.
Requirements engineering — as distinct from requirements gathering — is the discipline of producing requirements that hold up to that scrutiny. It is the part of business analysis where rigour earns its keep. It is also where the BA's job stops being clerical and starts being architectural: designing the structure inside which good requirements can be produced, validated, classified, and traced.
This guide describes that structure. It commits to a hierarchy, a naming convention, a set of work types, a traceability model, a workflow per type, and a chain of AI-augmented prompts that operate inside the structure. None of these are arbitrary. Each earns its place by closing a common failure mode: the orphan story, the untestable acceptance criterion, the change that nobody noticed, the rule that lived only in someone's email.
Read The Minimum Viable BA Practice first
This guide picks up where The Minimum Viable BA Practice (MVBA, Field Guide 1) ends. MVBA covers the work that must happen before requirements engineering opens — the problem statement, decision rights and stakeholder map, the four tests (clarity, ownership, resource reality, strategic intent), and the axe-sharpening discipline that distinguishes a BA from a documentation clerk.
This guide assumes that work is done. If the Problem Statement isn't agreed, if the Decision Log is empty, or if the Assumptions, Constraints & Open Questions register doesn't yet exist — go back to MVBA. Requirements engineering on top of a contested problem produces detailed answers to the wrong question.
Not sure whether that upstream work is solid? Run the Minimum Viable BA Practice Score — a 12-question diagnostic that tests exactly the foundations this guide depends on (system-of-work maturity, traceability, stakeholder co-production, AI governance).
What's covered here: a hierarchy, a set of work-type templates, naming conventions, traceability rules, workflows per type, quality gates, and the chain of AI-augmented prompts that operates inside all of it.
How this guide maps to BABOK and IEEE 29148
This guide operates primarily within BABOK's Requirements Analysis and Design Definition (RADD) knowledge area — specifying, modelling, verifying, validating, and defining requirements. It also draws on the Requirements Architecture practice within RADD: the hierarchy in §01 and the link types in §04 together are the requirements architecture for the programmes this guide describes. Requirements architecture, in BABOK's terms, defines the types of requirements, their relationships, the models used to represent them, and how they constrain solution and design options. The choices made here determine what can be traced, what can change, and what can be reported. They are architectural decisions, not administrative ones.
The foundational work that precedes requirements engineering — BA Planning & Monitoring, governance, information management, stakeholder engagement, BA approach selection — sits in MVBA (Field Guide 1). MVBA maps to BABOK's BA Planning & Monitoring knowledge area. BABOK treats BA Planning & Monitoring as foundational: it covers how the BA selects their approach, how requirements are stored and managed across the programme, how governance is structured, and how stakeholders are identified and engaged. All of that — the Decision Log, the Stakeholder Map, the four tests, the information management approach — is covered in MVBA. The two guides are designed to be read as a pair: MVBA sets up the conditions under which good requirements work is possible; this guide describes the requirements work itself.
On modelling: this guide anchors primarily to process models (BPs) and stakeholder requirement models (Requirements, Stories, Test Cases). BABOK's modelling toolkit is considerably broader — state transition models, use cases, decision models (DMN), data flow diagrams, scope/context diagrams, concept models, sequence diagrams. These are not covered in detail here; the §01 Requirements Architecture expandable lists them and explains when each becomes relevant. The AI runtime in §08 can read and synthesise additional model types alongside the standard sources — attach them to the Confluence working page as you would any other source artefact.
On terminology: this guide uses BRD throughout as the practical shorthand most enterprise programmes recognise. In strict BABOK / IEEE 29148 convention, the BRD (Business Requirements Document) is produced during early feasibility — it captures stakeholder needs and business context before detailed solution design. Once requirements are elaborated at system level, the resulting document is an SRS (System Requirements Specification) or SyRS. The structure in §12 is closer in substance to an SRS or elaborated requirements specification. If your programme uses SRS as its naming convention, the structure maps directly. The label is local to your programme; the discipline is the same.
On sequence: the chain in §08 is a recommended starting order, not a rigid one. BABOK deliberately avoids prescribing rigid sequences — it advocates practices, not protocols. The sequence here reflects what works in the context of the worked example: a large, integrated programme where Epic and Journey need to be agreed before phases can be decomposed. A smaller programme might start at BP level; a greenfield build might start at architecture constraints. Adapt to what you know and what's already been agreed in your context.
The four guarantees of a well-engineered requirement
Every requirement on a serious programme must satisfy these. Anything that fails one is not a requirement — it is a wish, an assumption, a process note, or a decision waiting to be made.
Atomic
One behaviour, one rule, one outcome. If it contains "and" or "or" in the behaviour clause, split it. Atomicity is what makes a requirement testable in isolation and changeable without collateral damage.
Testable
Stated in observable, verifiable terms. Acceptance criteria are written before the requirement is approved, not after. If you can't write a test for it, the requirement isn't ready — and may not be a requirement at all.
Traceable
Linked upward to the journey, process, decision, or constraint it serves; downward to the stories, tests, and configuration that deliver it. Traceability is not a documentation deliverable — it is the structure that makes change manageable.
Owned
A named business owner who can validate, approve, and answer for it. "The business" is not an owner. "The steering committee" is not an owner. A person is.
Assumptions & constraints
This guide commits to specific tools and a specific delivery context. The discipline transfers to other stacks and other contexts — but the specific examples are anchored to a real setup. Where your context differs, the principles still apply; the artefact names and tools change.
Where this guide stands
Why this stack: Jira ships with prebuilt AI work-breakdown agents, Confluence ships with template scaffolds, and Rovo can read across both natively — so a lot of what this guide describes is already half-built when you turn it on.
Notion + Linear + Claude (with Notion + Linear MCP connectors) · SharePoint Pages + Azure DevOps + Microsoft Copilot · Google Docs + Asana/Linear + Gemini · Obsidian + GitHub Issues + Claude/ChatGPT enterprise.
Each step in §08 names the alternative-stack equivalent. The names change, the chain doesn't.
The Architecture
The structural decisions that determine what your requirements practice can do — and what it can never do without rebuilding.
Once your hierarchy, work-types, naming, and traceability rules are set, almost everything downstream is automatic. Get these wrong and you spend the next two years patching a leaky abstraction.
The hierarchy
A six-level decomposition that takes a business intent and breaks it down to a verifiable test, without losing the line of sight between any two adjacent layers. In BABOK terms, this hierarchy is the requirements architecture for a programme — the structural choice that determines what can be traced, what can change, and what can be reported. The expandable on each level below shows how it aligns to BABOK and IEEE 29148.
The hierarchy is the single most important decision in setting up a requirements practice. It determines what can be planned, traced, reported, and changed. Get this wrong and the rest of the discipline is patching a leaky abstraction. Get it right and the work organises itself.
The model below uses a Lifecycle Value Stream at the top (e.g. Hire-to-Retire, Order-to-Cash, Plan-to-Build), with progressive decomposition through value streams (L1), sub-processes (L2), and standard activities (L3) — then crossing into the BA's working artefacts: journeys, processes, requirements, stories, and tests.
L0
Lifecycle Value StreamThe end-to-end business outcome
e.g. Hire-to-Retire, Order-to-Cash. Bounds the programme. One per programme.
▾
Verb-to-verb framing of the end-to-end business outcome the programme exists to serve. Names what the organisation does, not what software does.
Above: nothing — L0 bounds the programme. Below: 3–7 Value Streams (L1) that decompose it.
BABOK Strategy Analysis (Knowledge Area). Maps to Business Architecture perspective.
L1
Value StreamA major flow within the lifecycle
e.g. Hire-to-Onboard, Time-to-Pay. Owned by a business domain. Reportable.
▾
A coherent flow inside the L0 that produces a recognisable business value. Owned by a single business domain. Survives reorganisation because it describes what the business does, not how it's structured.
Above: the L0 lifecycle. Below: 5–12 Sub-Process Groups (L2). Sideways: the User Journey at this level — a Hire-to-Onboard value stream typically has 3–5 user journeys living inside it (e.g. New Starter, Cohort Intake, Conversion to Permanent).
BABOK RADD (Requirements Analysis & Design Definition). Technique: Functional Decomposition. The L1 layer is where most enterprise architecture practices anchor reporting and operating models.
L2
Sub-Process GroupA stable grouping inside a value stream
e.g. Position & Org Management, Onboarding Tasks, Time Capture. Survives reorganisation.
▾
A grouping of related processes that share a domain object (position, requisition, timesheet, payroll run). Stable across years — a reorg doesn't change what time capture is.
Above: the L1 value stream. Below: 4–10 Standard Activities (L3) per group. Sideways: the Business Process (BP) artefact corresponds roughly to L2 — but a BP carries the variations and exceptions, where the L2 is the platonic ideal.
BABOK Process Modelling. Technique: Decision Modelling for rule-heavy groups. This is the level at which rules and exceptions get agreed — most "the policy says…" conversations happen here.
L3
Standard ActivityA step inside a sub-process
e.g. Create requisition, Capture personal/tax/bank details, Approve timesheet. Carries variation.
▾
A single executable step within a sub-process group. Verb-first. Variations (by employment type, classification, location) hang off it.
Above: the L2 sub-process group. Below: Requirements. Each L3 activity typically produces 3–8 requirements when the variations are unpacked.
BABOK Process Modelling (Technique). IEEE 29148 §6 Stakeholder Requirements — L3 is where stakeholder requirements live as observable behaviours.
JNY
User JourneyEnd-to-end experience across phases
The BA's working artefact. Crosses L1–L3 boundaries. Has variations and pain points.
▾
A specific named experience an actor goes through end-to-end, organised by phases that the user themselves would recognise. Crosses L2/L3 boundaries — a single journey can touch multiple sub-process groups.
Above: the parent Epic and L1 value stream. Below: 3–6 Business Processes (BP) — the journey phases. Sideways: a journey may share BPs with another journey (e.g. New Starter and Cohort Intake both use the same Preboarding BP, with different variations).
BABOK Service Design / User Journey Mapping. IEEE 29148 §5 Concept of Operations — the journey is the operating concept.
BP
Business ProcessA phase or workflow inside a journey
Roles, inputs, outputs, exceptions. The unit at which rules are agreed.
▾
A phase or workflow inside a journey. Has a verb-phrase name. Owns its own roles (RACI), inputs, outputs, exceptions, and embedded controls. The level at which "how do we actually do this?" gets answered in writing.
Above: the parent User Journey. Below: 5–15 Requirements per BP, plus Decisions and Business Rules that govern the process. Sideways: may share Rules with other BPs (e.g. Higher Duties Eligibility rule applies to multiple BPs across journeys).
BABOK Process Modelling. Technique: Process Analysis. BPMN-compatible if you want a notation.
REQ
RequirementOne atomic behaviour or rule
Testable. Owned. Traceable. The contract between intent and delivery.
▾
One atomic behaviour or rule. Format: "When <trigger>, then <outcome>" or "The system must <behaviour> when <condition>". Carries a type (Functional, Integration, Data, Workflow, Reporting, Security, NFR, Compliance, Business Rule).
Above: the parent BP and journey. Below: 1–3 User Stories that implement it, 1+ Test Cases that prove it. Linked sideways to Decisions, Rules, and Risks.
BABOK RADD: Specify and Model Requirements. IEEE 29148 §7 System Requirements. The contract layer.
US
User StoryA build-ready slice of work
Must link to one or more requirements. Has acceptance criteria.
▾
A build-ready slice of work. "As a <user>, I want <goal> so that <benefit>." Must link to 1–3 Requirements. Has Given/When/Then acceptance criteria, including at least one exception path.
Above: 1–3 parent Requirements (mandatory link). Below: Test Cases that prove the AC. Sideways: may link to a Decision that shaped it.
BABOK Solution Evaluation. Agile technique: User Story with INVEST criteria.
TC
Test CaseThe evidence that a requirement holds
Verifies a requirement and/or story. Without this, "done" is opinion.
▾
A verifiable test that proves a requirement or story holds. Pre-conditions, numbered steps, expected outcome, evidence type. Status: Draft → Ready → Executed → Passed / Failed.
Above: 1+ Requirements (mandatory) and a Story. Below: bottom of the hierarchy. Sideways: linked from any Bug that fails this test.
BABOK Verification. IEEE 29148 §9 Validation & Verification. ISTQB acceptance test specification.
Guardrails
L1 is the value stream — only. Don't let project labels creep up to L1. Value streams outlive projects.
L2 is stable, L3 carries variation. If something changes more than once a year, it's probably L3, not L2.
The BA layer (JNY · BP · REQ · US · TC) is where the work lives. The L0–L3 framing exists to make sure the work serves the business architecture, not the project plan.
Requirements architecture — how this hierarchy fits the BABOK model
▾
In BABOK terms, the hierarchy on this page is the requirements architecture for a programme. Requirements architecture is the RADD practice of defining the types of requirements, their relationships to each other, and the models used to represent them. The choices made here — Epic → Journey → BP → Requirement → Story → Test Case — are the architecture decisions. They determine what can be traced, what can change, and what can be reported.
BABOK makes an important point that this guide endorses: solution and design options are ultimately shaped by the requirements architecture. The model you choose constrains what solutions are visible. A process-model-only view makes it harder to see data architecture problems. A use-case-only view makes it harder to see process complexity. The hierarchy here is a considered choice for enterprise integration programmes — not a universal prescription. If your programme context demands a different dominant model, the architecture should reflect that.
Model types used in this guide
This guide anchors primarily to process models (Business Process artefacts) and stakeholder requirement models (Requirements, Stories, Test Cases). BABOK's full modelling toolkit is broader. Depending on your programme context, you may also need:
- State transition models — for objects with lifecycle complexity (e.g. an employment record moving through Draft → Pending → Active → Terminated). Essential for integration requirements where event triggers depend on status transitions.
- Use case models — for actor-system interaction, particularly useful when the scope involves self-service portals, mobile applications, or multi-actor workflows where process models get unwieldy.
- Decision models (DMN) — for rule-heavy requirements where conditions, outcomes, and exceptions can be tabulated. Pairs naturally with the Decision work type (DEC) — the DEC ticket records the decision; the DMN table shows the logic.
- Data flow and entity models — for data migration, integration, and master-data requirements where the structure of what moves matters as much as the behaviour.
- Scope models — context diagrams, ecosystem maps — for defining system boundaries when the integration surface is complex (as it was in the worked example, where 40 systems were in scope).
- Sequence diagrams — for time-ordered interactions between systems or actors, particularly where synchronous/asynchronous behaviour, timing, and error handling are part of the requirement.
None of these are covered in detail here. For a programme that needs state transition diagrams alongside process models, the right place to store them is the same Confluence working page where the prompts run — the AI runtime in §08 can read and synthesise them alongside the standard sources.
Requirements relationships and exceptions
The guide emphasises tracing requirements upward to decisions that authorise them. In practice, not every requirement traces cleanly to a stakeholder decision. Legitimate exceptions include:
- Platform mandates — requirements driven by the vendor platform's behaviour, constraints, or default configuration. Not a stakeholder decision; a platform fact.
- Technical debt and architectural constraints — requirements to address existing technical debt or comply with architecture decisions made before the programme began. These trace to a constraint register or architecture decision record, not a DEC ticket.
- Regulatory and compliance requirements — mandatory behaviours imposed by regulation, award interpretation, or policy. These trace to the legislative or policy source, not to an internal decision.
For these, the guidance is: classify the source honestly (constraint, compliance, platform mandate) and link the requirement to the right source artefact — even if that artefact is external to the Jira/Confluence environment. The goal of traceability is to be able to answer "why does this requirement exist?" — not to force every requirement through the same authorisation pattern.
Work types & templates
A complete requirements practice needs more than just requirements. These twelve work types — each with its template, prompts, and quality gates — form the operating set. Click any to open.
The discipline of requirements engineering depends on a small, named set of artefact types and the relationships between them. Twelve is the right number: any fewer collapses critical distinctions (a rule is not a requirement; a decision is not a journey), any more produces sprawl.
Click each work type to see the template structure, prompts, and quality gates.
1
EPICEpic — Outcome container
Use for outcomes that span multiple stories, tasks, or process changes. One epic = one measurable outcome.
▾
Naming convention
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | Stream and outcome, no implementation detail. | Stream 2 | New Starter — Ready to Work |
| Workstream | The programme workstream the epic belongs to. | Service Design and User Journey |
| Outcome statement | What is measurably true when complete. KPI / cycle time / error rate / adoption number. "Done" is not an outcome. | By Day 1, 95% of new starters have full system access, equipment, and a manager-issued readiness checklist — without manual chasing. |
| Problem statement | Current state, impact (who, how often, what cost), evidence. Not "we don't have system X." | Day 1 access failures average 18% of new starters; PP&C spends ~4 hours per starter chasing IT, Facilities, Payroll. Evidence: ITSM incident report 2025-Q3. |
| In scope | Capabilities, journeys, processes, integrations included. | Offer & Accept · Preboarding · Day 1 readiness · Week 1 induction · Identity provisioning trigger |
| Out of scope | Explicitly excluded — even if requested. | Recruitment (covered by R2H epic); probation outcomes (covered by O2P epic). |
| Constraints | Policy, IR/award, compliance, technical, delivery. | Award interpretation locked to current EBA; payroll cutover dates immovable; SoD rules apply. |
| Primary users | Day-to-day users of the capability. | Hiring managers · new starters · PP&C team · IT Service Desk · Facilities |
| Approvers | Named decision-makers who can sign off. | HR Domain Lead (process); CIO delegate (integration); Head of Payroll (financial). |
| Dependencies | Upstream prerequisites and downstream impacts. | Upstream: recruitment system feed. Downstream: payroll trigger, AD provisioning, LMS enrolment. |
| Acceptance criteria | Outcome-based, quality-based, operational. Verifiable by someone outside the team. | AC1: Day 1 access failures <5%. AC2: Manager checklist auto-issued ≥24h before start date. AC3: Audit trail captures every status change. |
Definition of done
- Scope delivered and accepted against acceptance criteria
- Documentation updated (process, SOPs, knowledge base)
- Training artefacts created and linked
- Test evidence captured (links to test cases and results)
- Change impacts assessed (roles, permissions, data, integrations)
- Handover complete (support model, BAU ownership, monitoring)
2
JNYUser Journey — End-to-end blueprint
A single end-to-end scenario (e.g. "New starter", "Change in hours") with phases, variations, and pain points.
▾
Naming convention
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | Stream, lifecycle stage, scenario. | JNY | Hire | New Starter — Ready to Work |
| Trigger / entry | The event or state that starts the journey. | Offer accepted and starter record created in HR system of record. |
| End condition | What "done" looks like for the journey. | Starter logs in and accesses systems on Day 1; fully inducted by end of Week 1 with completion criteria recorded. |
| Primary actors | The roles directly performing or experiencing the journey. | New starter · hiring manager · PP&C / HR Ops · IT Service Desk · Facilities · Payroll |
| Systems involved | Systems the actors touch or that run in the background. | Core HR · case/workflow tool · identity provisioning · payroll · facilities access |
| Phases (high level) | 3–5 phases. Each becomes a Business Process artefact. | 1. Offer & Accept · 2. Preboarding · 3. Day One · 4. Week One |
| Variations | Where the journey forks — by user type, award/EA, location, employment type, approval pathway. Happy path vs exceptions. This is where the BA earns the work. | Remote vs onsite · cohort intake vs individual hire · start date change · conditional offer · no-show / delayed start |
| Pain points (with evidence) | Each pain point carries its own evidence and the opportunity it implies. | Start-date and position data quality issues cascade into Day 1 access and payroll failures. Evidence: Day 1 access tickets, payroll exceptions, manual chasing. Opportunity: mandatory-data gate + automated rescheduling + audit log. |
| Source artefact(s) | Where the journey lives — Miro board, PDF, SharePoint, workshop notes. | [Journey blueprint in SharePoint] · [Workshop recording + transcript] · [Current-state DOCX] |
| Derived requirements (initial) | First-pass requirement IDs the journey gives rise to. Filled in as Prompt 04 runs. | SJ2.Ph1.Req01 · SJ2.Ph1.Req02 · SJ2.Ph2.Req01 … |
Definition of done
- Journey artefact attached or linked
- Variations captured
- Pain points and opportunities captured (each with evidence)
- Requirements created and linked — or explicitly called out as next step
3
BPBusiness Process — How we work
An agreed current or future-state process, including roles, inputs/outputs, and exceptions.
▾
Naming convention
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | Stream, phase or domain, process verb phrase. | BP | Preboarding | Validate starter data |
| Parent journey | The User Journey this process belongs to. | JNY | Hire | New Starter — Ready to Work |
| Objective | Outcome the process achieves; problem it solves or control it enforces. | Ensure mandatory starter data is complete and consistent before downstream orchestration begins, preventing Day 1 access and payroll failures. |
| In scope | What this process covers. | Validation of mandatory fields; routing of incomplete records to PP&C; audit logging of all data corrections. |
| Out of scope | What this process does not cover. | Initial data entry (covered by Offer & Accept); identity provisioning (downstream BP). |
| Process flow | High-level numbered steps. Link a diagram if used. | 1. System checks mandatory fields → 2. If complete, trigger orchestration → 3. If incomplete, route to PP&C with named fields → 4. PP&C corrects, re-submits → 5. Audit log entry. |
| Roles (RACI) | RACI where handoffs are non-trivial. | R: PP&C analyst · A: HR Domain Lead · C: Hiring manager · I: IT, Payroll |
| Inputs | Data required to start the process. | Starter record; mandatory field definitions; current employment type rules. |
| Outputs | Record, approval, or artefact produced. | Validated starter record (status = Ready); audit log entry; routing notification if incomplete. |
| Exceptions | Each with handling rule and owner. | Mandatory field blank → route to PP&C, SLA 4h, owner: PP&C analyst. Conflicting position ID → escalate to HR Domain Lead. |
| Controls / compliance | Audit, SoD, regulatory controls embedded. | All field corrections audit-logged with user, timestamp, old/new value. SoD: initiator cannot also approve. |
Acceptance criteria for the process artefact itself
- Process can be followed end-to-end without undocumented decisions
- Roles and handoffs are clear
- Exceptions and controls are captured
4
REQRequirement — The contract
A single atomic requirement that can be tested and traced to one or more stories and test cases.
▾
Naming convention
Statement formats — pick one, stay consistent
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | ID + atomic behaviour statement. | SJ2.Ph2.Req03 | Start date change cascades to tasks & provisioning |
| Requirement type | Functional · Integration · Data · Workflow · Reporting · Security · Non-functional · Compliance · Business Rule. Multiple types allowed. | Functional + Integration |
| MoSCoW priority | Must / Should / Could / Won't (this release). | Must |
| Value Stream (L1) | Mapped from the Value Stream → Process Mapping reference. | Hire-to-Onboard (H2O) |
| Workstream | Programme workstream owning delivery. | Core HR Implementation |
| Phase (BP) | Parent business process from the journey breakdown. | BP | Preboarding | Validate starter data |
| Business need | Who needs it, why, what risk/cost/experience issue it addresses. | PP&C and IT spend ~4h/week reconciling start-date changes manually. Without cascading update, Day 1 access fails for ~15% of starters whose start date moves. |
| Description | Atomic, testable statement. No solution bias unless constraint requires. | When a starter's start date is changed in the HR system of record, all downstream tasks (provisioning, induction, manager checklists) must be rescheduled to the new effective date, and the change must be recorded in an audit log with timestamp and changer. |
| Acceptance criteria | Numbered. At least one measurable / observable. | 1. Given an approved starter with start date D, when the date is changed to D+5, then all linked orchestration tasks shift their due date by +5 business days. 2. When an auditor queries the audit log, the record shows old date, new date, changer, and timestamp. |
| Impacted stakeholders | Multi-select. Used for impact reporting. | Hiring managers · PP&C · IT Service Desk · Payroll · Facilities |
| Systems impacted | Multi-select. Used for integration planning. | Core HR · ServiceNow · AD · Payroll |
| Source | Where the requirement comes from. An unsourced requirement is a wish. | Workshop 2026-03-12 (link); HR Domain Lead validated; current-state DOCX p.14 |
| Dependencies / constraints | What blocks it; what bounds the solution. | Dep: Core HR effective-dating in place. Constraint: payroll cutover dates immovable. |
| Traceability & notes | Parent journey / process links; child stories and test cases. | Journey: JNY | Hire | New Starter. Stories: US12, US14. Test cases: TC09, TC10. |
| Status | Draft → Validated → Approved → Implemented → Tested → Closed. | Approved |
| Owner | Named business owner (a person, not a committee). | HR Domain Lead |
Atomicity check — before saving
- Single behaviour or rule
- Clear condition and outcome
- No solution bias — unless the constraint requires it
- Testable with objective evidence
Definition of ready
- Atomic statement · business need captured · source linked
- ≥1 measurable / observable acceptance criterion drafted
- Dependencies and constraints captured (or "none known")
- Open questions listed (or "none")
- Stakeholders identified for validation / approval
- Traceability started — source linked, intended story link(s) noted
Definition of done
- Approved by named owner (or explicitly marked not required)
- Linked implementation work exists (stories / tasks)
- Linked test case exists (or testing approach documented)
5
RULEBusiness Rule — When · Then · Else
A single rule of behaviour. Validation, calculation, derivation, defaulting, eligibility, routing, approval, compliance.
▾
Why rules deserve their own type
Rules are not requirements — though they often look like them. A requirement names a behaviour the system must support; a rule names a constraint on that behaviour. Conflating the two causes the rule to disappear into a story's acceptance criteria, where it becomes invisible to compliance, untestable as a standalone, and impossible to find next time the policy changes.
Keep rules atomic. If there are multiple conditions or outcomes, split them or use child rules.
Naming convention
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | Rule ID + plain-English statement. | RULE-PAY-Higher-Duties-Eligibility | Higher duties pay applies when an employee covers a role ≥1 classification level above their substantive role for ≥5 consecutive working days. |
| Rule type | Validation · Calculation · Derivation · Defaulting · Eligibility · Routing · Approval · Compliance. | Eligibility |
| When (trigger) | The condition that activates the rule. | When a higher-duties acting assignment is submitted with duration ≥5 working days and target classification level > substantive level. |
| Then (outcome) | The action or outcome when the rule is satisfied. | Then the employee receives the difference between substantive and acting classification pay, calculated daily, paid in arrears via standard payroll cycle. |
| Else (if applicable) | What happens when the rule is not satisfied — including escalation or exception handling. | Else assignments <5 days are recorded as informal acting (no pay impact); cross-classification assignments at same level get no uplift. |
| Inputs | Fields / data the rule reads. | Substantive position; acting position; classification matrix; assignment start/end dates; working calendar. |
| Outputs | Fields / data the rule produces or updates. | Higher-duties pay flag; daily uplift amount; effective-dated pay record entry. |
| Reference data | Lookup lists, rates, thresholds. | Classification matrix v2026.1; current EBA pay rates table; working calendar including public holidays. |
| Examples | Worked input → expected outcome rows. | In: Level 4 employee acting at Level 5 for 7 working days → Out: uplift × 7 days. In: Level 4 acting at Level 4 for 10 days → Out: no uplift (same level). |
| Source | Policy, legislation, SME, legacy system. | EBA 2024 cl. 18.4; HR Policy HR-PAY-007 (link); validated by Head of Payroll 2026-03-04. |
| Owner | Named business owner. | Head of Payroll |
| Lifecycle | Proposed → Agreed → Implemented → Retired. | Agreed |
| Related requirements | Requirements that depend on or implement this rule. | SJ1.Ph2.Req03 · SJ1.Ph2.Req04 |
What good looks like
- Examples table with input → expected outcome
- Exceptions and edge cases listed
- Test evidence linked
- Approver and date agreed recorded
- Related requirements / stories linked
6
USUser Story — A deliverable slice
A build-ready slice of work that implements one or more requirements. Must link upward.
▾
Naming convention
The traceability rule
A user story cannot move to "Up next" unless it links to at least one requirement. This is the workflow rule a requirements practice relies on most heavily. It prevents the orphan story — work that no one can trace to a stated need — from quietly entering delivery without accountability.
On exceptions. Some work doesn't derive from a business decision in the usual sense: platform mandates (vendor end-of-life forcing a migration), technical debt obligations (a security fix that has no business sponsor), architecture constraints (a load-bearing decision made years ago that now requires conforming changes). The rule still holds — but the upward link is to a Constraint, Mandate, or Decision artefact rather than a requirement. The point is not the type of parent; the point is that nothing in delivery is invisible. An architecture constraint that lives only in a developer's head is just as invisible as a missing requirement.
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | ID + user need. | UJ2.Ph3.US05 | Manager receives single Day 1 readiness checklist |
| Linked requirements | 1–3 requirement IDs. Must be populated before "Up next". | SJ2.Ph2.Req03 · SJ2.Ph3.Req01 |
| Parent journey / phase | Where the story sits in the journey. | JNY | Hire | New Starter → BP | Day One |
| User story | As-a / I-want / So-that. | As a hiring manager, I want a single Day 1 readiness checklist auto-issued 24h before my starter's start date, so that I know what's done and what's still needed without chasing IT or Facilities. |
| Context | Background, assumptions, out of scope. | Currently managers chase status across 3 channels (email, ServiceNow, Teams). Out of scope: post-Week-1 induction checklist. |
| Acceptance criteria | ≥2 Given/When/Then scenarios. ≥1 exception or validation rule. | 1. Given a starter with start date D and complete provisioning at D-1, when D-1 09:00 passes, then manager receives consolidated checklist via email + Teams. 2. Given incomplete provisioning at D-1, then checklist shows red items with owner/SLA. 3. Validation: checklist not issued if start date is in the past. |
| Non-functional | Performance, security, audit, accessibility — only where they apply. | Checklist generation <5s. Audit log entry on every send. WCAG AA for screen-reader managers. |
| Dependencies | Stated or "none known". | Dep: identity-provisioning status feed (Story US04) must be in place first. |
| Test approach | Test case to be created/updated, or stated why not. | TC07 to be drafted by test lead; covers happy path + exception path + validation rule. |
Definition of ready
- Linked requirement exists and is understood
- Story statement complete (user, goal, benefit)
- Context captured (background, assumptions, out of scope)
- ≥2 Given/When/Then scenarios drafted, including 1 exception
- Dependencies identified (or "none known")
- Non-functional considerations addressed where relevant
- Test approach clear (test case to be created/updated, or stated why not)
Definition of done
- Acceptance criteria met and evidenced
- Test case created or updated
- Linked requirement kept current
- Documentation updated if behaviour changes
7
TSKTask — Work that isn't a story
Analysis, configuration, documentation, or data work that supports a story, requirement, or milestone — but isn't user-facing.
▾
Tasks exist because not every piece of work is a user-facing slice. A configuration step, a data clean-up, a vendor query, a workshop write-up — these need to be planned, owned, and closed, but they don't merit the structure of a story. Without a Task type, this work either gets shoehorned into stories (polluting them) or vanishes off the plan.
Naming convention
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | Domain + discrete piece of work, verb phrase preferred. | TSK | New Starter | Migrate legacy starter records to Core HR |
| Supports | The requirement, story, or milestone this task enables. | SJ2.Ph1.Req02 (mandatory starter data gate); US12. |
| Description | What needs to be done, why, and the boundary of the work. | Extract starter records (status = Active, hire date ≥ 2025-01-01) from legacy SharePoint list; transform per mapping spec; load to Core HR. Exclude superseded duplicates. |
| Owner | Named person responsible — not "the team". | Data Migration Lead |
| Definition of done | Concrete completion criteria, observable. | All 412 in-scope records loaded; reconciliation report run; PP&C signoff on 5% sample. |
| Dependencies | Anything that blocks the task. "None known" if so. | Core HR sandbox configured; mapping spec v1.2 approved. |
| Effort estimate | Optional. Hours or t-shirt size if used on the project. | M (3–5 days) |
| Status | To do · In progress · Blocked · Done. | In progress |
8
TCTest Case — The evidence
A verifiable test for a requirement and/or story. Without one, "done" is opinion.
▾
Naming convention
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | TC ID + what is being verified, in business terms. | TC-NS-09 | Start date change cascades to downstream tasks within 5 minutes |
| Linked requirement(s) | The requirements this case proves. ≥1 required. | SJ2.Ph2.Req03 · SJ2.Ph2.Req04 |
| Linked story | The user story whose AC this case validates. | UJ2.Ph3.US05 |
| Pre-conditions | State the system must be in before the test begins. | Starter record exists in Core HR with status = Active. Original start date D set. Provisioning tasks generated and scheduled. |
| Steps | Numbered, executable actions. | 1. Open starter record. 2. Change start date from D to D+5. 3. Save. 4. Wait 5 minutes. 5. Query orchestration tasks for this starter. |
| Expected outcome | Observable, objective result. | All linked orchestration tasks show due date shifted by +5 business days. Audit log entry created with old date, new date, changer, timestamp. |
| Evidence type | What gets captured as proof. | Screenshot of task list before/after; audit log export row. |
| Test type | Functional · Integration · UAT · Regression · Performance. | Functional + Integration |
| Status | Draft → Ready → Executed → Passed / Failed. | Passed |
| Owner | Named test author / executor. | QA Lead |
Workflow
Draft → Ready → Executed → Passed or Failed
9
BUGBug — A defect found
A defect found during build, configuration, integration, or testing. Linked to the failing test or story.
▾
Bugs link back to the failing Test Case (Relates to) and to the Story whose acceptance criteria are not met (Blocks only if it truly prevents completion). Where a bug reveals that a requirement is mis-specified — not just under-built — it links to the Requirement with Relates to, and the requirement is reopened or amended via the change process.
Naming convention
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | Domain + observable symptom — not the suspected cause. | BUG | New Starter | Audit log missing entry when start date changed via API |
| Relates to (Test Case) | The failing test case. | TC-NS-09 |
| Relates to (Story / Requirement) | The story whose AC fails; the requirement if mis-specified. | UJ2.Ph3.US05 · (if mis-spec: SJ2.Ph2.Req03) |
| Steps to reproduce | Numbered, runnable from a clean state. | 1. POST /starters/{id}/change-date with new date. 2. Query audit log. 3. Observe no entry created. |
| Actual vs expected | Both stated explicitly. | Actual: no audit log entry. Expected: entry with old date, new date, changer, timestamp. |
| Environment | Where it was found. | SIT, Core HR build 2026.04.02, API v1. |
| Severity | Critical · High · Medium · Low. Based on impact, not anger. | High — audit compliance gap. |
| Priority | Fix now · Next sprint · Backlog. | Fix now |
| Owner | Named developer / config owner. | Integration Engineer |
| Status | Open → In progress → Fixed → Verified → Closed. | Verified |
10
DECDecision — An agreed answer
Captures what was decided, why, by whom, and what it changes. The decision log is the memory of the programme.
▾
Naming convention
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | ID + decision statement. | DEC-NS-Trigger-System | Core HR is the source-of-truth trigger for new-starter onboarding orchestration. |
| Context | The problem or open question that prompted the decision. | Currently three systems can independently trigger onboarding tasks (Recruitment, ITSM, Core HR). Result: duplicate provisioning, race conditions, no single audit trail. |
| Options considered | At minimum two. Pros and cons. Link to any supporting analysis. | A) Core HR triggers orchestration after mandatory data gate. B) Manager-initiated via ITSM form. C) Recruitment system trigger on offer acceptance. Pros/cons in [linked analysis page]. |
| Decision | The statement of what was decided. | Option A — Core HR triggers orchestration once the mandatory data gate is satisfied. All other systems become consumers. |
| Rationale | Why this option over the others. | Single source of truth for employee record; eliminates dual-key entry; aligns with payroll trigger and audit needs; simplifies role-based provisioning. |
| Decision owner | Named person accountable for the decision. | HR Domain Lead |
| Stakeholders consulted | People whose input shaped the decision. | Head of Payroll · Head of IT Operations · PP&C Lead · Audit & Compliance |
| Date decided | When the decision was finalised. | 2026-03-18 |
| Impacts | Where this decision lands — process, system, data, training, change. | Process: BP redesign for Preboarding orchestration. System: new event from Core HR to ITSM. Training: managers learn new trigger flow. Change: ITSM form sunset. |
| Follow-up actions | Specific actions with owners and due dates. | 1. Update BP "Validate starter data" (PP&C Lead, by 2026-04-01). 2. Notify ITSM team to plan form retirement (IT Ops, by 2026-04-15). |
| Linked requirements | Requirements made possible or constrained by this decision. | SJ2.Ph2.Req01 · SJ2.Ph2.Req02 · SJ2.Ph2.Req03 |
| Status | Proposed → Agreed → Active → Superseded. | Agreed |
11
RSKRisk — A named threat
A risk with impact, likelihood, owner, and mitigation. Linked to the work it threatens.
▾
A risk in the requirements layer is not a generic project risk — it's a risk that, if it materialises, makes a requirement undeliverable, untestable, or invalid. Examples: vendor cannot expose an API the integration requires; policy interpretation contested; data quality in legacy below threshold.
Naming convention
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | RSK ID + concise threat statement. | RSK-NS-03 | Legacy position data quality below threshold prevents Day 1 access provisioning |
| Description | What could happen, why, and what the trigger conditions look like. | ~12% of legacy position records are missing approver, cost centre, or classification level. If carried over at cutover, Core HR cannot generate downstream provisioning tasks for affected starters. |
| Threatens | The Epic, journey, BP, or requirement at risk. | Epic: New Starter — Ready to Work. Requirements: SJ2.Ph1.Req02 · SJ2.Ph2.Req01. |
| Impact | What happens if it materialises. Rate Low / Medium / High. | High — Day 1 access fails for ~50 starters in first month post-cutover; rework cost ~$45k. |
| Likelihood | Probability of materialising. Low / Medium / High. | High — data quality already evidenced in current state. |
| Inherent rating | Impact × likelihood before mitigation. | Critical |
| Mitigation | What is being done. Concrete actions with owners. | Data remediation sprint pre-cutover (PP&C Lead). Mandatory-data gate built into BP Validate starter data (BA). Cutover-day exception process (Change Lead). |
| Residual rating | Impact × likelihood after mitigation. | Medium |
| Owner | Named person accountable for managing the risk. | HR Domain Lead |
| Status | Open · Mitigating · Closed · Materialised. | Mitigating |
12
TRNTraining Artefact — For adoption
Guides, job aids, SOPs, runbooks, comms. Traced back to journeys and requirements so adoption survives change.
▾
Training is part of the requirements practice, not an afterthought. Each training artefact is tied to the journey it supports and the requirements it teaches. When a requirement changes after go-live, the linked training artefact is flagged for review — closing the loop between delivery and adoption.
Naming convention
Fields
| Field | Description | Example value |
|---|---|---|
| Summary | Audience or domain + artefact name. | TRN | Managers | Day 1 readiness — manager quick guide |
| Type | Quick guide · Job aid · SOP · Runbook · Comms · Video · eLearning. | Quick guide (PDF + Confluence page) |
| Audience | Who this is for, named by role. | All hiring managers (≈180 across the organisation); secondary: PP&C analysts. |
| Supports journey | The parent journey it serves. | JNY | Hire | New Starter — Ready to Work |
| Teaches requirements | Requirement IDs the artefact teaches. When these change, this artefact is flagged for review. | SJ2.Ph3.Req01 (Day 1 checklist auto-issue) · SJ2.Ph3.Req02 (exception routing on data gate failure) |
| Outcome / what the audience will be able to do | Behaviour change the artefact enables. | Manager can read the Day 1 checklist, identify red items with their owners, and take the right escalation path — without calling IT. |
| Content owner | Author / maintainer. | Change Lead |
| Approver | Person who signs off content as accurate. | HR Domain Lead |
| Distribution | How it reaches the audience. | Linked from Core HR landing page; emailed on first hire; embedded in LMS induction. |
| Review cadence | When and how it is reviewed. | Quarterly; immediate review triggered if linked requirement changes. |
| Status | Draft · Review · Published · Needs update · Retired. | Published |
Naming conventions
Names are not aesthetic. They are the first traceability mechanism. A title that reads "REQ | New Starter | Start date change cascades to provisioning" tells you the type, the domain, and the behaviour — before you've opened the ticket.
| Prefix | Work type | Structure | Example |
|---|---|---|---|
| EPIC | Epic | <Stream> | <Outcome> | Stream 1 | New Starter — Ready to Work |
| JNY | User Journey | <Stream> | <Lifecycle stage> | <Scenario> | JNY | Hire | New Starter — Ready to Work |
| BP | Business Process | <Stream> | <Phase or domain> | <Process verb> | BP | Preboarding | Validate starter data |
| REQ | Requirement | <Stream> | <Domain> | <Behaviour> | REQ | New Starter | Start date change cascades to provisioning |
| RULE | Business Rule | RULE | <Domain> | <Rule> | RULE | Pay | Overtime ≥ 8h requires manager approval |
| US | User Story | US | <Domain> | <User need> | US | New Starter | Manager receives single Day 1 checklist |
| TSK | Task | TSK | <Domain> | <Discrete work> | TSK | New Starter | Define mandatory fields for trigger |
| TC | Test Case | TC | <Domain> | <What is verified> | TC | New Starter | Start date change cascades to tasks |
| BUG | Bug | BUG | <Domain> | <Symptom> | BUG | New Starter | Date update does not reschedule provisioning |
| DEC | Decision | DEC | <Domain> | <Decision statement> | DEC | New Starter | System of record triggers orchestration |
| RSK | Risk | RSK | <Domain> | <Risk statement> | RSK | New Starter | Position mapping errors cause wrong access |
| TRN | Training Artefact | TRN | <Domain> | <Artefact name> | TRN | New Starter | Manager quick guide — Day 1 |
Three rules that make names work
1. Prefix is the type. Never skip it. The prefix lets you read a backlog as a sentence.
2. The middle segment is the domain, not the workstream. Domains are stable (e.g. New Starter, Pay, Leave). Workstreams change.
3. The trailing segment is a verb phrase. Behaviour for requirements; verb action for processes; outcome for stories. Never an implementation detail (avoid "in Workday", "via API").
Traceability & link types
The link type carries the meaning. "Implements" and "Relates to" are not interchangeable. A practice that uses one link type for everything has no traceability — only association.
Aim for one primary link type per connection. Mixing link types across similar connections (some "Implements", some "Relates to") makes reporting unreliable and traceability impossible to audit.
| Connection | Use this link | Why |
|---|---|---|
| Epic → Story / Task | Parent ⤴ or Epic Link | Decomposition. Standard hierarchy relationship. |
| Journey → Requirement | Is implemented by | The journey identifies the need; the requirement implements something from it. |
| Process → Requirement | Is implemented by | Process rules and steps become testable requirements. |
| Requirement → Story | Is implemented by | The critical trace. Supports the rule: no story to "Up next" without a requirement link. |
| Requirement → Test Case | Is verified by | The evidence link. Without this, "approved" is unprovable. |
| Story → Test Case | Is verified by | Optional but useful when story-level evidence differs from requirement-level. |
| Bug → Test Case | Relates to | The failed test is the evidence the bug exists. |
| Bug → Story | Blocks | Only if it truly prevents the story completing. Otherwise Relates to. |
| Story / Task ↔ Story / Task | Blocks / Is blocked by | Sequencing constraints only. Don't use for general association. |
| Decision → Epic / Requirement | Relates to | Decisions are governance context, not delivery items. |
| Risk → Epic / Requirement | Relates to | Risks are threats to the work, not part of the work. |
| Training → Story / Requirement | Relates to | Training supports adoption; not part of build itself. |
Worked examples — what each link looks like
The same tickets from §13's worked example, paired by the link that connects them. Click any pair to see how the trace reads in practice.
▾ Is implemented by — Requirement → Story Hide
▾ Is verified by — Requirement → Test Case Hide
▾ Authorises — Decision → Requirement(s) Hide
▾ Blocks — Bug → Story Hide
▾ Relates to — Risk → Requirement(s) Hide
▾ Derives from — Requirement → Business Process Hide
▾ Linked to training — Requirement → Training Artefact Hide
▾ Clones / supersedes — Requirement → Requirement Hide
The traceability spine — read both ways
Downward (planning): Journey → Process → Requirement → Story → Test Case
Upward (audit): A failed test case answers: which requirement is broken? which story shipped it? which journey demanded it? which decision authorised it?
If any link in this chain is missing, the requirements practice has a hole. The hole is not theoretical — it is the place where the next surprise will come from.
The Operating Layer
How the work flows through the architecture day to day — and the quality bars that hold the line.
Workflows describe how each work-type moves from Draft to Done. Quality gates (DoR / DoD) describe what must be true at each transition. Together they are the operational discipline that keeps the architecture from rotting in production.
Workflows by type
Most work types share a delivery flow. Requirements have their own — the extra status (Approved) is what distinguishes a decision-quality requirement from one that is merely written down.
| Work type | States |
|---|---|
| Epic, Story, Task, Process, Training Shared delivery flow |
Backlog→ Up next→ In progress→ Review→ Done |
| Requirement The bar is higher — note the Approved gate |
Draft→ Validated→ Approved→ Implemented→ Tested→ Closed |
| Test Case | Draft→ Ready→ Executed→ Passed or Failed |
| Bug | Backlog→ Up next→ In progress→ Review / Retest→ Done |
| Decision, Risk, Rule Lightweight — they're records, not delivery items |
Open→ In progress (optional)→ Closed |
Why the Requirement workflow has an Approved status
Draft → Validated means the requirement is internally consistent and atomic. Validated → Approved means the named business owner has accepted it as the basis for build. Without the Approved step, validation slides imperceptibly into build, and the business has not actually said yes.
The Approved gate is what turns the requirements register from a working document into a baselined contract. Changes after Approved become variations — new requirements linked to the baseline with an explicit reason — not silent edits.
Blocked is a status, not a column
Blocking is a property of work, not a stage of work. A blocked story can be blocked while In progress, in Review, or even in Backlog — what matters is the obstacle, not the column. Use a Blocked status (or flag/label) plus a saved filter, and resist the temptation to add a Blocked column. The column would lie about progress.
Quality gates
A practice that doesn't publish its Definition of Ready and Definition of Done is operating on taste. These two artefacts make quality visible, learnable, and reviewable.
| Type | Definition of Ready (before work starts) | Definition of Done (before close) |
|---|---|---|
| Requirement | Atomic statement · business need · source linked · ≥1 measurable AC · dependencies · open questions · stakeholders identified · traceability started | Approved by named owner · linked stories/tasks exist · linked test case exists or test approach documented |
| User Story | Linked requirement exists · story statement (user/goal/benefit) · context · ≥2 G/W/T scenarios · 1 exception · non-functional considered · test approach clear | Acceptance criteria met & evidenced · test case updated · linked requirement current · docs updated if behaviour changes |
| Epic | Outcome statement with measures · problem statement with evidence · scope (in/out/constraints) · users & approvers · milestones · risks/assumptions | Scope delivered against AC · docs updated · training created · test evidence captured · change impacts assessed · handover complete |
| Test Case | Linked to ≥1 requirement or story · pre-conditions stated · steps clear · expected outcome observable · evidence type named | Executed · result recorded · evidence attached · bugs raised where Failed · linked requirement marked Tested |
The Engine
Where the architecture meets the tools. The Jira + Confluence + Rovo setup that hosts the chain — and the AI prompt chain that runs inside it.
Part IV is where most of the practical implementation lives. Set up the environment in §07. Run the chain in §08. Apply it to agile in §09. This is the part you operationalise first if you only have a week.
Tool setup — Jira & Confluence
Before the prompt chain (§08) can run, the tools need to be configured to receive its output. The worked example used Jira Cloud, Confluence Cloud, and Rovo Chat (Atlassian Intelligence) for the AI runtime. Alternative-stack notes (Notion + Linear + Claude, SharePoint + Azure DevOps + Copilot) accompany each step where the substitution is non-obvious.
This is the unglamorous half of "the system that builds the system." The chain in §08 produces Jira-ready and Confluence-ready content — but only if Jira and Confluence are first configured to receive that content. The work below is what the BA does once, before any stakeholder runs a prompt.
Good news: a lot of this comes prebuilt. Jira ships with template work-types and AI work-breakdown. Confluence ships with template scaffolds. Rovo Chat, included in Atlassian Intelligence, reads across both natively — which is what the §08 chain runs in. The setup work is configuration, not invention.
Where to start today — Jira's prebuilt scaffolding
If you are starting from scratch, do not build everything yourself. Jira Cloud (as of 2026) ships with several pieces that line up with this guide directly:
- → Atlassian Intelligence — Rovo Chat inside Confluence and Jira. This is what the §08 chain actually runs in. Native read-access to working pages and linked artefacts; no plugin needed.
- → Atlassian Intelligence — AI Work Breakdown breaks an Epic into stories on demand. Pre-trained. Available in Jira Cloud standard tier. Useful adjunct to Prompt 06.
- → Default Rovo Agents — Issue Organiser, Decision Support, Knowledge Q&A, Comms Crafter. Useful as side tools around the chain (triage, look-ups, comms drafts), not as chain steps themselves.
- → Confluence templates — built-in templates for Project Plan, Decision, Meeting Notes. You'll extend these with custom templates for Epic, Journey, BP, Requirement, etc. (covered below).
- → Jira automation rules — codeless rule builder. Use this for status transitions, auto-classification on save, and traceability checks. The traceability rule in §05 is one automation rule.
Start with what ships. Customise where it matters. Custom Rovo Agents for each chain step are a Layer 2 move (§11) — useful once the chain is stable, premature before.
Setup, step by step
Each setup below is one expandable. Closed: what it is. Open: how to build it in Atlassian, what the prebuilt scaffold gives you, and the equivalent in Notion + Linear + Claude or SharePoint + Azure DevOps + Copilot.
SETUP 01Configure Jira work-types and fields
▾
What this is
Jira out-of-the-box has Epic, Story, Task, Bug, Sub-task. You need to add (or repurpose existing types as): User Journey, Business Process, Requirement, Business Rule, Decision, Risk, Test Case, Training Artefact. Each carries its full field set from §02.
How to do it in Atlassian (Jira Cloud)
1. Settings → Issues → Issue types. Create custom issue types matching §02 names. Use distinctive icons.
2. Create custom fields for: Requirement Type, MoSCoW Priority, Value Stream (L1), Workstream, Phase (BP), Business Need, Acceptance Criteria, Systems Impacted, Stakeholders Impacted, Definition of Ready, Definition of Done, Traceability & Notes. Most are single/multi-select; AC and Description are rich text.
3. Build a screen scheme per issue type. Map the fields from §02 to each screen.
4. Use an Issue Type Hierarchy: Epic → User Journey → Business Process → Requirement → User Story → Sub-task. Premium tier supports custom hierarchy levels.
What ships prebuilt
Epic, Story, Task, Sub-task as work-types. MoSCoW-like priorities. A handful of default link types (relates to, blocks, is blocked by). The custom fields and the extra work-types are configuration you do once.
Alternative stacks
Linear: Issue types and custom fields are simpler — Project (= Journey), Issue (= Requirement / Story), Sub-issue (= Task). Custom properties cover the field set. No native multi-level hierarchy beyond Project → Issue → Sub-issue, so the L0–L3 layers live in labels.
Azure DevOps: Work item types are fully customisable in Inheritance process. Closer to Jira's flexibility. Epic, Feature, User Story, Task, Bug ship by default. Add Requirement, Risk, Test Case.
GitHub Issues + Projects: Custom issue forms (YAML) cover most field sets. Hierarchy via task lists + project tables.
SETUP 02Build Confluence templates for each work-type
▾
What this is
Each work-type in §02 needs a Confluence page template that mirrors the Jira fields. The page is the long-form working document; the Jira ticket is the structured record. The page links to the Jira ticket; the prompts in §08 read from the page.
How to do it in Atlassian (Confluence Cloud)
1. Space Settings → Templates → Create blank template, one per work-type.
2. Each template includes: page properties macro (key fields summary), Jira issue macro (links the live ticket), headings for each Fields-table block from §02, and a placeholder for source artefacts (PDFs, recordings, transcripts).
3. Pin the Page Properties Report macro at the top of each space — it auto-aggregates all template pages into a filterable table.
4. Build a parent navigation page for each Epic — the parent page hosts the working pages for journey, BPs, requirements as children.
What ships prebuilt
Confluence ships with Decision, Project Plan, Meeting Notes, Retrospective templates. Decision template can be repurposed for the DEC work-type with minor edits. The others are blank-template builds, ~30 minutes each.
Alternative stacks
Notion: Databases with template buttons. One database per work-type, each row a record. Templates inside the database define the layout. Strong fit — Notion's database / template / linked-views model maps almost 1:1 to this guide.
SharePoint: Site pages with content types. Each content type carries the field set. Slightly more setup overhead than Confluence; Power Automate fills the role of Jira automation rules.
Google Docs + Drive: Templates folder, one Doc per type. Doesn't enforce structure the way Confluence/Notion do — use a Sheet alongside as the register.
SETUP 03Set up Jira automation rules
▾
What this is
The workflow and quality-gate logic from §05–06 lives as Jira automation rules. Rules enforce: no story moves to "Up next" without a linked Requirement; no Requirement reaches Approved without a populated Definition of Ready; when a requirement is edited after Approved, flag it for review (drift detection); auto-classify a new Requirement by reading its description.
How to do it in Atlassian
1. Settings → Automation → Create rule. Each rule has a trigger (e.g. "Issue transitioned"), conditions (e.g. "Issue type = Story AND linked issues count of type Requirement = 0"), and actions (e.g. "Block transition, comment with reason").
2. For drift detection: trigger "Field value changed", condition "Status = Approved", action "Transition to In Review + assign to original approver".
3. For auto-classification: trigger "Issue created", action "Use AI to suggest field values" (Atlassian Intelligence). Set MoSCoW, Requirement type, Value Stream from the description.
What ships prebuilt
The Automation engine itself. ~50 example rule templates in the rule library. AI suggestions on field values is built into newer Jira Cloud tiers — use it; don't hand-build classification logic.
Alternative stacks
Linear: Workflows and Triggers built in. Custom workflows per project. Simpler model than Jira, fewer hooks.
Azure DevOps: Work item rules in process customisation. Power Automate for cross-system rules.
GitHub: Actions for workflow logic; Projects automation for status transitions.
SETUP 04Wire the AI runtime to the working pages
▾
What this is
The chain in §08 only works if the AI assistant can read the working Confluence page and the linked sources (SharePoint files, Jira tickets, template pages). This is the "cross-referenced sources" property the chain depends on.
How we did it on the worked example
The simplest possible setup, and the one we recommend starting with:
1. Turn on Atlassian Intelligence (which includes Rovo Chat inside Confluence and Jira) — Settings → Atlassian Intelligence → Enable.
2. On the working Confluence page for a journey, attach the source artefacts: workshop recording, transcript, current-state PDF, the template scaffolds, and the value-stream reference page.
3. Embed each prompt from §08 as an expand-block on the working page — title visible, full prompt text inside the expand. The analyst copies the prompt into Rovo Chat in Confluence.
4. Rovo Chat reads the working page and its linked sources, runs the prompt, and returns structured output (a requirements table, a refined requirement block, a story list) inside the Confluence chat sidebar.
5. The analyst reviews the output, then copy-pastes the refined content into Jira — into the right work-type, with the right fields populated. One block at a time. Approvals follow in Jira.
This is Layer 1 of the maturity arc (§11) in plain form: Rovo Chat plus the human in the loop. No custom agents, no automation triggers, no Jira-Confluence syncing — just AI doing the drafting and a person doing the placing. It worked at scale on the worked example (a Core HR transformation with deep legacy integration); it works equally on smaller programmes with smaller volumes — the discipline is the same.
Better methods (optional, build later)
Custom Rovo Agents — one per prompt — pinned in Confluence and Jira. Each agent named after the prompt (e.g. RE-04 Requirements Definer, RE-05 Requirement Refiner). Saves the copy-prompt step; the analyst invokes the agent directly from the working page. Useful once the prompts are stable and you have 5+ journeys to run through. Treat as Layer 2 (§11) territory.
Jira-side ingestion — instead of copy-pasting refined content, use a Jira automation rule to ingest from a Confluence "ready to ingest" page. Still requires human approval per requirement, but no clipboard. Worth building when you're past 50 requirements per journey.
The cardinal rule: don't build either of these until the chain in §08 has run end-to-end on at least one real journey with copy-paste. Premature automation locks in the wrong workflow.
What ships prebuilt that helps today
Rovo Chat itself — out of the box, with native read-access to Confluence and Jira content. The default Rovo agents that are useful as side tools, not chain steps: Issue Organiser (Jira triage), Decision Support (decision shaping), Knowledge Q&A (workshop look-ups). These don't run the §08 chain — they assist around it.
Alternative stacks
Claude + MCP connectors: use Notion MCP, Linear MCP, Google Drive MCP, and/or SharePoint MCP. Run the §08 prompts in a Claude conversation with those data sources connected. Same copy-paste-to-tracker workflow.
Microsoft Copilot: Copilot in Word / Loop with SharePoint + Azure DevOps grounding. Same pattern — prompt embedded in working doc, Copilot reads, you copy refined output to ADO.
Glean: Glean Assistant with cross-system grounding — works well across Confluence + SharePoint + Slack + Jira in hybrid stacks.
ChatGPT Enterprise: custom GPTs with file-search and Actions connecting to your tools.
The thing that matters most: whichever AI runtime you pick, it should have read-access to the working page and the sources linked from it. A standalone chatbot without this access can still run the chain — but you'll be pasting context into every prompt, which is tedious and tends to erode discipline over time. The chain works far better when the AI can read the working page directly.
SETUP 05Define link types & the Page-properties registry
▾
What this is
Traceability lives as link types in Jira and as page properties in Confluence. The set is small and deliberate — see §04. Common mistake: enabling all default Jira link types and letting "relates to" become the catch-all.
How to do it in Atlassian
1. Settings → Issues → Issue Linking. Keep: implements / is implemented by, validates / is validated by, blocks / is blocked by, derives from / is derived from, relates to. Disable or remove the rest.
2. In each Confluence space, set the Page Properties macro to standard keys: Status, Owner, Linked Jira, Source Artefacts, Value Stream. Same keys across all template pages.
3. Add a Page Properties Report macro at the space root to act as the live register — auto-aggregates every working page in the space.
What ships prebuilt
The Page Properties / Page Properties Report macros are core Confluence — no plugin needed. Jira link types come with a default set; pruning takes 5 minutes.
Alternative stacks
Notion: Relation properties between databases. Cleaner than Jira link types — a Requirement row has a Stories relation, an "implements" Epic relation, etc.
Linear: Relations: Blocks, Blocked by, Related, Duplicates, Duplicated by. Sparser than Jira's set; works if you don't need fine-grained traceability vocabulary.
Azure DevOps: Work item links: Parent/Child, Predecessor/Successor, Related, Tests/Tested By, Affects/Affected By. Good fit.
SETUP 06Configure status workflows & validation gates
▾
What this is
The status workflow is the spine of the requirements practice in Jira. Requirements, Stories, Decisions, Test Cases, and Risks each have a lifecycle — Draft → In Review → Approved (or equivalent). The transitions between statuses are where quality gates are enforced, ownership is asserted, and the audit trail is built. This step makes those transitions intentional, not accidental.
How to do it in Atlassian
1. Create the workflow. Settings → Issues → Workflows. Clone the default workflow; rename it. Minimum statuses per work type:
- Requirement / Decision / Risk: Draft → In Review → Approved → (Blocked · Superseded)
- User Story: Draft → Ready → In Progress → Done → (Blocked)
- Test Case: Draft → Ready → Passed → Failed → (Blocked)
- Training Artefact: Draft → In Review → Published → Needs Review
2. Add transition validators.
Draft → In Review: required fields populated (Owner, Type, MoSCoW, Value Stream, Phase).
In Review → Approved: AC field not empty + Assignee = Current User (only the named owner approves).
Any → Blocked: comment required explaining the blocker.
3. Add post-functions. On → Approved: set custom date field "Approved On" to today. This timestamps every approval for BRD assembly and audit reporting.
4. Wire automation rules (from Setup 03). When: status transitions to Approved → post comment "Approved by {user} on {date}." The BRD assembly prompt reads this comment as the approval record.
5. Apply the workflow. Project settings → Workflows → Switch scheme. Apply to all relevant issue types.
What ships prebuilt
Jira's default workflow (To Do / In Progress / Done) is too simple. Create your own — it takes about a day including testing the validators. Do it once per programme setup; reuse across projects.
Alternative stacks
Linear: Status labels per team. Less rigid — rely more on automation rules. Azure DevOps: Use the Agile or CMMI process template as base; both have richer state models. Add state rules to enforce field population on transitions.
Setup checklist — when you're ready for the chain
Before running §08, you should have:
- ☐ All required Jira issue types created with field sets per §02
- ☐ Confluence templates published for Epic, Journey, BP, Requirement, Story (minimum)
- ☐ Page Properties Report at the requirements space root, showing all working pages
- ☐ Jira automation rules in place for traceability (story-to-requirement link enforcement) and quality gates (DoR check on Approved transition)
- ☐ Status workflows configured with transition validators and post-functions per Setup 06 — Draft → In Review → Approved with required-field and ownership gates
- ☐ Atlassian Intelligence on; Rovo Chat available inside Confluence and Jira
- ☐ One working Confluence page per journey, with source artefacts attached and §08 prompts embedded as expand-blocks
- ☐ Stakeholders have edit access to working pages; trained on the prompt cadence
- ☐ Value Stream (L1) reference page exists and is linked from each prompt
Setup time: a senior BA can stand this up in roughly 5 working days. After that, every journey runs through it.
The prompt chain
Eight prompts. Each operates on cross-referenced sources. Each produces a defined output. The BA designs the chain once. Stakeholders run it many times.
The traditional model — BA gathers, BA drafts, BA reviews, BA redrafts — does not scale. The compounding move is to design a system inside which a stakeholder, with AI as their writing partner, can produce a BA-quality requirement without the BA being in the room.
The chain below is built around eight prompts, each operating on cross-referenced sources, each with a specific job. The pattern is consistent: prompt + sources → draft → validate → next prompt. The BA designs the chain once. Stakeholders run it many times.
Eight steps, source-referenced, in sequence
The sequence below is a recommended starting point — the order that minimises rework and produces the most coherent output for a new journey. BABOK intentionally avoids prescribing rigid sequences; the right order depends on what you know, what's been agreed, and how much has already been done. If your programme already has approved Epics and BPs, start at Prompt 04. If stakeholders want stories first to frame scope, sketch them, then run the chain to elaborate. What matters is that each step's sources are in place before you run it — not that you run them in calendar order.
Before you run any prompt — get your source material right
The chain produces output proportional to the quality of what it reads. A weak source produces weak requirements, regardless of how well the prompt is written. Before running Prompt 01, it's worth spending time getting a good draft of each of these source artefacts to a high standard:
- Journey description — a clear, specific narrative of what happens end-to-end. Includes who does what, in what order, what can go wrong, and what the good outcome looks like. Workshop recording + transcript + any current-state documents attached to the Confluence page.
- Business process breakdown example — the worked example from your Confluence space that shows how phases, value streams, roles, and Jira naming conventions should look for this workstream. The AI reads this and mirrors it — the better the example, the more consistent the output.
- Templates — the Epic, Journey, BP, and Requirement templates that your programme uses. The AI uses these as field references; incomplete or inconsistent templates produce incomplete or inconsistent output.
- Value stream mapping — the L1 value streams your programme uses. The AI uses this to classify requirements; without it everything maps to [TBC].
The prompts are source-dependent by design. Garbage in, garbage out — the AI will not hallucinate scope you haven't provided, but it also cannot compensate for a source that hasn't been thought through. Good source material + good prompts = requirements your stakeholders will recognise and approve.
Each step shows what it produces and why. Open any step to see the full prompt — copy it directly into Rovo Chat (or your AI runtime) with your linked sources substituted for the [placeholders].
01
Epic definition
Take the raw journey description → structured Epic: outcome, problem, scope, stakeholders, dependencies, AC.
Output Epic ticket ready for Jira
▾
Epic definition
Take the raw journey description → structured Epic: outcome, problem, scope, stakeholders, dependencies, AC.
02
User Journey artefact
Same source material, different lens → Journey ticket with synopsis, phases, variations, pain points.
Output Journey ticket with phases verbatim from artefact
▾
User Journey artefact
Same source material, different lens → Journey ticket with synopsis, phases, variations, pain points.
03
Business Processes (Phases)
Decompose the journey into 3–6 BP phases — name, value stream, description, Jira placeholder.
Output Confluence-ready table: Phase · Value Stream · Description · Jira
▾
Business Processes (Phases)
Decompose the journey into 3–6 BP phases — name, value stream, description, Jira placeholder.
04
Requirements definition
Phase-by-phase: derive all requirements — rules, decisions, data, exceptions, integrations, NFRs, security, reporting. IDs assigned, value streams mapped.
Output Requirements table — one row per atomic behaviour, classified, traceable
▾
Requirements definition
Phase-by-phase: derive all requirements — rules, decisions, data, exceptions, integrations, NFRs, security, reporting. IDs assigned, value streams mapped.
05
Requirement refinement
Per requirement: refine into Jira-ready field content. Every field populated. No new requirements — gaps flagged separately.
Output Per-requirement Jira-ready blocks separated by -----
▾
Requirement refinement
Per requirement: refine into Jira-ready field content. Every field populated. No new requirements — gaps flagged separately.
-----
06
User Stories
Group 1–3 related requirements per story → story summary, AC, linked requirements in one table.
Output Story table: Phase · VS · US ID · title · statement · AC · links
▾
User Stories
Group 1–3 related requirements per story → story summary, AC, linked requirements in one table.
07
Tests · Training · Decisions · Risks
From requirements + stories: generate supporting artefacts — 3–5 test cases, 1–3 training, 1–3 decisions, 1–3 risks.
Output Single table: Type · Value Stream · Summary · Links to
▾
Tests · Training · Decisions · Risks
From requirements + stories: generate supporting artefacts — 3–5 test cases, 1–3 training, 1–3 decisions, 1–3 risks.
08
BRD generation
Once requirements are Approved in Jira, assemble the BRD from the approved register — executive summary, scope, requirements table, traceability matrix.
Output Draft BRD — all sections pre-populated. BA edits, doesn't write from scratch.
▾
BRD generation
Once requirements are Approved in Jira, assemble the BRD from the approved register — executive summary, scope, requirements table, traceability matrix.
What makes this work — cross-referenced sources at every step
Every prompt links to a defined set of sources the AI must read and respect. This is the mechanism that prevents fabrication and enforces consistency with the existing structure. The AI doesn't invent a value stream — it looks it up. It doesn't guess a template — it follows the one linked.
What the BA does · what the stakeholders do
The BA designs the chain, once. Picks the templates, defines the naming convention, links the sources, writes the prompts, decides the guardrails, sets the gates between steps. This is architecture work — it's slow, it's careful, it's done with senior judgement.
Stakeholders run the chain, repeatedly. An HR analyst with a new journey opens the working page, attaches the workshop artefact, and runs Prompt 1, then 2, then 3. They get drafts back. They validate them against their domain knowledge. They paste into Jira. They move on to the next journey.
The BA holds the standard at each gate. Not at every step — at the gates. A spot-check on the BP table. A review of the requirements before refinement. A walkthrough of refined Jira-ready content before approval. The BA doesn't write; the BA defends the bar.
Applying in agile
The worked example throughout this guide is a waterfall HR Core Systems transformation — phased, BRD-gated, single release. The chain still applies in agile, with different cadence and a different artefact at the end. The components don't change.
What changes is when each step is produced, and what it produces next. In waterfall, the chain runs once per journey, end-to-end, before build begins; the final artefact is the BRD. In agile, the chain runs per increment; the final artefact is a release pack — same content, smaller scope, more often.
For sector-specific delivery dial-ups (regulated finance, public sector procurement, healthcare, utilities), see the dial-ups chapter of The Minimum Viable BA Practice (MVBA, Field Guide 1).
One pass, BRD at the end
Chain runs once per Epic, before delivery starts. Stakeholders run prompts 01→07 over a few days per journey; prompt 08 produces the BRD once requirements reach Approved. Build follows the BRD; change after sign-off is a variation against the baseline.
- Cadence: linear, per Epic
- Gate: BRD approval before build
- Final artefact: signed BRD + Jira register
- Change control: variation request against baseline
- MVBA components most active: Problem Statement, Decision Log, four tests, axe-sharpening — all upfront
Many passes, release pack at increments
Chain runs per sprint or per feature. Prompts 01–03 happen once per Epic (Epic and Journey are stable). Prompts 04–07 run per refinement cycle as scope is elaborated. Prompt 08 produces a release pack per increment — same content as a BRD, scoped to what's in the increment.
- Cadence: rolling, per sprint or per feature
- Gate: Definition of Ready per story, not per project
- Final artefact: release pack per increment, kept current
- Change control: backlog refinement, not variation
- MVBA components most active: Assumptions / Constraints / Open Questions register — continuously, not once
What stays the same regardless of methodology
The structure. Epic → Journey → BP → Requirement → Story → Test still applies. The hierarchy doesn't care if you're running waterfall or agile.
The classification. Functional, integration, data, workflow, NFR, security, compliance, business rule — every requirement still carries a type, regardless of when it's elaborated.
The traceability spine. No story to "Up next" without a linked requirement. This rule holds in agile too — arguably more important there, because stories move fast and orphans appear silently.
The cross-referenced sources discipline. Whether the prompts run in a 4-day burst or rolling across sprints, the AI still needs the same source rigour: page artefacts, templates, value-stream mapping, classification rules. No invention.
Agile doesn't excuse you from requirements engineering. It changes when you do it, not whether.
From Draft to Approved
A refined requirement sitting in Jira is not yet a real requirement. It becomes one when it has been reviewed, verified against the four guarantees, validated against the stakeholder need, approved by a named owner, engineered into a BRD, and made navigable in a live register that delivery teams actually use.
Part V closes the loop from "draft in Jira" to "approved, traceable, navigable artefact that drives build, test, training, and change." The chain (§08) produces drafts; this part is how drafts become contracts.
Review & verification
A draft requirement is checked against the four guarantees (§ii), the work-type Fields template (§02), the naming convention (§03), and the traceability rules (§04). This is verification — "did we build it right against the criteria we set." Done in Jira, by the BA, before the requirement is offered to stakeholders for validation.
Verification is a deterministic check. The criteria don't shift between requirements. The same eleven checks run on requirement number 1 run on requirement number 300. The BA's job here is not to debate; it's to enforce the bar.
The chain in §08 produces drafts that already pass most of these checks — that's the point of cross-referenced sources and structured templates. Verification catches the ones that don't, before they reach a stakeholder. Stakeholders should not be reading malformed requirements; their time is for validation, not editing.
The verification checklist
Run on every requirement before it transitions from Draft to Ready for Review. Eleven checks. Each is yes/no. No partial credit.
| # | Check | What you're looking for |
|---|---|---|
| 1 | Atomic | One behaviour, one rule, one outcome. No "and / or / except" in the behaviour clause. If it contains a compound, split it. |
| 2 | Testable | A QA can write a Given/When/Then for it without asking a clarifying question. If they would have to ask, the requirement isn't testable yet. |
| 3 | Classified | Type is set (Functional, Integration, Data, Workflow, Reporting, Security, NFR, Compliance, Business Rule). MoSCoW priority is set. Value Stream and Phase populated. |
| 4 | Named correctly | Follows the naming convention from §03 — REQ | <Domain> | <Behaviour>. Domain is a stable business domain, not a workstream or system name. |
| 5 | Linked upward | Has at least one derives from link to a parent BP or User Journey. Orphan requirements are caught here. |
| 6 | Owned | Stakeholder owner is named. "The team" is not an owner. "TBC" is not an owner. |
| 7 | Solution-free | Describes behaviour, not implementation. "The system must …" not "In Core HR's screen X, click Y." |
| 8 | AC drafted | Acceptance criteria exist in Given/When/Then form. At least one exception path covered. Numbers and thresholds explicit. |
| 9 | Source-traced | The Confluence working page, the artefact, or the decision it derives from is linked. Reviewers can walk back to source. |
| 10 | Sized as a requirement | Not too big (whole feature posing as a requirement) or too small (sub-step of another requirement). Tested by: can this be implemented and tested as a unit? |
| 11 | Free of TBCs | No [TBC], [TBD], or ? in the body. If something is unknown, it goes in the Gaps register, not in the requirement. |
Who runs verification
The BA, in Jira. Verification is a BA discipline, not a stakeholder activity. A stakeholder reading a poorly-formed requirement loses confidence in the system, and may amend it themselves — which means the verification check should have caught it before they saw it.
On the worked example, the BA reviewed each batch of ~30 requirements at end-of-day on Day 2. Spot-check, not rewrite — if a requirement failed verification, it went back to the analyst with a one-line note ("Req 17: compound — split into starter-data-gate and exception-routing"). The analyst then re-ran Prompt 05 against the offending requirement.
This is also where Jira automation rules (Setup 03) earn their keep. A rule that blocks the Draft → Ready for Review transition until Owner, Type, MoSCoW, Value Stream, and Phase are populated catches checks 3, 4, and 6 automatically. AC quality scoring (Layer 2, §15) catches check 8. The rule does the work; the BA reviews the exceptions.
Validation & approval
A verified requirement is then offered to the stakeholder owner: "This is what we heard. Confirm it matches your domain, your policy, your exceptions — or correct it." Validation is the conversation. Approval is the signed result. Both are recorded in Jira, against the requirement, by the named person.
Where verification answers "did we build it right against the criteria," validation answers "is it the right thing for the business." A requirement can be perfectly atomic, testable, and traced — and still be wrong, because the stakeholder's domain doesn't actually work the way the draft says it does.
This is the step that most projects rush. The temptation is to send fifty requirements as a PDF to a stakeholder, ask for sign-off, and treat their silence as approval. That isn't validation. That's avoidance.
The validation cadence
Batch by domain owner
Group verified requirements by the stakeholder who owns them. The HR Domain Lead validates all requirements derived from BPs in the New Starter journey. The Compliance Lead validates all requirements derived from policy decisions. The IT Delivery Lead validates integration requirements. No-one validates the whole register — that's a recipe for fatigue and rubber-stamping.
Walkthrough, not handoff
A 60–90 minute working session per batch. BA + analyst + stakeholder owner. The BA walks each requirement: "This is what we heard from the workshop. Here's the source. Here's the AC. Does this match what actually happens in your team?" The stakeholder responds: confirm, correct, or escalate.
Approval recorded in Jira, not email
Approval is a Jira status transition: Ready for Review → Approved. The transition is performed by the named stakeholder owner, not the BA. The Jira comment captures the qualifying note. The transition timestamp is the approval timestamp.
What MVBA brings to validation
▾
If the upstream Minimum Viable BA Practice work has been done well, validation is fast. The four tests (clarity, ownership, resource reality, strategic intent), the Decision Log, and the Stakeholder Map mean the validator already knows what was promised, who owns what, and why each requirement exists. The walkthrough confirms behaviour against domain — it doesn't have to relitigate scope.
Where MVBA wasn't done, validation slows by 3–5×. Stakeholders relitigate scope mid-walkthrough. Owners aren't named. Decisions get re-opened. The BA spends the session re-establishing context that should have been settled before the BRD was opened. Validation is where pre-BRD discipline pays for itself.
When validation reveals a deeper problem
▾
Sometimes a walkthrough surfaces something bigger than a wording correction — a stakeholder reveals that a whole class of cases the requirements assumed doesn't exist, or a policy interpretation that drove an entire BP turns out to be contested. This is good news, not bad. It means the system caught the problem before build began.
When this happens: the requirement transitions to Blocked, a Decision artefact is raised (linked to the requirement), and the matter routes to the Decision owner per the MVBA Decision Log. The requirement does not get approved until the decision is settled. Approving around a contested decision is the largest single anti-pattern in requirements work — see §16.
The BRD as deliverable
The Business Requirements Document is no longer a thing the BA writes. It is a thing that gets assembled from approved content already in Jira, by Prompt 08, against a structured template. The BA edits, signs, and circulates. The drafting is over.
A BRD in this practice is a side-effect of approved requirements, not the goal of the requirements work. The goal was the approved register. The BRD is what gets handed to executives, vendors, auditors, and procurement — but the source of truth is Jira.
This matters because a BRD authored separately from the register drifts the moment a requirement changes. A BRD assembled from the register doesn't drift — it gets reassembled. Two hours, not two weeks isn't a productivity boast; it's a structural property.
On naming — BRD vs SRS. Strictly, a BRD (Business Requirements Document) is produced during early feasibility — it captures stakeholder needs and business context before detailed solution design begins. Once requirements are elaborated at system level, the resulting document is typically called an SRS (System Requirements Specification) or SyRS. The structure in §12 — requirements register, traceability matrix, AC, NFRs, decisions, risks, sign-off ledger — is closer in substance to an SRS or an elaborated requirements specification. This guide uses BRD as the shorthand most enterprise programmes already use for this artefact, but if your programme's naming convention calls it an SRS or Requirements Specification, the structure maps directly. The label is local to your programme; the discipline is the same either way.
What the BRD contains
Prompt 08 assembles the document against a standard structure. Every section pulls from approved content in Jira and supporting artefacts in Confluence. Nothing is invented at assembly time.
| Section | Pulled from | Form |
|---|---|---|
| 1. Document control | Confluence page properties; sign-off ledger | Version, date, author, approvers, change log. |
| 2. Executive summary | Problem Statement (MVBA), Epic outcome & problem fields, top-3 expected outcomes | 2-3 paragraphs, executive-grade prose. Names the problem and the bet — no feature talk. |
| 3. Background & current state | Epic background field, current-state PDFs / diagrams attached to the working page | 1-2 pages. The "why now" and what's broken. |
| 4. Scope & out-of-scope | Epic scope field, Phase definitions (BP), Assumptions panel (§iii) | Bulleted in-scope by phase; bulleted out-of-scope with rationale. Out-of-scope without rationale is just a list. |
| 5. Stakeholder map & RACI | MVBA Stakeholder Map, per-requirement owner field | Table: stakeholder, role, accountability, sign-off authority. |
| 6. Business processes | BP work-type tickets in Jira | Per-phase narrative + diagram link, inputs/outputs/exceptions, embedded Confluence BP links. |
| 7. Requirements register | All Jira requirements where status = Approved | Table by phase: ID, name, type, MoSCoW, owner, AC count, linked stories. Full AC content is in Jira; the BRD references not duplicates. |
| 8. Business rules | RULE work-type tickets, linked from requirements | Table: rule ID, when/then/else, owner, source policy. |
| 9. Decisions | DEC work-type tickets, linked from requirements | Table: decision, options considered, chosen option, rationale, owner, date. |
| 10. NFRs & constraints | Requirements with type = NFR, plus Assumptions / Constraints register | Performance, security, availability, compliance, data residency. |
| 11. Acceptance criteria summary | AC count and summary per approved requirement | AC count per requirement; full AC text lives in Jira — not duplicated here. |
| 12. Traceability matrix | Jira link types — derives from, validates, implements | Requirements × stories × test cases. Live in Jira via per-audience filters (§14); also packaged into the HTML explorer for stakeholders outside Jira. |
| 13. Risks & mitigations | RSK work-type tickets, status = Mitigating or Materialised | Table: risk, impact, likelihood, mitigation, owner, residual. |
| 14. Training & change impact | TRN work-type tickets, linked from requirements | Audience × artefact × delivery channel. Flagged for review on requirement change. |
| 15. Open items & gaps | Requirements in Draft, Decisions in Open, items tagged [TBC] | Explicit list with owner and target close date. A BRD that hides its gaps is worse than no BRD. |
| 16. Sign-off ledger | Confluence sign-off page | Name, role, date, version, qualifying notes. |
PROMPT 08How the BRD gets assembled — the actual prompt pattern
▾
Pre-requisites
- All in-scope requirements at APPROVED in Jira (or explicitly listed as Open with target close).
- Decisions, rules, risks, training artefacts linked to their parent requirements.
- A populated BRD template page in Confluence with section headings (the 16 above) and empty placeholders.
- The supporting artefacts attached: Problem Statement (from MVBA), Stakeholder Map, current-state diagrams, glossary, references list.
The prompt (paste into Rovo Chat on the BRD template page)
What Rovo / Claude does
Reads each source filter, returns structured content into the section placeholders. Sections 5–14 come back as tables. Sections 2–4 come back as prose. Section 11 (traceability) comes back as a generated matrix sized to the register.
What the BA does (the part that's not automated)
- Reads the inconsistency list at the bottom first. Resolves each one in Jira before circulating — the BRD is a snapshot of a consistent register, not a place to paper over conflicts.
- Edits sections 2–4 for executive tone and accuracy. The AI gets sections 5–14 right because they're structured; the prose sections need a BA's judgment.
- Validates the traceability matrix coverage. Every approved requirement should link to ≥1 story and ≥1 test case. If not, that's a register issue, not a BRD issue — go back and fix it.
- Confirms the open items list. Every gap named, every owner present, every target date plausible.
- Final read for tone. AI prose can be flat; the BA tightens.
Effort. Prompt 08 runs in ~2 minutes. BA edit + validation ≈ 2 hours for a register of 300 requirements (less for smaller registers). Circulation and sign-off coordination is separate work.
VERSIONVersioning & change control
▾
The BRD versioning follows the register, not the document. When the register changes, the BRD is re-assembled — it does not get hand-edited.
Versioning convention
- v0.x — draft assembly. Generated before sign-off. Open items list is long. Used for review cycles.
- v1.0 — first approved BRD. All sections populated; sign-off ledger complete.
- v1.x — change releases. Each material change to the register (decision reopened, scope adjusted, NFR added) triggers a new minor version. Change log notes which sections changed and why.
- v2.0 — phase boundary. Reserved for a structural change (new phase added to journey, scope expanded substantially).
Change-control rule
If a requirement at APPROVED is edited, the automation rule from §07 Setup 03 transitions it to IN REVIEW and pings the original approver. The BRD is not re-assembled until that requirement is re-approved. This keeps the document from chasing every in-flight edit.
What sits where
- Jira — the live register. Source of truth.
- Confluence — BRD page (current) — the latest assembled BRD.
- Confluence — BRD archive — child pages for each prior signed version, with the PDF attached.
- Sign-off ledger — a child page of the current BRD, recording every approval against every version.
SIGN-OFFHow it gets signed
▾
The BRD is circulated to the named approvers from the Stakeholder Map. Each approver has already validated their portion of the register in §11 — so what they're signing here is the document, not the underlying requirements. Sign-off is a 24–48 hour cycle, not a 2–3 week one, because there are no surprises in the document.
Sign-off is recorded on a Confluence page linked to the BRD — name, role, date, version, qualifying notes. The signed PDF is attached. The register in Jira remains the source of truth. If a requirement subsequently changes, the BRD is re-assembled, the change is highlighted, and the affected approvers re-confirm only the changed sections.
Sign-off convention:
- Each approver signs against a named version (v1.0, v1.1, etc.)
- Qualifying notes captured in the comment — "Approved subject to resolution of open item 3" is a valid qualifying note, not a blocker
- The BA does not sign — the BA assembles. Approval is the stakeholder's act.
- Re-approval is scoped: if section 6 changes, only the approvers for section 6 re-sign
In Motion
Where everything to this point lands as practice. The worked example shows the discipline in flight on one journey; the audience views show how its output is consumed; the maturity arc shows where this goes next.
Part VI is the part you'll come back to most often after the first read — once for sanity-checking your own implementation, once for planning the next layer.
A worked example
The discipline in action on one journey — New Starter — Ready to Work — within a Core HR transformation programme. The stakeholders did the writing. The BA built the system that made the writing possible. The volume below reflects this programme's context; on a leaner programme the discipline produces a leaner register at the same per-journey pace.
The context
A Core HR transformation at a utilities organisation. Two compounding properties shape the requirements surface:
- → A regulated, complex workforce — rosters, awards, EBAs, safety-sensitive roles, statutory leave, classification rules.
- → A deeply integrated legacy estate — multiple time-keeping systems, a long-running payroll engine, a permission-to-work overlay, a separate competency / authorisation system, two reporting warehouses, partial point-to-point integrations carried over multiple programmes.
▾ More on the integration surface Hide
High variation in employment types (full-time, part-time, casual, fixed-term, contractor, secondment, higher-duties). Thick rule density per BP (eligibility, escalation, waiver, exception). Cross-system orchestration on most journeys. These are the properties that drove requirement count up — not the discipline producing more, but the surface having more to describe.
What the chain produced
EPIC | Hire | New Starter — Ready to Work ACTIVE Epic ▾
| Summary | Stream 2 | New Starter — Ready to Work |
| Workstream | Service Design and User Journey |
| Outcome statement | By Day 1, 95% of new starters have full system access, equipment, and a manager-issued readiness checklist — without manual chasing. Manager incident rate for Day 1 access failures falls to <5%. |
| Problem statement | Day 1 access failures average 18% of new starters. PP&C spends ~4 hours per starter chasing IT, Facilities, and Payroll. Provisioning tasks are triggered manually and inconsistently — no single system owns the orchestration. |
| In scope | Offer & Accept · Preboarding · Day One readiness · Week One induction · Identity & access provisioning trigger |
| Out of scope | Recruitment (covered by R2H epic) · Probation outcomes (covered by O2P epic) · Offboarding |
| Constraints | Award interpretation locked to current EBA. Payroll cutover dates immovable. SoD rules enforced at access activation. |
| Primary users | Hiring managers · new starters · PP&C team · IT Service Desk · Facilities |
| Approvers | HR Domain Lead (process) · CIO delegate (integration) · Head of Payroll (financial) |
| Value Stream (L1) | H2O (Hire to Onboard) |
JNY | Hire | New Starter — Ready to Work ACTIVE User Journey ▾
| Summary | JNY | Hire | New Starter — Ready to Work |
| Phases | Offer & Accept → Preboarding → Day One → Week One |
| Journey synopsis | A candidate accepts an offer. Core HR creates the employment record. Orchestration triggers provisioning (accounts, access, equipment, induction). By Day 1 start time, the starter arrives to working accounts, equipment on desk, manager-issued checklist, and buddy assigned. |
| Variations |
|
| Pain points (current state) | Provisioning triggered by email from PP&C, not by system event. No visibility of task status. Day 1 failures discovered on Day 1. Manager chasing three systems. |
| Good outcome | Manager opens one checklist. All items green. Starter arrives to working environment. Zero chasing calls. |
| Value Stream (L1) | H2O · R2H (Recruit to Hire, phase 1) |
| Owner | HR Domain Lead |
BP | Preboarding Business Process APPROVED ▾
| Phase name | SJ2.Ph2 | BP | Preboarding |
| Value Stream (L1) | H2O (Hire to Onboard) |
| Description | The period between offer acceptance and Day 1. Employment record created in Core HR; mandatory data validated; provisioning tasks generated and tracked; starter communications sent. Gate: all provisioning tasks must complete before Day 1 start time. |
| Trigger | Employment record status transitions to "Accepted" in Core HR. |
| Process steps |
|
| Roles | PP&C analyst (data validation) · IT Service Desk (account provisioning) · Facilities (equipment) · HR Domain Lead (exception decisions) |
| Inputs | Accepted employment record · Position data · Role-based access bundle · Equipment standard |
| Outputs | Provisioned but inactive accounts · Equipment at desk · Manager readiness checklist showing all green |
| Exceptions | Missing mandatory field → exception routed to PP&C · SoD conflict → held for Security review · No-show → pause-cancel pathway |
| Definition of Done | All provisioning tasks in "Complete" status by 23:59 the night before start date. Manager has opened and acknowledged the Day 1 readiness checklist. |
DEC | System of record triggers orchestration ACTIVE Decision ▾
| Decision ID | DEC-NS-01 |
| Statement | Core HR is the system of record for employment status. Onboarding orchestration (provisioning, payroll setup, access activation) is triggered from Core HR events — not from the recruitment system, not from manager intent. |
| Rationale | Recruitment platform creates candidates, not employees. Orchestrating from candidate state produces ghosts (offers accepted that never land), duplicates (re-hires), and audit gaps. Core HR holds the contractual employment record; orchestration must follow it. |
| Alternatives considered |
|
| Authorises | SJ2.Ph1.Req02 · SJ2.Ph2.Req01 · SJ2.Ph2.Req02 |
| Owner | HR Domain Lead |
| Approved by | HR Domain Lead · IT Delivery Lead · 2026-02-14 |
| Status | ACTIVE |
DEC | Mandatory data gate before provisioning ACTIVE Decision ▾
| Decision ID | DEC-NS-02 |
| Statement | Provisioning tasks (account creation, access groups, equipment, induction) cannot be generated until a starter record has all mandatory fields populated: position ID, classification, cost centre, manager, start date, work pattern, location. |
| Rationale | ~12% of legacy position records were missing required fields. Carrying that forward at cutover produces provisioning failures on Day 1 — manager raises an incident, IT scrambles, starter sits idle. Better to fail at data-entry time than at Day-1 time. |
| Authorises | SJ2.Ph2.Req01 · SJ2.Ph2.Req02 |
| Linked risks | RSK-NS-03 (legacy data quality) |
| Owner | PP&C Lead |
| Status | ACTIVE |
REQ | Mandatory starter data gate APPROVED MUST Functional · Workflow ▾
| Requirement ID | SJ2.Ph2.Req01 |
| Statement | When a starter record reaches Preboarding phase, the system must verify that all mandatory fields (position ID, classification, cost centre, manager, start date, work pattern, location) are populated before any provisioning task is generated. If any field is missing, the system must hold the record at the data-gate state and route an exception to the PP&C Lead with the named missing fields. |
| Type | Functional · Workflow · Data quality |
| Priority | MUST |
| Acceptance criteria |
AC1 — Happy path Given a starter with all 7 mandatory fields populated, when the record transitions to Preboarding, then provisioning tasks are generated within 60 seconds.
AC2 — Missing field Given a starter with ≥1 mandatory field empty, when the record transitions to Preboarding, then no provisioning task is generated and an exception is created naming each missing field, assigned to PP&C Lead.
AC3 — Audit Every gate-pass and gate-fail event writes to the audit log with starter ID, timestamp, fields evaluated, result, actor.
|
| Derives from | DEC-NS-02 (Mandatory data gate) |
| Implemented by | UJ2.Ph3.US06 (Exception routing on data gate failure) |
| Validated by | TC-NS-10 (Mandatory fields incomplete → orchestration blocked) |
| Systems impacted | Core HR · Workflow Orchestrator · Audit log service |
| Owner | HR Domain Lead |
| Status | APPROVED · 2026-03-04 |
REQ | Start date change cascades to tasks + provisioning APPROVED MUST Functional · Integration ▾
| Requirement ID | SJ2.Ph2.Req02 |
| Statement | When a starter's start date is amended in Core HR (any time before Day 1), all dependent orchestration tasks — provisioning, access activation, equipment, induction, payroll setup — must have their due dates shifted by the same delta within 5 minutes. The previous and new date are written to audit log. |
| Type | Functional · Integration · Workflow |
| Priority | MUST |
| Acceptance criteria |
AC1 — Forward shift Given a starter with date D and N orchestration tasks scheduled, when the date is changed to D+δ, then all N tasks reschedule to original-due + δ within 5 minutes.
AC2 — Backward shift (recent past blocked) Given a date change to a past date, then the change is rejected with a workflow exception, no rescheduling occurs.
AC3 — Audit Every date change writes audit log entry: starter ID, old date, new date, changer, timestamp, affected task count.
|
| Derives from | DEC-NS-01 (System of record triggers orchestration) |
| Implemented by | UJ2.Ph3.US07 (Audit log entry on every date change) |
| Validated by | TC-NS-09 (Start date change cascades to downstream tasks) |
| Systems impacted | Core HR · Workflow Orchestrator · IAM · Service Desk · Payroll |
| Linked risks | RSK-NS-03 |
| Owner | HR Domain Lead · IT Delivery Lead (joint) |
| Status | APPROVED · 2026-03-04 |
REQ | Effective-dated access activation on start date APPROVED MUST Integration · Security ▾
| Requirement ID | SJ2.Ph2.Req03 |
| Statement | Access (IAM accounts, application entitlements, building/badge access where applicable) must activate at 00:01 local time on the starter's start date — not before, not after. Access remains in a "provisioned but inactive" state during preboarding. SoD-conflict checks run at activation time, not at provisioning. |
| Type | Integration · Security · NFR (timing) |
| Priority | MUST |
| Acceptance criteria |
AC1 — Activation timing Access transitions from inactive to active within 60 seconds of 00:01 on the start date in the starter's local timezone.
AC2 — No early access Any attempted login before 00:01 on the start date returns "account not yet active"; event is logged as a security event.
AC3 — SoD check at activation If the bundle of entitlements would breach SoD, activation is held, an alert is raised to Security Ops, and the starter's manager is notified.
|
| Derives from | DEC-NS-01 |
| Validated by | TC-NS-12 (Effective-dated access activation timing) |
| Systems impacted | IAM · Active Directory · 12 line-of-business apps · Building access · Audit log |
| Owner | IAM Lead · Security Lead (joint) |
| Status | APPROVED · 2026-03-06 |
REQ | No-show / delay pause-cancel pathway IN REVIEW SHOULD Functional · Workflow ▾
| Requirement ID | SJ2.Ph2.Req04 |
| Statement | If a starter does not present on the start date by EOD, the system must (a) flag the record as "no-show pending", (b) pause provisioning that would otherwise complete on Day 1, (c) hold access in inactive state. After 5 working days with no contact, the manager is prompted to confirm cancel-or-extend; cancel triggers de-provisioning per policy. |
| Type | Functional · Workflow |
| Priority | SHOULD |
| Acceptance criteria |
AC1 — Pause No-show toggle pauses all in-flight provisioning tasks within 5 minutes; access held inactive.
AC2 — Manager prompt At Day-5 no-show, manager receives an in-system task with two options: extend (re-issue start date) or cancel (de-provision).
AC3 — De-provision On cancel, all provisioned accounts are revoked within 24 hours; audit log captures actor, reason, timestamp.
|
| Validated by | TC-NS-11 (No-show toggle pauses provisioning within 5 min) |
| Open question | What's the policy for re-activation if a cancelled starter is reinstated? Owner: HR Domain Lead. Target close: 2026-03-15. |
| Owner | HR Domain Lead |
| Status | IN REVIEW · awaiting open-question resolution |
US | Manager receives single Day 1 readiness checklist READY MUST User Story ▾
| Story ID | UJ2.Ph3.US05 |
| Statement | As a hiring manager, I want a single consolidated Day 1 readiness checklist for my new starter — covering access, equipment, induction, and the human side (buddy assigned, welcome lunch) — so that I can see at a glance what's ready and what needs my attention, without chasing four different systems. |
| Priority | MUST |
| Acceptance criteria |
AC1 — Single view Manager opens the starter's record and sees one checklist with sections: Access, Equipment, Induction, People. Each section shows item, status (Ready / In progress / Blocked), owner.
AC2 — Real-time status Status updates within 5 minutes of underlying system events (no manual refresh).
AC3 — Drill-down Clicking any "Blocked" item shows the blocker (e.g. SoD conflict on entitlement X) and the owner to contact.
|
| Implements | SJ2.Ph3.Req01 (Day 1 readiness checklist) |
| Validated by | TC-NS-13 (Manager checklist consolidates all sources) |
| Status | READY |
US | Exception routing on data gate failure READY MUST User Story ▾
| Story ID | UJ2.Ph3.US06 |
| Statement | As a PP&C analyst, I want to receive an actionable exception whenever a starter fails the mandatory data gate — naming each missing field and the responsible role — so that I can resolve the gap before Day 1 instead of discovering it on Day 1. |
| Priority | MUST |
| Acceptance criteria |
AC1 — Exception content Exception names: starter, missing fields, last-known-source-of-data per field, escalation owner per field.
AC2 — SLA Exception lands in PP&C work queue within 60 seconds of gate failure.
AC3 — Re-evaluation Once missing fields are populated, gate auto-re-runs; if passed, provisioning resumes; if failed (new gap), new exception raised.
|
| Implements | SJ2.Ph2.Req01 (Mandatory starter data gate) |
| Validated by | TC-NS-10 |
| Status | READY |
US | Audit log entry on every date change READY MUST User Story ▾
| Story ID | UJ2.Ph3.US07 |
| Statement | As a compliance officer, I want every change to a starter's date (start date, end date, contract dates) recorded in an immutable audit log with old value, new value, actor, and timestamp — so that I can evidence date-change history for regulatory inspections and incident investigations. |
| Priority | MUST |
| Acceptance criteria |
AC1 — Coverage Every date change — via UI, API, or bulk import — writes a log entry. No path bypasses the log.
AC2 — Immutability Log entries cannot be edited or deleted; corrections are appended, not over-written.
AC3 — Retention Entries retained for 7 years per regulatory requirement.
|
| Implements | SJ2.Ph2.Req02 · NFR-SEC-04 (Audit retention) |
| Status | READY |
TC | Start date change cascades to downstream tasks PASSED Functional · Integration ▾
| Test ID | TC-NS-09 |
| Validates | SJ2.Ph2.Req02 · UJ2.Ph3.US07 |
| Pre-conditions | Starter record exists in Core HR with status Active. Original start date D set. 14 provisioning tasks scheduled. |
| Steps |
|
| Expected outcome | All 14 orchestration tasks shifted +5 business days. Audit log entry created with old date, new date, changer, timestamp, count = 14. |
| Evidence type | Screenshot of task list before/after; audit log export row. |
| Test type | Functional + Integration |
| Status | PASSED · 2026-03-12 · QA Lead |
TC | Mandatory fields incomplete → orchestration blocked PASSED Functional ▾
| Test ID | TC-NS-10 |
| Validates | SJ2.Ph2.Req01 · UJ2.Ph3.US06 |
| Pre-conditions | Starter record created with cost centre intentionally blank. |
| Steps |
|
| Expected outcome | No provisioning tasks generated. Exception in PP&C queue naming "cost centre missing", source-of-data hint, escalation owner = Finance BP. Audit entry written. |
| Status | PASSED · 2026-03-12 |
TC | No-show toggle pauses provisioning within 5 min FAILED Functional ▾
| Test ID | TC-NS-11 |
| Validates | SJ2.Ph2.Req04 · AC1 |
| Pre-conditions | Starter scheduled to start today; 8 provisioning tasks in flight. |
| Steps |
|
| Expected outcome | All 8 tasks transition to Paused within 5 minutes. |
| Actual outcome | 6 of 8 tasks paused within 5 minutes. 2 tasks (badge access, payroll setup) remained Running. Linked bug raised. |
| Linked bug | BUG-NS-04 (Badge + payroll subscribers not respecting no-show event) |
| Status | FAILED · 2026-03-13 · re-test pending after BUG-NS-04 fix |
RSK | Incorrect position mapping causes wrong access INHERENT: HIGH RESIDUAL: MED Risk ▾
| Risk ID | RSK-NS-03 |
| Description | ~12% of legacy position records are missing approver, cost centre, or classification. If carried over at cutover, Core HR cannot generate correct provisioning, or generates provisioning to the wrong entitlement bundle — risking either delayed start or over-provisioned access (security event). |
| Threatens | SJ2.Ph2.Req01 · SJ2.Ph2.Req02 · entire New Starter journey |
| Impact | HIGH — Day 1 access fails or over-provisions for ~50 starters in first month; rework cost ~$45k; potential audit finding on access control. |
| Likelihood | HIGH — data quality already evidenced in current state. |
| Inherent rating | CRITICAL |
| Mitigation | Data remediation sprint pre-cutover (PP&C Lead). Mandatory-data gate built into BP Validate starter data (BA). Cutover-day exception process (Change Lead). 100% of mapped records validated before go-live. |
| Residual rating | MEDIUM |
| Owner | HR Domain Lead |
| Status | MITIGATING |
TRN | Manager quick guide — Day 1 readiness PUBLISHED Training · Job aid ▾
| Artefact ID | TRN-NS-01 |
| Type | Quick guide (PDF + Confluence page) |
| Audience | All hiring managers (≈180); secondary: PP&C analysts. |
| Supports journey | JNY | Hire | New Starter — Ready to Work |
| Teaches requirements | SJ2.Ph3.Req01 · SJ2.Ph3.Req02 — flagged for review when these change |
| Outcome | Manager can read the Day 1 checklist, identify red items with their owners, and take the right escalation path — without calling IT. |
| Owner | Change Lead |
| Distribution | Linked from Core HR landing page; emailed on first hire; embedded in LMS induction. |
| Status | PUBLISHED |
How this got produced — the chain in flight
A walk through how the chain runs on one journey. The whole programme is this pattern repeated 13 times, with journeys running concurrently as stakeholder bandwidth allows.
Day 1 morning — workshop. HR domain lead and three SMEs meet with the BA for 90 minutes. Walk through the New Starter journey at the whiteboard. Recording on. Output: a journey synopsis written on a Confluence page, with the recording, the transcript, and a current-state PDF attached at the top of the page.
Day 1 afternoon — HR analyst opens the working page. Page has the artefacts attached and the prompts (§07) embedded as expand-blocks. The analyst — not the BA — copies Prompt 01 into Rovo Chat inside Confluence. Rovo reads the page artefacts, the Epic template, and the Journey Breakdown Example, and produces a draft Epic in the chat sidebar. Analyst reviews it, copy-pastes into Jira. Runs Prompt 02 the same way — gets the User Journey ticket back. Pastes it. Runs Prompt 03 — gets the BP phase table. The pattern across all eight prompts is the same: prompt into Rovo Chat, refined output back, copy-paste into Jira.
Day 2 morning — analyst runs Prompts 04 and 05. First pass produces the requirements table (Prompt 04: phase by phase, seven categories, no invented scope). Second pass refines each requirement into Jira-ready field content (Prompt 05). By lunch, ~30 refined requirement blocks sit in the page. Day 2 afternoon — analyst pastes into Jira, validates each against domain knowledge. They catch one solution bias, two missing exceptions, one mis-classified integration requirement. The BA reviews the batch at end of day: spot-check, not rewrite.
Day 3 — Prompts 06 and 07. Stories generated from approved requirements, then tests, training, decisions, risks. The compliance lead validates the decisions; the test lead picks up the test cases; the change lead picks up the training items.
Day 4 — Prompt 08, BRD generated. Once requirements reach Approved in Jira, the BA runs the BRD-generation prompt against the approved register, the traceability links, and the supporting artefacts. Draft BRD comes back — executive summary, scope by phase, requirements table, traceability matrix, AC, NFRs. BA edits and circulates. Two hours, not two weeks.
The HR analyst — not a BA — wrote the requirements. The BA built the system inside which the requirements got written. The volume above reflects this programme's context; the per-journey pace is independent of context, and the discipline scales down as cleanly as it scales up.
CALIBRATEOn numbers — context shapes volume, the discipline doesn't
▾
The 300+ figure above is a consequence of this programme's context, not a target. A different programme produces a different number. Volume is a diagnostic, not a goal.
Indicative ranges by context:
- ● Single-vendor SaaS rollout, low integration — 30–80 requirements, 1–2 weeks of BA effort. The discipline still applies; the surface is small.
- ● Mid-complexity replatform (e.g. CRM, finance module) — 80–180 requirements, 2–4 weeks of BA effort. Some legacy integration; one or two regulated touchpoints.
- ● Large core-systems transformation with deep legacy entanglement — 250–500+ requirements, 4–8 weeks of BA effort across longer elapsed time. The worked example sits here.
If your number is much higher than your context suggests, the requirements are probably not atomic. If much lower, scope is probably under-elaborated. Quality (atomic, testable, owned, traced) is the bar that holds regardless of count.
What this gives the programme
Line of sight in every direction. Open any test case and walk upward — to the story, to the requirement, to the decision, to the journey. Open any decision and walk downward — to the requirements it enabled, the stories that delivered them, the tests that proved them.
A baseline for change. If a regulation changes and the mandatory-data rule needs to widen, you find the rule, find its requirement, find its stories and tests, and update them coherently. The change is no longer a guess.
Stakeholder ownership. The HR domain lead owns the journey. The compliance lead owns the rule. The IT delivery lead owns the integration story. Each name is on the artefact — not buried in a meeting minute.
Throughput. The per-journey pace (~3–4 days of BA effort) is independent of programme size. A leaner programme finishes proportionally faster; a larger one scales by running journeys in parallel — same chain, more hands.
Audience views — Jira first, HTML as fallback
A signed BRD is a document. Delivery teams, testers, change managers, vendors, and executives don't read documents day-to-day — they navigate. The ideal state is per-audience views configured in Jira itself: same source data, native filtering, live updates. An HTML explorer is an optional fallback for audiences who don't have Jira access. Traceability Maximus, however it's served.
Ideal state — per-audience Jira views
If your audience has Jira access, configure their view in Jira. Each audience gets a saved filter (a JQL query), a board or dashboard, and a stable link to share. No exports, no regeneration, no staleness — the view is the live register, filtered to what matters for that role.
Views to configure (Jira saved filters + dashboards)
Each row is a saved Jira filter plus, where useful, a dashboard built on top of it. The JQL examples assume the issue type names, custom fields, and link types from §07.
| Audience | What they need | Jira filter (JQL) |
|---|---|---|
| Developers | Stories assigned to me or my team, ready to build, with parent requirement and AC one click away. | issuetype = "User Story" AND status in ("Ready", "In Progress") AND assignee in membersOf("dev-team") ORDER BY priority DESC |
| Testers | Test cases by phase, by linked requirement, by status. Surface coverage gaps (requirements without test cases). | issuetype = "Test Case" AND "Phase" = "Preboarding" ORDER BY "Linked Requirement" — paired with a gap filter: issuetype = Requirement AND issueLinkType != "is validated by" |
| Change leads | Training artefacts linked to journeys they own. Surface training items where the linked requirement has changed since last training review. | issuetype = "Training Artefact" AND "Supports Journey" = "JNY-NS-01" |
| Integration architects | Every requirement touching a given system, by integration type and NFR. | issuetype = Requirement AND "Systems Impacted" = "Core HR" AND "Requirement Type" in ("Integration", "NFR") ORDER BY "MoSCoW Priority" |
| Auditors & compliance | Decisions and the artefacts they authorise. Evidence the spine from decision → requirement → story → test. | issuetype = Decision AND status = "Active" — opened to a Structure tree showing each decision's downstream linked Requirements, Stories, Test Cases |
| Vendors / 3rd parties | Requirements scoped to their work-package only. Restricted by Jira permission scheme. | project = "VENDOR-X" AND issuetype = Requirement AND status = Approved AND "Vendor Scope" = "X" ORDER BY "Phase" |
| Executives | A dashboard with headline numbers (Epics, Journeys, Requirements approved, Decisions active, Risks open). Refreshed live. | A Jira dashboard built from count-aggregation gadgets over the above filters. |
SETUPHow to stand the views up
▾
1. Build each filter in Jira → Filters → Create. Name them by audience (RE — Developers: Active Stories). Set permissions so the target audience can see and subscribe.
2. Build dashboards per audience that pin 2–4 filters relevant to them, plus the headline counts. Share-link the dashboard URL with each stakeholder; pin to their Confluence space.
3. For tree views (Decision → Requirement → Story → Test Case), use Structure for Jira, Advanced Roadmaps, or the native Issue Hierarchy view depending on tier.
4. Subscribe stakeholders to email digests on their filter — weekly during build, daily during UAT, on-demand otherwise.
Effort: ~half a day per audience to set up filter + dashboard, plus 30 minutes per stakeholder to walk them through it.
Practical fallback — the HTML explorer
For audiences without Jira access or comfort — external stakeholders, executives who won't log in, vendors before they're provisioned, compliance reviewers from outside the org — generate a self-contained HTML explorer from the Jira data. One file, opens in any browser, search and filter the register, click through the traceability spine. Same data as the Jira views, frozen at the moment of generation. It's an optional addition, not a replacement for Jira views.
BUILDHow the HTML explorer gets built
▾
Two ways to produce it. Same outcome.
Option A — Export to Claude (or another AI runtime) and prompt. Export the approved Jira register to CSV or JSON. Upload the file to Claude. Provide a prompt naming the views you want, the audiences, the brand styling, the navigation structure. Claude generates a self-contained explorer.html with CSS and JS inline. Open and ship.
Option B — Via a Jira MCP connector. If your Claude (or other AI runtime) has a Jira MCP connector, skip the export. Claude pulls the data directly, applies the same generation prompt, returns the HTML. Useful when you want fresh data and don't want to babysit the export.
Refresh cycle. Regenerate on a cadence — weekly during build, daily during UAT, on-demand on request. Each version timestamped. The cover view shows the last refresh date so anyone reading knows how stale the snapshot is.
The worked example's explorer was built via Option A: register exported, uploaded to Claude, prompted for the views, HTML shipped. Half a day for the first version, an hour per refresh.
When to use which
Jira views — audience has Jira access, will look more than twice, benefits from live data (developers, testers, internal change leads, integration architects, internal execs).
HTML explorer — external (vendors before provisioning, compliance reviewers from outside the org), infrequent (execs reviewing once), unfamiliar (no Jira comfort), or offline (steering committee on a tablet, audit walkthrough without VPN).
Both — when the audience is mixed. Jira views as the primary surface; HTML explorer as the share-friendly version.
The maturity arc
Three layers, defined by what kind of work the AI is doing — not by calendar. Each capability inside a layer has its own readiness: some are ready now, some depend on your tooling tier, some are still maturing across the major stacks. Pick a layer to operate at per capability, not as a destination for the whole practice.
The chain in §08 is Layer 1 — that's where the worked example sits, and it works at full scale today. Layers 2 and 3 are not a timeline; they're a capability map. You can be on Layer 1 for prompt invocation and on Layer 2 for drift detection in the same week — because drift detection is one automation rule and two days of build. Maturity here is per-capability. Plan it that way.
Each layer's expand below lists individual capabilities with a readiness pill: EASY WIN if you can implement it from the instructions in this guide using widely-available tooling, TIER-DEPENDENT if it depends on your Atlassian / Microsoft / Google tier or vendor relationship, EMERGING if the platform pieces are still settling.
AI as draft engine
What the AI does. Drafts artefacts on demand from prompts the BA designed. What the human does. Invokes prompts, reviews output, places artefacts into Jira, validates at gates. The chain in §08 is this layer in full. Where the worked example sits — and where most teams should start.
Where to start: pick one journey. Set up §07. Run §08 in Rovo Chat. Ship the requirements. Then scale to the rest.
▾ What to use — 4 capabilities Hide capabilities
AI embedded in the workflow
What the AI does. Runs inside the workflow on triggers and rules — auto-classification on save, drift detection on edit, transcript-to-decisions on workshop end. What the human does. Confirms classifications, reviews AI-drafted decisions, designs the workflows. The BA becomes a workflow designer. Capabilities here vary in readiness — drift detection is a two-day build with native Jira automation; transcript-to-decisions depends on which transcription stack and AI runtime you have.
Where to start: drift detection. One Jira automation rule, two days of build, immediately stops silent re-decisions. EASY WIN
▾ Capabilities — 6 patterns Hide capabilities
AI as oversight loop
What the AI does. Acts on the register on schedule or trigger — sweeps for atomicity violations, watches for decision drift, maintains traceability links, refreshes the BRD when requirements change. What the human does. Reviews agent activity logs, intervenes on exceptions, holds the line on judgement the agent shouldn't make. Some patterns here are buildable today with Jira MCP + Claude or equivalents; others are still being engineered into the platforms.
Where to start: the register-audit agent. It only proposes — it doesn't act. Use it to surface gaps Layer 1+2 missed. EASY WIN via Jira MCP + Claude or Copilot Studio.
▾ Agents worth architecting — 4 patterns Hide agents
How to think about it
Each layer assumes the layer below is reasonable — not perfect, but solid enough for the layer above to add value rather than amplify mess. That's a soft constraint, not a hard gate. Within a single capability you can be anywhere on the curve: drift detection at Layer 2 even if you're still on Layer 1 for everything else. Pick the capability you'd most benefit from advancing, build it, move to the next one.
The temptation is to declare a "Layer N programme" and try to land everything at once. The better move is to advance one capability at a time, hold it until it's stable, then take the next. The chain in §08 is the foundation. The automation rules in §07 are the scaffolding. The agents are the residents that move in when the building is ready.
Discipline
What goes wrong, named out loud. Most failure modes in requirements practice are familiar — most patterns repeat across organisations. Refusing them by name is the start of senior practice.
Part VII is short on purpose. Read it once. Then re-read it every time you start a new programme.
Anti-patterns
Most failure modes in requirements practice are familiar. Naming them out loud is the first step to refusing them.
The compound requirement
Three behaviours in one sentence. Fix: split into one requirement per behaviour.
▾
Three or four behaviours masquerading as one. Cannot be tested as written; cannot be changed without ambiguity. The split is the discipline — atomicity is the test.
The untestable requirement
No measure, no AC, no way to know when it's met. Fix: demand measurable AC before Draft → In Review.
▾
No observable outcome. No measure. No way to know when it's met. A wish dressed as a requirement. These leak through when AC is treated as optional.
The orphan story
A story reaches "Up next" with no linked requirement. Fix: automation rule, not policy.
▾
Work entering delivery without a traceable parent. Quietly becomes scope creep — discovered at UAT, far from where it could be cheaply fixed.
The hidden rule
A business rule buried inside a story's AC. Fix: extract to a RULE work-type, link bidirectionally.
▾
The rule is invisible to compliance, untestable as a standalone, and impossible to find when the policy changes next year. Bury enough rules in AC and policy change becomes a code archaeology project.
Solution masquerading as requirement
"The system must use vendor X's standard workflow." Fix: describe the behaviour, not the implementation.
▾
This is an implementation choice, not a requirement. It pre-empts design, locks in vendor coupling, and removes the BA's evaluation criteria — if the vendor's workflow doesn't suit, the requirement says "yes anyway".
The retrospective acceptance criterion
AC written after build, to match what was built. Fix: AC at Approved, before build starts.
▾
AC has become a tautology — it proves the build matches itself, not that the build matches the requirement. This is the failure mode that produces a green test suite around a wrong feature.
The verbal decision
"We agreed in the workshop that…" but no DEC artefact exists. Fix: write the Decision in the workshop, not after.
▾
Six weeks later, no one remembers what was agreed. The decision is re-litigated. The programme loses days. The original "agreement" turns out to have been three different agreements held by three different people.
Workstream as a domain
"REQ | Phase 2 | …" — workstream label in the name. Fix: name by business domain, which persists.
▾
Workstreams change between projects; domains persist. Names tied to workstream become stale immediately. Two years later, no one remembers what "Phase 2" was — and the requirement looks orphaned.
The "everything" link
Every connection uses "Relates to". The graph is a hairball. Fix: one primary link type per connection.
▾
Relates-to is association, not traceability. Reports based on it lie. Impact analysis becomes impossible — you cannot tell what implements what, what validates what, what blocks what.