I found in my library the "Mastering the Requirements Process" book , that some might know as the " Volere " book. After many years I still find it very useful. I don't think the good Robertsons invented anything really new, but I do believe that this book covers 90% of the "how to" solve requirements problems in software development. And 90% is a lot ! The parts I appreciated more, this last time are: Chapter 12. Prototyping the Requirements Working together to the prototype, can really take out the users' implicit knowledge, correct lapses and help in many other ways. Chapter 11. The Quality Gateway You could try put an analyst that doesn't work on the same project, to read the project's requirements and have him refuse: all incomplete or inconsistent entries, frills, etc. I think it can be a very powerful practice.
Ever worked a lot and ended up realizing that the customer wants it another way?