Andriy Solovey gives 6 reasons why software requirements are elusive. A very interesting post which poses the challenges involved in identifying the requirements. The subjectivity, personal bias and preferences and continuous changes make it difficult to really complete the task.
I also feel that an inherent problem is that we start with the requirements and software instead of problems and solution. We need to look at using software for building solutions, which essentially means that we start looking at problems. Most of the times the customers bypass this step, for various reasons cited by Andriy. I believe the problems are directly tied to the ROI and value that the software will provide. More often than not the requirements end up being created to justify the use of software. Instead, the requirements should be a natural derivation from the problems identified.
Also, most of the times the customer and the software development team are on either sides of the table. They should not be. They should be together in this, providing insight and building software. The collaboration fails when the requirements are ignored or tweaked to fit the project management techniques.
I feel the irony in giving too much importance to software itself instead of the problem at hand. Which ends up ignoring a lot of things not inherent to the software domain, like processes and people. To be able to build a successful solution, software has to be treated as a part of the whole solution. The requirements have to represent the real world problem first and then translated into specifications.