Whose Fault Are Poor Requirements?

Randolpho St. John — Tue, 29 Jul 2008 03:33:04 GMT

I had thought I would do my first Lesson Learned about my control for the upcoming Silverlight Contest, but recent events changed my mind.

A phrase has been bandied about alot at work lately, a phrase we've all heard and uttered in one form or another at least once in our software careers. It exists in numerous variations, but essentially boils down to this:

"The software is bad because the requirements were bad."

I've seen it happen far too often: somebody complains that "<x> is broken" and the original developer goes on the defensive, blaming the customer for handing him faulty requirements. "It's not my fault! The customer asked for a button that rebooted the server! All I did was give them exactly what they wanted!"

I wholeheartedly disagree with this line of thinking. Claiming bad requirements is a copout.

We as developers have a responsibiltiy to find out why every feature is requested. We must get beyond that "I press a button and it does exactly what I'm thinking" requirement to the heart of the request. If you are handed a requirements document that doesn't make sense push back. Seek clarification. Learn more about the problem domain. Call the architect and tell him he's crazy, that it'll never work. And when you finally understand what the real requirement is, write it down. Save it for posterity. Communicate it with all parties. Find common ground. It can be done.

"But my boss told me to do it that way or I'd be fired!" you might say. Very true, but that's bad management, not bad requirements. That's a different copout.

Design & Architecture

Whose Fault Are Poor Requirements?