The waterfall model is reportedly employed by both the US D.O.D and NASA as their main software development model, due to its strict design practices and clear progress markers. This is despite being described as “risky and invites failure” by W.W.Royce, who . originally created the term “Waterfall model” and criticized it in favor of an iterative approach.
The waterfall model is a top down sequential model split into the sections shown in the software life cycle article, and illustrated by the image below

Image by Paul A. Hoadley, Creative Commons license
Note that:
  • Requirements are written in the user's language
  • Specification is written in system language
  • Unit testing checks units against the spec
  • System testing checks the requirements are met

    The waterfall model is well understood and time tested but generally considered to be less useful than it once was due to the increasing complexity of systems. It “works well for automating the tasks of clerks and accountants, less well for knowledge works such as experts trying to solve problems” (Information Center Quarterly article, Larry Runge). Another problem is that in the waterfall model users only input is in specifying requirements and that all requirements must be specified at one points before production begins. However, requirements typically change through the process and require more feedback.

    Summary of advantages:
  • Easy for managers to understand, plan by and to test progress against as it has very clear sequential milestones
  • Encourages good design practices such as early clarification of system goals, which in turn save time and money (the earlier a bug is caught, the less harm it can cause)
  • Due to lots of up front design planning, should the project be stopped and taken up at a later date, or should project members change, implementation can continue far easier than with more agile development models where there is considerably less design documentation.
  • Compatible with a wide range of design strategies

    Summary of disadvantages
  • Users may change requirements often, at stages beyond the requirements stage
  • Users may not be able to state requirements until they see a working prototype that they can criticise
  • At the implementation stage programmers may find that there is a near impossible problem to implement, and it may be easier to change the original design than to proceed ahead as planned.
  • Constant verification of each stage is required to ensure that the next phase can start on a correct base
  • Technology may change during development


    Most of the problems of the waterfall model are solved by iterative and evolutionary models such as the Spiral Model