Winston Royce Drew the Waterfall Model in 1970. Right Below It, He Called It Risky.

In August 1970, Winston W. Royce of the aerospace company TRW presented a paper on managing large software projects, with a diagram of seven boxes stepping down from system requirements to operations. That staircase is now known as the waterfall model. Directly beneath the diagram, Royce wrote: “I believe in this concept, but the implementation described above is risky and invites failure.”

The paper, “Managing the Development of Large Software Systems,” was published in the proceedings of WESCON, the Western Electronic Show and Convention. The word “waterfall” appears nowhere in it, and Royce spent most of its pages on how to repair the sequence he had just drawn. Even so, as Craig Larman and Victor Basili wrote in a 2003 history of iterative development, “many—incorrectly—view Royce’s paper as the paragon of single-pass waterfall.”

Spacecraft software and a seven-step staircase

Royce wrote from experience. He described the paper as his personal views, drawn from nine years of assignments, mostly on software for spacecraft mission planning, commanding and post-flight analysis. His Figure 2 listed the steps in order: system requirements, software requirements, analysis, program design, coding, testing and operations. An arrow led from each box down to the next.

His objection was about where the surprises landed. Testing came last, and Royce called it “the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed.” If timing or storage then failed to meet the system’s limits, a major redesign followed, and the requirements themselves might have to change. “In effect the development process has returned to the origin,” he wrote, “and one can expect up to a 100-percent overrun in schedule and/or costs.”

Figures 3 and 4: the arrows that point back up the staircase

Royce’s next two diagrams added arrows pointing back up the steps. Figure 3 carries a hopeful caption: “Hopefully, the iterative interaction between the various phases is confined to successive steps.” Figure 4 drops the hope. Its arrows run from testing all the way back to program design, and from program design back to software requirements, under the caption: “Unfortunately, for the process illustrated, the design iterations are never confined to the successive steps.”

He still called the basic approach “fundamentally sound.” What it needed, he argued, were five additional features “to eliminate most of the development risks.” Each one cost extra money, he acknowledged, but in his experience “the simpler method has never worked on large software development efforts.”

Royce’s five fixes: design first, document, do it twice

The first fix put a preliminary program design ahead of analysis, so that the software would not fail “because of storage, timing, and data flux reasons.” The second was documentation, and Royce wanted “quite a lot.” “The first rule of managing software development is ruthless enforcement of documentation requirements,” he wrote. By his estimate, a $5 million hardware device needed a 30-page specification, while $5 million of software needed about 1,500 pages. A written record, he argued, keeps a designer from hiding behind the “I am 90-percent finished” syndrome month after month.

The third fix was to “do it twice.” For a program built for the first time, Royce wanted the version delivered to the customer to be “actually the second version insofar as critical design/operations areas are concerned.” A 30-month project, he suggested, might first build a pilot model over 10 months. The last two fixes were to plan, control and monitor testing, and to involve the customer formally at several points before delivery, because “to give the contractor free rein between requirement definition and operation is inviting trouble.”

How the diagram got its name, and the Pentagon’s software standards

The label was in print by 1976, in what may be its earliest use: a paper by T. E. Bell and T. A. Thayer, also of TRW, at the second International Conference on Software Engineering. They wrote that the military standards MIL-STD-490 and MIL-STD-483 specified a top-down series of requirements documents. The same top-down approach, they said, was explained “without the specialized military jargon” in Royce’s paper, and Royce “introduced the concept of the ‘waterfall’ of development activities.”

The U.S. Department of Defense set out its own sequence in DOD-STD-2167, a standard for developing defense system software, issued on June 4, 1985. It required a development cycle of six phases, from software requirements analysis to testing, with formal reviews and documents along the way. Its text did allow several iterations to run at once, and it said this process “may be described as an ‘evolutionary acquisition’ or ‘incremental build’ approach.”

Still, according to Larman and Basili, the standard’s principal creator later expressed regret for creating “the strict waterfall-based standard.” He said he had not heard of iterative development at the time and, in hindsight, would have strongly recommended it.

In February 1988, the revised standard, DOD-STD-2167A, stated that it was “not intended to specify or discourage the use of any particular software development method.” Many readers, Larman and Basili note, still saw an implied preference for the waterfall in its document-driven milestones. That same year Barry Boehm, also of TRW, wrote that “the waterfall model has become the basis for most software acquisition standards in government and industry.” In December 1994, a new military standard, MIL-STD-498, replaced 2167A. Larman and Basili cite a summary of the changes with a section titled “Removing the Waterfall Bias.”

Was Royce for or against the waterfall?

Royce’s son, Walker Royce — who in the mid-1990s helped create the Rational Unified Process, an iterative method — told Larman and Basili that his father “was always a proponent of iterative, incremental, evolutionary development.” In the son’s words, the paper “described the waterfall as the simplest description, but that it would not work for all but the most straightforward projects.”

The paper itself gives a narrower answer: Royce was for the sequence, which he called “fundamentally sound,” but against running it in a single pass. His fixes kept design ahead of coding, demanded heavy documentation and relied on one pilot version rather than repeated cycles. Larman and Basili see “hints of iterative development, feedback, and adaptation” in the paper, but say that its do-it-twice step “is clearly not classic IID.” They describe IID (iterative and incremental development) as a cornerstone of agile methods. Boehm described the same step as an early way of bringing prototyping into the software life cycle.

Why the simple diagram outlived its warning

Larman and Basili give several reasons the simple sequence spread. It is easy to explain and remember: do the requirements, then design, then implement. It “gives the illusion of an orderly, accountable, and measurable process, with simple document-driven milestones.” And even Royce’s “original two-iteration waterfall immediately devolved into a single sequential step as other adopters used it and writers described it.”

A process diagram is a claim about where problems will surface. Royce’s figures make two different claims: the staircase, which later adopters and writers kept, and Figure 4, where an arrow runs from testing all the way back to program design.

Explore

Stay connected