Contents

Use Case DiagramEdit

Use Case diagrams are a staple of requirements analysis in software and systems engineering. They provide a high-level, visual way to show how external users and other systems interact with a given system to achieve specific goals. As part of the broader Unified Modeling Language, use case diagrams focus on user goals and the boundary between the system and its environment, rather than on internal processing details. They are especially useful in early project stages for communicating with stakeholders, clarifying scope, and aligning product teams around core functionalities.

While not a blueprint for every internal task, use case diagrams help stakeholders agree on what the system should do from a user-facing perspective. They complement other UML artifacts such as Activity Diagram, Sequence Diagram, and Class Diagram, providing a user-centric view that can guide subsequent design, development, and testing efforts.

Core concepts

  • System boundary and scope
    • The diagram typically presents a box that represents the system under consideration, with a labeled boundary that distinguishes what is inside the system from what lies outside. This makes it clear which behaviors are provided by the system and which entities interact with it. See System boundary and Use case for related ideas.
  • Actors
    • External entities that interact with the system to achieve goals. Actors can be humans (e.g., a Actor (UML)) or other systems (e.g., a Payment Gateway). In UML terms, actors may be primary (initiating interactions) or supporting (providing services). See Actor (UML) and Association (UML).
  • Use cases
    • A use case is a goal-oriented sequence of actions that yields a measurable result of value to an actor. Use cases are named with verbs and describe what the actor accomplishes, not how the system implements it. See Use case.
  • Relationships
    • Actors are connected to use cases with associations (solid lines), indicating participation. See Association (UML).
    • Includes: A use case can automatically incorporate the steps of another use case to factor out common functionality. This relationship is called an Include (UML).
    • Extends: A use case can extend another use case with additional optional behavior, under specified conditions. This is represented by an Extend (UML) relationship.
    • Generalization: Both actors and use cases can participate in generalization hierarchies, where a more general behavior or role is specialized by more specific ones. See Generalization (UML).
  • Notation and conventions
    • Use case diagrams emphasize goals and interactions over internal logic. They are typically kept at a level of detail appropriate for communicating with stakeholders, with more elaborate specifications available in accompanying documents such as Use Case Specification.

Example: an online bookstore

  • System boundary: Online Bookstore System System boundary.
  • Actors: Customer, Payment Processor, Inventory System.
  • Use cases: Browse Catalog, Search Books, View Book Details, Add to Cart, Checkout, Make Payment, Track Order.
  • Relationships: The customer has associations with many use cases; Checkout may include Make Payment; some purchases may extend with special offers or gift options.

This kind of example helps show which functions are visible to external users and how different actors interact with the system to achieve goals, such as buying a book or returning an item. For discussions of terminology and related notation, see the entries for Use case and Actor (UML).

Modeling practices and relationships

  • Decompose for clarity
    • Start with high-level use cases that capture major user goals, and avoid crowding the diagram with too many details. Use case generalization and includes/extends to reduce repetition and improve readability. See Generalization (UML) and Include (UML) / Extend (UML).
  • Name carefully
    • Use cases should be phrased as goals (e.g., "Place Order," "Pay Invoice") rather than internal steps. This helps ensure the diagram remains focused on user value. See Use case.
  • Distinguish actors from system behavior
    • Ensure there is a clear distinction between what the user (or another system) does and what the system provides. The notation should make responsibilities obvious to stakeholders. See Association (UML) and Actor (UML).
  • Use accompanying detail when needed
    • A use case diagram is often complemented by textual descriptions, flow of events, and non-functional requirements. See Use Case Specification for a common companion artifact.
  • Appropriate scope
    • Use case diagrams work best for describing system boundaries and user goals at a reasonably high level. They are less suitable for modeling internal processes or detailed data flows, which are better captured in other diagram types such as Activity Diagram or Data Flow Diagrams where applicable.

Applications and limitations

  • When to use
    • Early-phase requirements elicitation, stakeholder communication, scope agreement, and quick validation of system boundaries and core interactions. They are commonly used in projects following UML and benefit from alignment with other UML diagrams.
  • Limitations
    • A diagram by itself cannot fully specify a system’s behavior or data structures. Use cases describe goals and interactions but do not enumerate all edge cases, non-functional constraints, or internal algorithms. For deeper modeling, teams typically create accompanying documents and additional diagrams such as Sequence Diagram and Class Diagram.
  • Practical cautions
    • Overly large or dense diagrams can become hard to read. It is often better to split complex systems into multiple diagrams that reflect subsystems or logical boundaries, each with its own set of use cases and actors.

See also