Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Why do requirements interviews never pan out as they are planned - and how do I prepare for that? I'm looking for the following kind of help regarding how to prepare for these interviews and what I can pay attention to in order to make the most of them.

My information project, centered around management reporting within a firm, is currently in it's definition stage. All my stakeholders are managers of greater or lesser scope.

I had my previous two interviews planned out quite extensively, but on both occasions my interviewees both went off in completely different tangents, delivering quite interesting results. I completely ignored the question flow I had prepared, and tried to go along with the interviewees. But instead of going towards a common concept that can be developed on, I feel that I get in-depth pictures of each individual's local information requirements.

How can I conduct an interview that helps me get the participants on board and thinking towards a common solution, but doesn't inhibit their own thoughts which deliver me interesting material on data sources, formatting and communication paths?

share|improve this question
This question seems a bit open ended, perhaps you could try detailing a specific problem and asking how to avoid it, otherwise it's likely to be closed as a poor fit for the Q&A format of this site. –  Jimmy Hoffa Mar 13 '13 at 14:32
I removed a bullet point about pointers to resources - Stack Exchange is not a good format for people to simply provide resources, but their experiences and knowledge in combination with any resources that may be able to help you solve your particular problem. –  Thomas Owens Mar 13 '13 at 15:06
I can agree that the question is about an expansive topic, but that's precisely the point. Requirements analysis is a key part of information-systems development, that is riddled with pot holes. I'm looking for help in articulating a question flow for an interview, that can help me direct the stakeholder I am interviewing towards a common solution, but also allows them to express individual thoughts and really dig into their personal requiremens. –  Rafael Cichocki Mar 13 '13 at 15:22
@RafaelCichocki the edit you added is requesting a list of Questions which is a poll, polls don't have a single correct answer and are not in scope for any stackexchange site. –  Jimmy Hoffa Mar 13 '13 at 15:28
@JimmyHoffa reverted to previous formulation. No more request for poll. –  Rafael Cichocki Mar 13 '13 at 15:51
add comment

1 Answer

up vote 3 down vote accepted

I've found requirements gathering to go most smoothly when done in three stages:

  1. Get together to let the stakeholders talk only about the problem. You want to gather as much information as possible about what the problem is with the current way they are doing things, only talking about potential solutions if it helps frame the problem better. They need to get it off their chest anyway, and attempting to keep stakeholders from talking about the problem is usually futile, so you may as well plan for it. Also, non-programmers find it easier to talk in these terms, so you get a better idea of the requirements if you welcome this part of the discussion.
  2. Either yourself or in a smaller, more technical group, you translate the problem statement into some rough drafts of possible solutions, creating more than one option if necessary.
  3. Get back together with the stakeholders to let them poke holes in the proposed solutions. Make it clear how you've taken their problem description into account. Refine the requirements together until everyone is happy, which might take more than one meeting. Again, non-programmers find it easier to discuss a concrete proposal than to imagine potential abstract solutions.

Usually when people have problems, it's because they're trying to skip step 1 and cram steps 2 and 3 into the same meeting.

share|improve this answer
Thanks, perhaps a good point in separating problem identification and solution from the stakeholder point of view. I'll have to think about it. –  Rafael Cichocki Mar 13 '13 at 17:53
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.