Business analysis plan
AlphaHow requirements will be produced, tested and traced — and which design artefacts the scope actually demands.
What it is for
To make requirements a controlled deliverable rather than a by-product of workshops, so that what gets built is what was agreed and what was agreed can be tested.
- Audience
- Analysts, workstream leads, the people who will sign designs.
- The decision it supports
- Whether design will be finished in time to build against.
Inputs — 6 blocking
Blocking means the document cannot be honestly drafted without it. The rest can be left open and marked as such.
Process inventory in scope
From /scope
Every process in scope, including the ones dragged in by a crossing stream. This is the list analysis has to get through, and it is usually larger than the picks suggest.
Delivery
Design artefact list per sub-module
From /scope
What has to exist before a sub-module can be called designed — the decision that constrains everything else, the design itself, and the part most often skipped.
Analysts
Subject matter expert availability
Only you have it
Per business area, who can answer and how much of their time is released. The binding constraint on analysis is almost never analyst capacity.
Business owners · Digital Transformation Readiness Checklist
Sign-off authority per area
Only you have it
Who signs each design, and whether they will be present at user acceptance. Sign-off by someone who never uses it is a formality.
Business owners · Functional Specifications
Requirement and specification template
In the library
One template, carrying data, rules, exceptions, volumes and testable acceptance criteria. Plain language, in the organisation's own words.
Analysts · Functional Specifications
Standard-first position
In the library
The rule that every departure from the product's standard behaviour is justified in writing, and who may approve one.
Delivery and technology · Development Standards
Draft around these if needed
Traceability approach
In the library
Requirement to specification to test case to defect, so coverage is a fact rather than an assertion.
Analysts and test · Functional Specifications
Current-state documentation, such as it is
Only you have it
Whatever exists, plus an honest note on where it is wrong. Documentation drifts; verify rather than trust.
Business owners · ERP Health Check
Interfaces to specify
From /scope
The hand-offs where one side is being changed and the other is not — the interfaces most often missed at scoping and found during testing.
Technology · Integration Catalogue
Data and volume profile
Only you have it
Transaction volumes at peak, master data counts and measured quality. Designs sized on test data fail at year end.
Data · Data Migration
Bring a scope
Several of these inputs can be answered from a scope — the processes in play, the artefacts they demand, the interfaces that straddle the boundary, and the order the work falls into. Pick the areas you intend to change and come back.
Scope it first →Outline
- 01Approach and analysis method
- 02Processes in scope, and what is out
- 03Artefacts per sub-module, with owners
- 04Workshop and elicitation approach
- 05Templates, standards and plain-language rules
- 06Standard-first and the customisation position
- 07Traceability and acceptance criteria
- 08Sign-off authority by area
- 09Schedule, dependencies and SME load
What separates a useful one from a compliant one
- —Every requirement has testable acceptance criteria — nothing that two people could read differently.
- —Exception paths are in scope for analysis, not deferred to build.
- —Each design has a named signer who will be at user acceptance.
- —SME load is planned against released capacity, not against optimism.
- —Every specification answers why standard behaviour was insufficient.
The rest of the set