Why Don’t Use Cases Just Go Away?!

Part 1: Use Case Diagrams

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, blogged about—why don’t they just go away?!

They do not go away because they are, in our opinion, among the most useful tools/techniques we have in our business analysis toolkit. Without going into the history, [i]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.

We use the model in two very different ways. We find use case diagrams immeasurably helpful in understanding a project’s scope and the use case narrative invaluable for getting the detail needed to build the software. And before continuing, let us preempt one inevitable question—can they be used for other projects besides software development? The answer is “we don’t know” because we have only used them for software applications.

What is a use case? Before we look at the use case diagram, 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. It could be manual or automated processing, but we find it most useful for automated systems or equipment like a car or microwave. Elizabeth likes to use the microwave as an example. Theoretically the microwave system might include all interactions with the microwave, including our processes, but that does not make much sense. It’s cleaner and simpler to think of ourselves as an actor interacting with the microwave system. 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.

So if actors are always external to the system and always interact directly with the system, in the following examples, am I an actor?

1. The system is a banking deposit system. I walk by a bank lobby on my way to work. One day I decide to take a check 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. In this case, I am not an actor. I do not interact directly with the system as we’ve defined it. The teller, however, is an actor because they do.
2. In the above example, let’s broaden the definition of a system to include everything surrounding the teller work, including manual processes and the automated system. As above, I hand my check to the teller who enters it into the system. Because of how we’ve defined our system, in this example I interact directly with the “system” so I am an actor.
3. The next time I have a check to deposit I don’t want to stand in line, so I go to an ATM and deposit the check. Am I an actor? Possibly. Until we have defined our “system,” we won’t know who our actors are.

Which brings us to use case diagrams, how they help define the scope of our system, and why we like to narrow the system to the automated system. Use case diagrams are one of the several techniques we use to help scope the final product. We find that the use case diagram structures our thinking and helps us remember functionality we might otherwise have forgotten. The use case diagram not only is an easy way to engage business stakeholders, but is almost universally appreciated by the development team. So let’s quickly review the components of the diagram.

• Boundary box. We like to start with a box that has the name of the system, again our preference being an automated system or piece of equipment. See Figure 1.

• Actors and use cases are defined iteratively. Defining actors helps us discover use cases and defining use cases helps us discover more actors. Let’s start with actors, which can be people, other systems, time triggers, or event triggers. Actors provide some kind of actions that the system responds to. See Figure 2 below.

• Use cases describe the ways actors want to use the system. They are processes and eventually the use case narratives will describe each of the use cases. Because use cases are processes, they use the standard process “Verb-Noun” naming convention like “Make Deposit” or “Close Account.” The ovals in Figure 3 show five uses cases in our example.
• Interfaces allow actors to communicate with the system and the system to talk back to the actor. Using our ATM example, a customer needs to explain what kind of transaction is wanted and the ATM needs to be able to tell when it’s done, giving out money and a receipt perhaps, and asking if another transaction is needed. Interfaces are important. Our system will not be complete until we’ve built them. They are part of the product scope and Figure 3 shows a complete depiction of the scope in our example.

Use case diagrams are usually completed iteratively and fleshed out as more becomes known. Contrary to urban legend about scope, it does change, even after the original baseline. It changes on Agile projects and it changes on more traditional projects. Use case diagrams change, too, and keeping them current is helpful to all stakeholders on the project.

In this article we have defined use cases and looked at use cases and at the components which represent the scope of our product. In Part 2 we will continue with a discussion of use case narratives.

Authors: Elizabeth Larson and Richard Larson, Watermark Learning

Elizabeth Larson, CBAP, PMP, CSM and Richard Larson, CBAP, PMP are Co-Principals of Watermark Learning, a globally recognized business analysis and project management training company. With over 30 years of industry experience each, they have used their expertise to help thousands of BA and PM practitioners develop new skills. Their speaking history includes repeat appearances at IIBA and PMI Global Congresses, chapter meetings, and professional development days, as well as BA World conferences.

They have co-written the acclaimed CBAP Certification Study Guide and The Practitioners’ Guide to Requirements Management. They have been quoted in PM Network and CIO magazine. They were lead contributors to the BABOK Guide® Version 2.0, as well as the PMBOK Guide® – Fourth edition.

[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.”