Rodica pointed me at this article on why requirements stink on ice from the Forrester blog, which asks the question, why aren’t we using social media in helping to sort out what customers want, instead of relying solely on customer interviews and other old school approaches.

My answer? This is the wrong question. Data collection is not the big problem. Sure, forums and blogs can be handy, but rarely is finding better data the big challenge.

Requirements suck for two major reasons.

1. Requirements is not Design.

Here’s a requirements list: Make a $5 car that goes 500 miles per hour, weighs 10 lbs, and is invisible. Those are very clear requirements. They’re also impossible. No matter how well defined these requirements are, or how happy the customer and the VP is with them, the project is set up to fail.

How can you know if your requirements are BS? You probably can’t. Requirements are not a product. The product is the product. A requirement is best seen as a way to help the design/engineering team succeed in making the product. End of story. The design/engineering team is the true customer of a requirements document. They know first hand all the stupid things requirements often include since they’ve been forced to experience them before. Want to avoid these stupid mistakes? Get their input early.

The easy test for how much a requirements document sucks or rocks is what the people who have to use it to do their own work think of it. If they think it sucks, they’re right.Â This means anyone charged with requirements should, from day one, be collaborating with the designers and engineers in defining the requirements. Incorporating their ideas, their feedback, and convincing them of new perspectives they need to understand. If they think requirement #21 is stupid, and they are wrong, at a minimum, it’s Mr. Requirement’s job to invest the time to convince them otherwise. I don’t want an engineer working on something s/he thinks is stupid. How I can expect them to do good work on something they find stupid? I couldn’t do good work that way.Â So I can’t expect them to either.

However, if you throw a requirement over the wall, which is what most requirements document authors pridefully do, it’s about as likely to succeed as throwing a hand grenade – people will scream and run.Â But if instead the requirements document is something they feel they contributed do, that it’s in part their document, they’ll run towards it, love it, and work hard to make it real. Bingo.

2. Too many cooks.

Requirements processes are long and stupid only because authority is spread out too thin across the organization. Talk to any person that is self employed, like your plumber, your gardener, or even your hair stylist. They do requirements gathering with their customers all the time, for important and expensive things, without 20 page documents, committee meetings or therapy bills. How is this possible!? What magic do they know that has yet to hit the business world? It’s simple. They have requirements authority. They have the power to make decisions.

Your requirements process sucks not because you don’t have the right forms, or because you’re not following the right process, it’s because you have too many people involved, all pretending to be effective with a tiny, minuscule piece of the requirements pie.

Pick one person per major area, a person who gets that requirements are part of design and not the other way around, a person who sees the value of collaboration and input, but is confident enough to make unpopular decisions when they are in the best interest, and give them the authority to drive requirements. I guarantee quality will rise sharply by picking the right person and giving them more authority.

Fewer cooks. It’s a simple way to solve many problems, but oh so rare to see.

The one book anyone working on requirements needs to read is Exploring Requirements by Gerald Weinberg. It points out most of the stupidity that goes on, explains avoidance tactics, and clearly expresses how requirements are part of the design process – that good problem solving techniques can quickly make your requirements documents better than ever.

Weigers Software Requirements has an excellent reputation, but I’m not as familiar with it as Weinberg’s book.

And Chapters 3 thru 7 of my book Making things happen offers one way to get from ideas all the way to specs. There are tons of other ways of course, but if you want my general take on this for large teams, it’s in there.

And Getting Real, by the folks at 37 signals, is a book that puts simplicity first, advocating almost no formal documents, requirements lists or specs at all.