A PM’s Guide to Use Cases Part 1: What is a Use Case and Why Should PMs Care?

Originally published in PM Times on May 22, 2015.

Use case models have been around for decades. Long after Information Engineering was all the rage and through object-oriented analysis and design they hung around. They threatened to disappear when Agile methods gained popularity, but here they are–discussed, dissected, and the subject of many blogs. Aren’t they “old school” and not needed in today’s Agile world?

They are still needed and are, in our opinion, among the most useful tools/techniques practitioners have in their business analysis toolkit. Without going into the historyⁱ, use case models, both the diagram and the narrative text, provide a structured way to think about our work, work that we’ve always had to do in software development, but which has been simplified with use case models.

Although project managers who are not business analysis practitioners do not need to create use cases, they should know what use cases are, be familiar with key terms, and understand why they are important to getting the requirements right.

This series of articles will focus on these key points.

WHY USE CASES?

Use cases help our projects in two very different ways. Use case diagrams are immeasurably helpful in understanding a project’s scope and the use case narrative is invaluable for getting the detail needed to build the product or service. And although used primarily in software development, use cases are also useful when creating processes and developing equipment. They work wherever there is an interaction between people and what those people need to do.

TERMS, TERMS, AND MORE TERMS

A rose by another name, as we know, would probably smell the same, and use cases if called something else would serve the same purpose. Use cases are so named because they describe how people want to use their software or equipment.

However, it does sound a bit technical. It sounds like the kind of technique that a project manager could easily leave in the hands of more technical resources and forget about. And that would be too bad, because use cases help projects in many ways, as we’ll describe below.

Years ago, Elizabeth gave a presentation on use cases. She remembers saying that despite how useful they were, if it had been up to her, she would have called them something else, something less technical and more accessible to business stakeholders. She remembers one upset participant who said that it was a good thing no one listened to her! That’s probably true, but it still seems to us that use case terms are a bit arcane for most PMs and business stakeholders. So here are the key terms explained:

Let’s begin with a working definition of what a use case is. We like to think of it as the conversation back and forth between actors and a system. Which is all well and good if we know what actors are and what the system is. Let us explain.

• The system contains all the work we want to do on the project. We like to use the microwave as an example. As a microwave user when I heat up leftovers, for example, I am outside or external to what the microwave does, so I am not part of the systemⁱⁱ. I am an actor who interacts with the microwave system, telling it what I want done and getting heated leftovers as a result. Which brings us to actors.

• Actors are always outside the system and always interact directly with the system. They can initiate a use case, provide input to it, and/or receive outputs from it. Actors can be people, other systems, time triggers, or event triggers.

Let’s practice on a couple of examples. If actors are always external to the system and always interact directly with the system, in the following two examples, am I an actor?

1. Example 1. The system in this first example is an automated banking deposit application. I walk by a bank lobby on my way to work. One day I decide to take a cheque to deposit it in the bank. I stand in line with the deposit, and finally when it’s my turn I hand it to a teller who enters the transaction into the automated deposit system. Am I an actor?ⁱⁱⁱ
2. Example 2. The next time I have a check to deposit I don’t want to stand in line, or even go to an ATM to deposit the check. Instead I scan the check using my bank’s app on my smart phone. Am I an actor?

WHY PMS SHOULD CARE ABOUT USE CASE DIAGRAMS

Below is an example of a use case diagram. We will explain all the pieces in our next article.

Use case diagrams are one of the several techniques we use to help with both the project and product scope. We find that the use case diagram structures our thinking and helps us remember functionality we might otherwise have forgotten. The use case diagram has some key benefits:

1. It’s an easy way to engage business stakeholders. If we explain use cases using business terms, they can visualize what their system will include, helping get a big picture of the scope.
2. Because it’s a useful visual, our stakeholders are more inclined to be specific about their desired featured and functionality.
3. Use cases are almost universally appreciated by the development team, so that there is less time spent translating the business requirements into technical specifications.
4. Use cases become test cases with acceptance criteria. Whether the team prefers the “Given-When-Then format or the components of a use case, as odd as it sounds, the result is the same.

Stay tuned for future articles on use cases. We will show examples of use case diagrams, explain how to build them, describe why we should create use case narratives, and yes, we’ll explain how use cases provide the same information as the Given—When–Then format.

References

i Elizabeth saw an Ivar Jacobson presentation on use cases about 10 years ago. Jacobson, of course, is one of the ‘three amigos” (with Grady Booch and James Rumbaugh) who founded Rational Software and the Unified Modeling Language. “I had been working with use case models for several years at the time of his presentation. If I remember right, one of the things I learned was that the idea for use cases was rattling around Jacobson’s mind since his work at Ericsson, many decades before this presentation.”

ii Theoretically the microwave system might include all interactions with the microwave, including our processes, but that does not make much sense. It is cleaner and simpler to think of ourselves as an actor interacting with the microwave system.

iii Be careful. We need to define what the system is. In the first example we said it was an automated banking deposit application. In this example I do not interact directly with the system as we’ve defined it, so I am not an actor. The teller, however, is an actor because they do. In the second example we have not defined the boundaries of the system so we do not know who the actors are. It is quite possible that a user scanning a check for deposit is an actor since they are interacting directly with a system. It is also possible that the system is the back end and the user does not interact directly with the system. These examples show the importance of defining the system in order to understand our scope.