User Case is one of the great tools and reasons to use a use case is that they are really a connection point. Both business and technical users should be able to really understand them and provide feedback on them. As business analysts, we use them as a communication tool, really, to literally bridge that gap or really connect people together, in terms of a common technique, common language about what the software will do. 

 

As a technical person, you might be looking for a way to communicate with your business stakeholders and get rid of that “text” speak, less about how the system does it and more about what the system does. That really is going to help speed up the communication and clarify and make sure you’re building what the business actually needs and wants when you sit down and work on the code. 

 

It’s different than a business process, which might capture all the things that that user would do to achieve a bigger picture goal or outcome in the organization. Use case is very specific and dialed in, in terms of how that user actually interacts with that software system to achieve a goal. This is a more granular goal.

So, it might be “Purchase Course,” “Watch Video.” You’re executing a use case right now. “Subscribe to Free Training.” These are some of the ones we have for Bridging the Gap. “Download Template.” Things like that. Very specific and concrete things that a user can do with the software system, and it captures all the ways that that user and system can interact. All the exceptions and variations and what happens if you go to purchase a course, and your email address is invalid or your credit card’s not valid or something like that. All those variations of what can go wrong in variant paths in the scope of the system only. This is what allows us to get at the software requirements. 

 

Use Case Template: 

 

Use Case Title / Name:

You want to start with a name, and just like with a business process, you want that name to be verb-noun. So, “Purchase Course,” “Subscribe to Free Training,” not just “The Free Training Use Case.” You want to know: what is the action that user is taking that’s going to be described in the use case?  

 

Use Case Description:

 

Next is a brief description, and one of the things I really like to include in my brief description is a sentence that really gets clear about the scope. “This use case starts when…” and “This use case ends when…” because what happens when you start to write all those steps is you find all these variations. Then, all of a sudden, your use case is all over the place, and you’re like, “Laura, this isn’t a sequence of steps. It’s a web.” It’s usually because you’re going off track, or exploring alternates in too much detail, or really are just not staying within the scope of the steps that need to happen for the specific goal of that use case. “Starts when,” “Ends when.” Big tip. 

 

Actors:

Who are the users, or the roles, or the types of actors that might use the system? It’s not job title; it’s actor. Multiple people can fill that role with the system. It’s what the system can identify about you. Are you a purchaser? Are you an administrator? Are you a reporter? Something like that. 

 

Preconditions:

 

What must be true before the use case starts? This, again, is a very system-level. What can the system know to be true before the use case starts?

 

Basic Flow:

 

Think of the basic flow like ping pong. The user does one thing, the system does another thing. The user does one thing, the system does another thing. “Ping pong, ping pong.” It’s not always that clear-cut. Sometimes it’s like, “Ping, ping, pong, pong, pong. Ping pong.” It doesn’t have to be just one back-and-forth like that, but thinking about it as ping pong really helps make sure that you’re getting that user-system interaction. What we see very commonly among our course participants is that those with more of a business background are like, “Ping, ping, ping. User, user, user, user, user, user.” System does one thing. Really, the system is doing things all along, they’re just not seeing it because they’re not used to looking for what the system does to support them, and because they’re the business user, they’re thinking about all the things that are happening in the business. So, they’re not seeing. That’s part of the way that the use case is such a powerful tool. It really dials you into, as a businessperson, what the system is doing to support you and what those requirements actually are of the system that you might not see otherwise. It becomes very important when you’re just like the, “Ping, ping, ping, ping. User, user, user, user.” 

On the flip side, a more technical person will often say, “The user does one thing in a ‘Boom, boom, boom, boom.’” It’s like, “Pong, pong, pong, pong, pong.” It’s all the technical details of what the system is doing, which is way more depth than what the business actually cares about because you just lose them with “text” speak of, “Oh, the system executes this sort of procedure, and updates this data, and sends this to this API, and updates the web form,” and all this technical detail. That’s not what goes into the use case. It’s not a technical specification. It’s not a system specification. You want the requirements. What’s the observable piece that the system, that the user can see the system doing and experience the system doing? Not how the system is doing all that. I realize there’s a lot of magic and juicy stuff that happens there; it doesn’t go in your use case. Ping pong. Sometimes, “Ping, ping, pong,” but not all one or all the other. Otherwise, you really have a different kind of document, not a use case.

 

Alternate Flows:

 

Then, alternate flows and exception flows. These are the variant paths. Sometimes—Let’s just see an example. For “Watch Video,” you might have “Pause.” You can pause the video. You can end the video (please don’t do that!). You can do different things. You can “Like” the video. You might have—Sometimes it might not fit within the scope of that use case but all the different things you can do. An exception flow might be: what happens if your Internet connection cuts out and the stream ends? How does that get presented to the user? Things that go wrong and keep people from, stopping reaching the end goal or the end of the use case. 

 

Post-conditions:

 

Post-conditions are what are true after the use case is over. If there’s any information that needs to be stored or outputs that need to be generated, those all need to have steps in your use case, and you can capture them as post-conditions, as well. Again, you don’t have to remember all of these details. Be sure to download our use case template, which will give you an annotated template, all these sections, a quick synopsis of what’s included. Again, that’s just one of the thirteen templates that we include in our Business Analyst Template Toolkit. 

 

 

Use Cases Help You Ask Smart Questions

That’s why use cases are such a great tool; they help us ask really smart questions that uncover gaps in thinking and understanding and requirements. 

 

 

​