In this section we're going to look at asking questions and not just questions but asking the right questions as part of eliciting requirements, you're responsible for posing clear, concise questions and listening for a response. Once the response is given, you have to digest that information, and then determine if follow up questions are necessary before you continue on to the next topic. to completely define the requirements, you have to identify sources of information that are coming out of the conversation, and then frame questions properly. Your main job as a business analyst, right. The thing that you're going to do the most of and that quite frankly is the most important to your job is listening and analyzing information. The majority of the information is going to be gathered through the various different questioning techniques of different actors, different subject matter experts, different stakeholders, external agents, which could be vendors, customers, people like that.

So some potential sources of information. Our executive sponsors, the subject matter experts, which can come from upper management, middle management, business professionals, clerical. If you're working on a project related to a call center, then the people working in the call center, technology teams, the outside vendors, suppliers and customers, and then personnel that support interfacing software. So other software that's working with the application that you're working on, you want to be sure that you identify the people that represent each area of your scope, so that you're making sure that you are having conversations with representatives from each of those different area. So let's look at framing questions on business process. When you are probing for additional information related to process, some of the types of questions you can ask are things like, why is it done?

What does it involve? Who does it? When is it done? Where is it done? How is it currently done? Because there can be more than one way that they're doing a task right now?

How might it be done in the future? What constraints are affecting the process? Where's your problems at right now? And if you feel like you are saying why too much, you can try things like for what reason? You can switch it up a little bit. You don't always have to use the word Why?

When you're framing questions around data, right, because you have two different things that you're doing. You're identifying processes, but you're also identifying data. So when you're trying to figure out what data is needed some of the types questions you can ask are things like, who uses the data? Where does the data originate? Why do we need that data? What is the data?

How is the data defined? What are the constraints on the data? For example, if you had a project called training scheduling project, and the point of the project was to increase the number of classes that can be scheduled by the existing number of administration personnel. Some possible questions you could ask are, who schedules the training classes? What activities occur to schedule a class? Where's the class scheduling activity performed?

When is a class scheduled? Why do you schedule classes? Other possible questions are How are classes currently scheduled? How might classes be scheduled in the future? What constraints are there on scheduling classes? Who uses the class scheduling information?

What information is needed to schedule class? What information to scheduling a class generates? Where's the scheduling information generated? Why do we need each piece of information? What is the definition of each piece of data? What are the constraints on the data?

So you see when we have a simple statement for a project, and all of these questions came up. So a lot of times people don't take a moment to think about all the different things that they need to ask. And they look at a statement and say, Well, this is pretty simple. And they asked a couple of questions and they move on. Take some time to really dig in, and figure out all the different types of questions that you need to ask in order to get at all the different types of information that you need to know. Now let's look at appearing clueless in order to foster expanded discussion then sometimes you should ask silly or levels questions, and you're doing this on person.

Put yourself in the position of being clueless about the process that you're discussing, so that others will correct you and explain the options, the true nature of those options and why they chose the direction that they did. This helps teams to actually re examine their drivers for decision. And it often helps them look for simpler approaches. It sort of shocks their nervous system into reconsideration. Right? So takes them out of the norm and makes them think about it rather than having an automatic response to things.

However, you do need thick skin and self confidence to take that approach. Because people may look at you. Like they're thinking, hey, you should know the answer to that, or that's a dumb question. Why are you asking that and it's okay, if they look at you like that. It doesn't matter. At the end of the day.

It's your responsibility to get at the information that you need to have in order to make sure that you're giving them what they need to have. So if it requires that you use this technique, then use it Don't be concerned about what other people are thinking, making debatable statements. This is kind of a variation on the silly question approach. So instead of a silly question, you might be making a statement that will cause a debate to happen. So let me give you an example. In your business domain Sox compliancy might be an important criteria.

In requirement planning session, you might state that you've seen little or no information around Sox compliancy and testing, knowing that there really is a reasonable level, you're looking for the team to respond with the facts. And you're also looking for realization across the team of any SAS compliancy or testing gaps that might still exist. So even though you know it's there, you're going to make that type of statement, so that you cause them to think a little bit more about it. So it's still working the same way as appearing clueless. It's just a little bit of a variation on that. So again, thick skin when you're using that technique, Active listening, when you are actively listening, you are staying focused on the topic.

So if your mind is wandering and you're thinking about what to cook for dinner, or what you need to pick up on the way home from work, things like that, then you are not actively listening. So you need to stay focused on the topic. You need to respond in a professional manner to what the person is saying, not what you believe they're saying, right, that goes back to that true listening, hearing, paraphrasing back to them repeating back to them verbatim. You want to make sure that you're responding to what they're saying. We all hear and process information differently as the first part of your response, you want to repeat back what you heard them say. So that's where you either use the paraphrasing or the verbatim, right?

Because that's going to ensure that you're actually responding to the correct comment or question. Because if you say if I heard you, right, you said or I think I heard you say or help me make sure I understand you correctly. And you're paraphrasing back to them. And they say No, that wasn't actually when I met. Now you're actually getting on the right track, right? Where if you don't say that to them and you just continue down the path of thinking you understood them correctly, you could be responding to the wrong statement completely.

So you want to use that paraphrasing or verbatim technique, mirroring or paraphrasing to make sure that you're understanding what they're saying correctly.