Waterfall Model

Waterfall Model (1970+)

Model Phases

Diagram of the Waterfall Model

Feasibility: Defining a preferred concept for the software product, and determining its life-cycle feasibility and superiority to alternative concepts.
Requirements: A complete, verified specification of the required functions, interfaces, and performance for the software product.
Product Design: A complete verified specification of the overall hardware-software architecture, control structure, and data structure for the product, along with such other necessary components as draft user's manuals and test plans.
Detailed Design: A complete verified specification of the control structure, data structure, interface relations, sizing, key algorithms, and assumptions of each program component.
Coding: A complete, verified set of program components.
Integration: A properly function software product composed of the software components.
Implementation: A fully functioning operational hardware-software system, including such objectives as program and data conversion, installation, and training.
Maintenance: A fully functioning update of the hardware-software system repeated for each update.
Phaseout: A clean transition of the functions performed by the product to its successors.

Key Characteristics

  • Each phase is required.
  • Each phase ends with a verification, validation, or test activity to ensure that the objectives of each phase are satisfied.
  • The product goes through each phase sequentially and produces ever improving baselines of intermediate products.
  • Interactions within a phase occur until it is passes the transition criteria (verified or validated as satisfactory).
  • The baseline, once achieved, is put under formal change control process. (No changes are made to the baseline unless all interested parties agree.)

Economic Rationales

  1. In order to achieve a successful software product, must achieve all of the subgoals within each phase at some stage anyway.
  2. Any different ordering of the phases will produce a less successful software product. (It costs more to remove defects later in the development cycle.)


  • A sequential approach to building a product in which iteration is not visibly evident.
  • Emphasis on fully elaborated documents as completion criteria for early requirements and design phases does not work well for many classes of software, particularly interactive end-user applications.
“Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy. Hence, they cannot be fixed without fundamental revision—revision that provides for iterative development and specification of prototypes and products.”  —Fred Brooks

Copyright © 1995–2013 Dr. Jody Paul, All Rights Reserved