Business analysis / Requirements structure
Connect the business outcome to the detail
Grouping requirements helps a team see why a change matters, manage its scope and retain the links from a business need through to acceptance. We would agree a proportionate structure with the client, using stable IDs and clear ownership.
Business Requirements Document / BRD
Agree the business need before specifying the solution.
Where a consolidated requirements baseline is useful, SCP can help prepare or review a BRD with the client. It records the business problem, intended outcomes and success measures, scope and exclusions, stakeholders, business requirements, constraints, assumptions, dependencies and approval responsibilities.
Give requirements stable IDs, a source, rationale, priority and owner. Include or link the relevant process descriptions, business rules, detailed requirements and acceptance criteria. Record the approved version, open points and decisions so providers and internal teams work from the same agreed need.
The BRD establishes the business context and requirements; a functional specification develops the required solution behaviour, while HLD and LLD describe the technical design. Keep those links explicit. In iterative delivery, equivalent controlled backlog and repository records may fulfil this purpose without duplicating everything into a separate document.
A BRD is a document container, not another level in the epic–feature–requirement hierarchy. Its approval does not replace design review, testing or UAT. Assess later changes through change control.
Further reading: IIBA: Business Requirements Document resource ↗. The content and review approach described here are SCP proposals.
- Business outcome: the measurable improvement sought, with its baseline, scope and sponsor.
- Epic: a substantial body of related work supporting that outcome. Agree its boundary and success measures.
- Feature: a coherent capability within the epic, small enough to assess and plan. Define what it enables and its dependencies.
- Detailed requirements: specify the needed behaviour, rules, data and quality constraints. User stories can express a user's goal and reason; use cases describe interactions, alternative paths and exceptions.
- Acceptance criteria: define the specific, testable conditions each requirement must satisfy, expressed as Gherkin Given/When/Then scenarios where appropriate.
Linked underneath: testing and UAT evidence
Acceptance criteria → linked test cases → recorded results and defects → authorised acceptance decision. Retain the criterion version, test environment, tester and evidence so the team can see what was proved and what remains unresolved. The criteria define what must be met; testing and UAT evidence record whether it was met.
User stories and use cases are complementary ways to describe requirements. A use case may support several stories; it does not have to be a child work item. Security, accessibility, data freshness and performance requirements may apply across several features and should be linked wherever they need verification. Tasks describe the work to deliver the change.
A Customer Promise Protection example
Synthetic example — proposed SCP grouping, not a client implementation.
- Outcome CPP-01: improve fulfilment against the frozen customer promise, assessed alongside full operating costs. Targets would be agreed with each client.
- Epic EP-CPP-01: Customer Promise Protection.
- Feature FE-CPP-01: recognise and prioritise order risk. Groups US-01, US-02 and US-03 in the worked example.
- Story US-03: enable a planner to validate supply information before acting. Linked use case UC-CPP-01 describes reviewing an exception, checking freshness and requesting a correction when needed.
- Criterion AC-06: Given supply information is exactly 24 hours old, When freshness is assessed, Then it remains current under the synthetic rule.
Linked evidence for AC-06
AC-06 → UAT-06 → actual result, supporting evidence and any defect → authorised acceptance decision. UAT-06 remains Not run. The separate Python reference check passes; it does not constitute client UAT or acceptance.
Review testing and UAT status →
The other proposed features group controlled recovery (US-04, US-05), event handling and audit (US-06, US-07), and benefits measurement (US-08). Keep the tested version of each criterion and the evidence together when a requirement changes.
Manage the structure without losing the links
- Record an ID, parent or related item, owner, source, priority, status and version. Link dependencies and cross-cutting requirements explicitly.
- Prioritise features by value, risk and dependencies, then refine the detailed requirements with users. Assess changes against scope, tests and expected benefits.
- Use Define to establish the outcome and initial groups; refine them through Understand and Design; verify them in Test, prove and embed; monitor the outcome in Sustain and improve.
- Apply this to Control Tower workflows, automation readiness and other services where process or system changes require clear requirements and acceptance.
Tool mapping: Azure Boards provides Epic and Feature levels above requirement-level items; the item name depends on the chosen process. Jira commonly groups stories under epics, so a separate Feature level needs an agreed mapping or suitable configuration. Confluence can hold linked use cases, process descriptions and decision records. Agree the structure around the client's tools rather than assuming the same hierarchy everywhere.
References: Microsoft: organise features and epics; Microsoft: work item types; Atlassian: epics and stories. Source guidance reviewed 17 October 2026; the grouping and example above are SCP proposals.
