Use case diagrams in LLD - System Design Exercise

Design: Use Case Diagram Design

Designing use case diagrams to capture functional requirements and user interactions. Out of scope: detailed class or sequence diagrams.

Functional Requirements

FR1: Identify actors who interact with the system

FR2: Define system use cases representing user goals

FR3: Show relationships between actors and use cases

FR4: Include system boundaries to separate system from external actors

FR5: Support generalization and include/extend relationships between use cases

Non-Functional Requirements

NFR1: Diagram must be clear and easy to understand for non-technical stakeholders

NFR2: Must support scalability to add more actors and use cases without clutter

NFR3: Should be technology-agnostic and focus on user interactions

NFR4: Use standard UML notation for use case diagrams

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Actors (users or external systems)

Use cases (functional goals)

System boundary box

Relationships (associations, include, extend, generalization)

Design Patterns

Include relationship to reuse common behavior

Extend relationship for optional or conditional behavior

Generalization for actor or use case inheritance

Grouping use cases for modularity

Reference Architecture

  +-----------------------------+
  |         System Boundary     |
  |                             |
  |   (Use Case 1) <------------|---- Actor 1
  |   (Use Case 2) <------------|---- Actor 2
  |       ^                     |
  |       |                     |
  |   (Use Case 3) --include-->|
  +-----------------------------+

Actors outside the box, use cases inside the box, arrows show interactions.

Components

Actor

UML notation

Represents a user or external system interacting with the system

Use Case

UML notation

Represents a functional goal or task the system performs for an actor

System Boundary

UML notation

Defines the scope of the system and separates it from external actors

Relationships

UML notation

Shows associations, include, extend, and generalization between actors and use cases

Request Flow

1. 1. Identify all actors who interact with the system.

2. 2. Define use cases representing the goals actors want to achieve.

3. 3. Draw the system boundary box to enclose use cases.

4. 4. Connect actors to use cases with association lines.

5. 5. Use include relationships to factor out common behavior.

6. 6. Use extend relationships for optional or conditional behavior.

7. 7. Use generalization to show inheritance among actors or use cases.

8. 8. Review diagram for clarity and completeness.

Database Schema

Not applicable for use case diagrams as they are behavioral models focusing on interactions.

Scaling Discussion

Bottlenecks

Diagram becomes cluttered with many actors and use cases

Difficulty in maintaining clarity as system complexity grows

Hard to represent detailed behavior or data flow

Solutions

Group related use cases into packages or modules

Use multiple diagrams to separate different system parts or user roles

Limit scope per diagram to keep it understandable

Combine with other UML diagrams (sequence, activity) for detailed behavior

Interview Tips

Time: Spend 10 minutes explaining use case diagram basics, 15 minutes drawing a sample diagram, 10 minutes discussing extensions and scaling.

Explain purpose of use case diagrams to capture user goals

Describe actors and system boundary clearly

Show how include and extend relationships improve reuse and clarity

Discuss how diagrams help communication with non-technical stakeholders

Mention limitations and when to use complementary diagrams