When it comes to software, nobody knows what they want. Actually that’s not true. Everybody knows what they want; nobody understands what they need. Requirements are all about want vs. need. When you ask your customer for requirements, you are always going to get a list of things that the customer wants. If you are doing consulting work, most of the time you will probably just go ahead and do what the customer wants. After all they are paying you for it.
But a better approach to take is to review what they want and use it to think about what it is they are really telling you. You need to discover what is it they need. So, how do you go about discovering what they need? By asking questions, of course.
Why?
The first question is simple: why? Ask the customer why they want what they’ve just said they want. You’ll be surprised at the result. I once worked on a project where a customer “required” the ability to create management summary reports directly in our application using a rather complicated set of options and criteria. Building such a feature would have been extremely time consuming and I wasn’t really interested in building a reporting solution. There are plenty of other people doing that and they are much better at it than I would be.
Faced with this problem, I went back to the customer and asked, “why do you need this capability built into the application?”
Seems like a simple question, and it is. It’s important to keep your question simple. If you give them too much information, you run the risk of leading the customer or putting them on the defensive.
The customer’s response was “I don’t really need it in the application, I just need to be able to generate summary reports for management on the data I specified.” Well, that was a completely different story! And notice they actually said what they needed, even though they didn’t really know it. In the end, we built a small data mart that was updated periodically. They used Crystal Reports to create the reports against the summarized data. We didn’t have to build and support a reporting tool and they got the reports they wanted.
How?
Now the why question may not always be enough. Sometimes you’ll get an answer that really won’t help pinpoint their needs. So the next question to ask is “how?” As in “how will you use this capability”? Here’s an example conversion:
Customer: I require the ability to create management summary reports in the application.
You: Why do you need this capability in the application?
Customer: Management bugs me all the time about the data we’re processing. It’s a pain to summarize it all by hand.
You: I see. How would you use this capability if it were available?
Customer: I would put together a report based on the data I specified and then print it out to put on Bob’s desk.
You: So it doesn’t really need to be in the app; you just need to be able to do it?
Customer: Yes, that is correct.
You: OK, I think we have some things that could work….
Now none of this is easy, but the benefits make it worthwhile. Once you figure out the need, you will likely end up with a simpler solution. This will cost the customer less money. You might also end up with a great idea for a product, because you have solved a need. Products that meet needs are far more marketable than those that just satisfy someone’s specific wants.
Technorati Tag: softwaredevelopment
February 11th, 2007 at 5:05 pm
Your post highlights an interesting and common human behavior - we tend to debate the solution instead of the problem. It’s our nature I guess - providing solutions to problems. But when you are the person who is responsible for the solution, letting someone else dictate the solution without understand the problem is, at best, suboptimal, and at worst, a disaster.