The waterfall model, and the projects where it is the right answer

One pass, gated

The waterfall model — also called the linear sequential model — performs each framework activity exactly once, in order, and opens each stage only when the stage above it is complete and its work product has been reviewed. Communication settles the requirements; planning produces the estimate, the schedule and the tracking mechanism; modeling produces analysis and design; construction produces code and the tests that exercise it; deployment delivers the software and moves into ongoing support and feedback. It is the oldest software engineering paradigm, and it is the model against which every other one in this module is defined — when the spiral model is described as taking a prototyping loop and adding waterfall-style discipline to it, the discipline being borrowed is this gate.

Why it is still on the syllabus

An exam answer that treats waterfall as simply wrong cannot earn the comparison marks, because the comparison marks come from knowing the conditions under which it is right. Those conditions are narrow but real: the requirements have to be genuinely well understood and reasonably stable. The standard case is a clearly bounded change to a system that already exists and is already understood — an accounting package that must be amended because a tax rule was amended. Nothing is being discovered; the specification arrives from outside and then holds still.

When those conditions hold, the model buys you three things the evolutionary family cannot match. It produces a predictable document trail, because each stage has one named work product. It supports fixed-scope, fixed-price contracting, because the scope is settled before construction begins. And it gives an auditor or a regulator explicit sign-off gates to inspect — someone signed the requirements, someone signed the design, and the dates are recorded.

The four problems, and the fifth one nobody lists

The criticisms are old and specific. First, work does not actually arrive in that order: change turns up in the middle of a project and a strict sequence has nowhere to put it. Second, the opening stage demands something customers are rarely able to supply — a complete, explicit account of what they want, given before they have seen anything at all. Third, the customer has to be patient, because there is no program to look at until the schedule is nearly spent. Fourth, a mistake made in week two can sit undetected for months and reveal itself only when somebody finally runs the assembled program, at which point fixing it costs many times what it would have cost at the time.

The fifth problem is structural rather than a criticism of intent: blocking states. Because stage n+1 cannot start until stage n is signed off, people are idle waiting for someone else's work product. On a small team that idleness is the whole schedule.

Worked example — the one BorrowBox job that wants a waterfall

The BorrowBox product as a whole is a bad candidate: nobody could specify, in advance, how a member wearing gardening gloves scans a QR code in bright sunlight while holding a hedge trimmer. That is discovered, not specified.

But one BorrowBox job fits perfectly. The council mandates a new late-fee rate with a statutory start date. The requirement is a one-page rate schedule; there is no design freedom, no discovery, and a legally required sign-off. Run it as a waterfall: communication produces the signed schedule; planning produces a two-week estimate against the statutory date; modeling produces the amended fee rules and the revised test specification; construction implements and tests them; deployment ships and the change is recorded. Every gate is exactly the audit trail the council wants, and the model's chief weakness — that the customer sees nothing runnable until late — costs nothing here, because the customer already knows precisely what they are getting.

That contrast is the answer shape the exam rewards. Name the project attribute (requirements fixed and externally imposed), map it to the model property (a single gated pass with a document trail), and then show the same team on a job where the attribute is absent and the model fails.