by Derek Lindsey,
Principal Software Engineer

I have a four year-old who is heavily into the “Why?” stage right now. He asks, “Why?” about everything. Several years ago when my daughter was that age, she had a neighborhood friend who was the queen of, “Why?” One time I decided to play along to see how many times she would ask why before she gave up. I don’t remember the original topic, but it had something to do with our deck. After a few iterations of her asking why and me trying to explain, I had reached the molecular level of describing deck stain. (She outlasted me, by the way.)

Karl Wiegers wrote an excellent book called Software Requirements. In chapter 7, he discusses requirements elicitation. He calls it “the most difficult, most critical, most error prone and most communication-intensive aspect of software development.”

Often times, preliminary discussion of requirements will result in the customer telling you what he thinks he wants rather than what he really needs. Rather than ask the question, “What do you want?” we should really be asking “What do you need to do?” Wants are usually expressed as design details (i.e. “I want the button to be green if the state is active”) whereas needs are the real requirements (i.e. “I need a way of letting the user know when the state changes.”)

To really get to the heart of what the customer needs, we can all learn from my 4 year-old neighbor and ask “why” several times to get to the molecular level of the problem that needs to be solved. Just taking the customer comment that the button needs to be green at face value is easy to implement, but doesn’t really meet the need of the customer. Asking why the button needs to be green and a few follow on questions easily uncovers the real need.