Sometimes the easiest way to learn about stakeholders’ business goals is to ask. When we interview stakeholders we ask about their plans for the software, uncover the problem context, get a feeling for looming risks, and dig for details about quality attributes and other requirements.

Interviews may be either structured and follow a set script or unstructured. Unstructured interviews are more conversational and often easier for the subject, but you should still go into the interview with a planned set of topics. Interviews can also be either face-to-face or conducted offline via questionnaires or surveys.

There are many stakeholder interview resources with checklists and question templates. I recommend Designing for the Digital Age: How to Create Human-Centered Products and Services [Goo09] by Kim Goodwin if you are looking for further depth regarding this technique. An extensive excerpt from the chapter on stakeholder interviews is freely available on the web.^[29]

Benefits

• Focus on general information gathering

• Format allows for open back-and-forth discussion

• Provides background information that can be used to prepare for other workshops or activities

• Quickly validate quality attribute scenarios and other ASRs

• Creates a direct connection between stakeholders and architects

Activity Timing

A single interview should last no more than 30--60 minutes.

Participants

This activity can be done one-on-one or in small stakeholder groups. The architect leads the interview. Stakeholders are the interview subjects.

Additional team members may observe an interview, but the interview group should be small—no more than one or two active interviewers—to avoid overwhelming the subject.

Preparation and Materials

• Interview goals and questions
• Pen and paper or laptop for taking minor notes during the interview
• Voice recorder to record the session so you can focus on the conversation. Write detailed notes after the interview. Most teleconference software has options for recording.

Steps

1. Explain the goals of the interview and how the results of the interview will be used. We’re going to validate some requirements we’ve gathered so far to make sure we capture your real needs.

2. Ask the subject questions from your planned interview checklist.

3. Follow up with clarifying questions as needed to be sure you get the information you need.

4. Conclude the interview by thanking the subject for taking time to meet with you.

5. Directly after the meeting, jot down your general impressions of the interview, including any themes, technical asides, and design thoughts. If others observed the interview, collect their notes and general impressions.

6. Once all interviews have been completed, analyze the data collected. Update or create architecturally significant requirements as appropriate. Summarize any new risks or concerns that may require further action.

7. Once all interviews have been completed, hold a debrief meeting with the team and stakeholders to share insights.

Guidelines and Hints

• Avoid interviewing stakeholders about architectural concerns too early. There is often a significant amount of general design work that must happen before diving into architectural concerns.

• Phrase questions so the subject can share their true thoughts. Avoid leading the subject.

• When possible, use the subject’s words when summarizing ideas.

• Talk to real users and primary stakeholders of the system being designed. For example, it’s better to interview Eunice, who trains the hamsters herself, than Beatrice, who only oversees hamster trainers but doesn’t train the little critters.

• Use data to help jump start conversations. See Activity 9, ​Response Measure Straw Man​ for a method that can gently encourage interview subjects to be more specific.

• Record the session or have a designated note taker so the interviewer can devote his or her full attention to the subject.

Example

Here is an example of how an unstructured interview might go. In this exchange, the architect is attempting to clarify a business constraint.

Architect:

You mentioned earlier that this new system replaces an existing one. What is the plan for the old system?

Stakeholder:

Once the new system is on line we’ll start the deprecation time line for the old system. The deprecation process can take up to nine months since we have to give current customers time to migrate off the old system.

Architect:

Nine months is a long time. When do you hope that process will complete?

Stakeholder:

The earlier the better, but I’m hoping by December of next year.

Architect:

OK, working backward, to be able to deprecate by December the new system needs to be live by the end of March. Does that sound right to you?

Stakeholder:

That’s probably about right, yes.

Architect:

Can you tell me a little more about the deprecation requirements? I want to verify that we aren’t missing anything that could put deprecation at risk.

Stakeholder:

Sure, there are four must-have features we need in the new system before we can deprecate the old one…

With that last statement, the architect immediately begins thinking about influential functional requirements.