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.
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
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 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
What is a use case?
How does it solve these problems for us as analysts, as technical people, as business
It’s a textual description that captures the user system interaction.
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.
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.
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
This is what allows us to get at the software requirements.
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,
and you can get it at Bridging-the-Gap/UC Template.
It’s super easy to download for you.
There should also be a link below this video.
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
You want to know: what is the action that user is taking that’s going to be described
in the 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.
“Starts when,” “Ends when.”
The actor: who are the users, or the roles, or the types of actors that might use the
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?
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.
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.
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.
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
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 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,
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
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
“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
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.
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
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 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.
That is the kind of thing where 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.
That’s my spiel for today.
Thank you for watching.
Again, download that use case template at http://bridging-the-gap.com/uctemplate.
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