The waterfall model: what Royce actually proposed
The paper that introduced waterfall described it as risky and recommended iterating. How the model works, why it persists, and where it is genuinely the right answer.
The waterfall model is sequential development: requirements, then design, then implementation, then verification, then maintenance. Each phase completes and is signed off before the next begins, and the output of one is the input to the next.
The irony in its origin
The model is traced to Winston Royce's 1970 paper "Managing the Development of Large Software Systems". Royce drew the sequential diagram — and then wrote, of that very diagram, that the approach is "risky and invites failure".
The rest of his paper argues for iteration: build a pilot version first, involve the customer throughout, expect to return to earlier phases. The diagram was adopted and the argument accompanying it was not. Royce never used the word "waterfall"; it was applied later by others.
The phases
- Requirements. Everything the system must do, captured and agreed.
- Design. Architecture and detailed design derived from those requirements.
- Implementation. Code written to the design.
- Verification. Testing against the requirements.
- Maintenance. Corrections and changes after release.
The defining property is the gate between phases. Design does not start until requirements are signed off, which is what makes the model auditable — and what makes it brittle.
The real problem
The cost of a change rises sharply with how late it is found. A misunderstood requirement caught during the requirements phase costs a conversation. The same misunderstanding caught during acceptance testing means redesign, reimplementation and retesting.
Waterfall concentrates validation at the end, which is precisely where errors are most expensive. And it assumes requirements can be known completely in advance — which holds for a payroll system with a legal specification, and does not hold for a product whose users have not seen anything yet.
Where it is genuinely appropriate
Dismissing waterfall entirely is as unthinking as applying it everywhere. It is the right choice when:
- Requirements are externally fixed. A regulation, a published standard, a protocol specification.
- Iteration is expensive. Firmware in shipped hardware, or anything where a release requires recertification.
- The evidence trail is the deliverable. Medical devices under IEC 62304, avionics under DO-178C, and similar regimes require traceability from requirement to test that a sequential process produces naturally.
- The contract demands it. Fixed-price, fixed-scope agreements need a specification to be fixed against.
The V-model
A common variant that bends the sequence into a V: each phase on the way down has a corresponding verification activity on the way up. Requirements pair with acceptance testing, architecture with integration testing, detailed design with unit testing.
The improvement is real. Test planning happens alongside each phase rather than at the end, so ambiguous requirements are found while writing the acceptance criteria — early, when they are still cheap.
Choosing between the models
The useful question is not which is better but how much you already know:
- Requirements known and stable, iteration expensive — sequential, with a V-model's early test planning.
- Requirements uncertain, iteration cheap — iterative, with the technical practices that make change affordable.
- Some of each — which is most real projects. A stable regulated core delivered sequentially, with a user-facing layer developed iteratively, is a normal and defensible arrangement.
Royce's own recommendation still holds: whichever you choose, build something early enough to discover what you got wrong while it is still affordable to fix.
