A PM’s Guide to Use Cases Part 2: Use Case Diagrams Explained

Originally published in PM Times on November 10, 2015.

This is the third article in our requirements modeling series and the second article in our use cases series. We had promised that in future articles we would show examples of use case diagrams, explain how to build them, and 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. So here we go!

SUMMARY OF PREVIOUS ARTICLE

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

Use case diagrams are one of 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.

In the last article, we said we would explain the terms reference in this use case diagram example.

SUMMARY OF FIVE KEY TERMS

In the use case diagram example above, there are terms labeled with five numbers. Each one of these numbers represents

1. What is our solution? Usually, projects begin with a business need (problem or opportunity) to be addressed, and that need is addressed by a solution. In the world of use cases, this solution becomes our system, and it contains all the work we want to do on the project related to the end product. In other words, the “system” on the use case diagram represents the product scope. In our example, the scope of the banking system includes features and functions that we want to include as part of the solution scope. Let’s keep in mind that the scope of the project is directly related to the scope of the product, so the more complex the solution, the larger the project scope.
2. Which stakeholders will interact with our system? Using use case lingo, the stakeholders using the system are designated as actors on our diagram. Actors are always outside the system but always interact directly with the system. They can initiate a use case, provide input to it, and/or receive outputs from it. Actor to actor interaction is not described by use cases and can be thought of as business processes, not use cases.
3. What other systems interact with our system? These are also actors since Actors can be people, other systems, time triggers, or event triggers. Actors, again, whether they are people or other systems, for example, can provide input to our system and receive outputs from the system. For example, a process is kicked off at a particular time, like month-end, it is a time actor. If it is triggered by an outside event, such as the outside temperature causing a change in the thermostat, it is an event actor.
4. How do these stakeholders want to use the system? These are our use cases, which describe how actors want to use the system. Use cases are high-level processes and are shown on the use case diagram as a process name surrounded by an oval shape. The use case name describes the process at a very high level. In our example diagram, we know that customers and internal banking stakeholders want to have the functionality to perform banking transactions. But unless we examine the steps involved in these processes, we will not be able to understand the real requirements related to the desired functionality. That is, we can see the birds-eye view of the functionality needed, but we will know nothing about each process itself. That is why use case diagrams ae wonderful for an understanding of product scope, but do not provide the detail we need to build the requested features.
5. Interfaces. The lines between actors and use cases, sometimes known as associations, allow actors to talk to the system and the system to talk back to the actors. For software, these represent user interfaces. User interfaces are screens used to allow data to be both input and displayed. The use case diagram, by showing these interfaces, provides a nice picture of work that needs to be done, since each line, or interface, means a screen or series of screens that needs to be built. Notice that the lines do not have any arrow tips. Interfaces do no show whether the data is input (comes from the actor) or is displayed (comes from the system). Arrows denote dependent relationships, which we will discuss in a future article.

NAMING THE ACTORS AND USE CASES

Actors. As obvious as it sounds, the user role or function, and not names of individuals are preferred for the actors in the use case. For example, use “Accounting” instead of “Erik.” Although we know that we should not use names, we sometimes forget because everyone knows “Erik.” But what happens after “Erik” has left the organization? Not everyone will remember what his function was.

Use Cases. Remember that use cases are processes. Accordingly we name our use cases as we would any other process, with a strong verb and a noun, that is, an action and an object of the action. Instead of naming the use case “Deposit Function” or “Deposits,” for example, we would label it “Make Deposit” or “Deposit Funds.”

EXPECT THE USE CASE DIAGRAM TO CHANGE

Expect your diagram to change over time. Eliciting requirements, regardless of the model used to record the requirements, is an iterative process. Not only will requirements change, but details of the elicited requirements emerge as we know more. Therefore, it is helpful to use stickies for actors, use cases, and interfaces during elicitation until your diagram stabilizes. It is far less frustrating to move stickies than to redraw the entire diagram every time a change occurs. Similarly, do not spend energy trying to align actors with use cases. That alignment will change as the diagram changes. If is far easier to group actors after the diagram stabilizes. Also, there are tricks for simplifying the diagram when the model becomes complex and with the use of dependent relationships, which we’ll discuss in a future article.

In the next article, we will discuss the importance of a use case narrative and how to create one.