The waterfall methodology fails for many reasons. The waterfall methodology requires the analysis team to be nearly clairvoyant. They must define ALL details up front. There is no room for mistakes and no process for error correction after the final requirements are released. There is no feedback about the complexity of delivering each one of the requirements. An easily stated requirement may significantly increase the complexity of the implementation, and may not even be possible with today's technology. Had the requirement team known this fact, they could have substituted a slightly different requirement that met most of their needs and could have been easier to achieve.
The four teams may be different and may not talk to each other. The requirement team is long gone when the implementation team takes over. The requirement documents can only capture a small fraction of the knowledge and typically do not capture any information dealing with quality or performance.
In a fast moving technology, the waterfall methodology builds products that, by the time they are delivered, are obsolete. There is no early feedback from the customer.
Many times, once the customers see what they could get, the customers want something entirely different then what they said they wanted in the first place.
The waterfall methodology puts so much emphasis on planning that in a fast moving target arena it can not respond fast enough to change.