How to Use Interviews to Gather Requirements

Interviews are one of the easiest yet most powerful techniques available for gathering requirements. Anyone can learn to conduct interviews, as after all, an interview can be seen as a slightly more structured dialogue between two persons.

The hardest part is often to come up with bright questions to ask. Take it easy, read on and you will get suggestions for interview questions that will help you get the most out of your next requirements gathering interview.

To be successful in requirements management, you will obviously need to understand your stakeholders’ needs. Stakeholders may be clients, users, decision makers and anyone else who somehow influences the future system you’re building. As a requirements analyst, you should use interviews to give you a deeper insight into stakeholders’ concerns and using these insights will help you design a system that is well-suited to stakeholder needs.

In the end, you’ll have a better quality product and more satisfied users.

In preparing for an interview, you should keep the points below in mind –

First aim to get the basic facts about the stakeholder and his or her organization (whether that’s just one department or the entire company).
Ask one or two colleagues to review the interview questions you’re planning to ask.
By all means use this article as a starting point for developing a customized script to use during the interview, but remember that it’s not important to slavishly follow that script.
To keep your interview script from becoming a hindrance rather than a help, remember that the goal is to get thorough and consistent input for the design of the system.
Plan for follow-up questions and don’t be afraid to ask them if they occur to you during the interview.
Design the interview form in a way that makes it easy for you to write down the answers or enter them into a computer, or use recording equipment.
Remember that these techniques help you focus on the content of the discussion and not the act of documenting it.

Good luck with your interviews!

Template

Facts about Stakeholder

Name:
Company / Department:
Title / Role:
Primary responsibility:
What tasks are you responsible for completing?
To whom are you responsible for performing these tasks?
What problems prevent you from performing your duties?

Identify problems

What problems do you run into in your day-to-day work? Is there a standard way of solving it, or do you have a workaround?
- Why is this a problem?
- How do you solve the problem today?
- How would you ideally like to solve the problem?
Keep asking follow-up questions (“What else is a problem for you?”, “Are there other things that give you trouble?”) for as long as the interviewee has more problems to describe.

Tip: This is a very efficient technique to dig deeper and find out the root cause.

The user environment

Who will be the users of the system?
What level of education or training do the users have?
What computer skills do the users have?
Are users familiar with this type of IT system?
What technical platforms do they use today?
Do you know of any plans for future systems or platforms?
What other IT systems does the organization use today that the new system will need to link to?
What are your expectations regarding system usability?
What training needs do you expect for the future system?
What kind of documentation do you expect?

Tip: These kinds of questions are not always needed. If you build systems for internal use in your company and you have a short timespan from requirements to deployment the questions above might be unnecessary. If, however, you work as a consultant and the project might take a long time to deliver, this information can come in handy.

Summary of problem

Throughout the interview, summarize what you’ve captured from the interviewee to make sure you’ve understood correctly and captured everything relevant. You can say, for example:

So, as I understand it, you are experiencing the following problems/needs (describe the interviewee’s problems and needs in your own words – often you will discover that you do not share the same image. It is very very common to not understand each other even if at first you think you do).
Just to confirm, have I correctly understood the problems you have with the current solution?
Are there any other problems you’re experiencing? If so, what are they?

Make sure your understanding of the stakeholder’s problem is complete

If you identified areas in your preparation work that you think may be a problem for the stakeholder, but he/she still has not brought up any of them, you can ask about it directly: “Do you feel that X is a problem for you today?”

To get more detail about each problem, pose the following questions:

Why is it a problem?
How do you solve the problem today?
How would you ideally like to solve the problem?
How big is this problem compared to the problems you have mentioned earlier?

Using the interview to identify potential solutions

If time allows, you can propose solutions to the problems during the interview.

What would you think of a solution like X, Y, or Z?
How would you prioritize these proposed solutions?

Identify non-functional requirements:

What are your expectations for system availability?
What are your expectations for system performance?
Who will manage system support and maintenance?
What are the organization’s support requirements?
What are the organization’s system maintenance requirements?
What are the organization’s security requirements?
What are the organization’s requirements for installation and configuration?
How will the system be distributed?
Are there any legal requirements or other regulatory requirements that need to be met?
Can you think of any additional requirements that we should know about?

Conclusion

Are there any other questions you think I should be asking, or anything else you want to tell me?
Can I contact you again if I need to ask some follow-up questions?
Would you want to participate in a review of the requirements later on?

Conclude by summarizing three or four top priority issues for this stakeholder, and thank them for their time and input.