In the world of product development and software development, customers often come to you with a request for specific things. "It should be green with four wheels." or "Build me a web site to sell my origami." or "It should work just like Google." The thing is, these are specifications or requirements. They could describe just about anything, and often the result doesn't quite do what the customer was thinking of. Why is that?
Partially, this is due to the very familiar problem that people don't know what they want until they have it. One of the reasons that Agile development methodologies have taken hold is to try to solve some of this. Work with the customer directly, create prototypes and iterate, iterate, iterate.
Another direction, inspired for me by Theory of Constraints, is to develop an understanding of why they want these features. Rather than describe the solution - a description that is always going to be lacking - understand what problem they are trying to solve. What limitation or barrier do they need to overcome? And why do they want to do that? Knowing this, it is much easier for everyone in the process to understand what features / capabilities are truly needed to solve the problem and which might be nice-to-have. This doesn't eliminate the need for iteration - it helps people focus on the customer's needs.
[Photo: "scope" by ben dalton]