I've been on projects where we did detailed interviews and created massive, well-organized and detailed requirements. In most cases when we delivered the software we got a collective: "Huh? This is not what we asked for."
So then we tried the UI sample screens approach where we worked with them to identify what all of the user interface screens would look like, and collected the requirements through interaction with the clients. But then when we delivered the actual software, again we got the "Huh? This isn't what we wanted."
Until the users could actually interact with the application they really didn't grasp what they wanted it to do or how they wanted it to work. I really think it comes down to the fact that very few people are capable of thinking abstractly.
You almost have to build the application from scratch with continuous input from the user community to avoid rework. But of course the user community is already overworked and doesn't have time to spend helping you create the application that may eliminate their jobs.
So you gather enough requirements to get started knowing that whatever you build the first time will look nothing like the final version and you pray that the users will give your application enough time to identify all the missing requirements.
That’s where Agile Projects come into play.
Build your package incrementally. Management loathes rewriting existing functionality but it needs to be done. After several iterations you’ll get it right.
Real programmers are not Fungable...Lesson 1.
Most of the time, I find it is because the users are thinking in terms of design, and not in terms of function. They concentrate on what the program will look like, and not what it will produce to make their lives better.
I am on a personal mission to "fix" the requirements in the aerospace software industry, one classroom of practitioners at a time...