Waterfall: The Original Sequential Model

EveryEvery methodology course starts by knocking Waterfall down, usually without reading the paper that supposedly invented it. That's worth fixing, because the real history complicates the story in a useful way: the model students are taught to despise is not quite the model its most-cited source actually proposed, and the model does have places where it is still the right tool.

The Classic Sequence

WaterfallWaterfall structures a project as a chain of phases, each completed and signed off before the next begins:

The appeal is obvious: a plan you can put a Gantt chart on (see Gantt Charts), a contract you can price, and a paper trail that shows exactly what was agreed at each stage. The cost is equally obvious: nothing discovered in verification can cheaply change a decision made in requirements, because three phases and their sign-offs sit in between.

The Royce Paper: What It Actually Says

TheThe strict, one-pass version of Waterfall is almost always attributed to Winston W. Royce's 1970 paper "Managing the Development of Large Software Systems," presented at IEEE WESCON¹. This attribution is the field's most durable case of citing a paper for the opposite of what it says. Royce opens by describing the simple sequential model — exactly the diagram above — and then states plainly that implementing it in that pure form "is risky and invites failure"¹. The rest of the paper argues for modifications: feedback loops between adjacent phases so problems found downstream can correct the phase that caused them, doing the design twice (the second pass informed by lessons from the first), involving the customer at more than just the requirements and delivery stages, and building a pilot or prototype before committing to the full system. In other words, the paper most often cited as Waterfall's founding document is itself an early argument for iteration.

How the misattribution happened is itself a lesson: later authors and defence-contracting standards (notably the US DoD's 2167A) reproduced Royce's first diagram — the simple one, used as a strawman — without the surrounding argument, and the strawman became the industry's mental model of "the" waterfall method². The takeaway for a working engineer isn't just historical trivia: it's a standing warning about citing a diagram without reading the argument around it.

Where Waterfall Genuinely Still Fits

Agile'sAgile's critique of Waterfall assumes requirements will change and that this is normal and healthy. That assumption doesn't hold everywhere, and where it doesn't, sequential, gated development is the more honest choice rather than a legacy habit:

• Fixed-scope, fixed-price contracts. When the customer needs a firm number before work starts, a signed-off requirements phase is the mechanism that makes the number defensible for both sides. Changing requirements mid-contract becomes a formally priced change order, not a backlog reprioritisation — which is exactly what a public-sector procurement process usually requires.
• Safety-critical and regulated systems. Aviation software under DO-178C and medical device software under IEC 62304 require traceability: every requirement must map to a design element, to code, and to a test case, with the paper trail preserved for audit and certification. Freezing requirements before implementation isn't bureaucratic overhead here — it's what makes the traceability matrix possible at all, and what a regulator will ask to see. This is the same verification discipline the V-Model formalises, and the V-Model is essentially Waterfall folded to pair every decision with its check.
• Hardware-coupled or one-shot deliveries. Firmware shipped on a manufactured device, or software for a satellite that cannot be patched after launch, cannot rely on "release early, iterate later" — there may be no later release.

In each case "no changing requirements" is not Waterfall's weakness — it's the property the customer or regulator is actually paying for. The lesson isn't that Waterfall is right and Agile is wrong, or vice versa; it's that the two models optimise for different, sometimes mutually exclusive, guarantees. Most real organisations end up blending them — see Hybrid Waterfall/Agile — and Choosing a Methodology works through how to decide which guarantee a given project actually needs.

See Also

ForFor the testing philosophy that grew directly out of Waterfall's phase structure, see The V Model. For what replaced Waterfall as the default assumption in most software teams, see Agile: Origins and the Manifesto. For managing the schedule risk Waterfall makes visible on a chart, see Critical Path & PERT and Work Breakdown Structure.

References