Work Methodologies DefinedTerm

Waterfall Model

Also known as: Waterfall, Waterfall Development

Sequential approach to software development where each phase must be completed before starting the next one.

Updated: 2026-01-04

Definition

The Waterfall Model is a sequential approach to software development where the project proceeds through discrete phases (Requirements, Design, Implementation, Verification, Maintenance), each completed before starting the next. The flow is unidirectional like a waterfall, hence the name.

Ironically, Winston Royce’s original 1970 paper describing this model presented it as an example of a risky approach, not as best practice. Royce recommended iterations and prototyping. Later, the model was simplified and widely adopted in the 1980s-90s, becoming synonymous with “traditional approach”.

Waterfall phases

1. Requirements Analysis

  • Gather and document all requirements upfront
  • Output: requirements specification document (SRS)
  • Typically requires months of analysis and approvals

2. System Design

  • Design software architecture and database
  • Output: design documents, UML diagrams, technical specs
  • Architecture “carved in stone” before writing code

3. Implementation

  • Write code according to design
  • Often divided into modules developed by separate teams
  • Output: source code, unit tests

4. Integration and Testing

  • Integrate modules and test complete system
  • This is the first time different components are assembled
  • Output: test reports, bug lists

5. Deployment

  • Release software to end users
  • Training and user documentation
  • Output: deployed system, manuals

6. Maintenance

  • Bug fixes, updates, new features
  • Often managed by separate team from development

Distinctive characteristics

Heavy documentation: each phase produces formal documents that must be approved before proceeding. Requirements document, design specs, test plans.

Handoffs between phases: different specialists handle different phases (business analysts for requirements, architects for design, developers for implementation, QA for testing). Each handoff introduces miscommunication risk.

Late feedback: stakeholders see working software only after months/years, in the testing phase. If requirements were wrong, the cost of correction is very high.

Change resistance: changing requirements after design phase is expensive and discouraged. Formal change request processes.

When Waterfall works

Stable, well-understood requirements: projects in mature domains where requirements don’t change (e.g., compilers, hardware drivers, database migrations).

Regulatory compliance: regulated industries (aerospace, medical devices, finance) require heavy documentation and audit trail. Waterfall produces this documentation naturally.

Fixed-price contracts: when scope, timeline, and budget are contractually fixed, Waterfall provides predictability (at least in theory).

Small, simple projects: for projects of few weeks with limited scope, Waterfall overhead is acceptable.

When Waterfall fails

Uncertain requirements: when you don’t know exactly what to build, specifying everything upfront is impossible. Waterfall falsely assumes all requirements can be known at the start.

Fast-changing markets: in competitive contexts, waiting 12-18 months for delivery means being overtaken by more agile competitors.

User experience critical: UX requires rapid iteration on user feedback. Waterfall delivers UI only at the end, too late to iterate.

Innovation projects: innovation requires experimentation and failure. Waterfall penalizes changes of direction.

Comparison with Agile

Feedback loop: Waterfall has single feedback loop at the end. Agile has continuous feedback every 1-2 weeks.

Risk management: Waterfall shifts risk to the end (integration hell). Agile continuously mitigates risk with incremental working software.

Adaptability: Waterfall assumes stable requirements. Agile embraces change as inevitable and positive.

Team structure: Waterfall favors specialization and silos. Agile favors cross-functional teams.

Evolution and variants

V-Model: extension associating each development phase with corresponding testing phase. Improves quality assurance but maintains sequential nature.

Spiral Model: Barry Boehm (1986) introduces iterations and risk analysis in each cycle. Hybrid between Waterfall and iterative.

Waterfall with prototyping: hybrid approach maintaining Waterfall phases but including initial prototyping to validate requirements.

Common misconceptions

No. Royce’s 1970 paper described the sequential model as “risky and invites failure”. He recommended at least two iterations. The model was adopted by others who ignored his reservations.

”Waterfall is always obsolete and wrong”

False. For projects with stable requirements, regulatory constraints, and low technical uncertainty, Waterfall can be appropriate. The problem is applying it indiscriminately.

”Waterfall doesn’t do testing”

Not true. Waterfall has explicit testing phase. The problem is that testing comes late (after complete implementation), making bug fixes very expensive.

”Agile killed Waterfall”

Partially false. In regulated sectors (aerospace, medical, government), Waterfall is still prevalent for compliance reasons. Many orgs use hybrids (“Water-Scrum-Fall”).

  • Agile Software Development: iterative approach contrasting with Waterfall
  • Scrum: specific agile framework, antithesis of Waterfall
  • DevOps: extends agility to operations, incompatible with pure Waterfall
  • CRISP-DM: data science methodology with iterative elements, not waterfall

Sources

  • Royce, W. (1970). “Managing the Development of Large Software Systems”
  • Boehm, B. (1986). “A Spiral Model of Software Development and Enhancement”
  • Sommerville, I. (2015). Software Engineering, 10th Edition
  • Brooks, F. (1975). The Mythical Man-Month
Back to Glossary