STOP the Software Requirement Insanity

Rgalenoct251I 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!


Don’t forget to leave your comments below.

Article source:


Powered by Facebook Comments

  3 comments for “STOP the Software Requirement Insanity

  1. December 6, 2011 at 9:15 am

    Are you overreacting? For the projects you have been involved in, probably not.

    It seems to be very common in this industry to try and fit everything into one neat little box or methodology and for that box to change shape depending on who has just had a big success. Over the last 25 years I have seen how absolutely essential it is to have a strict development plan and follow a waterfall methodology, how development will only work in an agile environment, how essential it is to dictate exactly what a developer dose, how you need to let a developer have their creativity, how a developer should never test, how important it is for a developer to test their own work, how clear “requirements” are essential, how requirements stifle productivity and so on.

    The reality is that the way we develop software needs to fit the individual situations or projects. There are some that have very specific goals and requirements that you need to follow to the letter. There are others that you only have the slightest of ideas on what is needed when you start. And then there are the majority in between.

    Personally I think that we need to look at every organisations and projects needs on a case by case basis and use the best approach for each. Be flexible when deciding on how flexible you need to be.

  2. Janet Borggren
    December 6, 2011 at 6:24 pm

    Depends a lot on the relationship between the customer and the architect. If you gave your problem description to the architect, left for 6 months, then came back to a finished house and a big bill, you might not be so happy.

    Ideally, you go back and forth with the architect reviewing his/her designs and arriving at a solution you agree on. Then you get a cost and time estimate, and the architect creates the detailed blueprint to give the builders.

    Many of our current practices are born out of our need to formalize the design and development process: essentially, the need for a contract. How much detail do I need before I can respond to an RFP? How much design work am I willing to do on speculation (particularly if you haven’t hired me yet and might steel my great ideas)? At what point do I need to commit to a price and end date? If I deliver X, but the client doesn’t like it, will I still get paid? Can I demonstrate that I did what I was asked to do in case you decide to sue me? Can I give my off-shore developers clear directions?


  3. John Ruff
    December 19, 2011 at 3:20 am

    When I managed projects and programs, I had two basic sets of requirements. The first was in customer language and was similar to the first set of requirements you had for your house in Maine. Part of developing these requirements was the task of understanding, observing and even executing the customers day-to-day activity if at all practical. Once those requirements were documented and understood ( usually the QA team started Use-cases from these), a second set of what I called Technical Requirements were developed. Those allowed for understanding of what tables, fields, code, screens, etc had to be changed and in so doing how that related to functions already using that information or impacted by it. It also contributed to a great partner-relationship with the customer.

    It was not always easy and nothing is ever foolproof but it sure made things sucessful for my groups and we all understood how things worked so changes and corrections were done quickly when needed.

Leave a Reply

Your email address will not be published. Required fields are marked *