Interviews for eliciting requirements – what is different?

During my career (if you can call it a career – maybe I should say “during my working life”) I’ve conducted many an interview. The purpose of some of those interviews was to elicit (collect) requirements. I didn’t think there was much of a difference, until I started teaching other people to hold interviews for requirements elicitation. That there really is a difference became even more noticeable when I got someone to do two different kinds of interviews in a row.

To find out for yourself, try out the following:
Get someone to interview you for 10 minutes with the aim of being able to draw a floor plan of your house (just 1 floor is more than enough in most cases). Observe what happens. Then ask that same person to interview you for 10 minutes with the aim of collecting requirements for your next house. Again, observe.

What differences might you see?
With a moderately skilled interviewer, I’d expect so see a few noticeable differences such as:

  • More detailed questions for the floor plan than for the requirements.
  • For the floor plan the interviewer is more likely to draw a picture during the interview, and use his or her analysis of the evolving picture to guide the interview.
  • More frequent checks to verify understanding for the floor plan, due to the specific and tangible nature of the subject.
  • For the floor plan the interview will be less fluent, as the interviewer regularly takes time to analyse his/her notes.

Are these differences necessary?

I think not. I would hope that in a good requirements interview the interviewer also uses pictures and simple models for analysis and verification, etc. In other words, the interviewer doing the floor plan interview exhibits desired techniques which would be equally usefull for requirements elicitation and analysis. I guess these differences could be due to the more tangible, specific nature of an existing, well known house versus vague ideas of a possible future house.

There are some other differences as well, which I think are necessary:

  • When eliciting requirements, you would be interviewing a stakeholder representing a stakeholder group. It is important that the stakeholder provides answers which reflect the consensus of the group he or she represents; these may sometimes be different to their personal preference.
  • The answers of the stakeholder should be in line with the mandate of the stakeholder group. While it may be interesting to know what the representative of the marketing department has to say on the subject of compliance, for example, but if this subject is the responsibility of the risk & compliance department you should not rely on the answers from the marketing rep.

What are your experiences with interviews – in particular interviews to elicit and analyze requirements?


Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: