Now let's talk about the technique called interviewing. So the interviewing requirements technique, interviewing is a systematic method for quickly collecting information from a person or groups of people in an informal or formal setting by asking scripted questions. So keep in mind that the primary purpose is to gain an understanding of high level needs, constraints and assumptions. That's what you're doing with the interviews. interviews are designed to address some of the communication challenges that either cause delay in getting requirements and stakeholders, or can cause a decrease in the quality of the information that you're gathering. So interviewing really is meant to be with either a one on one situation or a smaller group, you're not going to conduct an interview with 40 people.

It's meant to be very small group of people. Some can be challenges that you might face are inadequate information provided to the project team. Too much information in a form that cannot be understood by key stakeholder, unaddressed cultural differences, perceptions and personalities of presenters and stakeholders. The use of technical terminology can sometimes cause confusion, filtering of information based on the experience of the facilitator. So this is where you making assumptions come into play and how you might not ask certain questions or you might take them down a certain path because of your own personal knowledge or experience related to the subject. So you need to be careful about that.

Preoccupation of the stakeholder due to other messages conflicting with the presentation, and lack of openness and trust between project stakeholders. So those are some of the challenges that you might face related to communications when you're doing interviews. Some interview types are things like personal interviews, job shadowing, And task analysis. The personal interviews approach, it really uses exploratory questions on topics that might change requirements, create new requirements, or even uncover assumptions or constraints and business rules. Interviews should not typically be used to document like huge volumes of information that's considered background and context setting. job shadowing, can be useful and understanding the operational environment and discover prerequisites for job success preconditions for tasks, or specific business rules that govern job execution.

I was working on a project once that was related to an application that we were creating to be used by call center representatives. And I went to one of our call centers and I sat with the call center reps when they were taking calls from customers. And I watched the different things that they had to do within the application process. Get at the different pieces of information that customers would ask them about. So that's an example of doing job shadowing, we were creating a new application that those call center representatives were going to be using that was supposed to be more efficient for them. So in order for us to ensure we were making it more efficient, we had to watch what they were doing so that we knew the different things that they did in their day to day jobs.

Task analysis as a interview type, the goal of that is to identify the most frequent tasks, essential tasks and essential processes. Ways to enable these tasks will then become priority features for a new or enhanced solution, right. So you're going to take those essential tasks and turn them into requirements basically. So benefits of interviews. Interviews provide a context to see and decode both verbal and nonverbal information provided by stakeholders. Verbal is of course, what was actually said and nonverbal was referring to how it was and the body language that was used during the interview.

Interviews can be used to uncover conflicts and discrepancies about stated needs or requirements. You're going to accomplish this by using a problem probing manner, not a confrontational style. In addition to that interviewing can also be used to secure agreement from your stakeholders that the existing requirements documentation is accurate related to that problem, probing not confrontational style. You want to make sure that during the interviews that you're not appearing to be argumentative with the people that you're talking to. You may be asking them to clarify why they do something a certain way, or why they're requesting something has to be a certain way. But just remember that you're looking at it from the perspective of what is the business need for that?

What is the goal of what you're trying to do there? What's the end result supposed to be? It's not about whether or not you are with them, it's about what their end goal is that they have in mind. So you want to ask prepared questions so that you're gathering information consistently. Let's say you're doing five interviews in a row, right? Let's say you're doing one on one interviews and you have five different people that you're interviewing, but you're interviewing them separately in those one on one sessions, you want to make sure you're asking all of them the same questions, if the interviews are, of course related to the same thing, match the pace of the interviewees, right?

So if they are cautious if they talk slowly, versus if they're in a hurry, and they talk quickly, right, you want to pace yourself according to their pace. Rather than trying to get them to match your pace. You want to check your understanding. Often you can use paraphrasing, mirroring, those kind of techniques to verify that you're understanding their information correctly. Ask for examples of their issues and documents, screenshots or names of stakeholders that have particular challenges. Let interviewees know what will be done with the information so that they don't think that you're just they're just spending this time talking to you and nothing's gonna happen with it.

Remember to apply your listening skills show interest in what the interviewer is saying. Stay focused on the conversation and be respectful of the person's time. Don't be late and don't let the interview run over some rules for effective interviews. Make a decision on the type and number of interviews based on the business objectives, access to stakeholders and schedule and budget constraints. Schedule interviews in advance, don't wait for the last minute because as I mentioned earlier, it can sometimes be challenging to get on people's calendars. Prepare for the interview by creating open ended questions.

So again, remember if the question can be answered with a yes or no, it's not an open ended question. Prepared document the format for the interview. The documentation should contain the name of the interviewee, the role of the person being interviewed and what their primary responsibilities are. You want to leave space for you to write in the answers. You want to leave space for the interviewers insights that would be you the VA, right? You're the interviewer.

You also want an action item box so that you can flag some key pieces of information that are related to maybe the fact that it's a functional requirement a non functional requirement, maybe they've given you a risk or an assumption a constraint, something that's not kind of the standard business requirement or is in addition to the business requirement. For all user categories, you want to work with two or three users to get a comprehensive picture. So you should never only interview one customer service rep or one teller or one data entry clerk. whoever they are, right, you want to interview multiples so that you're getting different perspectives. You also should create a thank you script stating that you appreciate the person's time and involvement and stating how the person's involvement is going to help in creating high quality requirements. thank them for their participation.

Create a follow up screen Time The person how the information will be used, whether it will be confidential. And then the next steps for follow up or project involvement. Use two interviewers if you can, one to ask questions and one to document the results. So this is like saying, have a scribe with you. If you can't do that, you're going to have to do it yourself, right. But if there is another VA assigned to the project, then you can work in tandem like that.

Allow time in the schedule for both of the interviewers to debrief and document the interview results immediately after the interview is over. So in other words, don't literally schedule meetings back to back if you have to do five interviews. And the interviews are 30 minutes apiece, leave 30 minutes in between them so that you have time to document the information that you're getting some of the questions that you can ask during the interview related to functional requirements. And I will tell you this is one of the biggest challenges that I find in elicitation is figuring out the best questions to ask a lot of people ask me Well, what kind of questions do I ask and it's just different for different projects and different for where you're at. But I do want to give you some examples of some things that you can think about. That could be questions that you would ask.

So when you're talking about functional requirements, you could ask things like, what are other ways to accomplish this goal? Tell me about your frustrations with this process. What makes a good day? What makes it a bad day? If you could wave a wand and make it different? What would the process look like for you?

For non functional requirements? You could ask what standards or regulations should we be aware of? Some usability questions would be things like who's going to use the product or process? What purpose is accomplished by using the product or process? What equipment tools templates and inputs? Do people need to use it?

How long should test take? How do you define success, intrusion and detective prevention? So things around security, you could ask questions like what are actions you take to detect unauthorized system access? What can be done to create Prevent improper system access. So this is if you're working on a project that is security related some interface questions what people do you share information with? What information is passed to other systems, software attributes, ranking questions, safety?

How do you plan for safety considerations? robustness? What fault tolerant systems are important to you? supportability What failures caused the organization the most pain maintainability what unexpected system behavior has surprised you? operations and maintenance questions, you could ask things like are there things in the operational environment that I should be aware of? And have Interview Questions?

What didn't I ask that I should? Do you feel this interview was effective? If we could change only one thing about the process that we've discussed? What should it be? interviews are necessary and valuable for any type of project. You should be scaling the interview activities To the project environment.

So you can have typically three different types of projects a low profile project, a moderately complex project or a highly complex project. A low profile project, for example, the interview can really be handled through informal discussions with users, right? Like you don't need to have a formal session on what's probably a low profile low risk project. If the project is moderately complex and has some risk, then you should do formal interview sessions with key stakeholders so that you produce some pre determined deliverables. And then if it's a large, highly complex project that has significant risks, then you should do really formal focus group interview sessions with key stakeholder groups with budgets and timelines for securing stakeholder approval on project deliverables. So those are some examples of how you can tailor the requirements, interviews to the ties of the project