Use case modeling describes the proposed functionality of a system from the user perspective. Use case modeling was developed in 1986 by Ivar Jacobson and then released to the mainstream in his 1992 book Object-Oriented Software Engineering – A Use Case Driven Approach.
Aspect | Explanation |
---|---|
Concept Overview | – Use Case Modeling is a technique in software engineering that helps capture, clarify, and organize system requirements from the perspective of end-users or actors interacting with a system. It focuses on functional requirements and provides a clear way to understand how a system will be used to achieve specific goals or tasks. Use Case Modeling is commonly associated with the Unified Modeling Language (UML) and is widely used in software development. |
Key Concepts | – Use Case Modeling involves several key concepts: 1. Actor: An actor is an external entity (user, system, or another application) that interacts with the system. 2. Use Case: A use case represents a specific functionality or a set of related actions that the system performs in response to an actor’s request. 3. System Boundary: It defines the scope of the system and separates it from external entities. 4. Relationships: Relationships between actors and use cases, such as associations, extend relationships, and include relationships, capture different interactions and scenarios. |
Use Case Diagram | – Use Case Modeling is often visualized using Use Case Diagrams, which provide a graphical representation of actors, use cases, and their relationships. Actors are represented as stick figures, and use cases are represented as ovals with the name of the use case inside. Arrows connect actors to use cases to depict interactions. |
Process | – The process of creating Use Case Models typically includes the following steps: 1. Identify Actors: Identify all the external entities (actors) that will interact with the system. 2. Identify Use Cases: Identify the different functionalities or actions that the system must perform to meet user needs. 3. Define Relationships: Define how actors and use cases are related, such as who initiates which use cases. 4. Create Diagrams: Create Use Case Diagrams to visualize the relationships and interactions. 5. Document Use Cases: Write detailed descriptions of each use case, specifying their behavior and conditions. |
Benefits | – Implementing Use Case Modeling offers several benefits: 1. Clear Requirements: It provides a clear and organized way to capture and communicate system requirements. 2. User-Centric: Focuses on how users will interact with the system, helping ensure it meets their needs. 3. Visual Clarity: Diagrams make it easier to visualize complex systems and their interactions. 4. Scope Definition: Defines the system’s boundaries and helps avoid scope creep. 5. Basis for Testing: Use cases serve as a foundation for designing test cases. |
Challenges and Risks | – Challenges in Use Case Modeling include the potential for incomplete or inaccurate requirements if actors and use cases are not identified correctly. There’s also the risk of overcomplicating diagrams with excessive detail. Collaboration and clear communication with stakeholders are essential to mitigate these challenges. |
Applications | – Use Case Modeling is widely applied in software development for designing and documenting software systems. It is also used in other domains, such as business process modeling, requirements analysis, and system design. |
Tools and Notation | – Various tools and notations support Use Case Modeling, including the use of UML, Use Case Diagrams, and software tools like Microsoft Visio, Lucidchart, and draw.io for creating visual representations of use cases and their relationships. |
Understanding use case modeling
Upon release, the book popularized use case modeling as a technique to capture functional requirements in software development.
Use case modeling can be applied in the following scenarios:
- Capturing system requirements.
- Driving the implementation and generation of test cases.
- Specifying the context of a system.
- Validation of a systems architecture.
- Developed by analysts with domain experts.
The core elements of a use case model
As a minimum, the use case model contains the following basic elements that are graphically depicted to show the relationship between each element:
Actor
Who is using the system? Actors encompass both human users and other computer systems.
They use a use case to perform some piece of work that is of value to the business.
The overall role and scope of each actor in the system are defined by the set of use cases they have access to.
Use case
What do the actors want to achieve?
A use case describes how the system should respond under various conditions to a request from an actor to deliver a specific goal.
Think of a use case as representing a discrete unit of meaningful work, such as the fulfillment of a new order or the registering of a new account.
A discrete use case may incorporate the functionality of another use case or extend a use case with its own behavior.
Associations
Or the relationship between actors and the particular use cases they interact with.
System boundary
Which defines the system of interest with respect to the world around it.
The core elements of a use case description
Using elements of the use case model, a use case description provides a detailed, step-by-step account of the interaction between the actor and the system.
This sequence of steps is called a scenario.
Ultimately, the account should clearly show how the actor must initiate an action to derive value and achieve a goal.
To that end, it should contain the following:
Title
Which must communicate the goal of the use case. In the case of a student wanting to sign up for a volleyball class, the title may be “Register Student for Volleyball Class”.
Description
Or a summary of what the use case does.
Actors
Again, these are the people or systems who interact with the use case.
Preconditions
What needs to be in place before the use case can commence?
Postconditions
What conditions must be met for the scenario to end, either successfully or unsuccessfully?
Path
Or the step-by-step interaction between the actor and the system, divided into three types.
The primary path is the most commonly taken route to a successful conclusion.
The alternate path is a less commonly used route to the same conclusion.
The exception path leads to an unsuccessful conclusion and may incorporate an error message or further instruction.
Date of creation and revision history
This chronology helps determine how old the use case is when undertaking document analysis.
Priority and frequency of use
How important is the use case? How often is it executed? Both are useful in solution planning.
Use case modeling examples
In the final section, let’s conclude by outlining some basic use case modeling examples.
Airport check-in and security screening
- Business actors – passenger, tour guide, passenger with special needs, minor passenger (child). Each of these actors plays an external role with respect to the airport business.
- Business use cases – individual passenger check-in, group check-in, passenger security screening, luggage handling. These describe business process functions that occur within the airport and serve the needs of users.
As we noted earlier, a discrete use case may incorporate the functionality of another use case or extend one with its own behavior.
In this example, the discrete use cases “luggage check-in” and “luggage handling” extend the business use case “individual passenger check-in”.
Since some individuals may be traveling without luggage, these use cases become optional.
Automated teller machine
In the case of an automated teller machine (ATM), a customer of the bank (actor) uses the machine in several different use cases. These include:
- Deposit funds.
- Transfer funds.
- Withdraw money.
- Check balance.
- Pay income tax.
- Print recent transactions.
Another actor is the ATM technician with the following use cases: maintenance, repair, and security check.
The use cases of both the ATM technician and the bank customer involve the “bank” actor – irrespective of whether the use case is related to banking transactions or maintenance.
Online shopping
A consumer that uses a website to purchase a product or service online is the actor, or more formally, the “online customer”.
Use cases in this scenario may include:
- Make a purchase.
- View items.
- Register details.
- Checkout.
For eCommerce companies, use case diagrams may be a little more difficult to define.
For example, the “view items” use case may only be relevant if the customer wants to look at an item without purchasing it.
This particular use case could also be incorporated into the “make purchase” use case if so desired.
It is important to note that in this example, the “checkout” use case is a component of making a purchase and is not available by itself.
Known as an included use case, “checkout” relies on the support and functionality of the base use case “make a purchase”.
The “view items” use case may also be extended by use cases such as “browse catalog”, “search for items”, “add to wedding registry”, or “add items to shopping cart”.
Again, these are all extending use cases because they add functionality to the process of a customer finding a product online.
In addition to the online customer actor, there are also several other actors. These include:
- New customer.
- Registered customer.
- Identity provider.
- Credit payment service.
- Service authentication.
- Afterpay.
If we return to the “checkout” use case, for example, we see that it includes multiple required use cases.
The online customer (actor) authentication process occurs via the use cases of “user cookie” or “single sign-on” (SSO). Note that “service authentication” is involved in both these use cases, with the SSO functionality also requiring an external identity provider.
Key takeaways:
- Use case modeling describes the proposed functionality of a system from the perspective of the user.
- At the very least, a use case model should contain four basic elements: actor, use case, associations, and system boundary.
- Use case modeling necessitates that a use case description is written. This is a series of steps that provides an account of the interaction between the actor and the system.
Key Highlights
- Introduction to Use Case Modeling:
- Use case modeling captures system functionality from the user’s perspective.
- Developed by Ivar Jacobson in 1986 and popularized through his 1992 book.
- Used to capture functional requirements in software development.
- Scenarios for Use Case Modeling:
- Use case modeling is used for capturing system requirements, driving implementation and testing, specifying system context, validating system architecture, and more.
- Developed collaboratively by analysts and domain experts.
- Core Elements of Use Case Model:
- Key elements include actors, use cases, associations, and system boundary.
- Actors are users or systems interacting with the system.
- Use cases describe how the system responds to requests from actors.
- Associations represent relationships between actors and use cases.
- System boundary defines the system’s scope.
- Core Elements of Use Case Description:
- A use case description provides a detailed step-by-step interaction between the actor and the system.
- Includes title, description, actors, preconditions, postconditions, and scenarios.
- Scenarios comprise the primary path, alternate path, and exception path.
- Also includes creation date, revision history, priority, and frequency of use.
- Use Case Modeling Examples:
- Airport Check-in and Security Screening:
- Business actors include passengers, tour guides, etc.
- Business use cases include individual/group check-in, security screening, luggage handling.
- Discrete use cases like luggage check-in extend individual passenger check-in.
- Automated Teller Machine (ATM):
- Customer and ATM technician are actors.
- Use cases involve depositing, transferring funds, withdrawals, etc.
- Technician use cases: maintenance, repair, security check.
- Online Shopping:
- Online customer is the actor.
- Use cases include making a purchase, viewing items, checkout, etc.
- Additional actors like new customer, registered customer, service authentication, etc.
- Use cases can be extended, included, and related to one another.
- Airport Check-in and Security Screening:
Related Frameworks | Description | When to Apply |
---|---|---|
User Stories | – Brief, informal descriptions of a software feature or requirement, typically written from the perspective of an end user. User Stories complement Use Case Modeling by providing lightweight, user-centric narratives that capture specific functionality or behavior. | – When gathering requirements and defining features for Agile software development projects. – Using User Stories to articulate user needs, prioritize features, and guide iterative development effectively. |
Activity Diagrams | – Graphical representations of workflows or business processes, showing the flow of activities and decisions within a system. Activity Diagrams can complement Use Case Modeling by providing detailed visualizations of specific scenarios or interactions. | – When modeling complex business processes or system behaviors. – Creating Activity Diagrams to illustrate Use Case scenarios, sequence of actions, and decision points effectively. |
Sequence Diagrams | – Visual representations of interactions between objects or components within a system over time. Sequence Diagrams complement Use Case Modeling by illustrating the sequence of messages exchanged between system elements in response to Use Case scenarios. | – When modeling the dynamic behavior of a system or component. – Using Sequence Diagrams to depict Use Case interactions, message flows, and collaboration between system elements effectively. |
State Diagrams | – Diagrams that depict the various states and transitions of a system or object over time. State Diagrams complement Use Case Modeling by illustrating how system behavior changes in response to external events or stimuli described in Use Case scenarios. | – When modeling the lifecycle or behavior of system entities with distinct states. – Creating State Diagrams to represent Use Case preconditions, postconditions, and state transitions effectively. |
Class Diagrams | – Diagrams that depict the structure and relationships between classes or objects in a system. Class Diagrams complement Use Case Modeling by providing a static view of the system’s entities and their associations, attributes, and behaviors. | – When modeling the structure and relationships of system components or entities. – Developing Class Diagrams to support Use Case realization, identify classes, and define their attributes and methods effectively. |
Scenario-based Testing | – A testing approach that uses real-world scenarios or use cases to validate system functionality and behavior. Scenario-based Testing aligns with Use Case Modeling by using Use Case scenarios as the basis for defining test cases and expected outcomes. | – When planning, designing, and executing software tests based on Use Case specifications. – Performing Scenario-based Testing to validate Use Case requirements, functionality, and system behavior effectively. |
Business Process Modeling | – A technique for visually representing and analyzing business processes, workflows, or operations within an organization. Business Process Modeling complements Use Case Modeling by providing a broader context for understanding how system functionality integrates with and supports business processes. | – When documenting, analyzing, or improving business processes impacted by system functionality. – Using Business Process Modeling to align Use Cases with organizational goals, workflows, and stakeholder needs effectively. |
Acceptance Criteria | – Specific conditions or criteria that must be met for a user story or Use Case to be considered complete and accepted by stakeholders. Acceptance Criteria provide detailed requirements and validation criteria for Use Case scenarios. | – When defining the scope, requirements, and acceptance criteria for Use Cases. – Specifying Acceptance Criteria to clarify Use Case functionality, behavior, and success criteria effectively. |
Requirements Traceability Matrix (RTM) | – A document that links system requirements to their sources and traces them throughout the software development lifecycle. A Requirements Traceability Matrix (RTM) complements Use Case Modeling by providing a structured way to track Use Case requirements, dependencies, and verification status. | – When managing and tracking requirements across Use Cases, user stories, and development activities. – Maintaining a Requirements Traceability Matrix (RTM) to ensure alignment between Use Case specifications, development tasks, and testing activities effectively. |
Unified Modeling Language (UML) | – A standardized modeling language for visualizing, specifying, constructing, and documenting software systems and processes. UML provides a comprehensive set of diagrams and notation for Use Case Modeling, as well as other aspects of system design and development. | – When modeling system structure, behavior, interactions, and architecture. – Applying UML diagrams, notation, and conventions to represent Use Cases, actors, relationships, and system dynamics effectively. |
Connected Agile & Lean Frameworks
Read Also: Continuous Innovation, Agile Methodology, Lean Startup, Business Model Innovation, Project Management.
Read Next: Agile Methodology, Lean Methodology, Agile Project Management, Scrum, Kanban, Six Sigma.
Main Guides:
- Business Models
- Business Strategy
- Business Development
- Distribution Channels
- Marketing Strategy
- Platform Business Models
- Network Effects
Main Case Studies: