The waterfall model is a sequential software development lifecycle in which each phase must be fully completed before the next begins. Progress flows downward through requirements, design, implementation, testing, and maintenance — like water tumbling over falls, never flowing upward. It is one of the oldest formal approaches to software engineering.
What are the five phases of the waterfall model?
Think of building a bridge: you cannot pour concrete until the architects have finished their drawings, and you cannot open it to traffic until safety tests are complete. The waterfall model applies the same discipline to software.
| Phase | What happens | Key output |
|---|---|---|
| 1. Requirements | Analysts gather exactly what the client needs | Requirements specification document |
| 2. Design | Programmers plan the system architecture, data structures, and interfaces | Design document |
| 3. Implementation | Developers write the code to the agreed design | Working code |
| 4. Testing | The completed system is verified against the requirements | Test reports, bug fixes |
| 5. Maintenance | The live system is updated and patched as issues arise | Patches, updates |
Each phase produces a deliverable — a document or piece of software — that is reviewed and signed off before the team proceeds. The entire project is planned upfront, with timescales and budgets agreed before a single line of code is written.
What are the advantages of the waterfall model?
The waterfall model suits projects where the requirements are clear, stable, and unlikely to change. Its structured nature brings several genuine strengths:
Clear milestones — managers can tell at a glance whether requirements are complete, whether design is signed off, and whether testing is done. Progress is unambiguous.
Thorough documentation — every phase ends with a formal document. This is invaluable when team members change, when auditors review the project, or when the system needs maintaining years later.
Easy to manage — because every task is defined upfront, the project manager knows the scope, schedule, and cost from the start. Fixed-price contracts are possible.
Separate roles — analysts, designers, developers, and testers can be organised into separate specialist teams, each responsible for one phase.
What are the disadvantages of the waterfall model?
The model's rigidity, which is also its greatest strength, becomes its greatest weakness the moment requirements change — which they almost always do.
No working software until late — the client sees nothing until implementation is complete, which could be months into the project. If the requirements were misunderstood, the team has wasted that entire time building the wrong thing.
Changes are expensive — returning to a previous phase to fix a misunderstood requirement means redoing design, implementation, and testing. In large projects this can be catastrophic.
Testing comes too late — bugs are found only in Phase 4. In an iterative model, testing happens continuously, making bugs cheaper and easier to fix while the code is still fresh.
Assumes stable requirements — most real-world software projects change during development. Clients discover new needs; markets shift; technology evolves. The waterfall model has no formal mechanism to accommodate this.
How does the waterfall model compare with agile development?
| Feature | Waterfall | Agile |
|---|---|---|
| Planning | Full plan upfront | Evolves through short sprints |
| Working software | Delivered at the end | Delivered continuously, sprint by sprint |
| Response to change | Difficult and costly | Welcomed and expected |
| Customer involvement | At requirements and sign-off only | Throughout every sprint |
| Documentation | Comprehensive and formal | Lightweight — working code is the primary measure |
| Best suited to | Stable, well-understood requirements | Evolving or unclear requirements |
| Team size | Large, specialist teams | Small, cross-functional teams |
Agile methods such as Scrum divide work into short sprints (typically two weeks), deliver a usable increment at the end of each one, and adapt the plan based on feedback. The customer sees progress constantly, not just at the end.
When is the waterfall model still used in practice?
Despite its limitations, the waterfall model remains appropriate in certain domains:
- Safety-critical systems — aircraft control software or medical devices require exhaustive upfront design and formal verification. A bug discovered post-deployment could cost lives; fixing it iteratively mid-flight is not an option.
- Government and defence contracts — large procurement contracts often specify deliverables, costs, and timelines in legally binding terms, favouring the waterfall's fixed-scope approach.
- Well-understood, stable projects — if a company has built the same type of payroll system ten times before, the requirements are well-known and unlikely to change. The overhead of waterfall is acceptable.
In practice, most modern software teams use agile, or a hybrid that borrows waterfall's documentation discipline for certain phases while remaining flexible in others.
How do GCSE examiners test this topic?
Exam questions typically ask you to:
- Name and describe the phases of the waterfall model.
- Give one advantage and one disadvantage.
- Compare waterfall and agile for a given scenario.
- Identify which model is more appropriate for a described project, justifying your choice.
When comparing, match the model to the scenario: a new social-media app for a startup suits agile (requirements will change); flight-control software for an airline suits waterfall (requirements must be exact and stable).
Frequently asked questions
What are the five phases of the waterfall model in order?
The five phases are: (1) Requirements — defining what the system must do; (2) Design — planning the architecture and interfaces; (3) Implementation — writing the code; (4) Testing — verifying the completed system against requirements; (5) Maintenance — patching and updating the live system. Each phase must be signed off before the next begins.
Why is the waterfall model considered inflexible?
Because the requirements are fixed at the start and there is no formal mechanism to revisit them once a phase is complete. If a client changes their mind in Phase 3, the team must return to Phase 1 and redo all subsequent work. In contrast, agile methods expect requirements to evolve and accommodate change through short, iterative development cycles.
When should you choose waterfall over agile in an exam answer?
Choose waterfall when the scenario describes: a safety-critical or highly regulated system; a project with fixed costs and timescales (e.g. a government contract); a well-understood problem domain where requirements are unlikely to change. Choose agile when requirements are evolving, the client wants frequent feedback, or the team is small and cross-functional.
Is the waterfall model still used by real software companies?
Yes, though less commonly than agile. It remains standard in defence, aerospace, and embedded systems — contexts where every requirement must be traceable, every design decision documented, and every test formally recorded. Most commercial software companies now prefer agile or hybrid approaches, using waterfall-style documentation only where regulation demands it.
Professor Turing at aitutors.me can walk you through waterfall vs agile scenarios and give you instant Socratic feedback on your exam-style answers.