Waterfall Model
Waterfall is a sequential SDLC model: requirements → design → implementation → verification → maintenance, with the intent that each phase completes before the next begins. In its pure form, change to earlier phase outputs is expensive and controlled through formal change management.
Pure Waterfall is rare in web product companies — but phased, gated delivery remains common in regulated industries, hardware-software systems, and fixed-price contracts. Understanding Waterfall helps you recognize when sequential gates are justified and when they are theater.
info
1. Requirements
Capture complete specifications. Sign-off freezes scope. Heavy documents: SRS/FRD, NFR specs, interface control documents.
2. System & software design
Architecture, detailed design, interface specs. Often V-model planning of tests against requirements.
3. Implementation
Build to the specification. Deviations require change requests.
4. Integration & verification
Execute the planned test suite; trace results to requirements.
5. Deployment / installation
Controlled release, acceptance by customer, documentation handover.
6. Operation & maintenance
Defect fixes and approved enhancements via change control.
The V-model variant pairs each development stage with a corresponding test stage (e.g., requirements ↔ acceptance tests, design ↔ integration tests), emphasizing traceability.
Choose sequential gated delivery when the cost of late change exceeds the cost of upfront analysis — or when regulators demand it.
| Driver | Why Waterfall helps |
|---|---|
| Fixed, well-understood requirements | Rework from ambiguity is unlikely |
| Heavy regulation (medical, avionics, finance core) | Traceability and phase evidence |
| Fixed-price contract with clear SOW | Scope control protects both parties |
| Hardware lead times | Software must align to frozen interfaces |
| High cost of failure in production | Verification emphasis before release |
- Requirements are stable or change is contractually controlled.
- Stakeholders can specify acceptance comprehensively before build.
- Integration with physical systems forces interface freezes.
- Auditors expect phase artifacts and signatures.
best practice
- Market or user needs change faster than the phase plan.
- Stakeholders cannot articulate requirements without seeing working software.
- Integration risk is discovered only at the end.
- Teams use Waterfall paperwork but skip actual verification rigor — worst of both worlds.
- Architecture is frozen before domain learning occurs.
danger
| Phase | Typical artifacts | Gate criteria |
|---|---|---|
| Requirements | SRS, use cases, NFR spec | Signed baseline; open issues listed |
| Design | SDD, ADRs, ICD, test plan | Review complete; risks mitigated/accepted |
| Implementation | Code, unit evidence | Coding standard met; peer review |
| Verification | Test reports, trace matrix | Coverage of critical reqs; defects dispositioned |
| Release | Release notes, acceptance cert | Customer/CAB approval |
| Risk | Mitigation |
|---|---|
| Late discovery of wrong product | Early prototypes; staged acceptance demos |
| Big-bang integration failure | Incremental integration builds inside implementation |
| Requirements gold-plating | MoSCoW; change budget; timeboxes on analysis |
| Knowledge silos across phases | Overlapping staff; living docs; ADRs |
| False sense of progress | Executable milestones, not document weight |
| Aspect | Waterfall | Iterative (Agile) |
|---|---|---|
| Feedback timing | Late (after phases) | Early and continuous |
| Change cost | High after baseline | Expected; managed in backlog |
| Documentation | Heavy, formal | Enough to sustain delivery |
| Architecture | Often BDUF | Evolutionary with ADRs |
| Best uncertainty level | Low | Medium–high |
Hybrid approaches are common: Waterfall-style gates for compliance artifacts inside an otherwise iterative delivery team — e.g., Scrum for development with formal verification packages for release trains.
Waterfall tempts big design up front. That can be appropriate when interfaces must freeze. Counter the risk by:
- Recording assumptions in ADRs with revisit criteria.
- Preferring modular monolith / hexagonal boundaries so frozen outer interfaces can still allow inner evolution.
- Planning verification of NFRs explicitly in the V-model, not as afterthoughts.
| 1 | # ADR: Baseline architecture for Phase 2 sign-off |
| 2 | |
| 3 | ## Context |
| 4 | Regulatory gate requires architecture baseline before coding. |
| 5 | |
| 6 | ## Decision |
| 7 | Modular monolith with hexagonal ports; PostgreSQL; sync REST for v1. |
| 8 | |
| 9 | ## Consequences |
| 10 | + Clear audit artifact |
| 11 | - Extraction of services deferred until post-release evidence |
| 12 | - Revisit if independent deploy becomes a requirement |
If your context truly requires sequential gates, run them deliberately:
- Staff phases with overlapping people so knowledge transfers.
- Timebox analysis; use MoSCoW to prevent gold-plating.
- Prototype high-risk UX and integration paths during requirements/design.
- Plan incremental integration builds — do not wait for a single big-bang integrate step.
- Define change-control SLAs so urgent fixes are not informal cowboy changes.
Requirements workshop
Facilitate structured sessions: goals, personas, scenarios, NFRs, out-of-scope. Record decisions and open questions.
Design baseline package
C4 + ADR set + interface control docs + test plan mapped to requirements (V-model).
Verification readiness
Trace matrix complete for must-have requirements; residual risk accepted by named owner.
Many organizations run "Waterfall on the outside, Agile on the inside": contractual milestones and compliance packages externally, iterative development internally between gates.
| Outer gate | Inner practice |
|---|---|
| SRS baseline | Discovery sprints + prototypes before sign-off |
| Design baseline | Spikes + ADR drafts reviewed at gate |
| Release package | Scrum/Kanban delivery with formal verification export |
pro tip
Community
Get help on Slack, Discord or VIP
Stuck on a guide? Join the community and ask.