Create a Use Case | Business Analyst Training

hello my name is theresa bennett and i'm the analyst coach i help businesses improve project success through better business analysis one of the areas i teach about my courses is regarding creating use cases many people that have taken my classes know about them but either they haven't had the opportunity to create them they don't know how to create them or they're just confused by the many different formats that you can do a use case in today i'm going to share one of four formats that i generally cover during training classes this format is simple and it will help you define a use case without spending a ton of time doing it and it's also great for first-timers plus you'll also learn how to use use cases to perform analysis and find potential missing requirements and then i'll also share with you what you should never do when you're creating use cases for the first time or really anytime but I definitely like to share this with people that are doing them for the first time so before we get into that use case I want to talk a minute about what use cases are used for what do you think the purpose of a use case is most people that I ask that question of will tell me that it's basically to document the flow of events that take place when a user performs a certain function if I ask why it's important to document that I usually get a response that it helps the developers to know how to code the solution and the testers to understand how to test it and what results they should be looking for when they're performing that test and that's correct as a matter of fact testers will probably love you if you give them use cases because it makes their job so much easier they can use them to have a clear understanding of how the solution should function what the end result should be and then the cherry on top is that it will also help them more easily create their test scripts so use cases are huge value to testers and of course also to developers however there's one more benefit to use cases that I rarely hear any BA articulate and that's the benefit to them we have a benefit to ourselves of using the use cases the business analyst can use use cases to help them analyze and verify that they have really solid complete requirements and this is huge for you as a BA to be able to find missed requirements while you're still in the analysis phase or or maybe as far as the design phase means that you can fix the problem before it gets too expensive for the project as you get closer to roll out in other words finding missed requirements during coding during testing during implementation or even after you've gone live it's going to get more costly to correct the issue and it will be more detrimental to the project missed requirements are the number one cause for project failure so keeping that in mind I want you to understand that use cases are an analysis tool not just a form of documentation to pass on to the rest of the team even if your organization doesn't include use cases in the formal requirements package that gets handed off to the rest of the team you can still do them for yourself as part of your analysis and this format I'm going to show you is fairly simple and it can be used to do just that so remember as we're going through this that one of the points is that we want to use use cases to do analysis to make sure we're not missing requirements okay let's go ahead and get started so this first page that you're seeing here of the use case is really it's just a title page and our use case that we're going to look at is a use case for a company called ABC office supplies that offers a retirement plan to their employees and this project is about the retirement plan system and people employees getting set up on a retirement plan and getting you know payments deducted from their paycheck to put towards their retirement plan so we're going to walk through one use case that is related to that there would obviously be many use cases and we'll talk about that but but for the purpose of the this video we're going to walk through one particular use case so the next page in the use case template is the revision history which is standard revision history the next page that we have here is a list of who are our primary actors and what use cases are they interacting with so our primary actors we've determined are the employee the plan manager and payroll staff and there may be others and that's okay you can keep adding to it as you find them but for right now we have identified that we have three main primary actors and then the use cases that those actors would be involved in so for the employee they would be the primary actor now I will say that they can they can be a secondary actor of any of these other use cases right that there's a time that an employee might be a secondary actor but what we're determining here in this list is who the primary actor is and then what use cases they are in fact the primary person for in other words the primary user or the primary person doing that function so for the employee they would be the primary actor when to request a retirement plan to change their retirement plan to cancel their retirement plan to view the retirement plan to register for payroll deduction for their plan to unregister for payroll deduction and to manage other payment options then we have the plan manager the plan manager is going to be the primary actor for creating a retirement plan for modifying a retirement plan for deleting a retirement plan and for generating retirement plan reports the payroll staff will be the primary actor who generates a payroll deduction removes a payroll deduction and generates payroll deduction reports so right now that's what we have identified initially as our different use cases and who our primary actors are so we're going to take one of these use cases and walk through what that would look like in creating that use case so the use case that we're going to go through is the register for payroll deductions so that's this number five on here all right so here we are at our use case and I have created the use case already and we're going to walk through these different areas of the use case and talk about them and then look at analyzing this use case and seeing where we might have missing information or other things that we need to think about in regards to this use case that will help us ensure that our requirements are complete so first we have our use case ID and name and it's register for payroll deduction who created it the date that they created it who is the primary actor which we've already determined is the employee and then we have a secondary actor which is the payroll system because they are registering for payroll deductions so the payroll system is going to be getting information from the employee as they're doing this registration so the system itself the payroll system not the retirement system is a secondary actor the description for the use case is employee who registers for the retirement plan one must be registered for payroll deduction so we're saying that if they choose retirement plan one they don't have an option they have to register for payroll deduction the retirement plan will issue a payment request to the payroll system which will deduct the plan costs from the next scheduled employee paid a direct deposit the trigger so what's going to trigger this use case is that the employee requests to register for payroll deduction or employee says yes when retirement plan one asks if he wants to register we are precondition is that the employee is logged into the retirement plan system which we're going to be calling our PS through the rest of the use case our post condition in other words where we will be at the end of the use case is that the employee is registered for payroll deduction and you might say in there for retirement plan one since we're saying that this is about retirement plan one next we have our normal flow so what is going to be the kind of normal process the happy path process whatever you might call it you've probably heard it return referred to as the normal flow of events the happy path maybe the main flow of events there's different different wordings for it but it is the normal flow the average flow the thing that's going to happen the most right so the normal flow is that they're going to register for payroll deduction that's what they're going to do and here are the steps that they're going to take to do it the employee selects retirement plan one the employee defines a dollar amount to contribute to retirement plan one the retirement plan system asks the payroll system if the employee is eligible to register for payroll deduction the payroll system confirms that the employee is eligible to register for payroll deduction the retirement plan system asks employee to confirm his desire to register for payroll deduction so we've got some sort of confirmation right that the that the person is going to have to take to say yes I really do want to do this if so RPS asks the payroll system to establish the payroll deduction for the employee the payroll system confirms that payroll deduction is established and the RPS system informs the employee that the payroll deduction is established and the amount of the deduction based on the retirement plan percentage or dollar amount which would be what the employee had selected as his percentage or dollar amount then we say that we don't have any alternative flows there isn't any any other path that they can go down but we do have some exception flows so exception flows are more related to error handling things that can go wrong right so with the exceptions we've identified two flows one is that the employee is not eligible for payroll deduction because remember we have here that the payroll system has to confirm that the employee is eligible and then our second one is that the employee is already enrolled for paid payroll deduction for this retirement plan so they don't need to re-enroll for payroll deduction because they already have it so those are two exception flows that we've identified we have also said that this is a high priority use case and then we have a place where we can say what business rules apply to it so for example if you have all of your business rules may be listed in an Excel spreadsheet and they're all numbered this is the place where you can say which business rules apply to which use case so you're saying here to the developer that they need to be concerned with business rules 86 88 and 74 as far as this use case goes then we have some other information and that's really just a place for a catch all right anything else that might need to be identified that there just wasn't a place on the forum for so in this case we said that we should expect high frequency of executing this use case within the first two weeks after the system is released because we've done some analysis and we've determined that retirement plan one is the most popular reach is going to be the most popular retirement plan and that there'll be a lot of people signing up for that and therefore signing up for payroll deduction because remember they're required to do that for this retirement plan so that's just an added note for the development team to understand as far as when they start thinking about things like infrastructure and the system availability and the resources they want to make sure that they have enough system resources available for the amount of people that are going to be using the system at any given time right so this is some additional information that can help them with that so there's our use case now this seems pretty pretty clear right it was fairly simple to write we have a standard set of steps we're not saying how the system is going to do things right so we're saying that the system for example on step 5 the RPS system asks the employee to confirm his desire to register we're not saying how because we may not know that yet right especially because it's a new system we also say that the payroll system confirms that the payroll deduction is established and that the retirement plan system informs the employee that payroll deduction is established so there are things that are happening to make confirmations and to inform the employee of things but we're not saying how that's happening maybe they're going to be informed by an email maybe there's going to be a popup message on the screen maybe there's just going to be a message displayed at the top of the screen it's we're not determining how it's going to happen only that it must happen that they must be informed right so now I want us to take a look at this a little bit more closely and see where we might have some missing information or some questions or some other things that might need to be - thought about so let's go back up to our description for our use case so we have in the description that an employee who registers for the retirement plan one must be registered for payroll deduction the retirement plan will issue a payment request of the payroll system which will deduct the plan costs from the next scheduled employee payday direct deposit so we're saying that they must take payroll deduction if they are using retirement plan one and yet we're saying in our trigger that the employee requests to register for payroll deduction or employee says yes when retirement plan one asks if he wants to register now I would argue why would we ask if they want to register if they're required to register right so we may have a conflict there in our requirements because we should not ask them if they want to if they're required to right make sense so that might be an area that we need to look at and think about and say hey is this really is this really the way it should be or do we need to rethink this a little bit the other thing that I want to point out about our description is that we say that at the deduction that the plan costs will be deducted from the next scheduled employee payday direct deposit not every employee may not have direct deposit right some people may get paper checks still so unless the company requires every employee to always use direct deposit we can't say only direct deposit here because there may be other other forms that the employees getting paid in like a paper paycheck so unless the company does that we can't say that here so it's something that we would want to check maybe the company does require that everybody gets direct deposit and then in that case this description is fine but the point is is that we don't want to make an assumption about that we want to verify it right the other thing that I want to point out is again in the trigger so if we look at the trigger it says employee requests to register for payroll deduction or employee says yes when retirement plan one asks if he wants to so we've already talked about the one problem related to the fact that we're saying that they have to do it for retirement plan one but here we're saying it's a kind of either-or thing the other thing I want to point out about that or statement is that anytime you see something like that where it says or you want to take a step back for a moment and say does this does this really belong here because is there really and truly two triggers or is there only one trigger for this particular use case so even if you didn't catch it in the other way where we were looking at the fact that it's retirement plan one says you must be registered for payroll deduction and then this here says kind of that you you can say you want to even if you don't catch it there this or statement should help you catch it as well right so there's a couple of different indicators that tell you that there's more that needs to be thought about here the next thing that I want to point out is another version of the or which is down here we have a if so so when something says if so to me then my question it would be well if not right we're saying if it's this way than this so could it be another way if it could be another way then we actually do have an alternate flow right so we're saying here that the RPS system asks the employee to confirm his desire to register for payroll deduction we've already determined that this might be a problem because we're saying here that they're required to do payroll deduction right but assuming they weren't required to do payroll deduction and we're saying that we're asking them and they're saying if so then we would establish the deduction for the employee well what if the employee says you know what no I don't actually desire to do that I've changed my mind I don't want to do it right so if they don't want to do payroll deduction then what so that then what would actually be an alternate flow so we do in fact have it have a possible alternate flow right in in the case where they would not be required to register for payroll deduction right so that's something else to think about as well now let's talk about our exception flows so we've already identified that we have two exceptions here right that we have the possibility of error if the employee is not eligible for payroll deductions so they've said they want payroll deduction they've chosen a plan that requires them to have payroll deduction but for some reason they're not eligible for payroll deduction so we've identified the flow but we haven't actually put any steps in here so when you have an exception flow you would need to have steps for it just like you have steps here so you could just simply you could take this and copy it down here just to have a a step number in here and you would renumber so I'm just going to go here and say my numbering is I just want to change this to be number one there we go restart numbering alright so now we're saying that for an employee is not eligible for payroll deduction here's the first thing that's going to happen maybe there we'll be an error message displayed on the screen right so we would say but we don't know for sure how that's going to be right so we're going to again be a little bit vague and just say that they're notified so employee is notified they are not eligible for payroll deduction so how that notification takes place again is determined in the in the coding part of the process right design and coding so so we're just saying that the employee has to be notified that they're not eligible for payroll deduction and if there are any other steps you would continue and put them there and then you would do the same thing for this exception flow you would have to list any steps underneath it that would take place for that exception right so this is this is just other things that have to be thought about so when you first first create your use case and you're first getting your thoughts down you might think I did a great use case right this is this is really clear and it has all of the information and you've got all the sections filled out and it on the surface looks like a good use case but when you start doing some analysis of it you find that you may have some things that you have put in here that causes the a conflict or you may find that you have some missing requirements or some things that might require you to split it up a little bit more and have a couple of different use cases so I hope this helps you to see how you can use a use case to do analysis so now that we've walked through creating the use case you should be able to see how beneficial it is not just for documenting a functional flow for developers and testers but also to do that analysis right you see how important that is I said I would share with you the one thing that you should never do when creating use cases for the first time and I'm going to do that now but first I want to show you real quick that that you would just continue using this for Matt it for your other use cases so you know how at the beginning of this we had our primary actors in all of our use cases listed here after you created this use case you would just use that scene template which is here and you would create your other use cases and you can just keep doing a simple copy and paste of the template and adding on to it so that you have one document that you have all of your use cases in so you can just continue doing that until you have all of your use cases created so I just wanted to share that with you so that you would understand how to continue doing that for the rest of your use cases so now let's go back to the one thing that you should never do when you're creating use cases for the first time don't get bogged down in analysis paralysis and as I mentioned before this isn't just when you're creating them for the first time although when you're new to it you know it takes some time to get to get used to what you're doing so it seems to be something that happens more frequently for people that are just starting out with creating their use cases so many times I've seen bas get stuck and continue down that kind of what-if path well what if this what if that what if that and they get so far down it that they're no longer even focused on what the original use case was about so we have to remember to keep our eye on what our use case is really about I can't stress this enough that you need to stay within the scope of the use case just like it's so important to stay within the scope of a project when you're working on a use case it's important to stay within the scope of that use case continue to go back to the title of the use case right what is it that we're doing and make sure that any alternate flows and exception flows truly are related to that title in other words they're directly connected to what you're accomplishing when you're performing this you know function this task whatever it is as I mentioned before this is one of four formats that I typically cover in my training classes if you're interested in learning more about use cases along with perfecting your requirements elicitation skills communication skills and learning how to use many other forms of documentation for analysis and for creating your requirements package then I invite you to register for the next mastering business analysis fundamentals course the fundamentals course is a 12-week training program that's endorsed by the IEEE IBA so besides testing and certification straight from the analyst coach you'll also receive a 21 professional development units or continuing development units from the IBA that can be used in the education requirements to sit for one of their a IBA exams or as credits for recertification if you already hold certification from the AIBA so you can go to the link below this video to get more information on that training program and get registered for our next upcoming class

Channel: Effortless Business Analysis

Views: 45,036

Rating: 4.878788 out of 5

Keywords: business analyst training, create use cases, how to create use cases

Id: BqbK5N2xQDE

Length: 25min 46sec (1546 seconds)

Published: Mon Sep 12 2016