You shouldn't use waterfall for anything but the simplest of projects, which effectively excludes about 90% of all software projects. Why? Because software projects are complex on three dimensions: Requirements, Technology and People.
To illustrate, this is a Stacey Graph, developed by Ralph Stacey of the University of Hertfordshire in the 1980s - he studied complexity and human behaviours in organizations and businesses and how to adapt management practices to counteract its effects. I've adapted it based on the graph that Ken Schwaber uses in his Scrum books and classes:
Waterfall projects fit into scenarios that map into the simple zones on the graph where we have almost perfect understanding of our customer's requirements and the technology(ies) we need to use to implement them into a working software solution along with a small team size 1-3. As you might guess, these scenarios are few.
Typical software projects, however, tend to reside in the complex area in the middle of the graph where requirements run along a continuum where they are not entirely understood or agreed upon (because they've yet to be implemented) and the technologies required run along a similar continuum where we're not 100% certain about how they work.
So far, this is the good news. We can deal with "complex" projects. However, what pushes complexity into the zone of anarchy is when we add people and put them into a highly-creative process like a software project where they need to collaborate to deal with the aforemention ambiguities. Waterfall methodologies, which enforce following a rigid plan over responding to change (within and outside the project), exacerbate this tension and contribute to failure.
In these situations (ie. 90%+ of the time) you need to use an iterative/incremental process to contain the complexity and mitigate risk exposure within a defined time box (the iteration or sprint) so that you can continually inspect and adapt the solution according to the realities of requirements + technology + people.