Skip to main content

[SE-4.3] Waterfall Methodology

Why This Matters

Before Agile existed, nearly all software was built using a sequential, phase-based approach now called Waterfall. Understanding it is not just historical context — Waterfall is still the right choice for certain projects, and many real-world teams use hybrid approaches that draw from both.


What Is Waterfall?

Waterfall is a linear, sequential development process where each phase must be fully completed before the next begins. Like water flowing down a cliff, progress moves in one direction only.

The name comes from the direction of flow — and the implication that going back up the waterfall is difficult and costly.

Recommended video: What is the Waterfall Model and How Does it Work?


The Six Phases

1. Requirements

All requirements are gathered and documented before any design begins.

  • What should the system do?
  • What are the constraints? (performance, security, budget, deadline)
  • Who are the stakeholders and what do they need?

The output is a Requirements Specification document — often hundreds of pages for large projects.

2. System Design

The technical architecture is designed based on the requirements.

  • Database schema
  • System architecture (servers, services, APIs)
  • UI wireframes and mockups
  • Technology choices

No code is written yet. The output is a Design Specification.

3. Implementation

Developers write the code, following the design specification.

  • This is often the longest phase
  • Developers are expected to follow the spec, not make design decisions
  • Changes to requirements at this stage are expensive

4. Testing

The completed system is tested against the requirements.

  • Unit testing, integration testing, user acceptance testing
  • Bugs are fixed
  • If a fundamental design flaw is found here, it may require going back to phase 2

5. Deployment

The system is released to users.

  • Often a single, large release event
  • User training and documentation are delivered
  • The system goes live

6. Maintenance

Ongoing support, bug fixes, and minor enhancements after release.

  • Not new features — those would require starting a new project cycle
  • The phase that often runs indefinitely

Recommended video: The Most Comprehensive Explanation of the Software Development Life Cycle (SDLC) in 7 Minutes!


Where Waterfall Works Well

Waterfall is not inherently inferior to Agile. It is a better fit when:

ConditionWhy Waterfall fits
Requirements are fixed and well-understoodNo need to iterate if you already know exactly what to build
The domain is safety-criticalMedical devices, aviation, nuclear systems need exhaustive documentation and traceability
Regulatory compliance is requiredSome industries legally require documented design approval before implementation
The team is large and geographically distributedDetailed specifications reduce the need for constant coordination
The client wants a fixed price and fixed scopeContracts are easier to write and enforce with Waterfall

Examples: hospital patient management systems, government infrastructure software, embedded systems in vehicles, defence contracts.


Where Waterfall Fails

ProblemWhat goes wrong
Requirements changeAny change after phase 1 is expensive — redesign, rework, re-test
Users don't know what they want until they see itA 200-page spec doesn't reveal usability problems — a working prototype does
Long time to first working softwareStakeholders may wait 12–18 months before seeing anything functional
Testing is too lateBugs found in phase 4 are far more expensive to fix than bugs found in phase 2
No feedback loopsIf the original requirements were wrong, you build the wrong thing — perfectly

The classic failure: a system is delivered on time and on budget, exactly to spec, and nobody uses it because the requirements were wrong from the start.


Agile vs Waterfall — Side by Side

DimensionWaterfallAgile
PlanningAll upfrontContinuous
RequirementsFixed at the startExpected to evolve
DeliverySingle release at the endRegular incremental releases
FeedbackAfter deploymentEvery sprint
ChangeCostly and resistedExpected and welcomed
DocumentationExtensiveLightweight ("just enough")
RiskHigh (discovered late)Lower (discovered early)
Best forStable, well-defined problemsEvolving, exploratory problems
Worst forProjects where requirements changeSafety-critical, fixed-contract work

Recommended video: If You're Choosing Agile or Waterfall… Watch This First


Hybrid Approaches

Most real-world teams do not use pure Agile or pure Waterfall. Common hybrids include:

  • Waterfall for architecture, Agile for features — design the system structure upfront, then build individual features in sprints
  • Agile with "phase gates" — use sprints but require formal sign-off at key milestones (common in regulated industries)
  • Scrumban — combines Scrum's sprints with Kanban's visual board and WIP limits

For your project, a lightweight hybrid is realistic: define your architecture and MVP upfront (Waterfall-like), then build feature by feature in weekly sprints (Agile-like).


A Note on History

Waterfall is often traced to a 1970 paper by Winston Royce — but that paper actually argued that pure sequential development was flawed and advocated for iteration. The term "Waterfall" itself was coined by its critics.

The broader lesson: methodologies are tools. The question is never "which is better?" — it is "which fits this project, this team, and these constraints?"


Key Vocabulary

  • Phase Gate: A formal checkpoint where a project must be reviewed and approved before proceeding to the next phase
  • Requirements Specification: A document that defines what a system must do, produced at the start of a Waterfall project
  • Sequential Development: A process where each phase must complete before the next begins
  • Traceability: The ability to link every line of code or test back to a specific requirement — critical in safety-critical Waterfall projects
  • Waterfall: A linear software development process that moves through fixed phases in sequence

Next Steps

Return to 2. Agile Methodologies to compare the two approaches.


End of Topic 3: Waterfall Methodology