Waterfall is the oldest formal software development lifecycle (SDLC) model still in active use. It organises a project into a fixed sequence of phases - each one completed before the next begins - producing a fully specified, fully documented system before any integration or delivery occurs. The model is frequently cited as the antithesis of Agile, but the historical record is more nuanced than that framing suggests.

The Royce Paper and What It Actually Said

The waterfall model is commonly attributed to Winston W. Royce’s 1970 paper, “Managing the Development of Large Software Systems,” published in the proceedings of IEEE WESCON. Royce illustrated a sequential phase diagram - Requirements, Preliminary Design, Detailed Design, Code, Test, Operations - and immediately called it “risky and invites failure.”

His actual recommendation was an iterative model with explicit feedback loops between adjacent phases. He advocated building a pilot system, throwing it away, and then building the real system - a concept that anticipates modern iterative approaches by decades. The widespread adoption of the diagram without its accompanying critique is one of the more consequential misreadings in the history of software engineering.

The Sequential Phases

Despite Royce’s caveats, the sequential waterfall model as commonly practised defines five or six phases:

  1. Requirements - All functional and non-functional requirements are gathered, documented, and signed off. The output is typically a Software Requirements Specification (SRS).
  2. Design - Architects translate requirements into system architecture, database schemas, API contracts, and component designs. The output is a Design Document.
  3. Implementation - Developers write code against the frozen design. No requirements changes are accepted during this phase.
  4. Verification - Testers validate the implemented system against the original requirements. Defects are fed back to implementation.
  5. Maintenance - The deployed system receives bug fixes and minor enhancements. Major new features typically restart the cycle.

The defining characteristic is that each phase produces a deliverable (a document or artifact) that is reviewed and formally approved before the next phase begins. This creates a clear audit trail, which is why the model persists in regulated industries.

The V-Model Extension

The V-Model (Verification and Validation Model) extends waterfall by pairing each development phase on the left side of a “V” shape with a corresponding test phase on the right:

Requirements            System Testing
    \                       /
  System Design       Integration Testing
      \                   /
    Module Design   Unit Testing
            \       /
            Implementation

The key insight is that test planning for each level begins at the same time as the corresponding design phase, not after implementation. This addresses one of the core weaknesses of pure waterfall - the deferred discovery of requirements defects - by making verification a continuous concern rather than a final gate.

The V-Model is mandated or strongly preferred in safety-critical domains including aerospace (DO-178C for avionics software), automotive (ISO 26262), and medical devices (IEC 62304).

When Waterfall Still Makes Sense

The persistence of waterfall is not simply organisational inertia. There are genuine project characteristics that favour sequential delivery:

Regulatory and compliance contexts. FDA Class II and III medical device software, nuclear instrumentation, and defence systems require documented evidence that requirements were established before implementation began. Waterfall’s phase gates generate exactly that documentation.

Fixed-price, fixed-scope contracts. Government procurement and large enterprise contracts frequently lock scope, schedule, and price before work begins. Waterfall aligns with this commercial structure because it front-loads the negotiation of scope. Agile scope flexibility is incompatible with fixed-price contracting without significant contract restructuring.

Hardware-coupled systems. When software development runs in parallel with hardware manufacturing, changing requirements mid-cycle may invalidate already-fabricated components. The cost of change in these environments justifies the cost of upfront specification.

Well-understood, stable problem domains. Migration of a legacy system to a new platform, where the behaviour of the legacy system is itself the specification, is a reasonable candidate for waterfall. The requirements are known; the risk is implementation, not discovery.

Criticisms and Failure Modes

Waterfall’s weaknesses are well documented and were already understood by Royce in 1970:

Late integration. All components are built and tested in isolation, then integrated at the end of the project. Integration failures - mismatched APIs, conflicting assumptions, emergent performance problems - surface only when there is no time to address them properly. This is sometimes called the “big bang” delivery problem.

Change resistance. A formal change control process is necessary to protect scope, but it also makes the system brittle. Requirements discovered to be wrong or incomplete after sign-off trigger expensive rework that cascades through design, implementation, and test documents.

No working software until late. Stakeholders see documentation and prototypes, not running software, for most of the project lifecycle. This delays feedback and means that misunderstandings in the requirements document compound undetected for months or years.

Optimistic upfront estimation. Waterfall projects require detailed estimates before the team has learned anything about the problem. These estimates are systematically too optimistic. Studies by the Standish Group (the CHAOS Report series) consistently found that large waterfall projects have high rates of cost overrun, schedule slippage, and outright cancellation.

A Practical Example: Requirements Sign-Off

A waterfall requirements document for a payments system might include a section like this:

REQ-PAY-042: The system shall process a payment authorisation request
             within 2000ms at the 99th percentile under a load of
             500 concurrent users.

Accepted by: [Business Sponsor]  Date: [Date]
             [Technical Lead]    Date: [Date]
             [QA Manager]        Date: [Date]

This triple sign-off creates legal accountability and an audit trail. It also means that if the 99th-percentile target turns out to be technically infeasible at reasonable cost, discovering that fact during performance testing - ten months later - is catastrophic. Under an iterative approach, a performance spike in week two would have surfaced the constraint early.

Relationship to Other Methodologies

Waterfall’s limitations drove the development of iterative and incremental approaches throughout the 1980s and 1990s - the Spiral Model (Boehm, 1986), the Rational Unified Process, and Feature-Driven Development among them. The frustration with these heavyweight successors in turn motivated the Agile movement. See Agile Manifesto for that history.

The Scrum framework, described in Scrum Framework, is the most widely adopted alternative to waterfall in commercial software development today.

Sources

  • Royce, W. W. (1970). “Managing the Development of Large Software Systems.” Proceedings of IEEE WESCON, 26, 1-9. Reprinted in Proceedings of the 9th International Conference on Software Engineering, 1987.
  • Boehm, B. (1988). “A Spiral Model of Software Development and Enhancement.” IEEE Computer, 21(5), 61-72.
  • Forsberg, K., and Mooz, H. (1991). “The Relationship of System Engineering to the Project Cycle.” Proceedings of the National Council for Systems Engineering.
  • Standish Group. CHAOS Report (various years). The Standish Group International.