Requirements across the project lifecycle

There's a common misconception that "requirements" is an early phase you complete and move on from. In practice, requirements run the entire length of a project — they just change shape at each stage. Managing that evolution well is a lot of what separates a smooth delivery from an expensive one.

Here's how I think about requirements across a standard project lifecycle — from the first business need to a validated, adopted solution.

Requirements change shape at every stage: business requirements → solution requirements → built and tested → validated – with traceability and change control running throughout.

Initiation — the case for change

Requirements begin as business requirements: the why. Before anyone reaches for a solution, the work is to understand the business need, map the As-Is, identify the real stakeholders, and draft and prioritise what the business actually needs to achieve. The output is a prioritised set of business requirements and a defensible case for change.

Planning — scope and define

With the need agreed, requirements sharpen into solution requirements: the what. This is where you agree scope, run elicitation workshops, design the To-Be process, and prioritise and baseline the detail. Get the scope honest here and you save a fortune later.

Execution — realise and assure

Now requirements are built and tested — and the analyst's job doesn't end at handover to the build team. It's writing clear acceptance criteria, defining test scenarios from those criteria, and triaging defects against what was actually specified. A requirement isn't done because it's built; it's done when it's proven.

Closure — validate and hand over

Finally, requirements are validated: user acceptance and sign-off, tracing each requirement back to the business need it served, supporting adoption and training, and confirming the benefits the project set out to deliver. This is where you prove the change was worth making.

The thread that runs throughout

One "stage" isn't really a stage at all. Monitoring & Control runs across the whole project — requirements traceability, change control and impact analysis are the discipline that keeps every requirement accounted for, from business need to validated outcome. Skip it and requirements quietly drift; keep it and you always know why every requirement exists and what changing it would cost.

Why it matters

Treating requirements as a lifecycle rather than an early phase is what makes delivery auditable and change affordable — and it's what lets an organisation prove, to itself and to a regulator, that what it built is what it needed. That's the difference between documenting requirements and genuinely managing them.