What Is Use Case?, Why Needed? And How To Make It? - All You Need To Know

What is a Use Case Diagram?

Use case analysis is a commonly used technique to identify the business goals to be accomplished by a software system. It’s nothing but the system functionalities written in an organized manner. Use case analysis provides an overview of business goals without knowing the system requirements in detail, hence easy to understand. It’s always the best practice to create use case to gather and track the business requirement.

User Stories helps to identify the real business requirement.

“A user story is a brief statement that describes a particular user problem or concern whereas use case represents a goal.”

Usually, User stories created under use cases to record and track the problems associated with different business goals. The separation of use cases and user stories provides a clear division of what is the business need and what the system has to support.

Where and Why Use Case Diagram?

  • Use case diagram aims to capture the dynamic aspect of a system. The objective of the Use Case diagram is to gather the usage requirements from the external usage point of view as it’s a very high-level diagram.
  • This helps to identify the external & internal factors influencing the system. This is a very useful technique to get to know the stakeholders to gather detailed requirements. The primary purpose of use case diagrams is to identify functions and how end users interact with them.
  • Use Case diagram required to understand the dynamic view of the system and also to describe the functions and to find the stakeholders.
  • Use Case diagrams are very high-level diagrams and this could be refined further to get a clear and detailed picture of the system. A well-structured use case also describes the pre-condition, post-condition, exceptions and these extra elements are used to make test cases when performing the testing.
  • It’s good to present to managers or the clients as it shows the high-level view of the system and it represents role which interacts with the system and what functionality system will provide without going much deeper.

Elements of Use Cases?

There are mainly three elements used for User case diagram

  1.    Actors
  2.    Use Case
  3.    Relationship
  4.    System (Optional)
  5.    Package (Optional)


Actors are nothing but the entity which will be interacting with the functions, it could be a person, organization, an internal or an external application. It is usually drawn like skeleton shown below.

There are two kinds of the actor:
  1. Primary actor is anyone or thing that interacts with the system to gain direct benefit.

  2. The secondary actor is anyone or thing that involve in achieving a use case yet, they do not gain direct benefit from the system. Very often, the secondary actor is someone who assists the primary actor to achieve a use case.

Use Case:

Use Cases are the functions or an action within the system. This is nothing but the business goal which will be performed by Actors. It’s usually drawn as an oval with fiction name.

E.g. consider an order management system where the goal is to collect the order, “Place Order" would be a business goal, hence a use case.


Relationship connects the Use Cases with Actors and represents the relationship between them. It shows, how actors interact with the functions to achieve the business goal.

System (Optional):

The system is nothing but the scope which defines the boundary for the use case, however, it’s not mandatory but it’s very useful when drawing a Use case for a large system. You can define the scope/boundary of each use case using the system or show different areas covered in different releases. Note that the actors in the system are outside the system.

Package (Optional): 

The package is another optional element which is very useful for the better readability of Use Cases in complex diagrams. A package object in a UML Class and Use Case Diagram provides the ability to group together classes and/or interfaces that are either similar in nature or related.

Relationship Type In The Use Cases:

It always confusion with relationship type in use case. You may get confused with their uses i.e. where to use what? Let’s go through with relationship type in Use Case Diagram without wasting any more time.

There is a total of 5 relationship types in a use case diagram.

  1. Association between actor and use case
  2. Generalization of an actor
  3. Extend between two use cases
  4. Include between two use cases
  5. Generalization of a use case

1. Association Between Actor and Use Case:

This is a direct association of actor with the Use Case.

An actor must be associated with at least one use case.
An actor can be associated with multiple use cases.
Multiple actors can be associated with a single use case.

2. Generalization of an Actor

In Generalization of an Actor, One actor inherits the role of another actor. If the user has use cases which are related to another actor then Actor can inherit the use cases from the Ancestor.

3. Extend Relationship - Between Two Use Cases

It extends the base use case and adds more functionality to the system. The extending use case is dependent on the extended (base) use case. In the below diagram the “Calculate interest” depends on “Deposit Funds” use case.

The extended (base) use case must be meaningful on its own. This means it should be independent and must not rely on the behavior of the extending use case. Although extending use case is optional in some of the cases whereas it could be must have in some of the scenarios especially in modeling complex behaviors.

4. Include Relationship Between Two Use Cases

Include relationship show that the behavior of the included use case is part of the including (base) use case. The main reason for this is to reuse common actions across multiple use cases. In some situations, this is done to simplify complex behaviors. Few things to consider

While using the <<include>> relationship.
  • The base use case is incomplete without the included use case.
  • The included use case is mandatory and not optional.
In the above example, Update Balance will be required while Depositing Fund as well as Withdrawing Fund, hence commonly used for both use cases.

5. Generalization of a Use Case

This is similar to the generalization of an actor. The behavior of the ancestor is inherited by the descendant. This is used when there is common behavior between the two use cases and also specialized behavior specific to each use case.

In the above example, Customer can pay the bill by Credit Card or Pay By Cash, hence This can be generalized as above. I'm sure you got it. :)

How To Create A Use Case Diagram?

Now we have understood the basics of Use Case Diagram and now it's time to understand, how to proceed in order to create Use Case;

Step 1: Identifying Actors:

This would be the first task. As explained earlier, an Actor could be the end user, Organization or internal or external application/system who will be interacting with functions. This helps to explore and find all possible Use Cases.

Step 2: Identifying Use Cases

Once you got the Actors, now it's time to find the functions of those actors, a good way to do this is to identify what the actor’s needs from the application/system. In ATM system customer will need to withdraw money, check transaction, update contact, request chequebooks, etc. and all of these can be considered as use cases.

To get the basic idea about the system and to get started with the project, you should always identify the complete actors. Top level use cases should always provide a complete function required by an actor and you can extend or include use cases depending on the complexity of the system.

Step 3: Look for Common Functionality to use Include

Look for common functionality in order to reuse across the system. If you find two or more use cases that share common functionality you can extract the common functions and add them 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.

If you notice in Include Example, Update Balance was the common function for Withdraw and Deposit fund, hence Include relationship was used. Focus on this area to make your use case more clean and self-explanatory.

Step 4: Possibility of Generalizing Actors / Use Cases?

There may be instances where actors are associated with similar use cases while triggering a 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 is - “Make Payment” use case in a payment system can be further generalized to “Pay by Credit Card”, “Pay by Cash”, “Pay by Check” etc. All of them have the attributes and the functionality of payment with special unique scenarios.

Step 5: Optional 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.

Sometimes it's mandatory to use the Extend relationship between use case, it describes and gives the better picture of a project. Hence, try to focus on these things before starting with the diagram.

Above is the basic Use Case Diagram for reference the reference, however, there are more detailed and complex use cases are required in projects.

Guidelines / Instructions

Below guidelines need to be considered while drawing impressive use and self-explanatory use case diagram. guideline to improve the readability of the diagram.


  • Give meaningful business relevant names for actors
  • Primary actors should be to the left side of the diagram – This helps to quickly highlight the important roles in the system.
  • Actors don’t interact with other actors (no association) – In case actors interact within a system, you need to create a new use case diagram with the system in the previous diagram represented as an actor.
  • Place inheriting actors below the parent actor

Use Cases

  • Make the Use Case name descriptive and should begin with a Verb – (Name of the use case should clearly represent functionality performed.)
  • Place the Use case in the logical order
  • Place included use cases to the right of the invoking use case
  • Place inheriting use case below parent use case


  • Arrow points to the base use case when using <<extend>>
  • Arrow points to the included use case when using <<include>>
  • Both <<extend>> and <<include>> should be shown as dashed arrows.
  • Actor and use case relationship doesn't show arrows.
  • Avoid including all types of relationships because the main purpose of the diagram is to identify requirements.
  • Use note whenever required to clarify some important points.

Hope you liked this article, Do let me know in the comment section if I missed anything in order to complete this article and make more useful for other readers.

Don't forget to share with your friends and colleagues via Twitter, Facebook, LinkedIn, Google+ or any other medium, because Sharing is Caring.


  1. A good tutorial. Thank you for sharing. Instead, I would like to show you what I use. I use this site http://charts.poweredtemplate.com/powerpoint-diagrams-charts/ppt-business-models-diagrams/0/index.html. On it I can quickly and easily find the right template.

  2. I used to be more than happy to seek out this internet-site.I needed to thanks in your time for this glorious read!! I definitely having fun with every little bit of it and I've you bookmarked to take a look at new stuff you blog post.

  3. It's a plreusae to find someone who can identify the issues so clearly


Post a Comment

Previous Post Next Post