The first rule of requirements is to ask your customer 'why?'. If they can't explain simply why the requirement is needed then it isn't essential and it should be discounted. If the response is acceptable, the next question is 'How am I going to validate that I have satisfied the requirement'? If you can't agree on how the requirement is to validated, then the requirement clearly needs clarifying, maybe with some constraints explicitly included in the requirement wording. The language of requirements is very important and the differences between shall, should, will, may are VERY important. Any requirement with phrases such as 'such as', 'for example' should always be rejected as they are open-ended and can never be fully satisfied.
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.
Other than experience, I have yet to find a reliable and objective way of assessing the 'goodness' of a requirement set. It would clearly be possible to perform some analysis of the language used, looking for ambiguous phrases for example, but would this be a sufficient measure?