Speaker 1: In this video I'm going to show you requirements gathering techniques for a business analyst. We will go over several techniques in detail in order to find out the pros, cons and concrete use cases on when to use them and when not. In the end I'll give you my recommended requirements gathering techniques, which I personally use the most in my job as a business analyst in a global operating bank. If this sounds interesting to you, then make sure to watch this video until the end. Let's create a mind map first on which useful and also popular techniques for business analysts are out there for requirements gathering. The very first technique is document-based analysis. Like the name says, it's all about documents here, not about users, stakeholders or the clients. Here the first step is to gather all the documents available and relevant for your case. This means there is a lot of reading involved. Requirements documents can be very long, so be patient. Key is to understand the system by reading the documents, so you are able to build a baseline of knowledge, which is very helpful throughout the whole requirements gathering process. This requirements gathering technique is pretty much used every single time. It's basically the starting point in requirements analysis. The very next technique I want to cover are surveys and questionnaires. Surveys are a great tool to collect answers on standardized questions. So it's perfect for getting a high volume of data, because you can easily send the survey to hundreds of people and get their insights and you don't have to talk to them one by one. You can include open and closed questions. And especially for closed questions, it is easy to evaluate. The issue here is really that asking the right questions is a challenge. And you also don't want to influence participants with the question themselves, because they could bias. Let's jump to the next requirements gathering techniques for a business analyst. Shadowing. Shadowing is to accompany a user or a stakeholder. By this, you're living the process the user goes through every single day. That's a powerful technique, because you're also able to perceive what I call silent requirements. Silent requirements are requirements your stakeholder won't tell you, because they are so self-evident for them. The downside here for sure is that it's very time consuming for you as a business analyst to shadow multiple stakeholders. Now let's go to the probably most used technique, at least for me. Interviews. Interviews are basically that what service cannot provide to you. By having someone in an interview, you can get very specific. And also you're able to get feedback instantly. So there is a question answer loop where you can dive deeper with follow-up questions to really get down to the root. Requirements are most of the time something very specific. So it actually is pretty much necessary to dive deeper. The next requirements gathering technique I want to show you is the workshop. A workshop is not only an interview. A workshop involves many people at once and also enables them to work together on specifying the requirements. A workshop is not only an interview. A workshop involves many people at once and also enables them to work together on specifying the requirements. Here the role of the business analyst, so you, is also to ensure to guide the stakeholders at the table into the right direction. So people don't get lost. The goal definition or the desired outcome of the session is important. Because when many people sit around a table for a long time, that's very costly. These workshops can go over hours or even full days as per my experience. And if you have seniors also on the table, you can imagine how much such a workshop costs in the end. So better make sure to get the outcome. After clarifying the workshop, let me explain to you the last important requirements gathering technique for business analysts. Prototyping. What prototyping is about is basically that you build an increment of your product or system based on the initial requirements. Show this increment to the stakeholder and from there on gather the next requirements. This is an iterative and incremental process. These concepts are part of the HR methodology. Have you already worked with Agile and AI methodologies? If so, let me know in the comment section below. After describing these requirements gathering techniques, I want to contrast them against each other in a table. Let's talk about their pros, cons and use cases on when to use them and when not. Like I've mentioned in the beginning, document analysis has the pro that you are not dependent on others because the information is inside a document. The con here is that you cannot ask questions to this document if there is something unclear to you or maybe any gaps. Also, in reality, we often have missing documentations or even, like I said, gaps in these documents. The use case here is that document analysis is a good requirements gathering technique, especially for business analysts for having a starting point or an entering point into the project. You can leverage existing documentation to build your baseline of know-how. That's good to get up to speed with the topic. Servers, on the other hand, have the advantage of an easy evaluation of the data and also getting a lot of data. The issue, although, is we cannot get too specific in these surveys because people cannot ask questions to clarify something. The use case would be if you want very generic information about the stakeholders or the use of a system or process, then surveys might be fine. Shadowing has the huge advantage of gathering real-life data. You're able to get hands-on experience as you observe and shadow your stakeholder or future user. The con here is the time-consuming aspect for the business analyst. Nonetheless, this technique is useful when your stakeholder has no time for meetings with you, but it's fine to shadow him or her to get more insights. Especially for process improvement, shadowing is a very powerful technique. Interviews have the pro to get real-time answers and also to have follow-up questions in order to get very specific. On the other hand, your stakeholder needs to have time for these meetings. That also can get very time-consuming. Nonetheless, interviews are perfect to get more detailed requirements. Workshops have the pro that a big group of stakeholders is involved and therefore the probability to cover all the important requirements is higher. Furthermore, the acceptance from stakeholders is also higher because they are involved in the process. The con here is especially the time-consuming aspect. Full-day workshops with 10 people are very costly. In my experience, I used workshops in complex scenarios when we had inconsistent requirements. It helped a lot to bring stakeholders on the same page. Prototyping has the pro that you deliver something tangible with each increment. That helps the stakeholder to understand what we are doing. On the other hand, producing an increment each time and then going back to the stakeholder can get time-consuming. The use case is when you have unclear requirements but the stakeholder wants to see results frequently. Now let's summarize. Based on my personal experience, I would recommend to always start the document-based analysis. So read the documents to build your initial know-how. After that, interviews will be your main requirements-gathering technique as a business analyst. Interviews enable you to get different perspectives and angles on the topic. Facilitate workshops if you have complex inconsistencies or stakeholders are not on the same page. And use the concept of prototyping in order to get feedback from the stakeholder. Try to make these feedback loops one or two weeks so you can sync with the stakeholder frequently and issues come up faster. Also, bring stakeholders on the same page with sync meetings. Optional are surveys and shadowing. The reasons were mentioned before. What technique have you already used? Do you want me to dive deeper into any of these techniques? Let me know in the comment section below. Also, tell me your opinion on these requirements-gathering techniques for business analysts. If you found this video helpful, leave a like and if you don't want to miss out new content, make sure to subscribe. Thanks for watching and take care.