In the waterfall model, a project progresses through an orderly sequence of steps from the initial software concept through system testing. The project holds a review at the end of each stage to determine whether it is ready to advance to the next phase. If not, it remains in the same phase.

The pure waterfall model performs well for product cycles in which you have a stable product defination and when you are working with well understood technical methodologies. In such cases, the waterfall model helps you to find out errors in the early, low cost stages of the product. It provides the requirements stability that developers crave. If you are building a well defined maintenance release of an existing product or porting an existing product to a new platform, a waterfall lifecycle might be the right choice for rapid development

The pure waterfall model helps to minimize planning overhead because you can do all the planning up front. It doesn't provide tangible results in the form of software until the end of the lifecycle, but to someone who is familiar with it, the documentation it generates provides meaningful indications of progress throughout the lifecycle. The waterfall model works well for projects that are well defined, well understood and complex, because you can benifit from tackling complexity in an orderly way. It works well when quality requirements dominate cost and schedule requirements. Elimination of midstream changes eliminates a huge and common source of potential errors.

The waterfall model works especially well if you have a technically weak staff or an inexperienced staff, because it provides the project with a structure that helps to minimize wasted effort.

The disadvantages of the pure waterfall model arise from the difficulty of fully specifying requirements at the beginning of the project, before any design work has been done and before any code has been written.

The major problem with the waterfall model is that it is not flexible. You have to fully specify the requirements at the beginning of the project.

Notes and images from Rapid Development: Taming Wild Software Schedules by Steve McConnell