Business Requirements Elicitation Basics Part 2 | Teresa Bennett | Skillshare

Playback Speed

  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Business Requirements Elicitation Basics Part 2

teacher avatar Teresa Bennett, Business Analysis Expert

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

    • 1.

      Introduction to Elicitation Part 2


    • 2.

      Brainstorming Elicitation Technique


    • 3.

      Interviewing Elicitation Technique


    • 4.

      Survey Elicitation Technique


    • 5.

      Workshop Elicitation Technique


    • 6.

      Conflict Resolution


    • 7.

      Requirements Session Exercise


  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.





About This Class

About This Class

Do you walk into requirements elicitation sessions already sweating because you can't stop worrying about what you might miss, or if someone will think you're not a "good" BA?

Eliciting requirements from stakeholders is the most important part of a business analyst's job. Everything you do, everything you document is based on those requirements. Everyone else on the project is relying on that documentation to do their part. Scary, right? Well, it doesn't have to be. 

Master specific elicitation techniques to set yourself apart from the growing crowd of business analysts

  • Learn the elicitation techniques you should be using to get the correct information from your stakeholders
  • Be confident you are asking the right questions
  • Get detailed requirements and minimize requirement gaps

What will you learn in this course?

  • Brainstorming requirements techniques
  • Interviewing requirements techniques
  • Survey requirements technique
  • Workshop requirements technique
  • Conflict resolution
  • A requirements session example

Who should take this course?

  • Current business analysts that are not confident in requirements elicitation meetings
  • Business analysts that are consistently missing requirements
  • Individuals that want to move into the business analyst career


  • To get the most out of this course, you should have an understanding of what the business analyst job function is.
  • I also recommend you complete the Mastering Business Analysis Communications Parts 1 and 2 courses prior to starting this course. While it is not required, it will set the stage for what you are learning in this course.
  • Complete the Mastering Business Requirements Elicitation Part 1 class

Meet Your Teacher

Teacher Profile Image

Teresa Bennett

Business Analysis Expert


We believe business analysis should be effortless. We have decades of BA experience. We've learned over the years what works, what doesn't work, and what made things easier vs. harder.

If you can get at the same information, provide the same level of concise, clear and complete requirements with less effort, then why wouldn't you do that?

Our unique method of analysis will help you understand exactly what's necessary, what can be left out and how to elicit, document and share information in a way that allows the entire project team to avoid roadblocks and be successful.

See full profile

Level: Beginner

Class Ratings

Expectations Met?
  • 0%
  • Yes
  • 0%
  • Somewhat
  • 0%
  • Not really
  • 0%

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.


1. Introduction to Elicitation Part 2: Hi. My name is Teresa Bennett, and I'm your instructor for the business analysis Requirements Solicitation of Part two course. In this course, you will learn four specific techniques for eliciting requirements and when to use each one . You'll also learn about conflict resolution as it pertains to requirements. And I'll go through a requirement session exercise to help solidify the points made in this course. Thanks for watching, and I'll see you in the course. 2. Brainstorming Elicitation Technique: So we've been talking about the listening requirements. Let's take a look at some different techniques that you can use to elicit requirements. We spent some time talking about how important it is to make sure that your requirements are complete. But one of the ways that you're doing that, of course, is by going through the exercise of talking to your stakeholders and getting the requirements from them. And there are some different types of meetings. If you will types of ways to get at requirements, so we're going to go through those. The first technique we're going to look at is brainstorming. Brainstorming is considered a group facilitation technique, and it's used in requirement sessions to generate ideas, approaches and issues and risks. Brainstorming is a creative process that's going to facilitate creative thinking, to allow the participants to look for solutions that they may not have previously considered. When you're using this process, you want to bring together a group of SMEs that possessed the required domain knowledge to solve complex problems and focus on innovative solutions so it doesn't do you any good to have people in the brainstorming session that aren't very familiar with the topic at hand, right, So make sure you've got the right people involved when you're going to use the brainstorming technique. Because business is increasingly complex and has many inter related parts, it really requires the contribution of a lot of different experts with diverse skills and perspectives. Using the brainstorming method is an effective way to bring those people together. Brainstorming is also a great tool to use to gain consensus like everybody in agreement. So this is an effective tool when you need all groups to support the decisions after leaving the meeting right. So if you want everybody to be on the same page, you want everybody to kind of jump on the on the same bandwagon, if you will, and support the decisions that are being made then Brainstorming is a great technique to use, so there are a few different types of brainstorming, individual, open and structured individual means. A project team member creates a list of ideas concerning a project or issue. Open means meeting participants call out ideas that are captured by the meeting facilitator or scribe. This is an efficient process when team dynamics are good and individual skill sets are strong, structured is when meeting participants silently write down their ideas, and the facilitator then requests that each person in turn shares an idea. And each person can only share one idea. However, the meeting continues until all ideas have been shared. But you do one round first, and then you go back to the first person and do another round and so on. Until all ideas have been discussed, you just don't want one person dominating the conversation and only getting a chance to share their ideas. So that's why you do the one at a time in a structured brainstorming type some rules for brainstorming. Our first of all, decide on the type of brainstorming, right if it's gonna be open or structured, and then stick to it clearly and concisely state the objective of the meeting. And by the way, I just want to point out that as the business analysts leading the meeting, you're the one that should make the decision about the type of brainstorming, whether or not it's open or structured. So I just want to make that point clear that you're the one that makes the decision about that, and then again, clearly and concisely stating the objective of the meeting and then create an environment where participants feel encouraged to participate and believe that their time is used effectively. You want them to feel like they were productive in the meeting. Some rules for brainstorming as faras some things that you should say at the beginning of the session to make sure that everybody is coming at it from the same perspective as one. Don't discuss the ideas during the brainstorming session. The brainstorming session is just to get ideas out there, right not to discuss them in detail. Do not dismiss an idea because that can cause a person to clam up and no longer share ideas . Do not discount a person or an idea for the same reason is above right. We want them to continue participating in the meeting. The only discussion that you can have during the meeting is questions to clarify the idea, build on each other's ideas and suggestions during the meeting. Have fun with it, and the B A should give rewards for the craziest ideas right that might help people to be more engaged in it. You should have a timekeeper, a facilitator and ascribe describe is used to capture the ideas right in attendance for the meeting. And sometimes, quite frankly, you're playing all three of those roles. But if you have the opportunity but have different people than you know, great, there's other people. But if not, then you may at least want to designate somebody in the room to kind of be the person to be that timekeeper to say, Hey, it's time to break or it's time for launcher, depending on how long your meeting is, if you just want to decimate somebody else to help with that because you may not be paying attention to the time when you're acting as the facilitator and maybe also acting as describe, right. So timekeeper is sometimes something that you can give out as a test to somebody else that's in the room. You want to determine the process that you're going to use for combining like and similar ideas and categorizing and summarizing the brainstorm results right. You need to be able to put things together that go together, right? So come up with a process for that. You want to publish an agenda prior to the meeting you want to schedule multiple meetings. If the issue our project is complex and you know you're just not gonna be able to get through everything in one meeting. You also want Teoh. Go ahead. Once you determine what those follow up meetings are, you need to schedule the initial meetings, right. You may not necessarily scheduled a follow up meetings right away because, quite frankly, I like to wait and see if I really got that right. So, for example, if I'm talking about a topic and I think that a topic is going to take two sessions, right, like there's no way I'm gonna get through this in an hour. I could only do one hour meetings, and I know that this gonna take two hours. I don't scheduled both sessions. At that same time, I will usually schedule the first session and then wait and see how far I got with that before I scheduled the second session. Now, there are times when I will tell you that you need to go ahead and schedule the follow up sessions and then cancel them if they're not needed. And that's if people schedules are really tight and you have trouble getting on people's calendars, Then go ahead and schedule the meetings and get him out there. And that way you can just cancel them. If you don't need them, you can use other internal Resource is so there could be other B is not necessarily assigned to your project, but that you might be able to get to help you with just kind of sorting through things. Get them to take a look at it. If you officially at more than one, be a assigned of project, then that's awesome. You guys should get together and sort the categories and the items into different categories. But if not, you know, offer to buy somebody launch and get them to help you with it. It's sometimes it's just worth that, you know, five or 10 bucks for lunch. Did you get some added help and a different perspective on things? Use prioritization techniques to short the ideas votes can be given to team members. Just like how we talked about prioritizing requirements, you can prioritise ideas in pretty much the same way as well 3. Interviewing Elicitation Technique: 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, air designed to address some of the communication challenges that either cause delay in getting requirements of 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 communication 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 your 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 . Conflict ing with the presentation and lack of openness and trust between projects. State quarters. So those 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 jobs, 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 to get 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 a central processes. Ways to enable these tasks will then become priority features for new or enhanced solution , right, so you're going to take those e central 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 nonverbals referring to how it was in the body language that was used during the interview interviews convey 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 Teoh, 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 agree 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 your understanding their information correctly. I asked 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 there 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 interview is saying. Stay focused on the conversation and be respectful. 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 and sometimes 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 interviewing, 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. Be a right you're the interviewer. You also want 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 of nonfunctional requirements . Maybe they've given you a risk or an assumption of constraint, something that's not kind of the standard business requirement or is in addition to the business requirement for all user categories. You wanna work with two or three users to get a comprehensive picture, so you should never only interview one customer service rep for one teller, 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 requirement, Thank them for their participation. Create a follow up script, telling the person how the information will be used, whether it will be confidential and then the next steps for follow her project involvement used to interviewers, if you can want to ask questions and one to document the results. So this is like saying have ascribed with you. If you can't do that, you're gonna have to do it yourself, right? But if there is another be a assigned to the project, then you can work in tandem like that. Allow time 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 air 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 Elicit ation is figuring out the best questions. Ask a lot of people Ask me Well, what kind of questions do I ask? And it's different for different projects in, 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 nonfunctional requirements? You could ask what standards or regulations should we be aware off 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 it puts. Do people need to use it? How long should tasks take? How do you define success, intrusion and detective prevention? So things around security you could ask questions like what our actions you take to detect unauthorized system access. What could be done to 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. Support ability. What failures cause the organization the most pain. Maintain ability. 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 off end of interview questions? What? Didn't I ask that I should have? 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 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 predetermined delivery bubbles. And then, if it's a large, highly complex project that has significant risk, then you should do really formal focus group interview sessions with key stakeholder groups with budgets and timelines for securing stakeholder approval on project delivery bubbles. So those are some examples of how you can tailor the requirements. Interviews to the size of the project 4. Survey Elicitation Technique: Let's take a look at the survey technique used for requirements. Elicit ation. A survey is a process used to quickly gather information without any type of verification. Surveys that gather information without verification are used to understand the process. Undergoing change, identify significant areas warranty, future study or analysis, and obtain information to help determine the appropriate requirements. Solicitation and analysis activities. When you're considering a survey, you need to make sure that your questions in your survey are unambiguous, so you need to put some of your requirements specifications to use. Here's because that's one of the things that you have to make sure of with requirements as well. Right is that you're clear and concise, and you need to do that in survey questions. To rate yourself as being a novice and average user or an expert user of the system versus do you consider yourself to be an expert. So getting specific, save complex questions for later in the survey in the space below. Provide additional information about how the system could improve the processing of exempt payroll. That is an example of something that you would want to save until later, because it's gonna take more time and thought for them to complete that question rather than it being a multiple choice type of question. And you also want to save demographic information like age group division, gender for last. So that you don't make them feel is if that information is a personal reflection on their answers, so make sure that is last. People respond to rewards, so you want to reward people for completing the survey. One reward can be simply providing visibility for the division or department with the highest percentage of responses. Competition can create more responses, right? People want their department to get noticed and get announced in the company newsletter for having completed it over another department. So things like that don't have any kind of monetary reward. It all can still be a reward to people. So consider something like that. And you can also consider a monetary incentive for random participation, like a voucher or a gift card, maybe a Starbucks gift card. Something like that, if your project budget allows for it when you create the survey, you want to use an inexpensive online tool that's readily available so that people can just access it online. and complete their survey. That way, it's increasingly easy and cost effective to develop surveys online and to create an anonymous portal that calculates the results. So it's not something that has to be really technical, really fancy. It's very simple to Dio. You would notify the participants when the survey is available and then continue to remind them to participate. So if you're gonna leave it open for a month, don't just send them one notice and expect them to respond to it. You need to send them multiple notices as reminders at least a couple of week. And if you're only leaving the survey open for one week, then I would do daily reminders. You also then, of course, need to analyze the survey results. This is probably the hardest part of the survey technique, because there may be some poorly performing questions due to ambiguity or confusion, because maybe you weren't clear enough in your questions, and then they're also can occasionally be problems or heirs in the survey tool itself. No software is perfect, so that can create some issues when you're analyzing the survey results, so just keep that mind when you are using surveys you want to tailor them Teoh the size of the projects. They can be valuable for most projects, but I would say for a small project with low risk that surveys air not necessary If stakeholders know each other, no the business and know the technical domain for moderately complex projects with some risk user surveys can quickly gather information or measure current state user satisfaction or needs so they can be useful with moderately complex projects and then with large, complex projects with high risk. That I would say user surveys should be used there actually needed to measure current state user satisfaction or needs and validate stakeholder assessments. So if you are working on a large project, especially a large project that has a lot of users that are spread out in different locations. So, for example, I worked on a project once that was for a new application call center reps to use, and we had 28 different call centers that had about 200 call center reps in each of those 28 centers. And if we wanted to get information on pain points that they were having today and things that they would like to see different in the future. Obviously, we wouldn't be able to take the time to talk to all of those people, So doing a survey to them was a good technique to use to get some feedback on that. So those air some things for you to consider when you're thinking about using the survey technique. 5. Workshop Elicitation Technique: Let's take a look at the workshop requirements technique. This one and the interview technique are probably the two most popular techniques used. Four requirements. Solicitation requirement workshops are structurally facilitated requirement meetings that our formal sessions that involved multiple groups and you'll sometimes hear those referred to his dad Sessions. Jad stands for joint application development. The idea of these sessions is to get every group from every area an application in a room together, including developers, for a certain number of hours or even days, and elicit the requirements for the entire project. This could be more productive than having requirements meetings with individual groups, because when you have separate meetings, you run more risk of having conflict in requirements that don't get resolved right away because you don't have all involved parties in the room. Workshops can also be used to refine requirements, do quality checks and reach closure on requirements. So some benefits of the workshop sessions are their effective at getting real requirements rather than perceived requirements. They can neutralize a predominant voice by creating ground rules for discussion and decision making. So everybody in the room gets the opportunity to speak and give their opinion on things rather than they're being one strong person that is always kind of listen. Teoh and the others aren't getting to share their opinions on things. There is a greater chance of obtaining consensus because stakeholders are presented with the issues and questions at the same time, Right? So everybody's hearing everything at the same time. Feedback is immediate. Interpretation of the information you're getting is documented for immediate stakeholder confirmation. I always make sure that, for example, if there is a three day workshop at the end of each day, I'm documenting what came out of that day. I'm sending it out and then the next morning, before we start the meeting, the first thing we do at the beginning of the meeting is to go over the information from the day before. So that way I'm able to get immediate feedback on any of the notes that I took in case there's anything that I misinterpreted your also able to successfully get their requirements from a large group in a short period of time, right? You can get people in a room together for a few days and get requirements that otherwise would take you weeks to dio and documentation is completed within hours of the session. Like I said, I would do it that day off and provided quickly to participants for their review. It's an excellent way of being able to quickly get a handle on the requirements for the project. Some disadvantages of workshops, right? Any time there's something good, there's always something not so good to consider, right. So disadvantages of workshops are things like the difficulty in getting appropriate stakeholders in one room. At the same time, there are an increased number of global projects that pose logistics difficulties and adds complexity. So if you're working with people in multiple areas, that could be difficult to do when you're talking about, you know, crossing country borders and things like that. Success of the session is highly dependent on the expertise of the facilitator. So if you are not an experienced a meeting facilitator, then it may not go as well as it should. And they can also be expensive, right, because you were bringing people in. So there's travel expenses and things like that. Dio and taking people wake from their jobs for X number of days. So those are things that need to be considered as well when determining if the workshop is the way to get Let's look at some rules for workshops, you want to be clear on what the session will deliver. Some common topics for workshop discussions include things like events, actors and a process for gathering requirements. So let's talk about events in software development. And event is defined as something that causes change in the environment that the proposed business solution must respond. Teoh, a time related example. Would be jobs need to be kicked off. A midnight payroll executes every other Friday. Some other things could be like request related things for events. People request cash from an A t m. The user presses submit on an enterprise portal. A satellite receives a transmission from Mission Control. Those are things that fall under that event category. Some examples of things that fall under the actor category because, remember, an actor can be a system or person that is interacting with the proposed solution. So when you think about it in that way, a people actor example could be soldiers interacting with equipment. The public requesting information from an agency enterprise portal, senior executives requesting financial analytical reports. Any of those three could be people after examples. Some system actor examples would be things like an interface to dependent systems such as payroll pulling, active employees from the HR system or an online payment acceptance systems requesting and receiving a credit card authorization. So those are some examples of events and actors that could be discussion topics for workshops, and the other thing to discuss in the workshop is the actual process for gathering requirements. So either a business process flow or a structure development process needs to be determined . And that should be talked about in the workshop about how you're going to go about gathering the requirements and then walking through that process, right? Are we looking at a process flow, or are we looking at a more structured kind of process for that and then sticking to that as you're going through the workshop? So let's look at some possible participants for Jad sessions so that if you're doing a workshop and you need to make sure that you have everybody there that needs to be there, thes could be some areas for you to consider whether or not you need to have representation from them in your session. Business process owners, which I would say should always be in the session. Operations managers, client representatives, business analysts, business managers and users. Data administrators, system analysts, system designers, advisers and project leaders. Auditors, security people standards, people, vendors. Especially if you're purchasing an off the shelf type of software, you want them involved in the session. Quality assurance. Contingency planners, production planners, I T specialists, human resource representatives and trainers are all areas that you consider. Do you need somebody? There doesn't mean that you always need somebody there from all those areas, but they are areas for you to consider and think about to make the decision about. Do you need someone from there? The executive sponsor is somebody that should always be included in your session. So management commitment is really required for any needs or requirements gathering process to succeed. It doesn't matter how you're doing it, and it's very important for the Jazz session team to have a management sponsor. The executive sponsor can be a manager of the business area whose needs and requirements are being addressed during the Jad session. The sponsor does not have to actively participate in every Jad session, but they're supported. The project needs to be clear, so it might be advisable toe, have them attend the first Dad session to show support and then the final Jad session to review the results and make comments. So if you're having one long session right, what may be a three day or four day session, then you would want them there on the first day and on the last day. The sponsors should be available through out the period of the jazz process so that they can solve any serious problems or issues that come up and you as the facilitator. Most likely you'll be the facilitator of the meeting. We'll need to work closely with that management sponsor, and you want to make sure that you're providing them full briefings on the progress being made during the jazz session. So if you're doing those reports every day, those meeting minutes and you're sending them out, you want to make sure they're included in that as well. Obviously, the business analyst, who is probably also acting as a facilitator should also always be included in the session . The facilitator is the key person in the group in his response for planning, executing and managing the session. That person needs to be respectful, and they need to be a skillful leader with a good reputation within the organization. Right, because you want the facilitator to be somebody that's being taken seriously. So if you don't fit that role, somebody else needs to be the facilitator. The choice of a facilitator can mean the difference, really, between a good session and a poor one. So you need to look at that objectively and look at it from the point of view of the project. If you are not the right person to be the facilitator, it's okay to be the be a on the project and to be asking questions during the meeting. But allow somebody else to be the facilitator of the meeting Jack Facilitator. Skills do not just happen by chance, and if you haven't learned them through specialized training and experience, then you just may not be the right person for that particular dad session. At that particular time. It's essential that the facilitator be given authority to work closely with the executive sponsor to achieve the objectives of the jazz session. This is not the time for us, a facilitator, Teoh think. Oh, they're executive sponsor is too high up for me to talk to their VP or, you know, a CEO or CEO and and you feel intimidated by their title. This is not the time for that. You can't let yourself be intimidated by executives simply because of their title. Remember that you are an extremely important piece of the project and you play a critical role in project success. So it doesn't matter who it is that you're talking to. A Sfar is what title they have goes. The focus should be on. What do we need to discuss on what needs to be done? In order for this project to be successful, the facilitator is going to know how to direct people to be able to get to the best information. And Jeff Facilitators should be able to focus on the process, not the information content of the jazz session. They should be unbiased and neutral and remain impartial. It's important that the reporting structure is such that the facilitator can't be influenced or biased, so you don't want it to be a situation where you feel like you can't say what you need to say because of who's in the room. Use organizational skills to lead groups and keep the sessions on track. Ensure that each subject under discussion is accurately recorded and completed to the stakeholder satisfaction. Before you proceed to the next topic and stop sideline conversations, you've got to be able to keep that meeting on track, especially if you have 20 people in the room. You don't want there to be 10 conversations going on it same time, so you've got to be comfortable with putting a stop to that when it starts happening. The recorder is the person that is responsible for documenting the Jad session that has to be done in an interactive fashion, and the recorder must work closely with the facilitator. Many ideas and suggestions are going to be discussed. Ah, large session may name multiple recorder's right. Multiple people taking notes. The recorder must capture the important discussion and decisions being made and who made them and why. Laptop computers, white boards, flip charts and overhead devices are things that you can use as part of that recording of information. It's the responsibility of the recorder to distribute and file the documentation at the end of the jazz session or soon as possible. After that, right? We talked about that before. It could be a difficult task, and it should not be underestimated. You may find yourself as both the facilitator and the recorder I have been in my Jad sessions. If so, make sure that you're also asking someone else to take notes as well so that you can combine them to help ensure you haven't missed anything. Since you're also facilitating the discussion. It just makes sense that you're going to be so involved in some of the discussions that you actually forget to take notes. So you want somebody else to also be taking notes so that you can minimize the content that gets missed. The recorder needs to have the following skills knowledge of the state quarter business area. So in order to record the results properly, they need to understand the concepts of what's being discussed. It can't be, you know, literally somebody pulled in off the street past me, somebody that understands the business area. They also have to have excellent analytical skills. They need to be able to analyze what's being discussed and presented in the Jad sessions, and they need to be experienced with any jazz tools. If they're being used and have good technical writing skills, the tool that's being used, I just want to say, can simply just be Microsoft Word or some other word. Processing software can be whiteboards. It can be, you know, a case to whatever the tool is that is being used doesn't have to be an official Jad tool, But even if you're using Microsoft Word, it's a tool, right? So whoever's doing the recording has to have knowledge and be able to use it will effectively. Stakeholders and business sponsors, of course, should always be included. I don't think there's anybody that doesn't think that it's necessary to have them there, right? That's who you're getting the information from. Without their involvement, the Jan session isn't going to be productive. The whole point of it is to bring stakeholder and performing organisations together in a structured environment, so obviously they need to be there in orderto make that happen. Stakeholders will rapidly gain a sense of involvement in ownership in the project or service development when there is a Jad session used, and this is vital to the overall success of the project. Most important, the stakeholders will get the product they want, and not one that has been designed poorly for them because we didn't understand completely the requirements. So some tips for successful workshops create a plan to address known project challenges that have prevented project success in the past. The session is led by trained facilitator again trained, trained, trained and assisted by scribe whose role is to document the workshop results. Participants include users, developers, SMEs and senior managers. Users can be individuals who are authorized to speak for the business or mission domain and who can make binding decisions for the project. Developers are key individuals responsible for design, construction and test of the solution who can provide high level architecture answers that speak toothy technical feasibility of implementing requirements so they can tell you if you're way off track in the meeting about whether or not being able to technically do something right. If it's technically possible for some of the things that's being discussed, it's Mies, the subject matter experts, of course, our process or technology experts who are able to provide immediate process economic or technical feasibility assessments to resolve any meeting conflicts or roadblocks that come up so you can have SMEs on both the business side and the technical side. Senior managers are individuals with the authority to commit organizational funds and make real time binding vision and direction decisions or trade offs during the meeting. So it might be that there's a conversation that needs to be hand to say, Well, it doesn't look like this is possible. We've got this option and this option. We need somebody to be able to make the decision. Let's go with that option. You want to limit the meeting. Teoh. Keep project participants. If project participants cannot be limited, then you may need to look and see if either the project scope or the meeting agenda is not sized correctly. Workshops can be valuable for most projects. We want to look again tailoring workshops, just like we looked at tailoring surveys, so you should scale the workshop activities to the project environment. If you have a small project with low risk, then that's really better handled with informal working sessions. Moderately complex projects that have some risk are best handled with formal meetings that have pre defined delivery bubbles and large, complex products with high risk should use formal meetings with budgets and timelines for securing stakeholder approval on pre defined deliverables. So a large, complex project, you may end up with a bad session with 40 people in it. That's an example that of moderately complex 1 may have 10 or 20 people. A small project. You may only have five, but it's still a workshop, and it should still be considered as such and still follow the same rules and guidelines. 6. Conflict Resolution: One of the things I want us to take a look at now is conflict resolution, because this will come up for you in interviews, workshops, anywhere where you have more than one person that you're getting requirements from, there's a possibility that they'll be the conflict of requirements and also the conflict of people. So when people conflicts come up, we need to make sure that we address them right away that we don't let them linger. So we're gonna look at some ways to resolve conflict. In many cases, conflict in the workplace just seems to be effective life right? We've all seen situations were different. People with different goals and needs have come into conflict, and we've all seen the often intense personal animosity that can result from conflicts. So we want to make sure that we're not letting that fester right and that we're resolving conflicts as soon as possible and that some of the good, if you will, that comes out of resolving conflict as there is an increased understanding. So the discussion needed to resolve the conflict can expand people's awareness of the situation and give them an insight into how they can achieve their own goals without undermining those of other people. It can also create increased group cohesion. So when conflict is resolved effectively than team members can develop stronger mutual respect and renewed faith in their ability to work together, and it can give improved to self knowledge. So it pushes individuals to really examine their own goals and helps them understand the things that are most important to them and also was sharpening their focus and enhancing their effectiveness. However, if it's not handled effectively, then the results can be really damaging, right, because we can have the possibility of personal dislike right where people just don't like each other. Teamwork with them break down because obviously people don't want to work together that they don't like. And talent gets wasted because people become disengaged from their work. If they're not enjoying the team that they're working with and they're not going to enjoy the work, and if they're not enjoying the work, then they're going to disengage from it. We want to make sure again that we're addressing conflict as quickly as we can. I want to talk about a few styles for dealing with conflict. The 1st 1 is competitive, so people who tend towards a competitive style take a firm stand and know what they want. They usually operate from a position of power drawn from things like position, rank, expertise or persuasive ability. So think about personalities and how people aren't. You can figure out if they are competitive and use this style. You yourself can use this style. You can use any of the styles, even if it's not your natural go to style. There are times when it is useful to use a specific style, right? So that's what I want to get across here. So the competitive style is useful when there is a quick decision that needs to be made right. We don't have a lot of time to discuss it, and a quick decision has to be made or when we know that the decision is going to be unpopular, or when defending against someone who's trying to exploit the situation selfishly, you know that they're trying to take everybody down a certain route for their own gain. However, it can leave people feeling kind of bruised, right, like they've been through a war, unsatisfied and resentful also, so you don't want to use it unless it truly is an urgent situation. The next style we have is collaborative people tending towards a collaborative style try to meet the needs of all the people involved. There are pleaser, right? They want to meet the needs of everybody. These people can be highly absurd tive. But unlike the competitors, er they cooperate effectively and acknowledge that everyone is important. This style is really useful when you need to bring together a lot of different viewpoints to get to the best solution and when there have been previous conflicts in the group, or when the situation is too important for a simple trade off, right? Like we're not gonna be able to do something else. We're gonna need to do it this way, and we're gonna need to get everybody basically jumping on the bandwagon for this solution . The way with that, we want to do this compromising people who prefer compromising style. Try to find a solution that will at least partially satisfy everyone. Everyone is expected to give up something, and the compromiser also expects to relinquish something compromises useful when the cost of conflict is higher than the cost of losing ground. So it's what's more important here when equal strength opponents are at a standstill and when there's a deadline looming. We wanted to use the collaborative approach when we know that we've got to move everybody towards a specific solution, it's OK to choose a different solution right when we don't have to be married to a particular one. Accommodating this style indicates a willingness to meet the needs of others at the expense of the person's own needs. So in the compromising, remember I said that everybody's giving something up, but in the accommodating style, it's more like, Hey, I'm giving something up, but you're getting what you want. Look at it that way. The accommodate ER often knows when to give in tow. Others, but can be persuaded to surrender a position even when it is not warranted. This person is not assertive but is highly cooperative. Accommodation is appropriate when the issue matters more to the other party, when peace is more valuable than winning, or when you want to be in a position to collect on a favor you gave. You may want to purposely use Thea accommodating style when you know okay, I'm gonna give into this person on this point. I'll go with what they're wanting to do here, and then later I'll be able to remind them, Hey, Sally, remember when I did X y Z for you? Now it's your turn to return the favor. That's when accommodating can be useful. However, people may not return favors, so you need to make sure that you're okay with that outcome, even if they're not going to do that. Usually you're not going to get the best outcome with that approach. But if it's the only approach that can be used, it's obviously better than none. Avoiding this is kind of the nun, right. People tending towards this style seek to evade the conflict entirely. We all probably know people like that. You might even be like that right where you're very uncomfortable with conflict. So you just avoid the situation and pretend it's not happening. That style you can tell when somebody uses that style when they delegate decisions to other people when they delegate accepting default decisions and they don't want to hurt anyone's feelings. Once you understand the different styles, you're able to use them to think about which is the most appropriate approach to use, right. So even though you're gonna have your own default style, you want to think about which style is right for a particular situation and then use that approach when you're using what we call the inner based relational approach to resolve conflict. That approach respects individual differences while helping people avoid becoming too entrenched in a particular fixed position, right, we want them to be opened. Other options. So when you're using that approach to resolve conflict, there's some rules that you need to follow to make sure that it works well for you. Make sure that good relationships are the first priority. So as far as it's possible, make sure that you treat the other calmly and that you try to build mutual respect. Do your best to be courteous to one another and remain constructive under pressure. Don't start name calling. Keep it people and problems separate. So even if you don't like the person that's separate from the problem, the other person isn't usually just being difficult. Their concerns are real and valid to them, and we need to be able to recognize that pay attention to the interests that are being presented, right? So use your listening skills and listen carefully. I listen first talk. Second, In order to be able to solve a problem effectively, you've got to understand where that other person is coming from. And before you can do that, you have to actually listen to what they have to say. Set out the facts, right? So take the emotion out of it and just set out the facts and agree and established the objective and observable elements that are going to have an impact on the decision. Explore options together. So be open to the idea that 1/3 position may exist, right? You may think it has to be this way. Sallie Mae think it has to be this way, But you guys may be able to come up with an idea together that's completely different from what either one of you originally envisioned as the solution. So make sure that you're open to that. By following those rules, you can keep discussions moving more down a positive path and more constructive. You should follow a conflict resolution process any time that you are in a position of needing to resolve conflict on The reason for that is because if you just kind of wing it so to speak, and you're not following a process than you're probably not going to be effective in dealing with the conflict. If you're involved in the conflict, then you want to emphasize the fact that you're presenting your perception of the problem. So you want to use the active listening skills to make sure that you hear and understand the other person's position and perceptions so you can use the paraphrasing technique. You can use the mirror technique right, which is where you restates specifically what they said. You can summarize what you're hearing. All that will help make sure that they're confirming that you're understanding them correctly. When you're in the midst of that conflict resolution, you want to make sure that you are not using terminology that is going to make the other person defensive. So besides using your active listening skills and making sure that you're interpreting correctly what they're saying, you also want to make sure that you use I statements and study use statements because when you say you this or you that, then you can put somebody on the defensive so use I statements rather than you statements and remember to remain flexible, right and be consider of their ideas and positions as well. I'm going, Teoh let you read the rest of the conflict resolution document on your own. It's a downloadable document in the learning management system, and you'll be able to review this information. I don't want to, you know, just sit and read this information to you. But it is the type of information that really does require that you read it and absorb it. 7. Requirements Session Exercise: okay, we're going to look at a example of a requirement session. So if I were in a live in person training session, then I would have multiple people playing roles in this requirement session. I call it a requirement session play, but because I am doing this as part of a recorded training, I'm going have to play the role of everybody. So I'm going to display on the screen the words basically of what's being said as part of the requirements session so that you can follow along with who the actors are. So let's get started. Some background. First, we have Smith's pools. Smith's pools has been in business for 15 years. They install new polls, repair existing pools in stop pool equipment such as pumps and heaters, and do pool maintenance via warranty and maintenance contracts. The company is both commercial and residential clients. Smith's pools is moving from storing data in an access database to using an Oracle database . Today, the data is manually entered by data entry clerk in the office from the documentation the installers bring back from the field. Project Goal is to convert all data currently stored in the access database to the new Oracle database Going forward. Data will be captured in spreadsheets, in the field and stored on the network. That data will then be auto uploaded into the new database. This is your first project at this company and as the B A. You don't know anything about installing pools or equipment. Your first task is to document current business processes. So why would you do that? It's just data conversion and learning new data. There's no user interface to be concerned with, So why worry about current business processes? The reason for that is because you need to see all of the points where data is collected in the various business processes, right, because we're talking about converting data, we need to understand where that data is coming from. So there are some SMEs in the room from the different areas of the business that you think that you as Thebe air going, need to talk. Teoh. We have Joe, who's been doing residential installs for five years. Mike, who's been doing commercial installs for three years. Sally is an admin and data entry clerk in the office, so she's the one that's entering the data today. in the access database, and John does pool equipment, installs and maintenance for pools. Susan is a sales rep for the company, so there's all your SMEs that you have in the room with you. You need to pick a starting point. So let's assume you start with the residential pool installation process, your inner requirements meeting and us. This means to explain the process from beginning to end for installing a new pool in a single family home location. Since Joe is the one who has been doing the residential installs, he's the one that explains the process, Joe says. Well, I go out to the site on work Day one, and the first thing we dio is get the hole dug in the yard where the pool will be, and then we lay the wire and we also install the pump. On Day two, we go back and pour the concrete. We give it three days for the concrete to set, and then we go back and we grind the concrete smooth and put a finishing coat on the concrete. We cover the pool and let the finishing coat dry for one day. The next day we go back and partially fill the pool and inspect for any leaks. We continue feeling the pool and inspecting until the pools full, and we have verified there no leaks, and that's it. We're done with the installation. So now you've been told the pool installation process, but nothing was mentioned about capturing any data. So let's take a look at this process that we've been given by Joe and start to analyze it. By the way, I just want to mention that I try not to interrupt us me when they're giving me a process. I don't want to break up their train of thought as they're going through it, so I will take down the process. And then I asked my questions after they're done. So that's why I just let Joe talk. I didn't interrupt him. I let him get through his process. But now I have to ask questions because in the process he gave me there was nothing related to data right, which is what my focus is on. So the conversation with Joe should go something like this. Great. Thanks, Joe. Let's back up to the beginning of the process, you said on day one of the install. You go out and dig the hole for the pool, Joe says. That's right, V says. How do you know how big of a hold a Dick Joe says We have paperwork from the main office that tells us that be it says, Do you know how the main office gets that info? Joe says the salesman that sold the pool gives the office that info. Here she does the measurements and based on the pool the buyer chooses. The sales person tells them what type of pulling what size to install. So I just want to point out that I've already missed talking about a requirement before I asked how the main office gets the info. I should've asked Joe how he gets the info from the main office. Right? So I should have been working backwards. How did he get the info? And then how does the office get the info? So now the B is moving on to ask Susan a question, right, Because Susan is that sales person Susan as the sales me for the project. Can you help us out with understanding the sales process? Susan says. Sure, when we go out to a customer site. Make a sale. The customer picks what type of pool they want, What size I measure the yard and find the best place for the pool. I put sticks in each corner with rope around them to rope off the area. The pool will be when it gets installed. I take down the measurements in the pool selection info and turn it into the home office that day or the next day. Thanks, Susan. I have a couple of questions for you. Honey pool shapes are there to choose from, Susan says. Three. How maney Pool sizes. Three. Free shape. So a total of nine pool size and shape options, Susan says. Yes, that's correct. Now we have Mike, our commercials, me that interrupts to say that they have four shapes. They also offer three pull types Olympic regular and baby. They do not offer pool size because size is dictated by the type. So the B says so. Mike, What you're saying is that you really do offer three pool sizes, but in the commercial world, they're called types and status sizes. Is that correct, Mike? Well, yeah, I guess that is correct. Be a OK, great. I'll make note of that now, but let's make sure we get to that in the commercial process when we're discussing the complete process for that later today. So notice how as a b A. I had to bring Mike back around to the fact that we're not talking commercial right now. We're talking residential. So now we moved back to Susan. How do you know to go to that customer site for the sales conversation? Susan says the customer contacts the home office and they send one of us out based on location, which have certain territories we cover. Thanks, Susan. Sally, I'd like to ask you a couple of questions about the office procedures you use when a potential customer calls in. Sally says. Okay, sure. So our first question is, Sally is What do you do when a customer calls in to make a sales appointment? Sally says, I asked for their address and contact information. I enter that info in the access database where we store potential customer data. I then discussed dates and times going pick a date and time that works for them for the sales person, and I enter the appointment date in the customer record. Mike are commercial. Spee interrupts again and says this won't work for commercial. That isn't the way commercial doesn't they only get commercial sales from sales people going out to potential sites? Potential customers? Clients do not call the main office for an appointment. B A. Says. Remember, Mike, we're talking about a solution at this point. We're talking about current business process. So this is referring to how Sally captures information today for the residential process, Mike says. Oh yes, sorry. I was thinking Solution, not current process be says No problem. Mike, let me ask you. Clarifying questions on you brought up the commercial process, even though today we don't have potential customer clients calling him for appointments. Do we need to restrict that? In other words, if a commercial person were to call in, would we say we couldn't help them? Because we don't accept calls from commercial organisations for potential sales? Mike says, Well, no. And probably looks at you like you're a little nutty. We would take their name and number and give it to a sales person for their area so they could call them back the B A says. How would we know who the sales person was for their area? Mike says. We asked for their address. B A says. So it looks like the commercial processes fairly close to the residential in regards to this area. If they happen to call the main office, we would still ask for name, number and address will document more specifics around this when we get into the complete commercial process later today. So you see how the be a one brought Mike back again to the fact that we're doing the residential process, but also made him realize that his process really isn't all that different from the residential process. So he needs to stop maybe thinking so much about how this won't work for them. You don't say that tomb, but you just start pointing things out, right? So the B A says what contact information are you capturing in the access database? And Sally says, complete address, first and last name, at least one phone number, but we can get to numbers like a home number in a cell number, and we asked for an email address. The B A says, Okay, thanks. When you're making the appointment. How do you know what times a sales person has available? Sally says. We use Microsoft Outlook, and I have access to all of the sales people's calendars so I can see when they're available. The Bay says So when you make an appointment, you update the sales person counter and outlook. Sally says Yes, that's correct, the B says. And all of the customer data is entered in the access database along with the appointment time. And Sally agrees that that's correct. So now she goes back to Susan. Susan, let's go back to you for a minute and talk about the sales data you're collecting. When a customer decides to make a purchase, What data isn't your collecting? Susan says, the size and shape of the pool they want and the measurements of the area where the pool will go. I also determine if they're trees that need to be remick. If so, I take down how many trees have to be removed. What size there are small, medium or large, by the way, I just want to point out here that if they don't tell you size options when they tell you that there are sizes then you need to ask when they tell you that they say that they're collecting the size and shape of the pool, and right there, you know that you need to find out what are the different options so that you're able Teoh have that set up within the database and then also the same thing for the trees. They determine if there are any trees that need to be removed and what size they are. So again, that's an indicator to you that you need to be able to collect the size of the trees. So you need to have a place in the database for that. And you need to know what the different options are, which in this case are small, medium and large. The bay says you mentioned turning in the sales data to the home office that day or the next day. How do you turn it in? Do you email it? Take it to the office, Have they get it? Susan says. I go into the office once per day, and I drop off whatever date I have at that point. If I have a late afternoon appointment, I may not take it into the office until the next day, the B A says. And what form is the data in? Do you type it into a document, or do you write it down on some sort of sales form and turn it in on hand written paper? Susan says It's handwritten on a sales form where I have some boxes I can check off for size and shape. And then I have the information about tree removal in a section on the paper for additional notes bases. Okay, thanks, Susan. Sally, Let's go back to you for a minute. Once Susan delivers off, that sales info to the office does that day to come to you and Sally says Yes, the sales forms come to my group so that the data can be entered in the access database. Do you add it to the record that's already created when the customer made the appointment? Or is the sale a new record in the database? Sally says No. We just have the data to the existing customer record. We don't create a new record for the sale, he says. OK, tell me what data you enter for the sale, and Sally says, Well, you know we already have the customer data from when we first initially entered them as a potential customer. So now we enter the pool shape and size. And if any trees need to be removed, all of the other customer data is, you know, already there. Maybe he says, Okay, what happens next in the process? I know at some point Joe is going install the pool, but what happens between the time you enter sales data to the time Joe installs and Sally says, Based on the sales data, I order supplies for the installation, reserve equipment and schedule on install date and the bases where the supplies order from And Sally says our vendors, We order concrete to be delivered from the concrete shop. We order the pool pump from our pumps supplier. We order dump trucks and backhoes from the big equipment rental company. We use all supplies or order from each vendor after I scheduled the installation date. After talking to the customer to get available dates from them and looking at the installers calendar and outlook. So what do we know now? From that, we know that we don't have to be concerned withdrawing supply data in the database, right, because we don't store any supplies. We don't manage inventory because our vendors are doing all of that for us, right? We don't store any actual inventory. And then Sally says after we decide on an install day, I had the info to the installers calendar B A. Says Joe. Let's go back to the install process for a minute. What if they're trees that need to be removed? When does that happen? Because remember, in our process, he didn't tell us that. Joe says we do that first thing on Day one. If we need to remove trees, the B says OK, and after you complete the pool installation, what do you do? Is there any data you collect any paperwork that you turn into the home office? Joe says. Yeah, we record the pool size and shape we installed. If we remove any trees, we say what size and how many. And of course, the date we started the installing the date we completed the install. We take that to the home office and turn it in the Sally's group. The bay says, Okay, Sally, what do you do with the install data you get from Joe says we enter it in the same customer record where we entered the sales data. He says, Okay, let me ask you a question. You are in the pool. Shape and size is part of the sale, and then you entered again Is part of the install. Sally says yes. That's correct. Bases. Okay. Do you enter in different fields than you entered in the sales information, or are you overlaying the data? And she says, No, we enter it in a different one. We have the sale pool size and shape fields and the install pool size and shape feels. Can I ask you why you record that info twice? Isn't it always the same? Sally says, Not necessarily. Sometimes they're issues that come up during the install that cause. And I have to change the size or shape. So we capture both so we know what was ordered and then what was actually installed. Okay, Gotcha. Thanks for explaining. Is there anything else that happens? Is part of the residential install process that we should know about if they don't offer up anything else than say, Okay. I'd like to do a high level re camp of what I've captured for the install process, and you guys can let me know if I've missed anything. Let's take a 15 minute break and then we'll do the recap. So in this case, they get the 15 minute break and you get 15 minutes to do a quick ordering of the tasks and hopefully, then still have enough time for a restroom break for yourself. So now let's the same. That 15 minute break is over, and you've kind of ordered the things that they've told you. So you would say, OK, let's go over this process at a high level and see if I've missed anything. So here's our process. Customer calls Home Office to request a sales appointment. Sales appointment is made and customer data is captured in the access database. Sales person makes a sale and capture sales data that is then hand delivered to the Home Office. Home Office ad sales data to the customer record in the access database. Installation date is scheduled and supplies and equipment are ordered from vendors. Install gets completed. The install data is hand delivered to the Home Office, and the install data is added to the customer record in the excess database. Anything to add? I've got the details here about what data is being captured. But as far as the flow goes, is there anything in the process that we're missing? And of course, at that point, if they tell you that there is, then you'll have those necessary steps. And then here's a few more questions that I would ask right some other things that would come to me that I need to ask. So I would ask when the sale takes place, how does the customer pay? I would also ask, Is there a warranty included with the pool? Right? Because there was originally some talk about warranty, and then I would ask some follow up questions that are related to that. So this is going to spur more discussion. We would continue to ask them some other questions related to that warranty process, so we might ask them if it gets offered to them again later if they don't purchase it the first time. And Sally might say, Well, we do sell from the people calling in about them, but we also call them 120 days before the current warranty is expiring and remind them that they only have 60 days left if they want to purchase an extended warranty, which then would make me ask the question, How do you know who to call and when to call them? And Sally says We get a report from the access database with the warranty expiration dates , and we figure out who needs to be contacted based on when their warranties expiring the B s . How often do you get the report? Sally says. I run the report from Microsoft reporting. I asked her how often she runs it, she says, once a week. And then I asked for a copy of the report. Why? Because if we're going to move to a new database and we're probably gonna have Teoh make some updates to that report So we want to see what it looks like right now and then that might lead you to another question. Right? So the B A says I was planning to ask if there were any reports creative from the sales and installation data. We know we have a report on the warranty data. Are there other reports? And Sally says there's a sales report that runs daily, and it's used by the accounting department to see the total dollar man with sales for each day. And then we would ask Salad to give us a copy of that report as well. And we would then ask if there were other reports. Susan would say There's a report that shows the number of sales by sales person and that all the salespeople get a copy of that report each week. Again, we're gonna ask for a copy of that report. Now, when Sally says we have the sales info to the customer record and that we ad sales person's name, then we have another question, right? So now we're backing up. We said that we got all the data. Now it turns out we don't have all the data by asking more questions. We find out that there's more data, so the B A says okay. So, along with the size and shape of the pool entries during move, you also captured the sales person's name. Sally says Yes, and the sales I D. And I ask, What is the sales idea in the sales person's employee I D bases? OK, great. I'll be sure to add that info as information that we capture for the sale. So see how more conversation brought out a missed requirement to capture the sales person named an I. D. We might ask. Now, are there any other reports that anyone is aware of? No. Okay, we'll move on to the commercial installations. Mike, can you tell us about commercial installation process? Might finally gets his opportunity to speak up at this point. So at this point, you're gonna go through the same thing that you did with the residential install process. Don't ask Mike to just tell you where his process is different from the residential process . This is really important. Most likely since he's commercial. He's not going to know the residential process that well, and you can't expect him to remember everything that we just discussed in the meeting. So just get him to start talking from the beginning and go through the same process for commercial that you did for residential, including those three final questions around payment warranty and reporting. So you see why it was important to document the current business process and to expand on what the SMEs air telling you. If you don't ask questions, you wouldn't have known off the points where data is captured or what specific data needed to be captured once you get the current processes documented. If your project is allowing for upgrades, this would be the time to start asking if there's other data that would be useful to capture That is not being captured today. Now, if you say it to somebody in that way, they're probably gonna say no, there's nothing else I can think of right, because you're basically asking them a yes or no question. So instead, you might say in a different way, something like What other data do you need in order to make the system more effective to you? What other data do you wish you had that you don't have today? So ask them questions. More like that, rather than a closed question of that just gives a yes or no answer. If you're on a project that specifies, it's a conversion on Lee Project and no changes are budgeted for the project. Then you do not want to lead. This means down the path of what they might want to add or change. It's important to make sure that you understand what the scope of the project is so that you don't start talking about things and then later have to tell them. Oh, hey, you know what? I know I asked you about that, but you don't get to have it to make sure that you're not doing that. And then, of course, when you got back to your desk, you're going to document the process flow, maybe in a busy a diagram or whatever tool it is that your company uses. And you would go through the process of reviewing that going back together with the same team and reviewing it with them to make sure that you documented that accurately. So that's an example of how our requirements session can go where you have several different SMEs that you have to talk to as you're working through the process and figuring out what the different steps are that they dio