In this article, I'll discuss the following:
- What is a Use Case?
- Why Create a Use Case?
- What are the Components of a Use Case?
- Step-by-step Guide to Creating a Use Case
- Tools to Create Use Cases
What is a use case diagram? topUse case diagrams represent a graphical overview of the functionality provided by the system in terms of actors, their goals, and dependencies between them.
Why create a use case? top
- A great way to show how the functionality works
- To represent how the system responds to the end user interactions by illustrating the interaction between the end user and the system from the user’s perspective
- Very easy to understand by non-technical stakeholders
Let's take a look at a food ordering app (e.g. a service like GrubHub or Seamless) example below:
In the above example, you can see some actors and functions (use cases) connected by a bunch of relationships (associations) to define the interactions between them. Before we get into the use case components, let's understand the system described in the above example:
- The system will be used by three types of actors: Waiters, Customers and a Cook
- Customers will place their order. Customers can also order a drink
- Customers will enter their information and pay for food
- Waiters will recieve the order and send it to the Cook
- The Cook will prepare the food and send a notification to the Waiter
- Waiters will finalize the order and deliver it to the Customer's address
What are the components of a use case? top
Use Cases contain two main deliverables: use case diagram and a use case document. Some organizations require both from the BA and others require just one of them. This depends on the project nature, your audience and the organization's PMO methodologies. In this post, I'll cover the use case diagram. You can read the use case document and download a free template in part 2.
- Actors: top
- Actors are not part of the system; they represent any person or system that interacts with the application
- The actor represents a specific role - not all users playing that role. In the above example, you can have more than one waiter but they are all represented by one actor
- We do not have control over actors – actors are free to do what they want, we can only control our system
- A use case typically represents a complete functionality that the actor can use in a system
- A use case must deliver something of value to an actor
- A group of use cases (functions) for a system defines the ways the system can be used.
Ask the following questions to identify the system's use cases:
- What are the goals of each actor?
- How can each actor achieve their goal?
- Will any actor create, store, modify, delete, or read information from the system?
- Does any actor need to be notified about certain occurrences in the system?
Once you have identified your actors and their goals, you have now created your initial list of high level use cases. Remember, effective use cases must have understandable actors and goals.
- Indicate the communication between an actor and a use case
- Can flow in both directions - actor to use case and use case to actor
- Represented with a solid line connecting the two parties and in some cases with an arrowhead
Three Types of Use Case Associations top
- 3.1. Generalization Relationship
- 3.2. Include Relationship
- 3.3. Extend Relationship
“A taxonomic relationship between a more general classifier and a more specific classifier. Each instance of the specific classifier is also an indirect instance of the general classifier. Thus the specific classifier indirectly has features of the more general classifier.” ~ UML2.0
♣ In a generalization relationship, think of the general use case as a “parent” use case
♣ Specific use cases inherit the behavior of the general use case
Include relationships describe a required (non-optional) behavior included in the base use case. It is a relationship created between a use case (base) that “uses” the functionality of another use case (included). Generally, it is assumed that the included use case will be called every time the basic path is run.
♣ The base use case “uses” the included uses case
♣ A base use case cannot function until it gets information from the included use case
In this relationship, an extension use case is created to extend the behavior of the extended (base) use case when exceptional circumstances are encountered. An extend relationship is used to represent an optional or exceptional behavior.
The system boundary box is a rectangular shape drawn around the concerned use case to represent the system’s scope. Only the use cases contained within that boundary box are considered to be in-scope, and anything outside is considered out-of-scope.
Step-by-step Guide to Creating a Use Case top
Tools to Create a Use Case top
There are several tools that can be used to develop UML diagrams. Depending on the organization you are working for, they may use any of the following tools: