How To Interview When Gathering Requirements

The importance of understanding why something is a requirement. Unfortunately, we can’t just ask “why why why?!” until we reach the end of the chain. This won’t be any more effective for us now than it was when we were in kindergarden. Eventually, our listeners will get frustrated, or worse, defensive.

Understanding why is still our goal - but we have to be smart about our interviews to get this information. In our previous post, we identify interviewing as a key technique for eliciting requirements. Interviewing is the cornerstone of our elicitation techniques - even if we gather the bulk of our information in group meetings, we have to follow-up, clarify and validate with individuals. There’s truth behind the old saw that nothing good is designed by committee.

Before the interview
Failing to plan is planning to fail. OK, stop groaning, I know it’s a cliche. Regardless, the first thing we do when interviewing is identify who we need to speak to, and what we need to speak about. If we’re going to talk to a sales manager, about our sales-support software, we will likely talk about user adoption, business processes, and the organization of the sales team. If we are talking to a sales person (a representative user), we will talk about how they do their job today, and how it could be different with the new software. In both cases, we plan our conversation before we have it.

During the interview
Amplifying your Effectiveness has an article on how to run interviews when gathering requirements. This is a great article, and one I’ve added to my links at del.icio.us (you should too).

Some key takeaways from their article:

* Use “how” and “what” questions to get to “why” answers - avoiding the knee-jerk defensive reaction.
* Use “tell me more” questions to drill down - “What happens next”, “Can you show me”, etc.
* Use open-ended questions. Yes/no questions are good for validating what you’ve learned already - not for learning new information.
* Don’t bias the results. It’s easy for the interviewer to ask leading questions. We need to realize if there is an implicit premise in the way we ask a question, and if that would bias the results. When we’re first starting out, this meta-perspective is almost impossible, but it becomes second nature over time. If we review our results (recording our questions helps too) after the interview.

Cliche though it may be - a book I’ve read at least a dozen times is How to Win Friends and Influence People by Dale Carnegie.

In that book, he helps us understand that people enjoy talking about what they do. He provides tips and suggestions about how to gain contacts, gather information, maintain relationships, and speak publicly. If you haven’t already read it, it’s in my top two “books that make you better” list. so go read it. One thing that will make you laugh is seeing the dated dollar amounts in many of his anecdotes (the book was written in 1936). My copy was published in 1964, and the pages are starting to get that nice yellowing that comes from great writing.

Carnegie stresses, encourages, and provides techniques for talking to people about what’s important to them, which is directly related to gathering requirements from the beneficiaries of a new system (and the users, who should benefit, but might not if we don’t gather the right requirements).

After the interview
Here’s where many good interviewers drop the ball. This is the time to put a little extra effort in managing our relationships. We should always followup with the interviewee, and let her know “how it went”. We should give her an update on status and let her know which of her great insights is being incorporated into the spec. Anecdotal data is fine, we don’t need to create a laundry list - just an affirmation that her needs are being addressed, and that the time she spent in our interview was valuable. If there’s something that is important to this stakeholder that didn’t make the cut - give her a head’s up.

If we get stuck for a good pretense to having the conversation, we can always use communication of the schedule as an excuse.

These follow-up conversations establish a long term relationship that is good for future releases, helps with change management of rolling out the solution, and establishes or firms up our credibility.

Source: Tyner Blain