excellent entry in a blog about "reqirements in software"

How many times have you heard the old adage, “The customer is always right”? If you’re like me you just took it as an altruism, something that was beyond questioning. I think it’s time for software developers and project managers to start questioning it.
I’m talking about that stage in software development where you’re trying to determine what you’re supposed to be writing and what it needs to do. How many users should it support? How much data should it handle? Little things like that.
The most natural approach would be to ask the customer. They should know what they want, right? And wouldn’t it be nice if you had some nice neat directions written down in a “requirements document”. This will help you all “manage expectations” later, so you can point out to the customer what it is they should be happy with. Oh, think of all the meetings you can have, working out the details of these requirements. Think of how good everyone can feel about it when it’s done, how the project leaders can pat themselves on the back for hammering out all the issues. Sadly, there’s one little problem with the results you get…
It’s fiction.
For the most part, the “requirements” will be made up. As in pulled out of the air. Bearing almost no relationship to reality, created from whole cloth. As with any rule there are exceptions, but speaking for myself, I’ve generally found this to be true. Not only can it be useless to you, it can be harmful, causing you to expend resources doing things you didn’t have to do, and skipping things that were really important. It can also be harmful to the user. Even if you give them everything on the list, they may still be unhappy, because satisfying a list isn’t what they wanted. It’s not their end goal for using your product.
Luckily there’s a better way: Watch them and feel their pain. Listen; not so much to the details of what they say they want, but to the underlying causes. What are they trying to achieve, and how is your software helping and hindering them to achieve that?
Challenge all your assumptions, and question all your feedback. A powerful tool you can use to do this is iterative development, deployment, and measurement.
As my favorite TV doctor likes to say, “Everybody lies.” He doesn’t even talk to his patients if he can help it. While I wouldn’t go that far, the symptoms your customer is trying to alleviate by coming to you, the data volumes they are dealing with now, the number of users they have, the deadlines they have, and how the product is performing right now in the field, all these are more telling than anything you’ll find in a “requirements document”.
Don’t “manage expectations” — deliver results.