Waterfall runs each phase once and usually finds its worst problems during testing. Spiral goes around a four-step cycle again and again, with a risk check on every pass.
Stable, well-defined scope suits waterfall. Large systems with open technology questions and shaky requirements suit spiral.
Waterfall usually gets credited to Winston Royce, but his 1970 IEEE WESCON paper never uses the word. It calls the single-pass flow it describes “risky and invites failure”. Barry Boehm published the spiral model in 1986.
Waterfall vs spiral model: the main differences
Waterfall signs off each phase before the next one begins. Spiral keeps cycling, and risk analysis sits inside every loop. What decides between them is how stable the requirements are and how much risk the project carries.
| Attribute | Waterfall | Spiral |
|---|---|---|
| Process structure | Sequential phases, each completed once | Repeated cycles of four quadrants |
| Risk handling | Risk surfaces mostly at testing | Risk analysis and prototyping in every cycle |
| Changes and customer feedback | Requirements frozen early, limited customer input | Requirements revisited each loop, customer reviews each cycle |
| Cost and documentation | Lower management cost, heavy upfront documents | Higher cost per cycle, needs risk-assessment expertise |
| Best fit | Stable, well-defined scope | Large, complex, high-risk systems |
Both sit inside the wider family of software development lifecycle models, but they start from opposite questions. Waterfall wants to know how to carry out a known plan cleanly. Spiral cares more about what could sink the plan in the first place.
Neither one wins in general. The project’s risk profile does the deciding.
How does the waterfall model work?
Every phase gets finished and reviewed before the next one starts, and a document marks each hand-off. Whatever one phase produces becomes the input for the one after it.
Origin and the waterfall label
Winston Royce laid out the staged flow in “Managing the Development of Large Software Systems,” presented at IEEE WESCON in August 1970.
He never used the word waterfall. In that same paper he called the plain single-pass version “risky and invites failure”.
To fix it, Royce added preliminary program design up front, a documented design, a second pass at the job, planned and monitored testing, and customer involvement.
The label showed up later. The earliest known use may be a 1976 paper by Bell and Thayer.
Government contracting then locked in the single-pass reading. DOD-STD-2167, issued June 4, 1985, set out the documents contractors had to deliver when developing software using the waterfall model, and DOD-STD-2167A followed on February 29, 1988.
MIL-STD-498 superseded 2167A on December 5, 1994.
The textbook version of the waterfall methodology keeps Royce’s phase order but drops the feedback loops he drew between steps.
Phases and what each one produces
Requirements work ends in an agreed specification of what the system must do. Design produces architecture and detailed design documents, and implementation turns those into working code, module by module. Testing delivers integration and system test results. Deployment and maintenance close things out with a released system and a steady stream of defect fixes.
Phase counts differ by source. Tutorials show 6 or 7, and Royce’s own diagram shows 7 steps: system requirements, software requirements, analysis, program design, coding, testing and operations.
Each gate closes with a reviewed software requirement specification or a design sign-off, and work does not move on until it passes.
Pros and cons of the waterfall model
Waterfall gives you clear milestones and gates, and it is easy to schedule and budget when scope is fixed. The documentation is thorough enough for hand-offs and audits. New team members can follow the process without much explanation.
The downsides are real, though. Testing starts late and changes after design cost a lot. Working software shows up only near the end, and customer feedback arrives after the big decisions are already made.
Waterfall pays off as long as the plan holds, and gets expensive when it doesn’t.
How does the spiral model work?
Each loop produces a more complete version of the product, and risk analysis decides what gets built next. The cycle itself has four steps.
Barry Boehm introduced the spiral model in software development in a 1986 paper, “A Spiral Model of Software Development and Enhancement.” A version for a wider audience ran in IEEE Computer in May 1988 (volume 21, issue 5).
The 1988 article works through a real case, the TRW Software Productivity System, and Boehm was with TRW’s Defense Systems Group at the time.
The four quadrants of one cycle
- Determine objectives, alternatives and constraints for this loop.
- Evaluate the alternatives, then identify and resolve risks.
- Develop and verify the next-level product.
- Plan the next phase, with a review and a commitment before the next loop starts.
On the usual diagram, distance from the center shows cumulative cost and the angle shows progress through the cycle.
Quadrant two usually settles a risk with a prototype, whether a throwaway mock-up or an evolving build, as described in guides to software prototyping.
Source wording differs. Some tutorials name the quadrants identification, design, development, and evaluation with risk analysis, but the order of activity matches the list above.
Pros and cons of the spiral model
Risk gets addressed before money goes into the next loop. Requirements can change between loops, and customers see working versions early.
On the other side, the process is only as good as the people judging the risk. Final cost and end date are hard to fix upfront, and the overhead weighs heavily on small, low-risk projects.
Spiral buys information early and charges for it in overhead.
How each model handles risk
Waterfall finds most of its risk at testing, late in the cycle. Spiral runs risk analysis and prototyping in every loop, so problems surface while changes are still cheap.
Finding and fixing a problem after delivery is often 100 times more expensive than fixing it during requirements and design, according to Boehm and Basili (IEEE Computer, 2001).
The same paper puts the ratio closer to 5:1 for small, non-critical systems. That spread helps explain why risk-heavy projects lean spiral, while small, stable ones can absorb waterfall’s late testing.
NIST’s 2002 study found that over half of all software errors are not caught until downstream in development or after release.
Royce named the test phase as the point of greatest risk in waterfall. Testing is the first full check of timing, storage and input/output behavior, so a failure there tends to force a redesign instead of a patch.
Spiral moves that check forward. Quadrant two evaluates alternatives and resolves risks before the build step, and prototypes test the shakiest assumptions first. The risk list gets rebuilt each loop as new unknowns turn up, and a review and commitment closes every loop before the next begins.
In waterfall, the software testing lifecycle starts only after coding ends, so the first full evidence arrives late.
Spiral teams can rank each loop’s risks on a risk assessment matrix, scoring likelihood against impact, and resolve the top items first.
One caveat. A spiral that skips or fakes its risk analysis is just slow waterfall with extra meetings.
Changing requirements and customer involvement
Waterfall freezes requirements early and limits customer input after sign-off. Spiral reopens requirements every loop and puts the customer in the review step of each cycle.
Requirement changes
NASA Tech Briefs describes a simulation of a spiral process built by repeating the IEEE 12207 waterfall steps. It notes a key difference: a spiral process accommodates requirement changes at each iteration, while a waterfall process treats requirements as fixed from the start.
In waterfall, a late change goes through formal change request management, with its impact on every finished phase assessed before anyone touches the design.
In spiral, requirements work becomes a repeated activity. Each loop starts by revisiting objectives and constraints, which is requirements engineering done in smaller pieces.
There is a catch. Every reopened requirement adds work to the loop, so spiral still needs a scope boundary per cycle.
Customer involvement
In waterfall the customer signs off at requirements and gets a review at delivery, plus any gates the contract sets. Spiral builds a review into the end of every loop, before the next one is funded.
Tutorial pages describe customer involvement in waterfall as minimal. Royce’s fifth addition says otherwise, since he asked for customer commitment before final delivery, so the weak involvement comes from how teams apply the model.
A customer who cannot review each loop removes most of spiral’s advantage.
What each model costs in time, documentation and expertise
Waterfall costs less to manage but front-loads the documentation. Spiral costs more per loop and needs people who can judge risk, though it spends in stages.
Waterfall’s end date is easiest to forecast when scope holds, while a spiral’s date moves with the number of loops the risks demand. Waterfall also produces a full set of documents at every gate, and in spiral the level of detail follows the risk.
Someone has to judge those risks, and a missed one wastes the loop meant to catch it. Funding follows the same split. Waterfall commits the budget up front, and spiral releases it loop by loop.
Every waterfall gate produces technical documentation that someone has to write, review and keep current. That load is the price of predictable hand-offs.
NASA Tech Briefs notes that, for a given project, a spiral process may cost more and take more time than a waterfall process, but may better satisfy the customer’s expectations.
Boehm’s 2000 report for the Software Engineering Institute, edited by Wilfred Hansen, frames the spiral as a way to commit money in increments, using an analogy to stud poker.
Tutorial pages label spiral very expensive but give no figure. The primary sources cited here put no total-cost number on the gap, so treat any percentage quoted elsewhere as unverified.
Is the waterfall model a special case of the spiral model?
In Boehm’s framing, yes. In later publications he calls the spiral a process model generator, so a project with low risk and fixed requirements generates a single waterfall pass.
Sources split on the reverse claim, whether spiral is just waterfall repeated.
NASA Tech Briefs says a spiral process can be regarded as a repeating modified waterfall process. Boehm disagrees, and lists treating the spiral as a sequence of waterfall increments among the most significant misconceptions to avoid.
The two views differ on what drives the repeats. In a repeated waterfall the plan sets the next pass, while in spiral risk sets the next step, its level of effort and its degree of detail (invariants 3 and 4 in the SEI’s 2000 report).
Spiral is an iterative software development approach, but iteration alone does not make a process spiral.
Hazardous spiral look-alikes break Boehm’s invariants in recognizable ways.
- Incremental waterfall passes used where waterfall’s assumptions do not hold
- Cycles that leave key stakeholders out
- Heavy investment in a poorly defined architecture
- Too much focus on the initial development of code
The test is short. If no risk decision picks the next step, it is not spiral.
Which model fits which project?
Pick waterfall when requirements are stable and late discovery is affordable. Pick spiral when a risk big enough to sink the project is still unresolved.
Start with requirement stability. Can they be written down, signed off and expected to hold? Then list the top unknowns in technology, performance, integration and users, and lean spiral if any one of them could sink the project. After that, look at the money. A fixed-price contract favors waterfall’s predictable cost, while a staged budget fits spiral. Last, check customer access, because spiral needs a reviewer at the end of every loop.
Size alone does not sort the models. Royce wrote about large systems, so tutorial pages that reserve waterfall for small projects and spiral for large ones oversimplify.
Choose waterfall when
Lockheed Martin’s on-board shuttle software group shows plan-first work at its best. Across the last 11 versions of its 420,000-line program it logged 17 errors in total, where comparable commercial software would carry about 5,000 (Fast Company, 1996).
About one-third of that process happens before anyone writes a line of code. Fast Company does not call it waterfall, but specify first and verify separately is the pattern waterfall is built for.
- Requirements fixed by contract or regulation
- Technology and integration already proven
- Customer needed at gates, not every loop
Choose spiral when
Unproven technology is the clearest trigger, because the shaky part can be prototyped before anyone commits to the rest. Unclear requirements sharpen with each loop. And when a large budget is at stake, money can be released loop by loop, after each review.
A feasibility study often surfaces the technical unknowns that tip a project this way.
When neither fits
PMI’s Pulse of the Profession 2024 reports hybrid approaches rising from 20% in 2020 to 31% in 2023, and finds that teams perform equally well with predictive, hybrid and agile approaches.
The label matters less than the match. When one part of a project is firm and another is risky, split it and run each part with the model it suits.
If risk is low but requirements keep moving, neither model is the right tool, and other software development methodologies fit better.
Where each model breaks down
Waterfall breaks on first-of-a-kind systems, where the first build is the real learning step. Spiral breaks when loops have no exit condition or when the risk analysis gets skipped.
| Failure | Model | Documented remedy |
|---|---|---|
| First-of-a-kind system built in one pass | Waterfall | Build it twice, deliver the second (Royce, 1970) |
| Loops with no exit condition | Spiral | Anchor point milestones (SEI, 2000) |
| Spiral in name only | Spiral | Six invariants (Boehm, SEI, 2000) |
Waterfall: first builds and fixed plans
Royce saw this limit himself. For a program developed for the first time, he advised arranging matters so that the version finally delivered is actually the second one built.
He also inserted a preliminary program design step between software requirements and analysis, so storage and timing constraints reach the analysts before they commit.
Two builds need a budget for two builds, though. A plan that keeps the single pass and drops the second build keeps the risk Royce described.
Spiral: loops without an exit
Boehm’s original description of the spiral model included no process milestones. The SEI’s 2000 report calls anchor point milestones a relatively recent innovation.
Life Cycle Objectives (LCO) is the point where stakeholders agree on the system’s objectives. Life Cycle Architecture (LCA) needs an architecture shown to support them, and Initial Operational Capability (IOC) marks a first usable release with its support material.
Xerox’s Time-to-Market process uses the anchor point milestones, and IBM’s Rational Unified Process adds product release as a fourth.
Boehm’s 1988 abstract lists the primary difficulties of the model at its then incomplete level of elaboration. The invariants and milestones came later, so a team working from the 1988 diagram alone is missing both.
Waterfall vs Spiral Model FAQ
Is the waterfall model still used today?
Yes. PMI’s Pulse of the Profession 2024 still tracks predictive approaches alongside hybrid and agile ones.
Waterfall persists where requirements are fixed by contract or regulation.
How does waterfall compare with agile?
Waterfall completes phases in sequence, while agile delivers working software in short iterations and adapts as feedback arrives.
Agile methods grew out of dissatisfaction with the overhead of heavy, documentation-driven processes, and the 2001 Agile Manifesto ranks working software above comprehensive documentation.
Is the spiral model the same as agile?
No. Spiral organizes each loop around risk analysis and prototyping, while agile builds short iterations around working software and customer feedback.
Spiral also requires a review and a commitment before each new loop starts.
How does the spiral model differ from incremental and iterative models?
Incremental development delivers a product in parts, and iterative development refines it through repeated passes.
Spiral adds a risk analysis before each pass, which is why it is often described as incremental development with more emphasis on risk.
What is the V-model, and how does it relate to waterfall?
It is a waterfall variant that pairs each development phase with a matching test phase, and you will see it called the V-model.
Requirements map to acceptance tests, design to integration tests, and code to unit tests, so test planning starts early while the flow stays single-pass.
Which tools plan each model?
Gantt charts and Microsoft Project suit phase-gated waterfall schedules.
An issue tracker such as Jira can hold each spiral loop’s risks and tasks.
What is IEEE 12207?
A standard for software life cycle processes. NASA Tech Briefs built its spiral-process simulation on the standard’s waterfall steps.
It also took over from MIL-STD-498, which was cancelled on May 27, 1998 and replaced by J-STD-016 and IEEE 12207.
What to Settle Before Committing to Either Model
The waterfall vs spiral model decision should wait until the project’s biggest technical risk is resolved. That answer decides whether the rest of the work can run as one fixed pass.
The order matters, because an early answer changes every later plan. Name the risk that could sink the project, run one short loop to settle it, and plan the stable parts as a single pass.
The trade-off is a start without a firm end date, since the first loop’s result sets the schedule.
Checked against the sources in October 2026, this still holds. If that loop retires the risk, the remaining work fits one waterfall pass, and the spiral has done its job.
When requirements keep moving after the loop, an agile vs waterfall comparison is the next step.
- How Software Teams Write SOPs for Releases and Deployments - October 22, 2026
- Notepad++ Android Options: Apps That Come Close - October 21, 2026
- Data Management Services: A Practical Guide for Growing Companies - October 21, 2026
