As an example, I encountered a requirement recently which included the phrase ‘any printer shall be supported’. After discussions, and any customer that doesn’t engage in discussions is clearly an indication of a very difficult customer!, it became very clear why the requirement had be written in the way – a third party would be supplying the as yet unspecified printer. However, the discussion did enable the requirement wording to became slightly more achievable by rephrasing as ‘a network connected printer supporting postscript’. At least I would have a chance of testing this (and have constrained it to exclude printers with parallel or usb interfaces).

The hardest part of requirements is not the accepting the requirement, it is the validation at the end. How often have you encountered ‘This isn’t what I wanted’. The only way to avoid this is to remain in constant contact with your customer to validate any assumptions throughout the development so that there aren’t any surprises at the end.

You have also touched slightly different subject – hidden assumptions which I consider as the biggest danger for any project. Especially those assumptions on client’s side are risky The real trick is unearth them early!

I’ve found that clients don’t like questions. Even the right ones. They prefer conversations.

Your second situation is really about playing back a solution with a bunch of assumptions you’ve made earlier. Instead of asking questions, let the client play with it. Then the real conversation starts in which you validate and/or refute ALL prior assumptions.

Man, I assumed you’d support IE6! Of course it should render on the IPAD? Yes, why on earth would you not make these pages SEO friendly.

Nothing hurts you more than hidden/unvalidated assumptions.