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
What your scope already answers
- Scope and exclusions: 11 topics across 2 modules — including Financial Accounting, unpicked.
- Artefacts to produce: 10 across 2 releases, 1 of them decisions that constrain what follows.
- Interfaces to specify: 6, including the hand-offs where only one side is being changed.
- Assumed already in place: Core HR — depended on, not included.
First draft
2/9 sections the scope could speak to
Generated from your scope. It is not a finished document and it does not pretend to be — where a section needs something only you have, it says so rather than inventing a plausible sentence, because plausible sentences are the ones that get left in.
Business analysis plan
Approach and analysis method
10 artefacts have to be produced across the releases, 1 of which are decisions that constrain everything after them. 6 interfaces need specifying on both sides.
End to end, the work sits on 1 value stream: Time-to-Pay.
Processes in scope, and what is out
The change covers 1 chosen area — Long Service Leave — which in turn implies 11 topics across 2 modules: Human Capital Management and Financial Accounting.
Financial Accounting was not chosen. It is in scope because the value streams the chosen areas sit on cross into it, so work happens there whether or not it was planned for. This needs to be accepted or the scope reduced — it should not be left unstated.
Artefacts per sub-module, with owners
To write. The scope cannot supply this one.
Workshop and elicitation approach
To write. The scope cannot supply this one.
Templates, standards and plain-language rules
To write. The scope cannot supply this one.
Standard-first and the customisation position
To write. The scope cannot supply this one.
Traceability and acceptance criteria
To write. The scope cannot supply this one.
Sign-off authority by area
To write. The scope cannot supply this one.
Schedule, dependencies and SME load
To write. The scope cannot supply this one.
Still needed
- Subject matter expert availability — Per business area, who can answer and how much of their time is released. The binding constraint on analysis is almost never analyst capacity.
- Sign-off authority per area — Who signs each design, and whether they will be present at user acceptance. Sign-off by someone who never uses it is a formality.
As markdown, to lift into a document
# Business analysis plan ## Approach and analysis method 10 artefacts have to be produced across the releases, 1 of which are decisions that constrain everything after them. 6 interfaces need specifying on both sides. End to end, the work sits on 1 value stream: Time-to-Pay. ## Processes in scope, and what is out The change covers 1 chosen area — Long Service Leave — which in turn implies 11 topics across 2 modules: Human Capital Management and Financial Accounting. Financial Accounting was not chosen. It is in scope because the value streams the chosen areas sit on cross into it, so work happens there whether or not it was planned for. This needs to be accepted or the scope reduced — it should not be left unstated. ## Artefacts per sub-module, with owners > To write. The scope cannot supply this one. ## Workshop and elicitation approach > To write. The scope cannot supply this one. ## Templates, standards and plain-language rules > To write. The scope cannot supply this one. ## Standard-first and the customisation position > To write. The scope cannot supply this one. ## Traceability and acceptance criteria > To write. The scope cannot supply this one. ## Sign-off authority by area > To write. The scope cannot supply this one. ## Schedule, dependencies and SME load > To write. The scope cannot supply this one. ## Still needed - **Subject matter expert availability** — Per business area, who can answer and how much of their time is released. The binding constraint on analysis is almost never analyst capacity. - **Sign-off authority per area** — Who signs each design, and whether they will be present at user acceptance. Sign-off by someone who never uses it is a formality. _First draft from a scope. 2 of 9 sections had something the scope could say; the rest need a person, and so does everything under Still needed._
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