Define Use Cases

Definition of Use Cases
A use case is a description of a specific way a user interacts with a system to achieve a particular goal. It represents a functional requirement of the system and outlines the sequence of actions or events between a user (or external system) and the system itself to accomplish an objective.
Characteristics of a Use Case:

1. Goal-Oriented: Focused on achieving a user's goal.
2. Actor Involvement: Specifies the primary and any secondary actors interacting with the system.
3. System Interaction: Defines the behavior of the system during the interaction.
4. Output: Produces a meaningful result for the actor.

How Use Cases Are Used in Use Case Diagrams:
In a use case diagram, use cases are depicted as "ovals" and represent functionalities or services provided by the system. They are one of the primary elements used to illustrate the interaction between "actors" (users or external systems) and the system. These diagrams provide a high-level view of system behavior and the relationships between actors and use cases.
Elements in a Use Case Diagram:

1. Actors:
   • Represented by stick figures.
   • They interact with the system to perform a task.
   • Examples: User, admin, external systems.
2. Use Cases:
   • Represented by ovals.
   • Show the tasks or functions that the system performs.
3. System Boundary:
   • Represented by a rectangle.
   • Defines the scope of the system and contains the use cases.
4. Relationships:
   • Associations: Lines connecting actors to use cases, indicating interaction.
   • Include: Represents mandatory behavior (e.g., "Login" is included in "Place Order").
   • Extend: Represents optional behavior (e.g., "Apply Discount" extends "Checkout").
   • Generalization: Represents inheritance between actors or use cases.

Example of a Use Case Diagram:: Imagine an "Online Shopping System":

• Actors:
  • Customer
  • Admin
• Use Cases:
  • Browse Items
  • Add to Cart
  • Make Payment
  • Manage Inventory (for Admin)
• Relationships:
  • The customer is associated with "Browse Items" and "Make Payment."
  • Admin is associated with "Manage Inventory."

Purpose of Use Case Diagrams::

1. Visualize Functional Requirements:
   • Provide a clear view of what the system will do.
2. Identify Actors and Relationships:
   • Highlight the users and their interactions with the system.
3. Facilitate Communication:
   • Serve as a bridge between stakeholders and developers.
4. Assist in System Design:
   • Guide developers in implementing the functional requirements.

Use cases define the required features of the system. Without these features, the system cannot be used successfully. Each use case is named using a verb phrase that expresses a goal the system must accomplish, for example, deposit money, withdraw money, adjust account. Although each use case implies a supporting process, again the focus is on the goal, not the process.

• Defining Use Case Requirements
  By defining use cases in this manner, the system is defined as a set of requirements rather than a solution. We do not describe how the system must work. We describe what the system must be able to do. The use cases describe only those features visible and meaningful to the actors who use the system. Keeping this in mind will help you avoid functional decomposition, the breaking down of procedures and tasks into smaller and smaller processes until you have described all the internal workings of the system.
• Pitfalls of Systems Development
  One of the pitfalls of systems development is going over budget, which happens when we don't limit the scope of each task or we make a model too inclusive. The UML provides seven other models for fully describing the behavior of the software solution for the system, so remember that you can save some ork for later. Step through the process of adding use cases to the use case diagram by viewing the following series of images.

Reference cited from Alistair Cockburn's Gold nuggets found in his book Writing Effective Use Cases . Cockburn points out, "We will not actually write every scenario separately from top to bottom. That is a poor strategy because it is tedious, redundant, and hard to maintain." A use case can be written nonredundantly, starting with an unconditional main flow that is subsequently enhanced with conditional additional flows of different kinds, where a flow is a sequence of steps. The main flow equates to the main success scenario and each additional flow represents a portion of one or more of the remaining scenarios. The UML does not deal with flows. Cockburn only refers to the main success scenario (main flow) and extensions (additional flows). Refining this view, the following sections present five different kinds of flow by providing a definition, diagram and simplified example for each. The purpose of the examples is to illustrate a clear, consistent and scalable writing convention for representing a use case's structure (they are not meant as full-fledged use case specifications).
In the next lesson, associations and association stereotypes will be discussed.