How to avoid "bad" requirements

I frequently hear "X% of software project fail due to bad requirements". The X in that statement has ranged from about 70 to 95. However, I seldom hear how requirements go bad. In fact, the statement itself suggests there were actually requirements.

What makes a "bad" requirement? How can one be avoided?

Solution

For successful requirement elicitation you need to

have your customer on site, discuss the requirements, let him explain them to you
the requirements have to be testable, verifiable. Having a list of them, at the end you should be able to go over the list and directly verify their correct implementation on the end-product.
they should have an appropriate level of detail. There exist different type of requirements (goal-level, domain-level, product-level, design-level). Requirements should be classified appropriately.

Usually the problem lies in a lack of communication and understandability between the customer and the developer. Moreover keep in mind that sometimes even the customer itself doesn't exactly have a good picture of what he wants. Therefore discussion, paper prototypes etc. are really important.

This pic is my favourite :)