In our tutorial series on Business Analysis Fundamentals, we are starting with Use Case Basics. Use Case Diagrams are central to use case modeling. Use cases are one of the easiest ways to capture the requirements.
This series is going to cover the basics of many business analysis skills like user stories, sequence diagrams, activity diagrams and many more. The purpose of publishing this business analysis fundamentals tutorials series is to provide a basic understanding of business analysis skills for everyone, who is new to these concepts.
What is a Use Case?
A use case is a pictorial notation to represent high-level requirements from a user perspective. Use case diagrams comprise 3 elements – the actor, use case and association link. A typical use case is represented as shown below:
Use case diagrams, however, can represent very limited information. So, we create use case specifications document to add more detailed information. Later in this tutorial, we are going to look at the format of the use case specification document as well.
Read More – 10 Steps to Effective Business Analysis
Who is an actor in Use Case Diagrams?
An actor is an external entity who is likely to interact with the proposed software system. The actor is always an outside entity like a user, another system, administrator, finance manager etc. Any entity in the system like a database, can not be an actor. An actor is represented as shown below:
Use Case in use case diagrams
An oval shape represents a use case in use case diagrams. A use case represents an interaction or functionality of the system. The notation for a use case is as shown below:
Use Cases example
Let’s look at a section of a requirements document and identify the use cases:
A user has to login into the system to book the flight tickets. Logged in users will also have the facility to use discount coupon codes to avail of discounts. The users can search for the flights on any domestic route and for any day. However, they can’t do it on the same day.
How do identify Use Cases?
In the above case, we can look for sections representing interaction points. The easiest way to look for them is to look for action verbs. I have marked these use cases with underlines as shown below:
A user has to login into the system to book the flight tickets. Logged in users will also have the facility to use discount coupon codes to avail discounts. The users can search for the flights on any domestic route and for any day.
The use cases are:
- Login into the system
- Book flight tickets
- Use discount codes
- Avail discounts
- Search for the flights
The use case diagram for the above example is as shown below:
Use case diagram is central to the use case modelling. All the other diagrams like activity diagrams, sequence diagrams, and state model diagrams are created using the use case diagram.
You can also notice that I have not created the use case for “Avail discounts”. Avail discounts is an actually a result of “enter discount coupons”. The discount is applied to the total bill amount and in that case, it is just a calculated field, which needs to be tested. It’s possible to have these cases which represent an action but may not be an interaction. In these cases, these are not candidates for being use cases.
Learn More – Data Analysis Skills for Business Analysts
Use Case specifications
Use case specifications are an integral part of every use case diagram. The specifications add important details to the use case diagrams. These details are:
The scenarios describe the positive and negative workflows related to each use case. We are going to discuss the same in later posts.
I am also posting a small video recorded in the ECBA business analyst training sessions.
