The problem with the waterfall method is that those using it do not follow it. Well after requirements and design are done, new requirements are injected during the development phase. If a business is truly following waterfall, they would not allow any new requirements to be injected at that point. By definition, they are no longer using waterfall.
I have a cousin who is a developer; he says that project managers never get all the requirements down. The blame cannot be placed squarely on their shoulders, however it is their fault when they insist on waterfall and insist on giving the developers new requirements in the middle of development or testing.
We use Scrum at my current employer, with 2 week "sprints". Each sprint begins when project managers present the new requirements and the priorities of those requirements. For the next two weeks, the developers work on a set of the highest priority requirements that they think could be accomplished during that sprint. No additions to the requirements are allowed after a sprint has started. This allows the development staff to be flexible to new requirements. New requirements can be added every two weeks. It also allows developers to concentrate on items that are given to them, knowing the rug will not be pulled out from under them. And it places long-term development planning, goals, vision, etc, where they should be, with the project management.
In saying all of that, I believe that there is still a place for the waterfall methodology, but only when followed as intended.