What Is a Use Case

Writing Use Cases to Define Interaction Requirements

FREE

Author: Tom and Angela Hathaway
Video Duration: 12:53 minutes

This KnowledgeKnugget™ is part of an affordable online course or as onsite facilitated workshop (live and online classroom).

In this KnowledgeKnugget™ you will learn what use cases are and, using a simple little exercise, we will demonstrate the use case concept. Use cases are a fundamental and phenomenal tool for defining the requirements for how people will interact with a proposed IT solution – and how the application will interact with other applications.

Video Transcript

What Are Use Cases?

Defining a proposed information technology (IT) application can be a daunting challenge. Whether you are tasked with defining a brand new application) or making changes to an existing one, an immense number of decisions awaits you. One of the very early and critical decisions you have to make is how you will represent the requirements that the solution must fulfill. Ensuring that both the business community and the developers share a common understanding of the requirements is notoriously difficult. Any standard method for structuring the communication between these two parties drastically reduces the probability of miscommunication with all of the related costs and misery. The Use Case paradigm is one specific method that you should have in your repertoire of tools for representing how the proposed application should interact with the external world.

Use Cases were introduced as a method for defining requirements for IT solutions in the late 1980’s by Ivar Jacobson and they spread like wildfire. Like all great techniques, practitioners have modified, augmented, adapted, and otherwise refined the basic concept over the years and most of the add-ons are valuable in the proper context. Regardless of the context, one of the common pillars of all Use Cases is that they define the interaction between two or more entities (called “Actors” in Use Case parlance). This correctly implies that the Use Case paradigm is not well-suited for defining systems lacking interaction, i.e. batch processing.

To address the communication issue, a Use Case is often presented in plain text and as a diagram. The Use Case description represents the interaction between involved Actors textually at an appropriate level of detail. The Use Case Diagram is a visual representation of one or more Use Cases depicting the Actors (stick-figure symbol with the name of the Actor below it) and their connection (a simple, solid line) to the Use Case (an oval with the name of the Use Case inside it). Due to the intentional simplicity of the Use Case Diagram, it is considered optional in many organizations. It does, however, provide a great tool for representing the context of the use case in relatively intuitive symbols. The diagram is particularly useful if the Use Case involves a lot of different Actors (which is often the case in embedded and real-time applications).

Use Case Example / Exercise:

Here is a very simple little exercise to demonstrate the use case concept. You need access to a cell phone to complete the exercise. Assume you just got off the airplane, meaning that your cell phone is off and you missed a call from a friend that you want to return. To set the stage for this exercise, confirm that your phone is turned off. Next, do whatever it takes to return the call (NOTE: DO NOT actually place the call — unless you really want to talk with that person.). But wait: every time you do something that causes your cell phone to react, write down exactly what you did and how your phone reacted in the text area below. For example, you might start off with “1. I push the ON button. 2. The Phone displays the home menu. 3. I press the PHONE symbol. 4. The Phone …” Note that you do not have to copy these steps, they are simply to illustrate how you should document the interaction. Click “SUBMIT” when you are done and we will show you our solution for comparison.

OUR SOLUTION:

NOTE: This interaction was created using a Samsung S4 cell phone.

The phone is powered off.

S05 I press the power button and hold for 4 seconds.
S10 The phone displays my home menu and plays a sound.
S15 I press the “Phone” symbol on the menu.
S20 The phone displays the Keypad menu.
S25 I press the “Recent” tab.
S30 The phone displays recent calls.
S35 I tap the Actions bar.
S40 The phone displays the options.
S45 I tap the “View” option.
S50 The phone displays all view options.
S55 I select the “Missed Call” option.
S60 The phone displays all missed calls.
S65 I click on the missed call from Dan.
S70 The phone displays Dan’s contact info.
I am ready to click the green phone to place the call..

END OF OUR SOLUTION

Assuming you actually did the exercise, your solution can look very different from ours and still be correct. Your solution depends on the specific phone you have and how you set it up. It also depends on how you perceived your interactions. We have seen solutions with as few as 4 steps and as many as 21, all of which were correct.

The key characteristics of a correct answer are the following:

You documented a PRE-CONDITION (e.g., “The phone is powered off.”)
You documented the interaction step-by-step in the form of a dialog you were having with the phone (“I did this”, “The phone reacted like this”).
You documented the POST-CONDITION (e.g. “I am ready to click the green phone to place the call.”).

All that is left is for you to give this a name (“Return Missed Call”) and you have the basic framework of a Use Case. Congratulations!

OK, let me correct a couple of oversimplifications. What you really created is technically a Use Case Scenario, meaning a specific interaction with a specific device to achieve a desired outcome given a specific initial state. Scenarios are instances of a single use case. I could give this scenario and my cell phone to a friend and ask her to return the call. Assuming they followed the steps faithfully, they would probably achieve the same outcome. However, there could be situations in which they were unable to achieve it. For instance, what would happen if they pushed the Power button on my phone and the battery was empty? They would not even get to step 2 let alone complete the entire Scenario. To ensure that this situation is covered, I could add a second PRE-CONDITION: The phone has sufficient power. Adding that condition would not change the Scenario I described, it simply clarifies it by documenting a pre-condition that I didn’t think about because it didn’t happen when I executed the scenario.

Now, assume that I want to not just limit my ability to return the missed call to situations where my phone has power. Instead of adding the pre-condition, I could define what action I would take if the battery was empty. That implies I am going to define an alternate set of actions I only do under specific circumstances. I do have a problem, however. There is a fundamental philosophy of the Use Case Paradigm: THERE ARE NO IFS IN A USE CASE! OK, if I am not allowed to use an IF, how do I introduce the concept of alternate actions?

To answer that, I need to introduce another Use Case term: the PATH. The steps you documented represent a specific PATH through the Use Case. They were the exact actions and reactions that you experienced in executing the assignment. If you had to create a different Use Case every time something was different (e.g., no power), you would end up with a thundering herd of Use Cases and a lot of the steps would be identical, meaning redundant. To avoid redundancy, the Use Case paradigm differentiates between a “Standard Path” (aka Basic Course of Events – BCOE or Happy Path – which we do not recommend as it implies an emotional component), and “Alternate Paths” (i.e., the path less taken). The Standard Path represents the interactions under “normal” circumstances, meaning nothing ever goes wrong (which was, by the way, the rationale for calling this the “happy” path). Generally speaking, there will only be one standard path in a Use Case. It can have any number of Alternate Paths, one for each time you want to document how to deal with a specific situation. How do you represent this in the scenario we just created? There are several possible solutions and we recommend using the “AT” convention.

If I add an alternate path for dealing with the dead battery situation, my solution would look like this:

PRE-CONDITION: The phone is powered off.
STANDARD PATH
S05 I press the power button and hold for 4 seconds.
S10 The phone displays my home menu and plays a sound.
S15 I press the “Phone” symbol on the menu
…
S70 The phone displays the caller’s contact info
POST-CONDITION: I am ready to click the green phone to place the call.
ALTERNATE PATHS
A01: @S05, the phone does not turn on
- A01.05 I locate an electrical outlet
- A01.10 I Plug the phone into the outlet
- A01.15 The phone displays the “Charging” symbol
- A01.20 RESUME @S05

You may note that this Alternate Path ends with a “RESUME” statement. This convention allows me to return to the standard path (S0x) at a specific step to attempt again to achieve the ultimate goal of the Use Case, namely return the missed call. Assuming that I am able to place a call while my phone is charging (a situation I have not personally tested), everything should then follow the “Standard Path”.

If you would like to try your hand at adding Alternate Paths to your Scenario, here are a couple of ideas to get you started (you do not have to limit yourself to these scenarios, consider Murphy’s law: “Whatever can go wrong, will! We encourage creative thinking.):

A02: @S40, the phone displays “Delete Call”
A04: @S60, the phone displays only Received Calls
A05: @ S70, the phone displays “UNKNOWN CALLER”

This brings us to the end of this brief introduction to Use Cases. Obviously, there is much more to learn about using this phenomenally simple but powerful tool to define requirements for IT solutions, but that will have to wait for future KnowledgeKnuggets™.

Here you can create the content that will be used within the module.