The Software Wiki

Waterfall model

Properties2
tagsprocess, methodology
aliasesWaterfall, Linear sequential model, Plan-driven development, Predictive model

4 min read

Waterfall model

By Allen Jay Bercero

The Waterfall model is a process model in which the stages of the Software development life cycle are done once, in strict sequence, each fully completed and signed off before the next begins, so progress flows steadily downward like water over a series of steps.

It’s the oldest formalized approach and the mental default most people reach for: gather all the requirements, design the whole thing, build the whole thing, test it, ship it. Its strength is predictability; its weakness is that it bets everything on getting the requirements right up front.

Also known as

Waterfall · linear-sequential model · plan-driven / predictive development · “big design up front” (BDUF, slightly pejorative)

Don't confuse with

A phase failing vs the model. People say “we went over waterfall” loosely to mean “we planned too much up front.” The model itself is a legitimate, specific approach, not just a synonym for bad planning.

The phases

Each box completes before the next starts, and (in the pure form) you don’t go back:

flowchart LR
  R["Requirements"] --> D["Design"] --> I["Implementation"] --> V["Verification<br/>(testing)"] --> Dep["Deployment"] --> M["Maintenance"]

These are simply the SDLC stages executed strictly in order. That’s the whole idea. The model is the SDLC taken literally as a one-way sequence.

In plain English

Decide everything, then build everything, then test everything, then ship. Like building a house from a finished blueprint, you don’t pour the foundation and then decide to move the kitchen.

History and a common myth

The Royce myth

Waterfall is usually traced to Winston Royce’s 1970 paper “Managing the Development of Large Software Systems.” The twist: Royce presented the pure sequential diagram as the risky, flawed baseline and spent the rest of the paper arguing you must iterate and build a prototype. He never used the word “waterfall.” The industry took his cautionary example and adopted it as the recommended model, the opposite of his point. So “Waterfall” is partly a historical misreading.

The term itself spread through the 1970s (notably a 1976 paper by Bell and Thayer) and became the dominant documented approach, later enshrined in standards like the US Department of Defense’s DOD-STD-2167.

Strengths

  • Predictable and measurable: clear milestones, easy to schedule and budget, easy to report progress to non-technical stakeholders.
  • Heavy documentation: good for regulated industries and for handing work between separate teams.
  • Works well when requirements are truly stable and well understood (e.g. re-implementing a known system, or safety-critical work where change is dangerous).

Weaknesses

  • Change is expensive and unwelcome. A requirement discovered wrong in testing means walking back through design and code, costly, sometimes impossible within budget.
  • No working software until late. Stakeholders first see the product near the end, when it’s most expensive to fix.
  • Bets everything on up-front correctness, which is exactly what’s hardest for novel products where nobody yet knows what users need.

This last point is precisely the pain that the agile movement organized itself against.

When it still makes sense

  • Requirements are fixed, understood, and unlikely to change.
  • The cost or risk of change is high (aerospace, medical devices, contracts with fixed scope).
  • Regulators or clients demand full documentation and sign-off gates.

Many organizations run a hybrid (“water-scrum-fall”): waterfall-style contracts and dates wrapped around an agile delivery core.

  • V-model: Waterfall bent into a V, pairing each build stage with a matching test stage (design ↔ system test, etc.).
  • Spiral model: Waterfall repeated in risk-driven loops, prototyping the riskiest parts first (Boehm, 1988).

See also

References

Graph View

Backlinks