A-Level Computer Science / Unit 12: Software Design, Testing and Evolution

12.1.2 Developing Software with the Waterfall Model

🔒 Lesson slides are available to signed-in users. Sign in

12.1.2 Developing Software with the Waterfall Model

The waterfall model organises software development into clearly separated stages. Work normally progresses from analysis to design, coding, testing and maintenance, with the output of one stage supporting the work of the next.

This approach can make a project easier to plan and document when its requirements are stable. However, changes discovered late in development may require substantial work to be repeated.

By the end of this section, you should be able to:

  • Explain how the waterfall model organises the development stages.
  • Describe how evidence passes from one stage to the next.
  • Explain the main benefits and limitations of waterfall development.
  • Explain why late changes can be costly in a waterfall project.
  • Judge whether waterfall is suitable for a given project scenario.

The Core Principle of Waterfall Development

In a waterfall project, development is divided into a sequence of defined stages. A team aims to complete and review the work of one stage before committing major resources to the next.

Waterfall model: a development approach in which a project moves through clearly defined stages in a mainly sequential order.

The model is called “waterfall” because the main direction of movement is down through the stages. Information produced during analysis supports design; the design guides coding; the implemented program is passed to testing.

Earlier work may still need to be revisited when a problem is found. Waterfall therefore does not mean that returning to a previous stage is impossible. The important idea is that the project is planned around separated stages and formal handovers rather than frequent overlapping cycles.

Common misconception: Waterfall does not guarantee that every stage will be correct the first time. A later discovery may require the team to return to an earlier stage.

A Waterfall Project Stage by Stage

The purposes of the stages were introduced in the previous section. In the waterfall model, attention is placed on completing the expected work and evidence at each stage before moving forward.

Stage Main waterfall activity Typical evidence before progressing
Analysis Investigate the problem and agree what the software is required to achieve. Reviewed requirements specification
Design Plan the data, algorithms, modules, interfaces and storage required by the agreed requirements. Design documentation and algorithm plans
Coding Implement the approved design using a suitable programming language. Completed source code and working build
Testing Check the completed program against the requirements and expected results. Test records, fault reports and corrected version
Maintenance Make controlled changes after the software has entered use. Change requests, revised code and update records
Exam tip: “Sequential” does not simply mean listing the stages in order. Explain that the completed output of one stage is used by the following stage.

Stage Outputs and Handoffs

A major feature of waterfall development is the handover between stages. The next group of tasks depends on information produced earlier, so missing or unclear evidence can cause problems later.

Handover Information passed forward Risk if it is unclear or incomplete
Analysis → Design Agreed functions, rules, inputs, outputs and constraints The design may solve the wrong problem or omit a required feature.
Design → Coding Algorithms, modules, data structures and interfaces Different programmers may implement incompatible solutions.
Coding → Testing A completed build and information about implemented features Testing may begin before all required functionality is available.
Testing → Release Test evidence, unresolved issues and corrected versions Known faults may reach users or required behaviour may remain unchecked.
A deliverable is an identifiable output produced during a stage, such as a requirements document, design plan, program build or test report.

Worked Example: Planetarium Booking Reports

A small planetarium needs a program that produces daily seating reports for staff. Its booking rules have already been agreed, and management does not expect them to change during development.

The team chooses waterfall because the required outputs, input files and report format are stable.

Stage Original project activity
Analysis Staff specify the booking file format, the number of seating zones and the information required in each daily report.
Design The team plans records for bookings, an algorithm for counting occupied seats and a procedure for producing the final report.
Coding Developers implement the file-reading, counting and report-generation modules.
Testing Test files represent an empty performance, a partly booked performance and a completely full performance.
Maintenance After release, the report heading is updated when the planetarium changes its organisation name.

This project is a reasonable waterfall candidate because the requirements are understood in advance and the output is limited and predictable.

Exam tip: A justification should connect the project evidence to the model. Here, the strongest point is not simply that the project is “small”; it is that the requirements and report format are stable.

Benefits of the Waterfall Model

Clear organisation

The separated stages make the overall process straightforward to understand. Team members can see what work belongs to the current stage and what evidence is expected.

Visible milestones

Completion of a requirements document, design specification, implementation or test report provides a recognisable project milestone. This can help with schedules, responsibilities and progress reporting.

Strong documentation

Formal handovers encourage the team to document decisions. This can support later developers who need to understand why a particular design was chosen.

Effective with stable requirements

When the problem is well understood and unlikely to change, early planning can reduce uncertainty. The team can design the full solution against a dependable set of requirements.

Benefit Project consequence
Defined stages Responsibilities and expected outputs are easier to organise.
Planned sequence Time and resources can be assigned to known stages.
Documented decisions Future developers have a record of requirements and design choices.
Stable starting point Less rework is needed when requirements remain unchanged.

Limitations of the Waterfall Model

Working software appears relatively late

Much of the analysis and design may be completed before users can interact with a working version. A misunderstanding may therefore remain hidden until coding or testing.

Late changes create rework

A new requirement may affect the requirements specification, design, code and tests. Changing one stage can therefore require several later deliverables to be revised.

Feedback may arrive too late

Users may find it difficult to judge a written specification or design. They might only recognise that the system is unsuitable after seeing the completed program.

Integration problems can be discovered late

If separately developed parts are combined near the end of coding, incompatibilities may not become visible until much of the implementation has already been completed.

Limitation Possible result
Limited early working software Users cannot evaluate the complete interaction until later.
Difficult requirement changes Several completed stages may need revision.
Late discovery of misunderstandings The team may have implemented a carefully planned but unsuitable system.
Late technical integration Major module-interface faults may affect the schedule.
Common mistake: Do not state that waterfall is always unsuitable for large projects or always suitable for small projects. Requirement stability and the need for early feedback are often more important factors than size alone.

Why a Late Change Can Be Expensive

Suppose the planetarium reaches the testing stage. Management then asks for each report to include a QR code linking to an online seating map.

The team may need to revisit several completed stages.

Stage revisited Work caused by the late request
Analysis Clarify what the QR code links to, when it is generated and who can access the destination.
Design Plan how the URL is stored, how the QR code is produced and where it appears in the report.
Coding Add the generation module and alter the report layout.
Testing Test valid links, unavailable links, report layout and existing seating totals.
Rework: repeating or revising completed work because a requirement, design decision or implementation must change.
Exam tip: When explaining the difficulty of change in waterfall, identify the completed documents, code and tests that must be updated. Avoid the unsupported statement that “waterfall cannot change.”

When Is Waterfall a Suitable Choice?

Waterfall is most convincing when the development team can make reliable decisions early and those decisions are unlikely to change during implementation.

Waterfall is more suitable when... Waterfall is less suitable when...
The required functions are clearly understood. Users are still discovering what they need.
Requirements are expected to remain stable. Rules, technology or priorities are changing frequently.
Formal documentation and approval are valuable. Users need to evaluate working versions very early.
The technology and implementation method are familiar. Important technical risks can only be understood through experimentation.
The complete project can be planned with reasonable confidence. The final solution is expected to emerge through repeated feedback.
Strong justification pattern: “Waterfall is suitable because the project has [specific characteristic]. This allows [relevant waterfall feature] to provide [project benefit].”

Interactive: Waterfall Project Simulator

Explore a project that follows its planned sequence, receives a late requirement change or discovers an integration fault during testing.

Waterfall path

Planned waterfall project

Clear stages and predictable handovers

The requirements remain stable, so each completed stage provides a dependable input for the next.

Step 1 of 5

Agree the requirements

The team confirms the required booking inputs, rules and reports.

Common Mistakes and Misconceptions

  • “Waterfall means no stage can ever be revisited.” Earlier stages can be revisited, but doing so may create substantial rework.
  • “Waterfall is suitable whenever a project is small.” Stable, well-understood requirements are a stronger justification.
  • “The model produces working software early.” A complete working system usually appears after significant analysis, design and coding.
  • “Documentation is unnecessary extra work.” In waterfall, documents support handovers, approval and later maintenance.
  • “A change only affects the coding stage.” A new requirement may alter analysis, design, code and testing.

Practice

Core questions

  1. Explain why the waterfall model is described as mainly sequential.
  2. Give two examples of deliverables that can be passed between stages.
  3. Explain two benefits of using waterfall when requirements are stable.
  4. Explain why working software may appear relatively late.
  5. Explain why a change requested during testing can create rework.
  6. Explain one problem that may result from late module integration.

Scenario: Environmental Sensor Report

A research station needs a small program that reads a fixed sensor-file format and produces a standard weekly temperature report. The scientists have used the same report format for six years and do not expect it to change.

  1. Explain two reasons why waterfall could be suitable.
  2. Identify one deliverable that could be produced during design.
  3. Describe one limitation the team should still consider.
  4. During final testing, the scientists request an interactive graph. Explain why this is more difficult than requesting it during analysis.
Challenge: Write a balanced judgement containing one project-linked benefit, one project-linked limitation and a final conclusion about suitability.

Review

Prompt A strong response should include
Waterfall principle Defined stages completed mainly in sequence, with outputs passed forward.
Main benefit Clear planning, milestones and documentation when requirements are stable.
Main limitation Late feedback or changing requirements can cause substantial rework.
Working software A complete working version normally appears after analysis, design and coding.
Suitable project A project with clear, stable requirements and a familiar technical solution.
Unsuitable project A project that depends on frequent user feedback or changing requirements.
Final exam tip: Avoid describing waterfall only with adjectives such as “simple”, “slow” or “inflexible”. Explain the project process that produces the advantage or limitation.