Problems with waterfall software development model

Other software development models were developed (such as the Agile model) because it was felt that the sequential process defined in the Waterfall model was argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product's lifecycle in a complete form before the next step is started. As an example, clients are almost never confident of their requirements being in a final form before they see a working prototype and can comment upon it; they may change their requirements constantly, and program designers and implementers may have little control over this. If clients change their requirements after a design is finished, that design must be modified to accommodate the new requirements, invalidating quite a good deal of effort if overly large amounts of time have been invested into preparing a comprehensive design. In addition, designers cannot anticipate technical difficulties with their design, and typically these difficulties become clear during development, at which time it is expensive to change design.
Summary of problems:
- Client requirements are never complete at the time of requirement specification. They change, and it is realistic to anticipate that such change would occur
- Each phase needs information from the following phases to be fully complete. For example, requirements phase needs information from design phase as to what is feasible; design phase needs feedback from coding phase as to which design has the best chances of succeeding
- Builds in a waterfall model are typically available much later, but there is a need to have builds much earlier so as to build confidence
- Each phase has people who are specialised for that phase. It is a hard task to get people specialized for each phase, as well as make sure that they are connecting with each other for proper information transfer