[Use Case] What?, Why? & How? – All You Need To Know
What is 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 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 the 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 the 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 show 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?
- Use Case
- System (Optional)
- 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.
- Primary actor is anyone or thing that interacts with the system to gain the direct benefit.
- 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 an 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.
Don’t worry, this article has the detailed explanation of Relationship in Use Case Diagram. Just scroll this page a little if you don’t see below. 🙂
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 to show different areas covered in different releases. Note that the actors in the system are outside the system.
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 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.
- Association between actor and use case
- Generalization of an actor
- Extend between two use cases
- Include between two use cases
- Generalization of a 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.
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 behaviour 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 modelling complex behaviours.
- The base use case is incomplete without the included use case.
- The included use case is mandatory and not optional.
In above example, Update Balance will be required while Depositing Fund as well as Withdrawing Fund, hence commonly used for both use cases.
How to create 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 the 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 check books 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 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.
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 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 a 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 and extension rule to it.
Sometime 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.
Guidelines / Instructions
Below guidelines need to be considered while drawing impressive use and self-explanatory use case diagram. guideline for 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
- 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 don’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 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 … 🙂