Again on detailed requirements

Some time ago I wrote about how detailed written requirements are just, well, detailed written requirements. They don't add value for our customers, at least not direct value, they can just help them to build or enforce their vision about a system. And at a high price.

Clashing with reality, sometimes you just have to produce these huge documents even if you know that no one will ever read them, and you'll sign contracts that say that you'll produce exactly what is "so clearly" written.

Pity that when you actually try to read through these 600 pages and understand what's expected from your team, most of the times you find out that you have to start out again, wasting your time and your customer money; I like very much this example borrowed from Mike Cohn, who refers to the following requirements written in IEEE style:

1. the product shall have a gasoline-powered engine
2. the product shall have four wheels (mmm I see where we're going)
3. the product shall have a rubber tyre mounted to each wheel (yes, yes)
4. the product shall have a steering wheel (definitely! we're on it!)
5. the product shall have a steel body (of course it should)

At this point it should be clear to everybody we're talking about a car. But... would not be easier if we just had the customer at hand in case of need and a simple card with the user story "the customer needs a comfortable product with which it's fast and easy to mow the lawn"? Yes, this customer just wanted a riding lawnmower. What happens if you find it out only AFTER you've built a car? Do you think it is always possibile to attach a rotary blade under a Cadillac?

Get this one. The same holds true for software systems. So you'd better consider it before you embark on the quest.