A Comprehensive Guide to Use Case Modeling

What is Use Case Modeling?

This is a technique used in software development and systems engineering to describe the functional requirements of a system. It focuses on understanding and documenting how a system is supposed to work from the perspective of the end users. In essence, it helps answer the question: “What should the system do to meet the needs and goals of its users?”

Key Concepts of Use Case Modeling

Functional Requirements: Functional requirements are the features, actions, and behaviors a system must have to fulfill its intended purpose. Use case modeling is primarily concerned with defining and capturing these requirements in a structured manner.

End User’s Perspective: Use case modeling starts by looking at the system from the viewpoint of the people or entities (referred to as “actors”) who will interact with the system. It’s essential to understand how these actors will use the system to achieve their objectives or perform their tasks.

Interactions: Use case modeling emphasizes capturing the interactions between these end users (actors) and the system. It’s not just about what the system does in isolation; it’s about how it responds to user actions or requests.

The Basics of Use Cases:

• A use case is a description of how a system interacts with one or more external entities, called actors, to achieve a specific goal.
• A use case can be written in textual or diagrammatic form, depending on the level of detail and complexity required.
• A use case should capture the essential and relevant aspects of the interaction, such as the preconditions, postconditions, main flow, alternative flows, and exceptions.

What is a Use Case Diagram?

A use case diagram is a graphical representation used in use case modeling to visualize and communicate these interactions and relationships. In a use case diagram, you’ll typically see actors represented as stick figures, and the use cases (specific functionalities or features) as ovals or rectangles. Lines and arrows connect the actors to the use cases, showing how they interact.

 

• • Actors: These are the entities or users outside the system who interact with it. They can be people, other systems, or even external hardware devices. Each actor has specific roles or responsibilities within the system.
  • Use Cases: Use cases represent specific functionalities or processes that the system can perform to meet the needs of the actors. Each use case typically has a name and a description, which helps in understanding what it accomplishes.
  • Relationships: The lines and arrows connecting actors and use cases in the diagram depict how the actors interact with the system through these use cases. Different types of relationships, such as associations, extend relationships, and include relationships, can be used to specify the nature of these interactions.

How to Perform Use Case Modeling?

1. To understand a use case, you need to identify the actors and the use cases involved in the system.
   An actor is an external entity that has a role in the interaction with the system. An actor can be a person, another system, or a time event.
2. A use case is a set of scenarios that describe how the system and the actor collaborate to achieve a common goal1. A scenario is a sequence of steps that describe what happens in a specific situation1.
   Actors in Use Case Modeling:
3. Actors are represented by stick figures in a Use Case diagram.
   Actors can have generalization relationships, which indicate that one actor inherits the characteristics and behaviors of another actor. For example, a Student actor can be a generalization of an Undergraduate Student actor and a Graduate Student actor.
4. Actors can also have association relationships, which indicate that an actor is involved in a use case. For example, an Instructor actor can be associated with a Grade Assignment use case.

Relationships Between Actors and Use Cases:

• Use cases can have include relationships, which indicate that one use case incorporates the behavior of another use case as part of its normal execution. For example, a Login use case can be included by many other use cases that require authentication.
  • An include relationship is a dependency between two use cases, where one use case (the base) incorporates the behavior of another use case (the inclusion) as part of its normal execution.
  • An include relationship is represented by a dashed arrow with the stereotype «include» from the base to the inclusion.
  • An include relationship can be used to reuse common functionality, simplify complex use cases, or abstract low-level details

• Use cases can also have extend relationships, which indicate that one use case adds optional or exceptional behavior to another use case under certain conditions. For example, a Cancel Reservation use case can extend a Make Reservation use case if the user decides to cancel their reservation.
  • An extend relationship is a dependency between two use cases, where one use case (the extension) adds some optional or exceptional behavior to another use case (the base) under certain conditions.
  • An extend relationship is represented by a dashed arrow with the stereotype «extend» from the extension to the base.
  • An extend relationship can have an extension point, which is a location in the base use case where the extension can be inserted.
  • An extension point can be labeled with a name and a condition

Creating Effective Use Cases:

• Identifying System Boundaries:
  • A system boundary is a box that encloses the use cases and shows the scope of the system.
  • A system boundary helps to distinguish what is inside the system (the use cases) and what is outside the system (the actors).
  • A system boundary should be clearly labeled with the name of the system and its version1.
• Defining Use Case Goals and Scenarios:
  • A use case goal is a statement that summarizes what the use case accomplishes for the actor.
  • A use case goal should be specific, measurable, achievable, relevant, and testable.
  • A use case scenario is a sequence of steps that describes how the actor and the system interact to achieve the goal.
  • A use case scenario should be complete, consistent, realistic, and traceable.
• Writing Clear and Concise Use Case Descriptions:
  • A use case description is a textual document that provides more details about the use case, such as the preconditions, postconditions, main flow, alternative flows, and exceptions.
  • A use case description should be clear and concise, using simple and precise language, avoiding jargon and ambiguity, and following a consistent format.
  • A use case description should also be coherent and comprehensive, covering all possible scenarios, outcomes, and variations, and addressing all relevant requirements.
• Use Case Templates and Documentation:
  • A use case template is a standardized format that helps to organize and present the use case information in a consistent and structured way.
  • A use case template can include various sections, such as the use case name, ID, goal, actors, priority, assumptions, preconditions, postconditions, main flow, alternative flows, exceptions, etc.
  • A use case documentation is a collection of use cases that describes the functionality of the system from different perspectives.
  • A use case documentation can be used for various purposes, such as communication, validation, verification, testing, maintenance, etc.

Use Case Modeling Best Practices:

• Some best practices for use case modeling are:
  • Identify the key stakeholders and their goals, and involve them in the use case development process
  • Use a top-down approach to identify and prioritize the most important use cases
  • Use a naming convention that is consistent, meaningful, and descriptive for the use cases and actors
  • Use diagrams and textual descriptions to complement each other and provide different levels of detail
  • Use relationships such as extend, include, and generalization to show dependencies and commonalities among use cases
  • Review and validate the use cases with the stakeholders and ensure that they are aligned with the system requirements

Use Case Modeling using Use Case Template

Problem Description: University Library System

The University Library System is facing a range of operational challenges that impact its efficiency and the quality of service it provides to students, faculty, and staff. These challenges include:

1. Manual Borrowing and Return Processes: The library relies on paper-based processes for book borrowing, return, and tracking of due dates. This manual approach is prone to errors, leading to discrepancies in record-keeping and occasional disputes between library staff and users.
2. Inventory Management: The current system for managing the library’s extensive collection of books and materials is outdated. The lack of an efficient inventory management system makes it difficult to locate specific items, leading to frustration among library patrons and unnecessary delays.
3. Late Fee Tracking: Tracking and collecting late fees for overdue books are challenging tasks. The library staff lacks an automated system to monitor due dates and assess fines accurately. This results in a loss of revenue and inconvenience for users.
4. User Account Management: User accounts, including library card issuance and management, rely on manual processes. This leads to delays in providing access to library resources for new students and difficulties in updating user information for existing members.
5. Limited Accessibility: The current library system lacks online access for users to search for books, place holds, or renew checked-out items remotely. This limitation hinders the convenience and accessibility that modern students and faculty expect.
6. Inefficient Resource Allocation: The library staff often face challenges in optimizing the allocation of resources, such as books, journals, and study spaces. The lack of real-time data and analytics makes it difficult to make informed decisions about resource distribution.
7. Communication Gaps: There is a communication gap between library staff and users. Users are often unaware of library policies, new arrivals, or changes in operating hours, leading to misunderstandings and frustration.
8. Security Concerns: The library system lacks adequate security measures to protect user data and prevent theft or unauthorized access to library resources.

These challenges collectively contribute to a suboptimal library experience for both library staff and users. Addressing these issues and modernizing the University Library System is essential to provide efficient services, enhance user satisfaction, and improve the overall academic experience within the university community.

Use Case Template:

Here’s the use case template and example for borrowing a book from a university library in tabular format:

Use Case Name	Borrow a Book
Use Case ID	UC001
Primary Actor	Student
Secondary Actors	Librarian, Book Inventory System
Preconditions	– The student has a valid library card.
	– The book is available in the library’s inventory.
Postconditions	– The book is marked as checked out in the system.
	– The student has the book in their possession.
Main Flow	1. Description: The student wants to borrow a
	book from the university library.
	2. Actor’s Actions:
	– The student presents their library card to
	the librarian.
	– The librarian scans the library card to
	verify its validity.
	– The student provides the title or ISBN of the
	book they wish to borrow.
	– The librarian searches the library catalog
	for the book.
	– The librarian confirms the book’s availability.
	– The librarian checks out the book to the
	student.
	– The student takes the book and leaves the
	library.
	3. System’s Actions:
	– The system validates the library card.
	– The system updates the book’s status to
	“checked out.”
	– The system records the due date for the book
	loan.
	– The system generates a receipt for the
	transaction.
	4. Alternate Flows:
	– If the student’s library card is invalid, the
	librarian informs the student, and the use
	case terminates.
	– If the requested book is not available, the
	librarian informs the student, and the use
	case terminates.
Extensions	– If the student has overdue books, a notification
	is sent to the student.
	– If the student wants to renew the book, they can
	request a renewal through the library website.
Special Requirements	– The system should have a secure database of
	library cardholders.
	– Due dates and late fees should be calculated and
	enforced by the system.

Example Use Case: Borrowing a Book from University Library

Use Case Name	Borrow a Book
Use Case ID	UC001
Primary Actor	Student
Secondary Actors	Librarian, Book Inventory System
Preconditions	– The student has a valid library card.
	– The book is available in the library’s inventory.
Postconditions	– The book is marked as checked out in the system.
	– The student has the book in their possession.
Main Flow	1. Description: The student wants to borrow a
	book from the university library.
	2. Actor’s Actions:
	– The student presents their library card to
	the librarian.
	– The librarian scans the library card to
	verify its validity.
	– The student provides the title or ISBN of the
	book they wish to borrow.
	– The librarian searches the library catalog
	for the book.
	– The librarian confirms the book’s availability.
	– The librarian checks out the book to the
	student.
	– The student takes the book and leaves the
	library.
	3. System’s Actions:
	– The system validates the library card.
	– The system updates the book’s status to
	“checked out.”
	– The system records the due date for the book
	loan.
	– The system generates a receipt for the
	transaction.
	4. Alternate Flows:
	– If the student’s library card is invalid, the
	librarian informs the student, and the use
	case terminates.
	– If the requested book is not available, the
	librarian informs the student, and the use
	case terminates.
Extensions	– If the student has overdue books, a notification
	is sent to the student.
	– If the student wants to renew the book, they can
	request a renewal through the library website.
Special Requirements	– The system should have a secure database of
	library cardholders.
	– Due dates and late fees should be calculated and
	enforced by the system.

These tables above presents the use case template and example in a structured and organized way, making it easier to read and understand the key elements of the use case.

Granularity of Use Cases

Use Case Granularity Definition: Use case granularity refers to the degree of detail and organization within use case specifications. It essentially describes how finely you break down the functionality of a system when documenting use cases. In simpler terms, it’s about how much or how little you decompose a use case into smaller parts or steps.

Importance of Use Case Granularity:

1. Communication Enhancement: Use case granularity plays a crucial role in improving communication between different stakeholders involved in a software project, such as business analysts, developers, testers, and end-users. When use cases are well-defined and appropriately granulated, everyone can better understand the system’s functionality and requirements.
2. Project Planning: The level of granularity in use cases impacts project planning. Smaller, more finely grained use cases can make it easier to estimate the time and effort required for development tasks. This aids project managers in creating more accurate project schedules and resource allocation.
3. Clarity and Precision: Achieving the right level of granularity ensures that use cases are clear and precise. If use cases are too high-level and abstract, they might lack the necessary detail for effective development. Conversely, overly detailed use cases can become unwieldy and difficult to manage.

Example: Let’s illustrate use case granularity with an example related to a “User Registration” functionality in an e-commerce application:

• High Granularity: A single use case titled “User Registration” covers the entire registration process from start to finish. It includes every step, such as entering personal information, creating a password, confirming the password, and submitting the registration form.
• Medium Granularity: Use cases are divided into smaller, more focused parts. For instance, “Enter Personal Information,” “Create Password,” and “Submit Registration” could be separate use cases. Each of these focuses on a specific aspect of user registration.
• Low Granularity: The lowest level of granularity might involve breaking down actions within a single step. For example, “Enter Personal Information” could further decompose into “Enter First Name,” “Enter Last Name,” “Enter Email Address,” and so on.

The appropriate level of granularity depends on project requirements and the specific needs of stakeholders. Finding the right balance is essential to ensure that use cases are understandable, manageable, and effective in conveying system functionality to all involved parties.

In his book ‘Writing Effective Use Cases,’ Alastair Cockburn provides a simple analogy to help us visualize various levels of goal attainment. He suggests thinking about these levels using the analogy of the sea

References:

1. What is Use Case Diagram? (visual-paradigm.com)
2. What is Use Case Specification?