The SDLC & Methodologies

The Waterfall Model

18 min Lesson 2 of 10

The Waterfall Model

In 1970, Dr. Winston Royce published a paper describing a sequential approach to software development that would become the most recognizable methodology in the industry. Though Royce himself noted its risks, the diagram he included — showing work flowing downward from one phase to the next like water cascading over a cliff — gave the world the Waterfall model. Understanding it deeply matters not just for historical context, but because its core structure still underpins formal contracts, regulated industries, and hybrid methods used today.

The Sequential Phases

Waterfall divides a project into a fixed sequence of phases. Each phase must be completed and formally signed off before the next begins. The classic sequence, illustrated below, consists of six phases:

  1. Requirements — All business and user needs are captured in a written specification. The analyst interviews stakeholders, documents functional and non-functional requirements, and produces a System Requirements Specification (SRS).
  2. System Design — Architects translate requirements into a high-level system architecture (hardware, network topology, major components, third-party integrations). The output is a System Design Document (SDD).
  3. Detailed Design — Developers and analysts break down the architecture into module-level designs: database schemas, class diagrams, API contracts, UI wireframes. This produces detailed technical specifications.
  4. Implementation (Coding) — Developers build the system according to the approved design. No design decisions are made here — the code simply implements what was specified.
  5. Testing & Verification — A dedicated QA team validates the built system against the original requirements. Defects are fixed and re-tested until the system passes acceptance criteria.
  6. Deployment & Maintenance — The system is released to production. Maintenance covers bug fixes, minor enhancements, and performance tuning over the product's operational lifetime.
The Waterfall Model — Sequential Phases 1. Requirements SRS — signed by stakeholders 2. System Design SDD — architecture & components 3. Detailed Design DB schema, class diagrams, APIs 4. Implementation Coding per approved design 5. Testing & Verification UAT, defect resolution 6. Deployment & Maintenance Sign-off required Sign-off required Sign-off required
The Waterfall model: each phase flows into the next, with a formal sign-off gate between phases.

Deliverables and Sign-offs

The defining characteristic of Waterfall is its gate-based governance. At the end of every phase, the project team produces a formal deliverable that is reviewed by stakeholders, managers, and sometimes an independent auditor. Work on the next phase cannot begin until an authorized sponsor signs off that the deliverable is complete and accepted.

Consider a clinic booking system being built under a Waterfall contract. The project timeline might look like this:

  • Requirements phase (6 weeks): The analyst interviews the medical director, reception staff, and three doctors. The output — a 45-page SRS — specifies every booking rule, access-control requirement, and integration with the existing patient-records system. The clinic director and IT manager sign the document. From this moment, any change to requirements triggers a formal Change Request (CR) process.
  • System Design phase (4 weeks): Architects produce an SDD: a three-tier web architecture (browser, application server, MySQL database), a data-flow diagram, and an entity-relationship diagram. The technical lead and project manager sign off.
  • Detailed Design phase (3 weeks): Developers produce database schema scripts, REST API contracts, and annotated wireframes. Another sign-off gate.
  • Implementation phase (10 weeks): Five developers write code against the approved specifications. Mid-point code review included.
  • Testing phase (4 weeks): QA runs 220 test cases drawn directly from the SRS. 14 defects found; 14 resolved and re-tested. User acceptance testing with clinic reception staff. Final sign-off by the clinic director.
  • Deployment (1 week): System goes live. The clinic goes paper-free for bookings.

Total project duration: approximately 28 weeks. The clinic saw nothing working until week 23. Every deliverable was a document, not software.

The sign-off is a legal and professional boundary. In fixed-price government or healthcare contracts, a signed SRS is binding. If the client later wants a feature that was not in the SRS, they must raise a change request, which may extend the timeline and increase the cost. The sign-off protects both the development team and the client.

Strengths of the Waterfall Model

Waterfall's longevity is not an accident. It has genuine strengths that make it the right choice in specific contexts:

  • Clarity of scope: Every requirement is agreed up front. Budget and timeline can be estimated with reasonable confidence because the scope is fixed.
  • Predictability for fixed-price contracts: A government agency tendering for a national tax system, or a hospital commissioning a patient management platform, needs a legally binding specification. Waterfall provides this through its documentation and sign-off structure.
  • Auditability: Every decision is documented and traceable. Regulated industries (aviation, medical devices, defense) require proof that requirements were specified, reviewed, implemented as specified, and tested against those specifications. Waterfall's paper trail satisfies these demands.
  • Clear role boundaries: Analysts analyze. Architects design. Developers code. Testers test. Each team knows when it is responsible and what it must produce.
  • Well-suited to stable domains: If you are building payroll software where the rules are codified in law and do not change, exhaustive upfront requirements capture is both feasible and efficient.

Weaknesses of the Waterfall Model

The same properties that make Waterfall strong in stable environments make it brittle elsewhere. Its weaknesses are well-documented and significant:

  • Late discovery of problems: Stakeholders see working software only at the end of the project. A misunderstood requirement discovered at testing costs 10–100 times more to fix than if it had been caught during analysis.
  • Resistance to change: The change request process, designed to protect scope, also makes it expensive and slow to adapt to legitimate business changes that occur during a long project.
  • Unrealistic requirements upfront: Users often cannot articulate requirements clearly until they see a prototype. Asking a receptionist to sign off on a 45-page SRS and hold them to it is a recipe for a system that technically meets requirements but fails in real use.
  • Long time to market: A logistics firm building a route-optimization portal under Waterfall might wait 18 months before the tool reaches drivers — by which time a competitor has shipped two iterations of an agile product.
  • Integration risk: Individual modules are built independently and integrated only near the end. Integration problems compound, and resolving them in testing compresses the schedule.
Waterfall Strengths vs Weaknesses Comparison Panel Strengths + Clear, fixed scope upfront + Predictable budgets & timelines + Full audit trail of decisions + Satisfies regulatory requirements + Clear team role boundaries + Good for stable, known domains + Simple to manage & explain Weaknesses − Software seen only at the end − Changes are costly & slow − Users cannot specify upfront − Long time to market − Late integration problems − Risk concentrated at end − Low stakeholder engagement
Waterfall strengths favor stable, regulated, fixed-scope projects; weaknesses appear in fast-changing or complex-requirement environments.

When to Use Waterfall

Despite its limitations, Waterfall is not obsolete. It is the correct choice when:

  • Requirements are well understood, stable, and unlikely to change (embedded systems, compliance-driven platforms).
  • The project is governed by a fixed-price or fixed-scope contract where legal accountability demands a signed specification.
  • The domain is safety-critical — aviation avionics, medical device software, nuclear plant control systems — where traceability from requirement to test is a regulatory mandate.
  • The team is geographically distributed or outsourced across multiple vendors, and tight coordination requires clear written handoffs between phases.
Analyst tip — Royce's original warning: Winston Royce did not advocate blindly for the sequential model he illustrated. He explicitly warned that delivering software in one sequence without any feedback is "risky and invites failure." He recommended building a preliminary prototype during design to reduce requirements uncertainty — advice that foreshadowed modern iterative methods. When you are forced to use Waterfall, consider advocating for a limited proof-of-concept before the requirements phase closes.
The hidden feedback loops: Real Waterfall projects almost never stay purely sequential. Requirements change. Designs prove unfeasible. Test failures cascade back to requirements. In practice, these feedback loops exist but are managed through expensive change requests rather than designed-in iteration. A methodology that denies natural feedback loops does not eliminate them — it just makes them costlier.

Summary

  • Waterfall divides projects into six sequential phases: Requirements, System Design, Detailed Design, Implementation, Testing, and Deployment.
  • Each phase ends with a formal deliverable and sign-off gate before the next phase begins.
  • Strengths include predictability, auditability, and suitability for regulated or fixed-price contracts.
  • Weaknesses include late feedback, high cost of change, and difficulty handling uncertain requirements.
  • Waterfall is appropriate for stable, well-understood, compliance-driven projects — and poorly suited to anything where requirements are expected to evolve.
Previous Lesson The System Development Life Cycle
Next Lesson Iterative & Incremental Development
Back to Course