Waterfall

Waterfall on one screen

Here is the whole model first. Waterfall is defined less by its phases than by what closes each one: a document, a review and a signature. The table walks through the five phases in order — what each one produces, what must be true before anyone may leave it, and what a change costs if it is discovered there.

Whether to use the model at all is decided by one number — what it costs you to change your mind late — and the fifth section turns that number into six questions you can answer about your own project.

What Royce actually wrote in 1970

Now for a piece of history worth knowing, because it changes how you read every diagram of this model you will ever see.

The cascade comes from a paper that Winston Royce, a manager at the defence contractor TRW, presented at the WESCON conference in August 1970: "Managing the Development of Large Software Systems". His second figure shows seven steps in a line — system requirements, software requirements, analysis, program design, coding, testing, operations. The word "waterfall" appears nowhere in the paper. Thomas Bell and T. A. Thayer are usually credited with attaching that name to it, in 1976.

A page later, Royce wrote: "I believe in this concept, but the implementation described above is risky and invites failure." His reason is precise. Testing is the first moment at which timing, storage and input and output are experienced rather than analysed. If they fail their constraints, the design has to change, and then, in his words, "the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs."

He spent the rest of the paper on five additions that make the sequence survivable. The table gives each one under his own heading, what he asked for, and what the same idea is called today.

His son, Walker Royce, who later helped build the Rational Unified Process, told Craig Larman and Victor Basili that his father "was always a proponent of iterative, incremental, evolutionary development", and that the paper described the waterfall as the simplest description, one that "would not work for all but the most straightforward projects" (IEEE Computer, 2003).

The five phases, one at a time

Let us walk through each phase: what happens in it, what it produces, and the question that has to be answered before you are allowed to move on.

1. Requirements

Everything the system must do is gathered and written down. Not just features — also the non-functional requirements: how fast, how many users at once, what must be logged, which regulations apply.

The output is a specification, and the gate question is: do we all agree this is what is being built? The signatures here are what make everything downstream possible — and what makes a late change a contractual matter rather than a conversation.

One test separates a usable requirement from a wish: can someone write down how it would be checked? "The system shall be fast" cannot be tested. "Search returns results within two seconds for 95 percent of queries, with 500 users online" can — and the V-model below makes that test part of the requirement.

2. Design

The specification is turned into a technical plan. This usually splits in two: high-level design decides the components and how they talk to each other, and detailed design decides what happens inside each one.

The gate question is whether this design can actually meet the specification. This is the phase where an experienced architect earns their keep, because a structural mistake found here costs a week and the same mistake found during testing costs a quarter.

3. Implementation

The code gets written, following the design. Developers write unit tests as they go, but there is no integrated system to try yet — components are built against the interfaces the design specified rather than against each other.

This is the longest phase and, counter-intuitively, the calmest. Everything has been decided; the work is execution. It is also where the project is most likely to be quietly behind, because there is no working system to measure progress against — only percentages of completion.

4. Verification

The pieces are integrated and tested together, then handed to the customer for acceptance testing. This is the first moment anyone sees the whole system behave.

And this is where the model’s central weakness shows. Every assumption made in requirements — nine months ago, by people who had never used the thing — is tested at once, at the point where correcting any of them is most expensive.

5. Maintenance

The system is live. Defects are fixed, small changes are made through a formal change request process, and the product runs until it is replaced.

Worth noting: in most waterfall projects this phase is longer than all the others combined, and it is usually the one nobody plans for properly.

The V-model: every phase paired with its test

There is a variant worth knowing, because it fixes the biggest practical problem with the pure model and you will meet it in regulated industries.

The V-model takes the same phases and bends the line into a V. The left arm goes down through requirements, design and detailed design. The right arm comes back up through the corresponding levels of testing. Each phase on the left is paired with the test level that will verify it.

The practical gain is that the acceptance tests are written during the requirements phase, not after the build. That forces a useful question early: how would we prove this requirement is met? A requirement nobody can write a test for is a requirement nobody has understood, and the V-model surfaces those in month one rather than month nine.

The shape has two independent origins. In Germany, the V-Modell was developed from 1986 by IABG for the Federal Ministry of Defence, taken over for civilian federal agencies in 1992, and revised as V-Modell 97 and then V-Modell XT, which German federal IT projects still use. In the United States, Kevin Forsberg and Harold Mooz presented a "Vee" for systems engineering at the first NCOSE symposium in 1991.

The two halves of the right arm answer different questions, and Barry Boehm gave them their standard wording in 1981. Verification asks "are we building the product right?" — does the build match the specification? Validation asks "are we building the right product?" — was the specification what the user needed? Integration and system testing verify. Only acceptance testing validates.

When a predictive plan is cheaper: six questions

Strip away the culture war and the choice between Waterfall and Agile comes down to a single number: how much does it cost you to change your mind late?

That number is hard to state directly, so here it is split into six questions. Each row says which answer points to a predictive plan and which to an iterative one. Most projects answer some each way, and the mix — not the majority — tells you which parts to plan up front and which to discover by building.

Why the answers matter comes down to when risk is retired. A risk is retired when something runs and proves an assumption right or wrong — not when a document describing the assumption is signed. A single pass retires little until integration; an iterative plan retires some every time something runs in front of someone.

• Change is cheap → iterate

  A web service with automated tests and continuous deployment. A wrong decision costs a redeploy. Deferring decisions costs almost nothing, so gather evidence instead of guessing.

• Change is expensive → specify

  Firmware on hardware already in customers’ hands. A certified medical device. A system integration where the other side’s interface is frozen by contract. Here, careful upfront thinking is the cheaper path.

Notice that this is a property of your situation, not of your beliefs about software development. The same team may be right to iterate on the web frontend and right to specify carefully on the firmware, in the same quarter.

The hybrids real projects run

Very few organisations run either model in pure form. The common real shape is a predictive wrapper around iterative execution: a fixed contractual scope and milestone plan on the outside, with the team working in sprints inside it.

That hybrid is honest as long as one condition holds: the outer plan gets genuinely re-baselined when the inner work discovers something. To re-baseline is to agree a new version of the plan and measure against it from then on, instead of reporting against the old one as if nothing had happened.

Stage-Gate deserves a sentence of its own, because it is often confused with Waterfall and is a different thing. Its gates are investment decisions — continue, change course, or stop — taken by people who control the money, and a portfolio in which no project is ever stopped at a gate is running a ceremony, not the method. The planning-side version of the same idea, detailing the near term and leaving the far term coarse, is rolling wave planningrolling wave planningdetail the near term, outline the restPlanning the next few months in detail and the rest only as budgeted placeholders, then detailing the next stretch at each planning cycle. It keeps the plan complete without inventing detail nobody can know yet; it fails when the placeholders are never revisited.Full article →All terms, covered on the work breakdown structure page.

Five documented cases, and the control each one tested

Waterfall’s record is better documented than most methods’, because so much of it was written by governments and inquiry boards. The first two cases are about the model itself. The other three are about what a gate can and cannot catch.

Where it degrades into theatre

The honest limit first. Waterfall is honest about scope and date and silent about knowledge. It can only ever be as right as the requirements were in month one, and it has no mechanism of its own for finding out they were wrong before the verification phase. Where knowledge genuinely exists before the build — a frozen interface, a known migration target, a team doing the fifth version of the same thing — that silence costs nothing, and the model’s discipline is pure gain.

Its defenders and its critics agree on more than either admits. David Parnas and Paul Clements, who believed in the ideal of a rational, specification-first process, published "A Rational Design Process: How and Why to Fake It" in 1986: nobody can actually work that way, they argued, but the documents should be written as if they had. Fred Brooks put the other half more bluntly in his keynote at the 1995 International Conference on Software Engineering: "The waterfall model is wrong!"

• Requirements signed off by people who will not use the system, so acceptance is the first real review.
• A verification phase compressed to fit a date, which turns testing into a formality.
• Change requests treated as failures rather than as information, so the plan is defended past its usefulness.
• A change control board that meets monthly, so every change — right or wrong — waits a month.
• A traceability matrix filled in after the build, to pass the audit rather than to find a gap.
• A design review that reviews slides instead of the design, so the gate is a meeting rather than a check.
• Acceptance tests written after the code, which keeps the V on paper and removes its only gain.
• SprintsSprinta fixed-length work cycleA fixed period, usually one to four weeks, at the end of which there is something finished enough to show. The length is fixed and the scope moves — a sprint that is extended to fit the work has given up the only thing it was for.Full article →All terms inside a plan that is never re-baselined — iteration in appearance only.
• Progress reported as percentage complete, which cannot be verified until the system runs.
• "Waterfall because the regulator requires it", when the regulator requires evidence, not a sequence.

When to use it

Related pages

• ManagementAgileAgile is a set of four values and twelve principles for building software, written in 2001, that puts learning from working software ahead of the plan. It is not a methodology — Scrum, Kanban and Extreme Programming are the methodologies built on top of it — and it has no meetings, roles or artefacts of its own. The page opens with the Manifesto in full, numbered so a line can be cited, then covers the layer it occupies, what each value trades, the bet it makes on the cost of change, feedback loops as its real mechanism, each principle as a test you can run on your own team, six programmes it decided, and where it degrades into theatre.
• ManagementPRINCE2PRINCE2 is a structured method for governing projects, built around one question a project must keep answering: is it still worth funding? It says almost nothing about how the work gets done and a great deal about who may decide that it continues. The page opens with one project set up the PRINCE2 way, finished, then covers what the method is, its seven principles, seven practices and seven processes, tolerances and exceptions, two projects it exists to stop, and where it degrades.
• ManagementWork Breakdown StructureA work breakdown structure (WBS) is a hierarchical breakdown of everything a project will deliver — and, by definition, nothing it will not. It is a scope boundary drawn as a tree: if a piece of work is not somewhere in it, it is not in the project, and adding it is a change rather than an edit. The page opens with a finished WBS for an IT project — eight branches, thirty-one work packages, coded and adding up to 100% — then covers the rules that make a tree a WBS, the dictionary where scope actually lives, codes and control accounts, how deep to decompose, the WBS beside an agile backlog, three documented cases, and where it degrades.