How do you know what your client actually wants?

I'm sure this topic has been debated time and time again but I've been thinking about it a lot lately and hey, this is my blog anyway. How do you build a requirements document? And how do you know when it is right? And my thoughts at the moment, Who do you get to gather them?

I believe that requirements gathering is really a very specialized skill and that a software development company needs to find a better than average developer to perform this task.

The kinds of skills required are less in tune with software development and more along the lines of investigative journalism. That sounds a little strange so let me explain.

In Software Development you take a collection of requirements and deliver a software solution to a business problem. In Investigative Journalism you run around collecting facts and opinions, interviewing involved parties to tell a compelling and factually accurate story.

Now which of the above activities actually sounds like the requirements analysis phase of software engineering? It isn't really about for-loops or curly braces. Isn't it really about talking to people to find out what their needs are?

I work in a communications business and so I get access to Communications Consultants. If you have a Communications department you should really try and make friends with them because you can learn a lot.

Two of the best tricks I have learned about requirements analysis that have come from being in contact with journalists and communications experts include:

  1. Ask the same question several different ways, don't concentrate to the answers provided, instead learn to figure out what is being said by examining the differences in response.
  2. Don't stop because you understand what is going on. If you can't take your specification to someone who wasn't at your meetings and have them fully understand what is going on, your spec isn't detailed enough. Communications Consultants know this. They don't tell a story for themselves to understand the message, they've got to convince other people.

I mentioned in the opening paragraph the question of how you know when it is right. The trick is to find someone else who was aware of the business need from the beginning but has been isolated from the requirements gathering process. If you can show her the requirements document and she truly cannot think of anything you have missed, you've done it right.

Of course, if she finds anything, she is now useless to the process. You really need someone who hasn't been involved at the end.

In closing, it is my belief that requirements analysis is best left to a non-developer. A developer will spend much of his time thinking about how the software will work inside, whereas a client really doesn't care. They just want it to solve their business problem.

If you have an opinion on requirements analysis, feel free to drop a comment.

Posted by: Mike Minutillo
Last revised: 27 May, 2011 02:42 PM History

Comments

No comments yet. Be the first!

No new comments are allowed on this post.