Constructing Use Case Diagrams
The following checklist shows the steps necessary for the construction of use case diagrams. After this, we will explain the individual steps further.
Checklist 3.1 Constructing Use Case Diagrams from the External View
- Collect information sources—How am I supposed to know that?
- Identify potential actors—Which partners and customers use the goods and services of the business system?
- Identify potential business use cases—Which goods and services can actors draw upon?
- Connect business use cases—Who can make use of what goods and services of the business system?
- Describe actors—Who or what do the actors represent?
- Search for more business use cases—What else needs to be done?
- Edit business use cases—What actually has to be included in a business use case?
- Document business use cases—What happens in a business use case?
- Model relationships between business use cases—What activities are conducted repeatedly?
- Verify the view—Is everything correct?
We deliberately chose the order in which the steps are performed. However, this order is not mandatory, since in practice, the individual steps often overlap heavily.
On one hand, a general understanding of the business system and business processes is important for the realization of each individual step. On the other hand, for many steps it is also necessary to consult knowledge carriers. It makes little sense to cling to the personal view of the analyst, who knows too little about the area of application.
Collecting Information Sources—How am I Supposed to Know That?
As a first step, it is important to find knowledge carriers, in order for analysts and knowledge carriers to work out the basic principles together. Such knowledge carriers are, for example:
- People who are involved in performing, operating, and controlling business processes
- Users of similar or related IT systems
- Customers, who are often critical and creative knowledge carriers
- Business partners
- Domain experts
- External observers
Several helpful techniques have proven to be practical for the analysis and understanding of business processes:
- Observing employees at work
- Participating in the business processes being investigated
- Taking the role of an outsider (e.g., of a customer)
- Giving out surveys
- Performing interviews
- Brainstorming with everyone involved
- Discussing with domain experts
- Reviewing existing forms, documentation, specifications, handbooks, and work tools
- Describing organizational structure and workflow management
- Reviewing organization charts and job descriptions
- Read through the introduction to the case study in Basic Principles and Background once more. In this introduction, we explain the basics of the case study, to help with understanding its business processes.
- In your mind, run through all the roles that you can think of and their business processes (passenger, clerk in the duty-free shop, etc.).
- Which activities can you think of from the view of the passenger? How would you try to freshen up your memory?
The result of this first step is often a collection of forms, work instructions, completed surveys, existing process descriptions, business objects such as tickets or boarding passes, etc. This overview is often not yet complete, and will be further extended during the modeling process.
Identifying Potential Actors—Which Partners and Customers Use the Goods and Services of the Business System?
This step is all about identifying potential actors. Here, this rule applies: the more the merrier. You can work with these actors in later steps; or they can be reduced in number or combined.
More potential actors can be found by answering the following questions (e.g., through consulting knowledge carriers). In doing this, it is advisable to create groups of people and types of organizations by abstracting directly from concrete examples of specific persons and organizations:
- Which customers are customers of the business system, and which are customers of the business processes?
- Who are the external partners of the business system? Which goods and services do these external partners use?
- Which in-house positions and organization units are partners of the business system and use its goods and services?
- With what external business systems does the business system interact?
As a first step, the previous explanations of our case study result in the following actors:
In addition to the passenger, who represents travelers, there is the check-in representative. The check-in representative is a person who is not the actual passenger, but an agent of the passenger. The check-in representative has the task of performing the check-in with the ticket of the passenger.
Identifying Potential Business Use Cases—Which Goods and Services can Actors Draw Upon?
This step is about finding potential business use cases. The rule—the more the merrier—applies here as well (in reasonable moderation). Potential business use cases can be found by answering the following questions:
- Which goods or services are provided to and used by the customer?
- Which goods or services are provided to and used by external partners?
- Which goods and services that are provided by the business system involve suppliers (suppliers of goods and suppliers of services)?
- What are the individual actors doing?
- How and on what occasions does communication take place with other business systems or business partners?
- Which events trigger what activities?
First considerations of our case study result in the following business use cases:
Initially, the business use cases can only be described in a concise and informal manner:
- The check-in procedure includes submitting the ticket, baggage check-in, seat reservation, and issuing and handing over the boarding pass.
- Passengers who only have hand luggage can use express check-in. No baggage check-in is performed.
- During boarding, the boarding pass of the passenger is verified at the gate.
- Automated check-in is conducted without the help of a check-in clerk, directly at a machine (screen). Baggage cannot be checked in.
For us, in practice, the observation technique has proven effective for identifying business use cases. By observing people involved in the business processes, activity lists can be created. Following this, the activities can be grouped by events that lead to the first business use cases.
Connecting Business Use Cases—Who Can Make Use of What Goods and Services of the Business System?
By assigning business use cases to actors, a first draft of the use case diagram evolves (Figure 3.12). This is achieved by answering the following question:
- Which customers or business partners have what functionalities available to them?
With this first draft we obtain the basis from which we can further edit and refine the use case diagram.
The passenger can choose between a normal check-in, automated check-in, and express check-in. The passenger walks to the gate and presents his or her boarding pass. The check-in representative can perform a regular check-in, but is not able to perform express check-in and automated check-in.
Describing Actors—Who or What do the Actors Represent?
An actor in a diagram has to be named in a way that clarifies the role that is represented. Here, it is of utter importance that the terminology of the domain area, meaning a business-oriented term, is used. In addition to the name, an actor can be further defined with a description. The question to this end is:
- How can an actor be described further? For instance, this description can include an area of responsibility, requirements from the system, or a formal definition of his, her, or its role. Don't be afraid to add job descriptions or organizational profiles (for example of a catering company)—even if these are not represented in UML.
Searching for More Business Use Cases—What else Needs to be Done?
Once you have found several business use cases, they can be used as starting points for further questions. Starting from a particular business use case, the following questions can be asked:
- Is there anything that has to be done at some point beforehand, prior to accessing a particular functionality?
- Is there anything that has to be done at some point afterwards, after performing a particular business use case?
- Is there anything that needs to be done if nobody performs a particular business use case?
In doing so, it is important to consider the proper business system. Many of the events that occur before or after a business use case take place outside the business system under consideration. In our case study, for instance, booking the flight or getting to the airport does not belong to the system being considered.
If we take a closer look, we notice that a passenger often travels with luggage, which he or she checks in. Baggage transportation is responsible for loading luggage into the airplane. Baggage transportation is carried out by an independent organization, known as a handling agent. Consequently, it is considered an actor, more specifically, an outside service provider. It does not matter for our diagram that individual employees of the partner enterprise perform these tasks.
Ten minutes before a flight leaves, baggage transportation requests a passenger list from passenger services, which includes every passenger who checked in, but did not board the airplane. On the basis of this list all affected luggage will be unloaded again from the airplane. If the flight is an international flight, the customs authorities of the country in which the destination airport is located also request a passenger list.
This results in two new actors: baggage transportation and the customs authorities at the destination airport (Figure 3.13):
Editing Business Use Cases—What actually has to be Included in a Business Use Case?
Without a doubt, it is difficult to find the right amount of detail in the modeling of business systems. If almost all the activities of an actor in a business use case are combined, the use case diagram will lose practically all of its significance. If the activities are itemized too thoroughly, the use case diagram gets too complex and contains too many activities with interrelationships that are hardly recognizable.
Fortunately, some criteria will help you determine the optimal scope of a business use case. For this purpose, ask yourself the following questions:
- Does the business use case consist of a behaviourally related sequence of interactions that belong together (an interaction sequence)? Items that are included in a business use case have to be directly related. Issuing a boarding pass and searching for lost luggage are not related at all. Business use cases that violate this criterion have to be divided. This prevents the occurrence of oversized business use cases.
- How many actors are involved in a business use case? Business use cases that have too many actors have to be divided. This also prevents oversized business use cases.
- Does the business use case deliver tangible and relevant goods or services? A business use case is not supposed to describe incomplete steps, for example, counting pieces of luggage. Rather, at least in a regular case, it is supposed to produce a benefit that has meaning from a customer's perspective. Business use cases that violate this criterion have to be combined with other business use cases. This way, undersized business use cases are prevented.
- Is the business use case never performed alone, but always in a sequence in combination with other business use cases? A business use case is not supposed to describe goods and services that are only used in combination with other goods and services. Business use cases that violate this criterion, have to be combined with other business use cases. This also prevents undersized business use cases.
- Is the business use case initiated by an actor? Business use cases that are not initiated by an actor are not use cases but internal activities that are depicted in the internal view of the business system.
A review of the existing business use cases on the basis of these questions can lead to the consolidation or division of business use cases.
Documenting Business Use Cases—What Happens in a Business Use Case?
To understand a business use case, the information from the use case diagram is not sufficient. The chain of interactions and of the various scenarios that are behind each business use case have to be described. This means that the goods and services that the business system provides have to be described, namely the chain of events from the perspective of the customer or business partner.
In addition to purely verbal description, documentation in activity diagrams and sequence diagrams has proven to be especially valuable. The construction of these diagram types will be treated in the following sections: Activity Diagrams, and High-Level Sequence Diagrams.
Modeling Relationships between Business Use Cases—What Activities are Conducted Repeatedly?
If you realize that certain parts of an interaction are the same in several business use cases, you can extract these similarities and combine them into their own business use case. This new business use case can be used in other business use cases with an include relationship.
In our case study, the business use case issuing boarding pass has not yet been assigned. We know that the boarding pass is generated and issued during check-in. At some point during the business use cases check-in, express check-in, and automated check-in, the boarding pass is issued (see Figure 3.14):
Verifying the View—Is Everything Correct?
All diagrams and records have to be verified by the knowledge carriers. What we should ask the knowledge carriers for every diagram or view is:
- Is everything that is contained in the diagram correct and complete?
Even if knowledge carriers can read and understand diagrams themselves (they can use the reading directions in this text), we should still read the diagrams to them. Only with this last step is the circle completed. This results in a verified view, which reflects a current shared understanding of business systems and business processes.
The completed use case diagram can be verified with the following checklist:
Checklist 3.2 Verifying Use Case Diagrams from the External View
- Completeness: The use case diagram is complete if there are no further business use cases in the system. All goods and services that are available to customers and partners of the business system are depicted in the form of business use cases (if necessary, business use cases can be spread out into several diagrams).
- Extent: All business use cases that are included in the use case diagram are real business use cases, meaning they meet the definition of a business use case.
- Degree of detail: The degree of detail of the business use cases meets the following requirements: A business use case represents a behaviorally coherent interaction sequence. A business use case is initiated by an actor, and has only a few actors. A business use case represents a functionality that is tangible and that yields a relevant result.
- Relationships between business use cases: Include relationships are applied properly.
- Naming and describing: The names of business use cases describe the functionalities that the business system provides. The naming was done in accordance with the normal terminology of the business system.
- Actors: The actors in the use case diagram represent roles taken up by outside persons, organizations, or other business systems during interactions.
When using use case diagrams for modeling business systems and business processes, it is advisable to keep the level of abstraction low. For the comprehensibility of the diagrams and for communication between the involved parties, it is better to add redundancies than to abstract too much.
It is of fundamental importance that the terminology of the business processes or the organization is used, and that the descriptions of the business use cases are chosen in a way that can be understood intuitively.
Terminology from the field of Information Technology does not belong in use case diagrams on the business-process level. The mixing of terms from the business process and IT communities leads to poor results. In reality, we often encounter use cases that are already very close to IT on the business-process level, e.g., updating a customer index. This leads to confusion in two aspects:
- Users—meaning people who are involved in business processes, and who are not familiar with IT terminology—do not understand the business use cases. Since business use cases describe the performance requirements for a business system, the business system and business processes cannot be understood, and therefore cannot be verified. In a project with poorly formulated business use cases, an IT department presented the business use cases to users for verification and received just one short answer: "Men throwing arrows?!".
- Technical details on the level of business use cases distract from the business-process specific requirements for a system.
Use case diagram is a behavioral UML diagram type and frequently used to analyze various systems. They enable you to visualize the different types of roles in a system and how those roles interact with the system. This use case diagram tutorial will cover the following topics and help you create better use cases.
Importance of Use Case Diagrams
As mentioned before use case diagrams are used to gather a usage requirement of a system. Depending on your requirement you can use that data in different ways. Below are few ways to use them.
- To identify functions and how roles interact with them – The primary purpose of use case diagrams.
- For a high-level view of the system – Especially useful when presenting to managers or stakeholders. You can highlight the roles that interact with the system and the functionality provided by the system without going deep into inner workings of the system.
- To identify internal and external factors – This might sound simple but in large complex projects a system can be identified as an external role in another use case.
Use Case Diagram objects
Use case diagrams consist of 4 objects.
- Use case
The objects are further explained below.
Actor in ause case diagram is any entity that performs a role in one given system. This could be a person, organization or an external system and usually drawn like skeleton shown below.
A use case represents a function or an action within the system. It’s drawn as an oval and named with the function.
The system is used to define the scope of the use case and drawn as a rectangle. This an optional element but useful when you’re visualizing large systems. For example, you can create all the use cases and then use the system object to define the scope covered by your project. Or you can even use it to show the different areas covered in different releases.
The package is another optional element that is extremely useful in complex diagrams. Similar to class diagrams, packages are used to group together use cases. They are drawn like the image shown below.
Use Case Diagram Guidelines
Although use case diagrams can be used for various purposes there are some common guidelines you need to follow when drawing use cases.
These include naming standards, directions of arrows, the placing of use cases, usage of system boxes and also proper usage of relationships.
We’ve covered these guidelines in detail in a separate blog post. So go ahead and check out use case diagram guidelines >>.
Relationships in Use Case Diagrams
There are five types of relationships in a use case diagram. They are
- Association between an actor and a use case
- Generalization of an actor
- Extend relationship between two use cases
- Include relationship between two use cases
- Generalization of a use case
We have covered all these relationships in a separate blog post that has examples with images. We will not go into detail in this post but you can check out relationships in use case diagrams >>.
How to Create a Use Case Diagram
Up to now, you’ve learned about objects, relationships and guidelines that are critical when drawing use case diagrams. I’ll explain the various processes using a banking system as an example.
Actors are external entities that interact with your system. It can be a person, another system or an organization. In a banking system, the most obvious actor is the customer. Other actors can be bank employee or cashier depending on the role you’re trying to show in the use case.
An example of an external organization can be the tax authority or the central bank. The loan processor is a good example of an external system associated as an actor.
Identifying Use Cases
Now it’s time to identify the use cases. A good way to do this is to identify what the actors need from the system. In a banking system, a customer will need to open accounts, deposit and withdraw funds, request check books and similar functions. So all of these can be considered as use cases.
Top level use cases should always provide a complete function required by an actor. You can extend or include use cases depending on the complexity of the system.
Once you identify the actors and the top level use case you have a basic idea of the system. Now you can fine tune it and add extra layers of detail to it.
Look for Common Functionality to use Include
Look for common functionality that can be reused across the system. If you find two or more use cases that share common functionality you can extract the common functions and add it to a separate use case. Then you can connect it via the include relationship to show that it’s always called when the original use case is executed. ( see the diagram for an example ).
Is it Possible to Generalize Actors and Use Cases
There may be instances where actors are associated with similar use cases while triggering few use cases unique only to them. In such instances, you can generalize the actor to show the inheritance of functions. You can do a similar thing for use case as well.
One of the best examples of this is “Make Payment” use case in a payment system. You can further generalize it to “Pay by Credit Card”, “Pay by Cash”, “Pay by Check” etc. All of them have the attributes and the functionality of a payment with special scenarios unique to them.
Optional Functions or Additional Functions
There are some functions that are triggered optionally. In such cases, you can use the extend relationship and attach an extension rule to it. In the below banking system example “Calculate Bonus” is optional and only triggers when a certain condition is matched.
Extend doesn’t always mean it’s optional. Sometimes the use case connected by extend can supplement the base use case. The thing to remember is that the base use case should be able to perform a function on its own even if the extending use case is not called.
A use case with most of the scenarios found in use case diagrams
Use Case Diagram Templates
A use case template for an ATM system
We’ve gone ahead and created use case diagram templates for some common scenarios. Although your problem or scenario won’t be exactly like this you can use them as a starting point. Check out our use case diagram templates >>.
Questions Regarding the Use Case Diagram Tutorial
We’ve tried to comprehensively cover everything you need to know about creating use case diagrams. If you have doubts about any section or can think of ways to improve this tutorial please let us know in the comments.
More Diagram Tutorials
Use Case diagramuse case diagram exampleuse case diagram scenario