How do the waterfall, iterative and agile approaches differ, and when is each suitable?
The waterfall, iterative or incremental and agile or rapid application development methodologies, their characteristics, advantages, disadvantages and the situations that suit each.
A CCEA A-Level Digital Technology answer comparing the waterfall, iterative or incremental and agile or rapid application development methodologies, their characteristics, strengths, weaknesses and the projects that suit each approach.
Reviewed by: AI editorial process; not yet individually human-reviewed
Have a quick question? Jump to the Q&A page
Jump to a section
What this dot point is asking
CCEA wants you to know the main development methodologies, the waterfall, iterative or incremental, and agile or rapid application development (RAD), to describe how each organises the life cycle, and to weigh their advantages and disadvantages so you can recommend one for a given situation. Exam questions usually give a scenario and ask you to choose and justify.
The waterfall model
Waterfall suits projects where requirements are clear and stable from the start, where formal documentation is needed (for example for a regulated or audited system), and where the final cost and timetable must be agreed up front. Its weaknesses are poor tolerance of change (going back up the waterfall is expensive) and the customer seeing no working software until late in the project, so a misunderstanding can go undetected for months.
Iterative and incremental development
Because the customer sees working parts early, misunderstandings surface sooner and risk is spread across several smaller deliveries rather than one big release. This suits medium and large systems where the full set of requirements is hard to pin down in one go.
Agile and rapid application development
Agile and RAD welcome changing requirements and give frequent feedback, which is why they suit projects where needs are unclear at the start or expected to change, and where speed to a working product matters. The trade-off is lighter documentation and a scope that moves, making final cost, deadline and shape harder to predict; they also depend on a customer who is available throughout.
Comparing the approaches
Across all three, the same trade-off recurs: structure and predictability (waterfall) versus flexibility and early feedback (agile), with iterative and incremental sitting between. The right choice depends on how stable the requirements are, how much documentation is needed, how big the project is, and how available the customer is.
Try this
Q1. State one situation in which waterfall is more suitable than agile. [1 mark]
- Cue. When requirements are stable and full, signed-off documentation is required (for example for audit).
Q2. Give two advantages of delivering a system in increments. [2 marks]
- Cue. The customer sees working software early so misunderstandings surface sooner; risk is spread across smaller deliveries rather than one large release.
Q3. Explain why agile depends on close customer involvement. [2 marks]
- Cue. Requirements are refined each iteration from customer feedback, so without an available customer the team cannot validate direction or prioritise the next iteration.
Exam-style practice questions
Practice questions written in the style of CCEA exam questions on this dot point, with worked answer explainers. The year tag is the paper they imitate, not the source.
CCEA AS 16 marksCompare the waterfall and agile methodologies, giving one advantage and one disadvantage of each.Show worked answer →
Set the two approaches side by side rather than describing them separately.
Waterfall runs the life cycle stages once, in a fixed sequence, with each stage signed off before the next begins. Advantage: clear documentation and milestones make progress easy to manage and audit. Disadvantage: it copes badly with changing requirements, because returning to an earlier stage is costly and the customer sees nothing working until late.
Agile delivers the system in short iterations, each producing working software, with the customer involved throughout. Advantage: it welcomes changing requirements and gives early, frequent feedback. Disadvantage: lighter documentation and a moving scope make cost, time and final shape harder to predict, and it relies on close customer availability.
Markers reward a genuine comparison (fixed sequence versus iterations, sign-off versus continuous feedback) plus one valid advantage and one valid disadvantage per method. A list of features with no advantages or disadvantages caps the mark.
CCEA AS 14 marksA company is building a system whose requirements are well understood, stable and must be fully documented for an external audit. Recommend a suitable methodology and justify your choice.Show worked answer →
Recommend the waterfall (or a structured, plan-driven) methodology and justify it against the three clues in the question.
Stable, well-understood requirements mean little change is expected, so waterfall's weakness (poor tolerance of change) does not bite. The need for full documentation suits waterfall, because each stage produces a signed-off deliverable, giving the audit trail the external auditor needs. The fixed sequence and milestones make progress and cost predictable.
Markers award the recommendation mark for naming waterfall (or an equivalent structured approach) and the justification marks for linking it to stable requirements and the documentation or audit requirement. A recommendation with no justification, or one that ignores the stated context, loses the justification marks.
Related dot points
- The stages of the systems development life cycle, the activities carried out in each stage and the documented outputs each stage hands on to the next.
A CCEA A-Level Digital Technology answer on the systems development life cycle: its stages from feasibility through analysis, design, implementation, testing and maintenance, the activities in each, and the documents each stage produces.
- The purpose and types of feasibility (technical, economic, legal, operational and schedule), fact-finding techniques for requirements gathering, and functional and non-functional requirements.
A CCEA A-Level Digital Technology answer on the feasibility study (technical, economic, legal, operational and schedule), fact-finding techniques for gathering requirements, and the difference between functional and non-functional requirements.
- Designing the inputs, outputs, processing, data storage and user interface of a system, and the design tools used: data flow diagrams, system flowcharts, entity relationship diagrams and the data dictionary.
A CCEA A-Level Digital Technology answer on the design stage: specifying inputs, outputs, processing, data storage and the user interface, and the design tools used including data flow diagrams, system flowcharts, entity relationship diagrams and the data dictionary.
- Levels of testing (unit, integration, system and acceptance), the purpose of a test plan, and the use of normal, boundary and erroneous test data.
A CCEA A-Level Digital Technology answer on testing: the levels of testing (unit, integration, system and acceptance), the purpose of a test plan, and the use of normal, boundary and erroneous test data with expected results.
- The purpose and contents of technical documentation and user documentation, and the audience each serves during development, use and maintenance.
A CCEA A-Level Digital Technology answer on system documentation: the purpose, contents and audience of technical documentation and user documentation, and why each matters during development, use and maintenance.
Sources & how we know this
- CCEA GCE Digital Technology specification — CCEA (2016)