The Courage to Try Something Old – Use Cases
There are many articles about project management trends for 2023. Among the common threads are a focus on AI and more automated PM tools. There are also contradictory trends like workers returning to the office or continuing to work from home. What I find most interesting, though, is that many of the trends have been around for years—like change management, agile and hybrid development methods, and focusing on benefits.[i] Does that mean that these old horses are not really trends? Not at all. It means that even when these techniques are out of favor, they are needed to successfully manage our projects.
One “old” trend I was happy to see was entitled Use Cases Are Back.[ii] Not that they’ve ever gone away. They’ve had different formats and names, like the Given, When, Then format, but the thought processes needed to develop a use case model have always been required.
To review, a use case is a model that describes how stakeholders want to use pretty much anything that’s being built, like a car, an elevator, a phone app, or a change to an existing system. But defining them is not easy. We can’t just ask our stakeholders how they would like to use a microwave or what functionality is needed in a sales app. We need to ask the right questions. And a use case model is a great tool for getting at those requirements.
A use case model, like almost all models, has both a graphical and textual component.[iii] The first component, a use case diagram, is a picture of the how the stakeholders will interact with what’s being developed. It identifies all stakeholder groups who will use the end product and how they want to use it. It also describes all the systems and other components needed to make it work. It becomes a picture of all the people and technical components, as well as all the functionality needed to make it useable. And it’s a great picture of the scope of the effort.
Some PMs and BAs have trouble getting started, so I have developed 5 business questions that can provide a jumpstart in the creation of a use case diagram.
Use Case Diagram Questions
- What’s being built? It’s usually called a system, but we can call it whatever we want. Examples include a new car, a change to an order system, and kitchen cabinets.
- Who are the stakeholders who will use this system? These are often called actors, such as an auto service consultant, a consumer, and cabinet designer.
- How do these stakeholders want to use the system? What functionality do they need? These are the use cases themselves. They are stated as high-level processes, like Start Car, Order Product, Measure Cabinets.
- What other systems or components will interact directly with the system? These are also commonly called actors, like Ignition system, Replenishment system, and Cabinet Delivery Schedule system.
- How will the actors and the system talk to each other? These eventually become the user interfaces that allow the system to recognize what the actor wants to do. The driver sends some signal to the Start Car use case. A consumer enters an item into Order Product use case. A cabinet designer enters measurements into a design cabinet use case.
The textual component is known as a use case narrative or scenario. It describes the process steps which detail the interaction between the stakeholders and what’s being built.
Advertisement
[widget id=”custom_html-68″]
For example, how do we start the car? Does the driver put a key into the ignition? Press a button? Does the car start when the car phone app is connected and the driver opens the door? Something else? There is no one right answer. But the questions below will help our stakeholders go through the required thought processes.
Use Case Scenario Questions:
- How do I know where to begin? Preconditions provide the answer. They tell us where to begin by describing what has already occurred. In our example, do I already have my keys? Have I already unlocked the car? Adjusted the mirrors? More preconditions mean that the use case scenario will be shorter and there will be fewer different paths. For example, if a precondition is that I have my keys, we don’t need to document what happens when I’ve lost my keys in this scenario.
- How do I know when I’m done? These are the postconditions. We stop when we reach these conditions. The pre and post conditions form the scope of the use case because they define what’s in and out of each one.
- What is the most common way of getting from the pre to the post condition? This is the “happy path.” There are no decisions in this path, such as what happens if the car won’t start.
- What are other ways of getting from the pre to the postcondition? These are the alternate paths. The car starts, but it takes three tries.
- What prevents us from getting to the postcondition? These are the exception paths, like when the battery is dead.
Use case models are extremely useful for getting the requirements of the interaction between stakeholders and what’s being built. There are other ways of getting them, but the structure of the use case can help us focus on what questions to ask and ultimately saves time and frustration.