Managing user expectation

Many years ago my lecturer, Clive Boughton in one of his COMP8100 class would asked us some opinion on our definitions of (software) requirement. I remembered some precise definitions from ISO/IEEE standard and quotes from software engineering books from his pdf file presentation. But I raised my hand and suggest an alternative. Requirement includes user's expectation.

It was difficult at that time for me to explain why. I just knew that some of the projects i was involved with that came to sudden halt from technical point of were not as many as which unable satisfy the client's subjective imprecise and always changing "expectation". Maybe this warrant some more looking by researchers?

Article from 2006 discuss the merit on consciously making mock-ups looks unfinished, which lead me to a relevant article by Joel Spoesky. Making visual mock-up looks ugly idea has even led to a real gold prototyping tool: Balsamiq Mockup.

At the end of the day, I'm still clueless. How do you actually measure user expectation? Is it ethical to bring down their expectation of getting good software, just so at the end we have a lot more lee way and they won't complain much? Does it actually improve requirement gathering process by excluding irrelevant aspects of discussion? Or should we simply shrug off and forget those and focus on delivering the best we could and hope everything would gone well?