By definition, that nagging thing called Reality means that you'll never be able to get all the right requirements defined in a time-frame that is useful to implement the software the business really needs.

What Andrew is missing here, is that the idea of creating the perfect requirements document is THE cause why IT projects have failed since the dawn of days. That's why the Waterfall approach is dying... and why so many companies are turning to Agile methods.

It takes 6 months to write that perfect requirements document, where the business puts in every single feature they think they'll need, just to make sure the project team will not get back to them later saying "sorry, you didn't ask for that, it's out of scope, we're not implementing it".

When the doc is ready, months have gone by, the business/market/needs have changed, the and the requirements are now obsolete. And, oh joy, the project team start implementing those old requirements, and after several months show what they did to the business... who looks at the solution in disbelief! So the project goes on pause, so the business can revise the requirements (some more months worth of word processing work), and the cycle starts again.
The main reason for this approach is that, historically, the cost of making changes to software grows exponentially as the projects evolves. So, if you try to minimize change, you'll be able to keep the project cost under control. Unfortunately that's not the way the world works!

It has been said over and over in this chain of comments: change is the only constant.

The only way you can ensure the success of your project is to make sure you have the processes and tools in place to be able to quickly react to those changes, while keeping the cost of change low.

As Tony said, stop pretending that gathering requirements will solve project failure. Wake up to the new way of delivering software. Get the right tools to keep cost of change low. Only then you'll be successful and realize that the issues mentioned here are not really the causes for project failure.