Waterfall model

The Waterfall model is often attributed to Winston W. Royce, who described it in a 1970 paper, though he did not use the term "waterfall" and actually criticized the model as risky.¹ Royce's paper, titled "Managing the Development of Large Software Systems," presented the sequential phases as a strawman, arguing that iterative feedback between phases was necessary. The term "waterfall" was popularized later, possibly by the U.S. Department of Defense, which adopted the model in its standards such as MIL-STD-2167A.² The model's linear structure mirrored earlier engineering and manufacturing processes, and it became the dominant approach in the 1970s and 1980s, especially for large government and defense projects.

The Waterfall model typically consists of five to seven phases: requirements analysis, system design, implementation, testing, deployment, and maintenance.³ Each phase produces specific deliverables, such as a requirements document, design specifications, code, and test reports. The model assumes that requirements can be fully understood upfront and that changes are costly, so it emphasizes documentation and formal reviews at each stage. This makes it suitable for projects with stable, well-defined requirements, such as safety-critical systems in aerospace or medical devices, where traceability and rigorous validation are essential. However, its rigidity can lead to late discovery of errors and poor adaptability to changing user needs.

Critics argue that the Waterfall model is unrealistic because real projects rarely follow a linear path; requirements evolve, and feedback loops are necessary.⁴ The model has been blamed for project failures where stakeholders only see a working product at the end, leading to mismatches with actual needs. In response, iterative and incremental models such as the Spiral model, V-model, and later agile frameworks like Scrum were developed to address these weaknesses.⁵ The V-model, for instance, emphasizes verification and validation by mapping each development phase to a corresponding testing phase. Despite criticism, the Waterfall model remains a foundational concept in software engineering education and is still used in contexts where requirements are fixed and regulatory compliance demands a sequential approach.

One lesser-known fact is that Royce's original paper included a diagram that is often misrepresented as the Waterfall model; his actual recommendation was for a two-step iterative process.¹ Another obscure detail is that the model has been applied beyond software, such as in hardware development and construction, where sequential phases are more natural. Additionally, the Waterfall model influenced the Capability Maturity Model (CMM) for software process improvement, which emphasizes defined, repeatable processes.⁶ Some niche applications include safety-critical systems in the nuclear and aviation industries, where the model's documentation-heavy approach supports certification. The model also appears in academic curricula as a baseline for comparing other methodologies, and its terminology is used in project management standards like the PMBOK.

Phase

A distinct stage in the Waterfall model, such as requirements or testing, that must be completed before the next begins.

Deliverable

A tangible output produced at the end of a phase, such as a document or code.

Iterative development

An approach that revisits phases in cycles, in contrast to the linear Waterfall model.