A use case is a powerful tool to both analyze and communication the software requirements.
- If you have a business background, a use case will help you define what the software needs to do, even if you don’t have much (or any) technology/coding knowledge.
- As a technical professional, a use case will help you communicate about what the software does using less “tech speak”.
In this use case tutorial, you’ll learn exactly how to apply use cases in your analytical work. I’ll also share favorite use case template, with detailed annotations and descriptions so you know exactly what goes into each section.
>> Click here to download the use case template <<
For those who like to read instead of watch, here’s the full text of the video:
Hi, I’m Laura Brandenburg from Bridging the Gap, and today we’re going to talk about how to write a use case. I’m super excited because these cases are my absolute favorite analytical technique. Hopefully, as I share this tutorial of how to actually put one together, you start to see why and are encouraged to start experimenting with them, as well, or maybe have a takeaway if you’ve done them before about you can make them a little bit better.
Why Write a Use Case
First of all, why would you write a use case? What is this for? Why do you need to do it? As a businessperson, you might be concerned about how to actually communicate the technical requirements or the software requirements to a—I don’t even know what those are, first of all. How do I communicate with my software developers to make sure I get what I want out of the software system?
That’s one of the great tools or 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, build stakeholder engagement, 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.
What is a Use Case?
What is a use case? How does it solve these problems for us as analysts, as technical people, as business users?
- A use case is a textual description that captures the interaction between a user and a system to achieve a specific goal.
This is really important. It’s the interaction between the user and a software system.
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.
Use Case Examples
Some example use cases include:
- Purchase Course
- Watch Video
- Subscribe to Free Training
- Download Template
Use cases represent 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.
The details of the use case include 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 + Step-by-Step Tutorial
What is included in a use case? I’m going to go through the common sections that are in a very traditional use case template.
You can take notes if you want, but you can also download our template.
It’s one of the thirteen templates we include with our Business Analyst Template Toolkit.
How to Name a Use Case
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?
Writing a Brief Description for a Use Case
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.
Get clear on your: Starts when / Ends when.
Big tip.
Define Use Case Actors
The 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.
Define Preconditions
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?
Write the Basic Flow of the Use Case
Then, you get into the Basic Flow, and I like to 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 business analysis 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.
Instead, explore data modeling techniques such as a data dictionary, system context diagram, and data map to be sure you have a full understanding of the data requirements.
The use case is not a technical specification. It’s not a system specification.
You want to the requirements, or what would go into a functional specification. This involves 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.
Break out Alternate and Exception Flows in a Use Case
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. These are the alternate flows.
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.
Finally, decide on 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 Do Not Require Technical Knowledge
One thing I want to cover—and I’ve alluded to this as I described a use case, but we still get a lot of questions about it—is: doesn’t that use case require technical knowledge? “What do I do if I don’t know the tech? How do I communicate with developers, and how do I do things like requirements? It seems like I’ve got to know all this technology, and I have to know the business analysis.”
Really, you’ve got to think of the use case as a tool that allows you to communicate about what the technology needs to do without actually knowing how it’s built because you’re not doing all those “Pong, pong, pong, pongs.” You’re not seeing all of the different pieces of the tech that happen behind the scenes.
You’re saying, “As a user, what is my observable functionality? What do I see the system doing for me?” We should be able to be very clear about that as a business analyst. That’s part of the clarity we bring to the table.
Use Cases Help You Ask Smart Questions
That’s why use cases are such a great tool; they help us ask really, really smart questions that uncover gaps in thinking and understanding and requirements.
As an example, say we’re talking about “Purchase Course.” We have a step for the user choosing a course, a step for the system presenting the order form. Then, the user fills in the order form; the user submits the order form, the shopping cart checks credit card details. I’m probably missing a few things here, but you’re going to have this back-and-forth between the user and the system.
If you watched my business process video, you know that there’s a course participant registration that happens automatically. How does that actually happen? What’s the output that enables that to happen? Behind the scenes, there’s a—I don’t know the technical term—but there’s a data ping, likely specified by a data map, that’s sending that credit card information. That would be really important, the user information from one system to the other, so we can automate that setup and get people their course registration details as quickly as possible.
Interested in learning more about a business process? Here’s the full video:
As you detail out the use case to fulfill this business process, you would see the gap. Like, “Well, wait. We see this thing happening here. We have this thing happening here. We don’t actually know what the steps are to get from point A to point B. It’s not clear to me.” We’ve had people ask that question that are new to our business. “How does that actually happen?”
They’re using their use case thinking to think it through and to find the gap.
It’s way easier when you’re actually writing the use case and getting all to the steps to where the last step is that the user receives their course registration email. You’re like, “Wait a minute. That’s not coming from the shopping cart. Where does it come from, and how does it get there?” That’s the kind of step-by-step thinking that you want to be doing in your use cases and that you want to bring to the table. It really helps you understand the technology without having to build the technology.
I hope that is both a tutorial on how to create a use case and a lesson in why they’re so fun and important, and why I love them so much, and how they are such a powerful analytical tool for you to be using to really get clear on the requirements to bridge the gap between your business and technology stakeholders, bring everyone truly on the same page about what the software needs to do using a communication tool and an analytical tool that helps you uncover gaps and communicate with people who are both technical and non-technical.
Download Your Use Case Template Today
Thank you for watching.
Again, download that use case template here.
This will give you a great starting point to writing your first or next use case, and save you so much time gettings tarted. It even has instructional text to guide you ever step of the way.
As always, we build our profession one business analyst at a time. Success starts with you.
Thank you for being here. Thank you for watching. I’m Laura Brandenburg from Bridging the Gap, and we’ll help you start your business analyst career. Happy modeling!
Use Cases Are One Way to Analyze the Functional Requirements
Discover how use cases are just one type of functional requirements specification that you can use on a software project, and how you can leverage use case thinking skills even if you are creating other types of requirements documentation.
Use Cases vs. User Stories
Another frequently asked question is what’s the difference between use cases and user stories – be sure to check out this video next to understand why even if you are writing user stories for your software development team, you’ll still benefit from analyzing your requirements using use case thinking.