Why Requirements Are Hard

It should be so simple shouldn’t it? Ask a customer what they want and then design and build some software that does it. Easy.

In his post Limitations of “The system shall…” Roger L. Cauvin quotes a great example by Mike Cohn of how easy it is to misinterpret what a user needs. First the requirements are listed like this:

  • The product shall have a gasoline-powered engine.
  • The product shall have four wheels.
  • The product shall have a rubber tire mounted to each wheel.
  • The product shall have a steering wheel.
  • The product shall have a steel body.

Then they are re-stated as follows:

  • The product makes it easy and fast for me to mow my lawn.
  • I am comfortable while using the product.

Unless you are very different to me you would interpret the first set as describing some kind of car whilst the second (much simpler) set clearly describes a sit-on lawn mower.

This may seem like a trite and unrealistic example but I don’t think it is all that far fetched. This type of situation frequently arises in software development and has two principle causes:

  1. The customer or user assumes that you know more about their business/work than you actually do
  2. You take the incomplete picture presented by your customer or user and complete it based on your previous experience

This isn’t surprising. The human brain is brilliant at filling in gaps. What’s more it does it so well that often you don’t even realise that there were gaps that needed filling in the first place! This is why how you perceive something is totally dependent on your prior experience.

One fascinating experiment that shows this to be true is described by Matt Davis in An Introduction to Sine-Wave Speech. An article titled “Mind tricks: Six ways to explore your brain” published by the NewScientist on 19th September 2007 described it as follows:

Another demonstration of the brain’s ability to extract meaning from distorted signals is a form of synthesised speech called sine-wave speech. When you first hear a sentence in sine-wave speech it sounds alien and unintelligible, somewhat reminiscent of whistling or birdsong. But if you listen to the same sentence in normal speech and then return to the sine-wave version, it suddenly snaps into auditory focus. Try as you might, you cannot “unhear” the words that you didn’t even realise were words the first time you heard them.

I really recommend you try this for yourself. It is amazing how, once you have been primed to hear something, unintelligible noise becomes permanently understandable.

So how do you switch off your brain’s inbuilt mechanism to fill in the gaps and ensure that you get an accurate picture of what your software should do? The answer to this question could probably fill several hundred more blog posts but the three key technique I find useful are:

Be stupid

All too often people try to impress their clients by showing how much domain experience and knowledge they have. You might know lots about your customer’s business but to gather good requirements you’d better forget it. Don’t be afraid of showing ignorance by asking questions. Requirements gathering is the best time to ask them!

Step back a level

Often customers present their requirements to you with phrases like “I need a button on the bottom left of the screen that brings up the contact details”. Always take a step back and discover what the purpose of the button really is. You may uncover a deeper need that can be fulfilled in a better way.

Ask why

You need to keep asking why a customer has a particular requirement. My advice is to keep asking why until you think you fully understand the reasons for a particular requirement. And then ask one more time.

Using these techniques allows you to dig deeper and understand what is behind a user’s perceived requirements. In turn this enables you to deliver a solution that best meets their needs (and may be quite different from what they thought they wanted). To come back to Mike Cohn’s example: last year I had a similar need for a comfortable and time efficient way to get my grass cut. In the end I opted for a solution that in no way conforms to the first requirements list: a gardener!

If you liked this you might also like some of my other posts about software design and requirements:


No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: