The Waterfall Model: What Royce Actually Said in 1970

Version note: This post is based on the original text of Winston W. Royce's "Managing the Development of Large Software Systems", published in August 1970; we use our own wording instead of quotations.

Guess First

In an interview you are asked: "Who proposed the Waterfall model, and in which year?" Your answer is most likely "Winston Royce, 1970", and most textbooks would agree with you. Now the second question: in that paper, did Royce propose the step-by-step, single-pass model, or did he criticize it? And how many times does the word "waterfall" appear in the paper?

The answer to the second question is zero. The answer to the first one is the subject of this post: a text in which Royce draws the single-pass model, immediately says it is risky and then proposes five fixes was described for fifty years as if it argued the exact opposite.

The Context of the Paper

Royce was an engineer who managed teams building software for space missions at TRW (Thompson Ramo Wooldridge). The paper was published in the proceedings of IEEE (Institute of Electrical and Electronics Engineers) WESCON (Western Electronic Show and Convention). Its subject is how to manage large software systems; that is, less like a web application of today and more like systems with fixed hardware, tight memory and timing budgets, and a government customer.

Royce first says that for small programs only two steps are needed: analysis and coding. For large systems, requirements, design and test steps are added to those two, which produces the seven-step diagram everyone now knows as "Waterfall": system requirements, software requirements, analysis, program design, coding, testing, operations.

Why Did Royce Call the Single Pass "Risky"?

Right after drawing the diagram, Royce writes that this implementation is "risky and invites failure". His reasoning still holds: behavior such as timing, memory use and input/output is predicted by analysis, but actually experienced for the first time in the test phase. If testing shows that this behavior differs from what was expected, the fix rarely ends with a small code change. Either the requirements must change or the design needs a major change. According to Royce, the process then effectively returns to the start, and overruns of up to one hundred percent in schedule or cost can be expected.

The core idea in this passage is that the place where a risk is discovered last is the most expensive place. The later you learn that a design decision was wrong, the more work depends on that decision. This idea will later lead to the risk-driven approach of the Spiral model, and from there to Agile's short feedback loops.

Royce's Five Recommendations

Most of the paper is devoted to five steps proposed to reduce that risk. In short:

First, program design comes first. Before analysis is finished, program designers make a rough preliminary design for memory, timing and data flow. The goal is to keep the analysis within realistic limits. Today's equivalent is testing architecturally risky decisions early with a small experiment.

Second, document the design. Royce is very clear on this: the amount of documentation should not be small but quite large. His reasons are practical: the document is the proof that the design really exists, it is the only source of information for testers and the operations team, and it is how knowledge survives when the team changes. Reading this today as a call for unlimited piles of documents would be a mistake; in Royce's world the tools for understanding a system by looking at its code were very limited.

Third, do it twice. The version delivered to the customer should, for its critical parts, actually be the second version. First a pilot model is built on a compressed schedule; in Royce's example, roughly a 10-month pilot for a 30-month project. The pilot's purpose is to surface the unknowns before the real project starts. This is an early description of what we now call prototyping and spikes.

Fourth, plan, control and monitor testing. Testing is planned by specialists independent of the original designers; every piece of code and analysis is reviewed by a second pair of eyes; every logic path in the program is checked numerically at least once. This is the 1970 version of the code review and coverage debates.

Fifth, involve the customer. Royce wants the customer involved formally and deeply throughout the process, not only at the beginning and the end; at points such as a preliminary design review, critical design reviews and a final acceptance review. Regular contact with the customer reduces the risk of misunderstood requirements.

The right-hand side of the figure shows the shape of these recommendations: every step is tied to the previous one by a feedback loop, and a design problem found in testing explicitly goes back to program design. This is not a single-pass waterfall; it is a process with controlled returns.

The Name "Waterfall" and Institutionalization

The word "waterfall" doesn't appear in Royce's paper. A 1976 paper by Bell and Thayer is often cited as one of the earliest known uses of the name in a software context, but sources are not certain that it really was the first. The diagram Royce drew started to be called by that name because of its cascading look.

What really institutionalized the model was contracts. In 1985 the US Department of Defense (DOD) published the DOD-STD-2167 standard for software development with its contractors. The standard described a structure in which phases follow one another and a formal document and review are expected at the end of each phase. Because government contracts tied payments to those documents and reviews, the model spread across a large ecosystem. The new military standard published in 1994 (MIL-STD-498) moved away from that line and adopted language open to evolutionary and iterative development.

So "Waterfall" was born largely not from Royce's proposal but from the simplicity of the diagram Royce found risky, which suited the needs of contracts and audits. For a customer who pays at the end of each document, the single-pass model is an easy model to manage.

The Waterfall Plan for the Same Feature at Bookstore

Let's imagine that we build the returns feature from the first post of the series for a large corporate customer of Bookstore, under a fixed-scope contract. The plan looks like this as a Gantt chart:

Phase                    Mar   Apr   May   Jun   Jul   Aug
Requirements             ████
Analysis and design            ████  ██
Coding                               ████  ████
Integration and testing                          ████
Deployment                                             ██

In March the requirements document is signed. The document says the shipping company's delivery event contains a date field; this information was taken from the company's documentation from a year earlier. Design happens in April and May, coding from May to July. The team connects to the shipping company's real system for the first time in the integration test in July.

In July three things surface at once. The delivery event no longer sends a date but a timestamp without a time zone, and the 14-day calculation shifts by one day for some customers. The payment provider that performs refunds requires an idempotency key on every request to prevent the same refund from being made twice; the design has no such field. And the testers notice that partial returns, returning two books from a five-book order, were never defined in the requirements.

All three are the situation Royce described: the problem shows up in the test phase, but its root is in requirements and design. The fix requires changing the document signed in March, which means a change request against the contract. The August deployment slips to October. Nobody was lazy; the plan was built around the place where risk is seen last.

Where Does Waterfall Really Fit?

This doesn't mean Waterfall is useless everywhere. A sequential model can be a reasonable choice where change is expensive and the requirements really are fixed. Firmware embedded in a device that is hard to update in the field is an example. So is a regulated process where a regulator approves the documents of each phase separately; there the document is an output of the process itself. A contract whose scope is legally frozen, or the same kind of integration the team has done many times before, can also suit sequential planning.

The places where it doesn't fit are also clear: product development with uncertain requirements, projects that leave integration with external systems to the end, and the big-bang test approach where all testing is done as one big block at the very end. In these three situations a single-pass plan does nothing but postpone risk. We will look at which model to choose when, with decision factors, in the last post of the series.

Production Notes

If a contract or an audit forces you into a sequential plan, Royce's own recommendations still work. Pull integration risk into the first month: a small spike that connects to the shipping company's real test environment in the first week would have caught two of July's three surprises in March. Do the critical parts twice: a short pilot for uncertain points such as idempotency and partial returns makes the requirements section of the contract more realistic. Write the test plan during requirements: this idea of designing acceptance tests together with requirements is the foundation of the V-Model, the subject of the next post. Involve the customer with a demo every month; a signed document is no substitute for a working screen.

Also make the cost of change visible. In a sequential plan, if every late change request is recorded together with the phases it affects, the next project can discuss with data which decisions need to be settled early.

Common Pitfalls

The most common pitfall is believing Royce was an advocate of Waterfall. The paper draws the single-pass model as a starting point and then tries to fix it.

The second pitfall is treating Waterfall as bad in every situation. In a context where the cost of change really is high and the requirements really are fixed, a sequential plan can be an honest choice. The problem is not the model but applying it to a problem it doesn't fit.

The third is carrying Royce's emphasis on documentation unchanged into today. In 1970 the tools for understanding a system from its code were very limited; today lighter tools such as tests, type systems, OpenAPI documents and ADRs (Architecture Decision Records) can serve the same purpose. The goal is not documents but not losing knowledge.

The fourth is forgetting the "do it twice" advice and turning the pilot directly into production code. A pilot's value is in what it teaches, not in its code. We will come back to this pitfall in the fourth post of the series when we discuss prototyping.

A Small Experiment

★☆☆ Read Royce's paper yourself; it is short and freely available. Pay attention to the order of the figures: which figure is the single-pass diagram, and which ones are the diagrams with feedback?

★★☆ List three problems that first showed up in the test phase of your team's last big project. For each, in which phase and with which small experiment could it have been caught earlier?

★★★ Redraw the Gantt plan above by applying Royce's five recommendations: where does the pilot go, when does integration start, where are the customer reviews? Did the total duration of the new plan get shorter, or was the risk just pulled forward?

Royce's fourth recommendation was to plan testing instead of leaving it to the end. In the next post we look at the V-Model, which puts that idea at the center: a model where every development step is paired with a test level and test design starts on the left arm.