Use Case Diagrams: Capturing System Requirements

Before you define your database schemas or API endpoints, you need to know exactly what the system is supposed to do and who is going to use it. This is where the Use Case Diagram shines.

Unlike Class or Sequence diagrams, Use Case diagrams are extremely high-level. They aren't meant to show technical implementation; instead, they capture the functional requirements of a system. They are the perfect tool for bridging the gap between product managers, stakeholders, and engineers.

The 4 Components of a Use Case Diagram

1. Actors

An actor is anyone (or anything) that interacts with the system. Actors are typically drawn as stick figures.

It's important to note that an actor doesn't have to be a human. An actor could be:

• A primary human user (e.g., a Shopper, an Admin).
• An external hardware device (e.g., a Barcode Scanner, a GPS Tracker).
• Another external software system (e.g., a Payment Gateway, an Email Service).

2. Use Cases

A use case represents a specific piece of functionality or a goal the system must achieve. They are drawn as ovals/ellipses with the name of the use case written inside. Use cases should be written as verbs (e.g., "Checkout Cart", "Generate Report", "Reset Password").

3. System Boundary

The system boundary defines the scope of what you are building. It is drawn as a large rectangle around all the use cases. Actors are placed outside the boundary, and Use Cases are placed inside. The name of the system goes at the top of the box.

4. Relationships

Lines connecting the actors to the use cases show which actors can trigger or participate in which use cases. But use cases can also relate to each other to reuse logic.

<<include>> vs <<extend>>

The most confusing part of Use Case diagrams for beginners is the difference between an Include and an Extend relationship.

The <<include>> Relationship

Use <<include>> when a use case must execute another use case to finish its job. It's mandatory. You extract this out to avoid repeating yourself across multiple use cases (just like extracting a helper function in code).

Example: Both the "Checkout Cart" and "Subscribe to Newsletter" use cases might point to "Verify Payment Details" with an <<include>> arrow. Checking out requires verifying payment.

Syntax: A dashed arrow pointing from the base use case to the included use case.

The <<extend>> Relationship

Use <<extend>> for optional or exceptional behavior. The base use case can complete perfectly fine on its own, but under certain conditions, additional steps might be added.

Example: The base use case is "Checkout Cart". You might have an <<extend>> relationship from "Apply Discount Code". You don't have to apply a discount code to checkout, but you can if you have one.

Syntax: A dashed arrow pointing from the extended (optional) use case back to the base use case.

Why AI is Perfect for Use Cases

During requirements gathering, product managers often write out user stories in a document. Drawing these out as ovals and stick figures can be a chore.

With AutoUML, you can simply paste your user stories into the prompt:

"The system is a Restaurant POS. A Waiter can Take Order and Print Receipt. A Manager can Print Receipt and Void Order. Taking an Order includes Authenticating."

The AI will instantly generate the Actors, group the Use Cases inside the System Boundary, and draw the correct dependency arrows for you.