Key points
- Waterfall is a development methodology that moves through requirements, design, implementation, testing, and release just once, in order.
- Because each stage must finish before the next begins, it's easy to plan and easy to track progress.
- On the other hand, it's weak against spec changes that surface late, where the cost of rework tends to be high.
What Waterfall is
Waterfall is a development methodology that splits system development into stages — "requirements," "design," "implementation," "testing," and "release" — and moves through them one direction only, from upstream to downstream.
Just as water, once it falls from high ground to low ground, never flows back uphill, Waterfall in principle never returns to a previous stage — which is where the name comes from.
The flow of the stages
Each stage builds on the deliverables — the decisions already made — from the stage before it, as follows.
📋Requirements
↓
✏️Design
↓
💻Implementation
↓
🧪Testing
↓
🚀Release
The basic rule is that you only move on once a stage is fully settled — you don't start design until requirements are entirely fixed, and you don't start implementation until design is entirely fixed.
Teacher Pochi's hintIt's a lot like building construction. You can't put up walls before the foundation is finished, and you can't add a roof before the walls are up. Waterfall works the same way — finishing the previous stage is the precondition for starting the next.
Advantage: easy to plan
Because all requirements and specifications are decided before work begins, the overall timeline and staffing needed for the whole project can be estimated early on.
Since it's clear what should be finished by the end of each stage, tracking progress and reporting to stakeholders becomes much easier. This ease of planning matters even more as a project grows larger.
Disadvantage: weak against late changes
Because Waterfall assumes you never go back to a previous stage, a request to "change the requirements" that comes up during implementation or testing forces a rework starting from design — a large and costly setback.
Upstream changesNarrower impact, relatively easy to handle
Downstream changesRequires redoing work in stages already completed — costly
Teacher Pochi's hintBeing asked to rearrange the rooms when a building is nearly finished means tearing down walls and starting over from the foundation. A late spec change in Waterfall tends to be just as heavy a burden.
Which projects it suits
Waterfall suits projects where the requirements for what's being built are clear from the outset and unlikely to shift significantly during development.
It's also often chosen for systems such as financial systems or public infrastructure, where quality and safety standards are strict and the cost and impact of going back are extremely high — situations where prioritizing careful planning pays off.
The V-Model perspective
When illustrating waterfall, it's common to draw it not just as a straight vertical sequence, but as a "V-Model" that shows how each design phase corresponds to a testing phase.
📋 Requirements Definition
↔ Acceptance Testing
✏️ Basic Design
↔ Integration Testing
🔧 Detailed Design
↔ Unit Testing
Keeping this correspondence in mind — that what's decided in each design phase should be verified in its matching test phase — makes it easier to organize what needs to be tested where.
Summary
Waterfall is a development methodology that moves through requirements, design, implementation, testing, and release in order, without going back. Its ease of planning is a major strength, but it's important to understand its weakness against late-stage spec changes as well.
Related topics:
🏠 Back to top
Learn IT Fundamentals with Teacher Pochi