Take a look at when requirements elicitation is complete. The project scope is your guiding light when you're looking for completeness. So did you cover every request in the scope? Did you make sure that you're not including anything that is either designated specifically as out of scope or not designated as in scope. The requirements are going to drive all downstream analysis, design, development and testing activities. So for that reason, you need to make sure that you're doing the part of the process where you are analyzing for completeness, right.

So besides analyzing that your requirements themselves are complete. you're analyzing that you've actually covered everything that's included in the scope of the project, and that you're not including things that should not be included in the project. You want to analyze the data. So what I'm saying by analyze the data, I'm not referring to data fields specifically related to requirements. I'm talking about the data that you have received as part of eliciting your requirements. So analysis as part of what you do to ensure your requirements are complete.

You have to think of yourself as a knowledge worker, right part of your job really just involves thinking and analyzing it's sometimes you're not always doing right. So don't get caught up in so much of that doing that you forget to do the analysis piece. Sometimes there is just thought that needs to be put into things you need to review things you need to think about them. You need to say, Is there anywhere here with somebody could assume this is something different? Is there a piece of data that's missing from here? Is there a process I didn't document or identify?

You need to just go through some thought processes related to identifying if your requirements are complete or not. So let's look at some analysis tech There's a lot of tools that you can use and thought processes to complete analysis that I want to talk about what some of those are. So one of the things that I want to make sure that you are thinking about is assumptions. Did you make any assumptions? Is there anything that someone could say is different, right? That it could be this or it could be that because if so then your requirements aren't clear enough, you don't have all the detail there.

You're leaving things open for people to assume it's one way and then another person could assume another way, right. So make sure you're looking at it from that assumptions perspective. So you can use process flows to determine if anything has been missed in the requirements. You may not know the system flow yet, but you should be able to do a process flow that is not related to a system to help you figure out if you've missed any requirements. So I'm going to give you an example of what I mean by not knowing what the system's low is. So for example, if you were defining the process for putting on tying a pair of shoes, you wouldn't need to know the brand of the shoes or anything about what they look like only that they are shoes with laces.

If you were defining requirements for a pair of tennis shoes, you could lay out the process for putting on and lacing the shoes to help check if you got all of the requirements. If for example, you had in the process that laces needed to be criss crossed up the chute to give support to hold the shoe on, you might realize that you missed requirements to have the ability to do that. It doesn't matter what the brand is the color the style of the shoe, you can still lay out that process without knowing that sometimes you'll do documentation that nobody else ever sees. And that's okay. It's about using the tools that are available to you to do that analysis piece of the process. So if you're laying out a process flow, or you're laying out a use case or something to verify whether or not you've got all the information, even though your organization may say hey, we don't do use cases here.

It doesn't matter if they To use cases, you don't have to include them in the final requirements package that's getting signed off on. But you may use use cases as part of your analysis. It's about using the tools that you have available to you. In order to be able to verify if you've got complete and accurate requirements, you can use data flow diagrams to ensure that you've captured all of the requirements related to data. This is going to help you ensure that you've covered every place that data is coming from or being sent to if your application is doing either of those things. And you always need to verify if your changes are going to affect that other system.

And then bring those other systems into the conversation to define what that will look like for them. And they may even need to have their own project that supports the changes that you're making. But they're not going to know that if they don't know about the project and don't know that your project is affecting them. So you always want to make sure that you're identifying who the people are for those systems and having those conversations to find out if they are impacted. Entity Relationship diagrams can help you define relationships between entities and can also help you define business rules. So again, this tool can help you ensure that you've captured all the requirements.

And I just want to be clear here because business rules are in fact part of requirements. They can be in their own document, they can be included in the details for each of the requirements. But however you do it, you are in fact defining requirements when you're defining what the business rules are. screen and report mockups can also help ensure that you've identified all of the requirements. You might have login requirements, and you have, let's say requirements around password criteria. But maybe you forgot to add details related to the login field.

And when you're identifying business rules or you're doing a screen mock up, it may help you remember that you didn't define anything that's related to the login name parameters, which then brings me to the next point that I want to make error and exception Handling, need to make sure that you're defining requirements for how to handle errors and exceptions. And that includes both system errors and user errors, it's going to happen. And we need to know how those things should be handled. And use cases are a great way of ensuring that you're defining those requirements, right? Because you can do alternate flows for what happens if there's an error with the system or what happens if the user does something that wasn't expected or that they shouldn't do? I don't feel like there's really a standard process for analysis, I would just like to say that there isn't some magical formula that you use.

It's really based on your project. And it can be vary depending on what information you've collected so far, and what gaps you still have, and what you personally need to do in order to ensure that you have detailed requirements. But using some of these tools can help you and you should consider them as part of your analysis process at the end of the lesson. cetacean activities, you as the business analyst should be leading the effort to review and refine the requirements, you should conduct reviews with both the business side of the team and the technical team. It can be one meeting, it can be separate meetings. But however you're going to do it, you need to make sure that you're reviewing the requirements with both of them, so that they can both say that they feel like the requirements are complete, or if they see any holes in anything, that would be the time to identify that.

So those refuse should be used to validate that the requirements are clear, consistent, complete and validated. So we want to know that the requirements can be linked to an upstream customer or sponsor document, we want to know it's the scope, maybe there's requirements related to organizational goals, whatever it is that that's related to, we want to be able to take it back to that right. And then of course, making sure that they're complete, consistent and clear. We've been talking about throughout the course. So those are the things that you're looking for when you're valid. dating or complete