The waterfall model is a linear approach to software development where a project moves through a fixed sequence of phases, one at a time, from initial planning through deployment and maintenance. Each phase must be completed and formally approved before the next one begins. It was one of the first structured methodologies for building software and remains widely used in industries where strict documentation and regulatory compliance matter, such as healthcare, finance, government, and aerospace.
How the Phases Work
The waterfall model flows in one direction, like water over a series of ledges. While different organizations use slightly different labels, most versions include these core phases:
- Requirements analysis: The team gathers and documents exactly what the software needs to do. This means interviewing stakeholders, analyzing business needs, and producing a detailed specification. The output is a formal requirements document that becomes the blueprint for everything that follows.
- System design: Engineers translate those requirements into a technical plan. This includes screen layouts, data structures, process diagrams, and business rules. The goal is a design detailed enough that developers can build from it without ambiguity.
- Development: The actual coding happens here. Developers write the software based on the design documents, typically building individual modules or components.
- Integration and testing: The separate modules are assembled and tested together. The team checks for bugs, errors, and compatibility issues. All defects found during testing must be addressed before moving forward.
- Deployment: The finished system goes into production. This can involve training users, setting up hardware, and migrating data from any prior system.
- Maintenance: Once live, the team monitors performance and makes fixes or small updates as needed. This phase continues for the life of the software.
The U.S. Department of Defense formalized a version of this sequence in its DOD-STD-2167 standard, which required software contractors to follow six sequential phases: requirement analysis, preliminary design, detailed design, coding and unit testing, integration, and testing.
The Gate Between Each Phase
What makes waterfall distinct from other approaches is the hard boundary between phases. You cannot move to the next phase until the current one is complete and approved. These transitions are sometimes called “quality gates” or “phase gates,” and they involve structured reviews of deliverables, stakeholder sign-offs, and documentation of any open issues. This creates a clear paper trail showing what was decided, when, and by whom.
In practice, this means the requirements document gets formally locked before design begins. The design gets locked before coding starts. There is no going back to redesign a feature while testing is underway, at least not without a formal change process that can be expensive and time-consuming.
Where Waterfall Works Well
The model’s greatest strength is predictability. Because all features are documented in detail before any code is written, project managers can communicate budgets, timelines, and key milestones to stakeholders with relative confidence. Everyone involved knows the scope from day one.
This structure is especially valuable in regulated industries. Healthcare, finance, and government software projects often require audits, compliance checks, and external reviews. Waterfall’s formal approvals and extensive documentation provide the traceability that auditors need. NASA, for example, has traditionally used a waterfall model for its mission-critical software, including systems that run inside Mission Control. When a software failure could endanger lives or cost billions, having every requirement traced through design, code, and testing is not optional.
Waterfall also suits projects where the requirements are genuinely stable. If you’re building software to meet a specific regulation or a well-understood internal process, the chance of major requirement changes is low, and the model’s rigidity becomes an asset rather than a liability.
Where Waterfall Breaks Down
The biggest risk is late discovery of problems. Because testing happens after development is complete, defects and gaps surface near the end of the project, when timelines are tight and fixes can cascade through the schedule and budget. A misunderstood requirement that could have been caught in week two might not show up until month eight.
This is not a theoretical concern. Research comparing project outcomes found that waterfall projects averaged only a 47% success rate across criteria like proper process selection, integration, implementation, and alignment, compared to 88.2% for agile projects. Much of that gap comes from waterfall’s inability to absorb change. If a client realizes mid-project that they need something different from what was specified, the formal change process can be slow and costly, and the downstream phases (design, code, testing) may all need rework.
The model also assumes you can define all requirements accurately at the start. For many modern software products, especially consumer-facing apps or products entering new markets, this is unrealistic. Users often don’t know what they want until they see a working version, which waterfall doesn’t deliver until the very end.
How Waterfall Compares to Agile
Agile development emerged largely as a reaction to waterfall’s limitations. Instead of planning the entire project upfront, an agile team breaks the product into individual features and builds each one in short cycles called sprints, typically lasting two to four weeks. At the end of each sprint, there’s a working piece of software that stakeholders can review and give feedback on.
The tradeoffs are almost mirror images. Waterfall gives you a clear scope, firm budget estimate, and detailed documentation from the start, but makes it painful to change direction. Agile lets you adapt quickly to new information and user feedback, but can lack comprehensive documentation, which makes it harder to provide accurate cost estimates or onboard new team members mid-project.
Neither approach is universally better. The choice depends on how well you understand the requirements upfront, how likely they are to change, and how much regulatory documentation you need to produce.
The V-Model: Waterfall With Built-In Testing
One common adaptation of waterfall is the V-Model, which addresses the late-testing problem by pairing each development phase with a corresponding testing phase from the very beginning. Instead of a straight downward line, the process bends upward after coding, forming a V shape. Requirements analysis maps directly to acceptance testing. System design maps to integration testing. Detailed design maps to unit testing.
The practical difference is that testers get involved during the requirements phase itself, writing test plans and identifying potential issues before a single line of code exists. In the standard waterfall model, the test team often isn’t involved until development is nearly finished, which is precisely when defects are most expensive to fix. The V-Model keeps waterfall’s sequential discipline while reducing the odds of a costly surprise at the end.
When Teams Still Choose Waterfall
Despite agile’s popularity, waterfall remains a deliberate choice in several scenarios. Construction and manufacturing software, embedded systems for medical devices, defense contracts, and large-scale infrastructure projects all frequently use waterfall or waterfall-derived models. These projects share common traits: the requirements are defined by regulations or physical constraints, the cost of failure is extremely high, and stakeholders need detailed documentation before approving funding.
Even in organizations that primarily use agile, individual components sometimes follow a waterfall process. A team might iterate quickly on a user interface while the underlying database migration follows a strict, sequential plan. The key is matching the methodology to the level of uncertainty in the work. When you know exactly what you’re building and the stakes demand a paper trail, waterfall’s structure is a feature, not a flaw.