← Back to PortfolioPhase 1Phase 2Phase 3Phase 4Phase 5
Phase 03 of 05
Define & Analyse
Chs 5 & 6
Business Analysis Demystified · Zoomed Phase Map
Requirements & Scope · Gap Analysis
This is where the work becomes contractual. Requirements define precisely what must be built and what is not in scope. Gap analysis quantifies the distance between where things are now and where they need to be. Together they provide the evidence base for the business case and the specification base for delivery. Both require the same discipline: specificity over comfort.
The question this phase must answer
“
The fundamental question of Phase 3
Can we state precisely what must change, what the system or service must do, what is explicitly out of scope, and what the cost of the current gap is — in terms that a decision-maker can act on?
Requirements that say "the system should be easy to use" are not requirements — they are hopes. Gap analysis that describes a gap without quantifying it gives decision-makers a reason to defer rather than act. Both artefacts require the practitioner to be uncomfortable with vagueness.
Chapter artefacts & prompts
CH.05
Requirements & Scope
Define precisely what must be built — and what must not
Requirements Document
Functional and non-functional requirements, each with an owner, a priority (MoSCoW), and a testable acceptance condition. No requirement without a test.
Scope Statement
What is in scope and what is explicitly out of scope. The out-of-scope list is as important as the in-scope list — it is what prevents scope creep.
MoSCoW Prioritisation
Must Have / Should Have / Could Have / Won't Have. Makes trade-off decisions explicit before delivery rather than implicit during it.
Prompts
P01 Orient Me
P02 Show Me an Example
P03 Generate Requirements
P04 MoSCoW Prioritisation
P05 Write Non-Functional Requirements
P06 Define the Scope Boundary
P07 Challenge My Requirements
P08 Review My Draft
CH.06
Gap Analysis
Quantify the distance between now and where you need to be
Gap Analysis
A structured comparison of current state and future state — what exists, what is needed, what is missing, and what that gap costs in measurable terms.
Prompts
P01 Orient Me
P02 Show Me an Example
P03 Build a Gap Analysis
P04 Quantify the Gap
P05 Prioritise the Gaps
P06 Link Gaps to Requirements
P07 Challenge My Gap Analysis
P08 Review My Draft
How the work flows through this phase
01 / 06
Map current state
What exists now? What does it do? What does it not do? Grounded in observation, not assumption.
02 / 06
Define future state
What must exist after the change? Specific enough to be testable. Vague future states produce vague requirements.
03 / 06
Identify the gaps
What is missing, broken, or insufficient? Named specifically — not "the system is slow" but "response time exceeds 8 seconds under normal load."
04 / 06
Quantify the gap cost
What does the gap cost in time, money, risk, or compliance exposure?
⚡ Gap analysis without quantification invites deferral
05 / 06
Write requirements
Each gap becomes one or more requirements. Each requirement gets an owner, a priority, and a test condition.
06 / 06
Apply MoSCoW
Make priority decisions explicit. Must Haves define the minimum viable product. Won't Haves close scope creep doors.
Practitioner confidence curve
Phase startPhase end
Structured, methodical
Scope becomes real
Gap is uncomfortable
Evidence is solid
Traps & failure modes
Trap 01
Untestable requirements
"The system shall be user-friendly" cannot be tested. Every requirement must have a condition under which a tester can say pass or fail. If you cannot write that condition, the requirement is not yet a requirement.
Trap 02
Gap analysis without numbers
A gap analysis that describes the gap without quantifying it gives decision-makers a reason to defer. "We are missing X capability" is an observation. "That gap costs us £180k per year in manual processing" is a case for action.
Trap 03
Scope creep by omission
The out-of-scope list matters as much as the in-scope list. Requirements that expand without MoSCoW become a scope creep engine. The Won't Have list is what closes the doors before delivery opens them.
Feeds forward & practitioner signals
→What this phase feeds into
→
Phase 4 — Make the Case
The quantified gap is the financial case. Requirements define what the investment must deliver. Both are essential inputs to Ch.7 business cases.
→
Phase 5 — Deliver & Close
Requirements feed directly into Ch.8 process maps, Ch.10 use cases, and Ch.12 agile backlog decomposition.
💬What practitioners say at this phase
💬
The gap is bigger than anyone admitted.
💬
This is the first time the scope has felt real.
💬
Requirements keep expanding — I need to use MoSCoW.
💬
If I can't write a test for it, it isn't a requirement.
Business Analysis Demystified
16 prompts · 2 chapters · Phase 3 of 5