Let's take a look at the recommended steps to business analysis. The executive sponsor and business people are going to put together an initial project request you may be involved during or after this step they may use a business analyst to help with that or they may not you may not come in yet at that point of the project. The business analyst is going to review the available documentation and begin by asking high level questions once you are brought into the project, you as the business analyst and the project manager are going to work with stakeholders to document the scope of the project. So that scope usually includes objectives statement of purpose, problem statement risks and issues. You may find it useful also to do a contact level data flow diagram at this point to identify external agents and data flows. So again, this may be an area that you are brought into and that you assist with or it may be an area that you are not brought in at.

Sometimes I've worked on some projects and in some organizations where they did not bring a business analyst onto the project until after the scope had already been identified, created, reviewed, signed off, on and approved. And then I've worked at other organizations where the VA was part of that. So it just depends on how your organization operates and how they have that set up. And then of course, the fourth step would be meeting with the stakeholders to verify and validate the project scope and the initial documentation just to make sure we're on the right track. We all understand what the scope of this project is before we move forward, and start doing any analysis and gathering of requirements. So the fifth step would be planning the analysis work.

So now that you know what's involved in the project, you can plan how you're going to go about eliciting and analyzing the requirements and then the next step. would be to actually do that right to go ahead and elicit and analyze the detailed requirements, you would also want to identify and document core business components. So part of your requirements should include data processes, business rules, and external agents. And then you should also be creating a comprehensive glossary of terms. You never want to assume that everyone reading your documentation is familiar with all the terminology that's being used. So always make sure that you're including a glossary of terms.

You also next want to be sure that you elicit requirements. As I said before, around data and process. You don't want to just focus on processes and not get requirements related to data. So I want you to have a list here of some things that fall under both of those categories. So under data you would of course, identify pieces of data. pieces of data can be like things like name, Social Security, Number dollar amounts any piece of data, right?

You would group them into entities attributes and relationships. You may create diagrams like Entity Relationship diagrams or document the data in tables. You're going to review that with stakeholders, you're going to review it with developers. For processes, you'll identify a list of processes, right things that processes that the business is doing. To structure and organize those in a decomposition diagram. You'll review those with stakeholders, you should focus on lowest level processes, right, not the higher level because you want to get down to the detail.

And then textually describe each process using either a process template or use case scenarios will work for that. You can diagram processes even using a workflow diagram rather than a use case. If you want to use that type of format. You're going to review those with stakeholders and also with developers as well. The 10th step would be double checking for Miss requirements by linking data requirements to process requirements. We'll be talking about some other things related to how you ensure that you haven't missed requirements.

But this is one step in the process that you want to make sure that you're doing is linking those data requirements to the process requirements. Once the business requirements are complete, you're going to work with the business stakeholders and the technical team to design a solution. I want you to keep in mind that it is not your job to design the solution. But you do need to support the technical team and be available to them to answer questions that they're going to have related to those business requirements. Do you remember Pac Man a game I think that was back in the 80s? You had to eat all the little circles in the maze and it didn't matter in which order you did it.

Eliciting requirements is really a similar concept to that. You go to one area, you grab everything you can as far as the requirements go, you're going to miss a few. Then you go to another area, you grab all you can, you're gonna miss a few, then you backtrack, then you go to another area until you find that you're retracing your steps. And you really can't find any more requirements. Or your time is up. I always like to say that or your time is up because I feel like requirements elicitation can almost go on forever.

And I feel the same way about testing, right? It's not feasible to say that we're going to do it forever, right? We'd never get a completed project. So there does have to be, you know, a stopping point in time where we say it's good enough. But good enough should be excellent requirements, right? So you don't want to say oh, well, I ran out of time.

So I just didn't get all the requirements. That's not an excuse to not get all the requirements, right. So don't use time as a reason why you weren't able to complete requirements. If there's going to be something missed, it should be something known and that should be identified as a risk up front. But really, what you should be doing is that kind of a contract. menual iterative type of process as you're going through and gathering and eliciting requirements, and then documenting them where you are, you know, going back, you're getting more.

And basically, you're getting to the point where you feel really comfortable that there's minimal risk that you're missing requirements. Now let's talk about defining requirements using diagrams. All of the diagrams that I'm showing you here, can be used during elicitation, and analysis. And again, we're going to talk more about this in a bit. But diagrams can help you verify that your requirements are complete. using them during elicitation actually helps you to define complete requirements.

So if you don't wait until after you have all the requirements, to start creating documentation, and you actually use the tools that you have the different types of diagrams and the different types of templates. As you're gathering the requirements. It's going to help you make sure that you're getting complete requirements and there'll be less going back to For more, because you're figuring it out as you go along. During project scope time, you can use context level data flow diagrams, which are meant to be an overview, the diagram is not detailed, but it's a great way to help identify the scope of the project. When you're looking at business data, you can use Entity Relationship diagrams to help you figure that out. And data definitions can be defined using an attribute template.

When you're looking at business processes, decomposition diagrams are great to use to help you identify all of the business processes. And then you can use a process template to help make sure that you're identifying all of the process definitions, and then all of that is really going to feed into your business rules, which we'll talk about more later as well.