STOP the Software Requirement Insanity

I attended the Agiles 2011 conference in Buenos Aires, Argentina in early October. Jeff Patton was a keynote speaker at the event. In his keynote, one of the remarkable (at least to me) points that Jeff made was that he really hated the term requirements.

He made the point that in the early parts of his career, he worked for small software companies that really didn’t refer to requirements as requirements. The used customer centric terms that connoted customer needs, business problems, and desired outcomes. There was no “requirements analysis” or “requirement sign-off” per se; there were only customer and business problems to solve.

When he changed jobs and first encountered true waterfall processes and the term requirements, he encountered the fixed, seemingly non-negotiable nature of requirements.

Software Requirements?

So the critical question that Jeff raised is that are software requirements truly REQUIREMENTS? Are they:

• Absolutely required?
• Non-negotiable?
• Blindly followed?
• Simply listed?
• Taken verbatim?
• Targeted as a whole?

In the interactions of the organization asking for them and in the minds of the teams tasked with implementing them.

In Jeff’s view and my own, they are. Organizations get wrapped around the “requirement axle” in demanding “a list” that they blindly follow to completion. Oh sure, requirements are discussed, clarified, negotiated, decomposed, written, and dissected. But they are, by and large, followed!

But what’s missing?

I think the key point is that demanding anything specifically limits our solutions, our creativity, our ability to innovate, and our thinking. Let me try to make this point with an example.

I love Maine. It’s one of my favorite states and since I moved from Connecticut to North Carolina many years ago, I don’t visit it often enough.  One of the wonderful aspects of Maine is the cabins and cottages along its many lakes. Let’s pretend I have a little piece of property in Maine and I want to build a year-round cottage on the lake. I want to give my architect some directions towards designing my cottage, so here goes…I can say that my requirements are:

• A 3 bedroom, 2 bath cottage
• Somewhere around 1900 to 2200 sq. ft.
• I want it to be a log cabin
• Timber frame construction
• The family room should look out over the lake
• I want a sun room, encased in glass
• The master bath needs to include a whirlpool and sauna
• Granite, state of the art appliances, and Italian tile need to be in the kitchen
• Wrap-around porch – 10’ for a porch swing
• 2 car garage, etc.

You get the idea, it’s a list of “requirements”, and I’m “the customer”. So, what will I get in my house design? I strongly suspect exactly what I asked for. Not bad, but what if I was mistaken? Nor am I an expert in house design—so what if I asked for the wrong things?

Perhaps something else…

Now let me try another approach. I want to simply describe the business situation, but not necessarily require anything. I’m not sure this will be the best example, but I hope you get the idea…So instead I describe for my architect some of my preferences, or things that I really enjoy. For example:

• My wife and I are gourmet cooks and we’d really like a kitchen that would support the both of us cooking. It needs to be modern, with high-end appliances, but reflect the simple nature of a Maine kitchen.
• We also entertain quite a lot, so we need space to support that. Most of the entertainment starts with dinner, again our cooking thing. And we’d like the ability to entertain inside & outside as the seasons and weather permit.
• I personally love the water. I love seeing it in the morning when I get up and looking out over it at night with the moon reflecting off of it. Can we position the house to maximize the exposure to the water?
• There’s just the two of us. Our children and friends visit infrequently, perhaps 4-5 times a year. So, we need some space for visitors…but, but not too much. Oh, and I’m a consultant, so I need a private office.
• I plan on purchasing a boat, somewhere in the 22-27 ft. range, within the next 2-3 years. I’d love a place to store it in winter and something dock it on in the summer.
• Oh and I hate, absolutely hate, doing yard work. Yet, I love a well groomed property and garden. It just needs to be ultra-easy to maintain.

I’d like to call this last list something other than requirements. I consider it insights, design goals, customer usage intentions, etc; almost anything other than requirements.  What does this re-frame do?

My hope is that it communicates my home goals while leaving the flexibility for my architect to do their job. Then I hope it fosters review and communication while we refine the plans.  Ultimately, I want my architect to “delight me” by interpreting my goals, collaborating with me, and leveraging their creativity to create something “just right”.

Wrapping Up

So enough of my ramblings… Do you feel the term requirement has become too restrictive? Or are Jeff and I simply overreacting? Please weigh-in with your comments. And please share your experiences, thoughts and ideas for how we might frame requirements to drive more innovation & creativity, team-based engagement, and simpler overall solutions.

It’s not required that you weigh-in, but it’s very, very welcome!

Bob.

Don’t forget to leave your comments below.