Brainstorming the People and Systems (Actors) That Interact with the System and Their High-Level Goals (Use Cases)
The core strength of use case modeling lies in its user-centric perspective: it focuses on who is interacting with the system and why—what valuable goal they are trying to achieve. This section is where abstract vision starts turning into concrete functionality.
Actors represent the external entities (people, roles, organizations, or other systems) that interact with the system under consideration. They are not internal components or parts of the system itself. Use cases, in turn, capture the high-level goals those actors pursue when they use the system—expressed from the actor’s point of view in a verb + noun phrase (e.g., “Withdraw Cash”, “Book a Table”, “Generate Compliance Report”).
In this initial brainstorming phase, the goal is breadth over depth: identify as many meaningful actor–goal pairs as possible without getting lost in detailed steps or exceptions. Visual Paradigm’s AI-Powered Use Case Modeling Studio supports this creative yet structured process by:
- Reusing the stakeholder and user map you created in Section 1.3 as a starting point
- Proposing candidate actors and high-level use cases based on the scope statement and problem description
- Presenting suggestions in an editable table or list format
- Allowing one-click promotion of selected items into the formal model
You remain in full control: accept good suggestions, reject poor ones, merge duplicates, split overly broad items, and—most importantly—add your own domain-specific actors and goals that the AI might not have inferred.
Step-by-Step Brainstorming Approach in the Studio
- Review the stakeholder/user map from Section 1.3.
- For each primary and secondary actor/role, ask: “What major goal(s) does this actor have when interacting with the system?”
- Let the AI suggest candidates (click “Generate Candidates” or similar).
- Review the proposed list in the table view.
- Refine names to be goal-oriented, concise, and actor-centric.
- Add any missing actors or use cases based on your expertise.
- Save selections—these become the seeds for the Use Case Diagram in Section 2.3.
Practical Examples
Example 1: GourmetReserve – Mobile Dining Reservation App
-
Starting Actors (from stakeholder map): Diner, Restaurant Staff, Payment Gateway
-
Brainstormed Actor–Use Case Pairs (after AI suggestion + human refinement):
Actor Use Case Name High-Level Goal (Why the actor uses the system) Diner Search for Available Tables Quickly discover restaurants with open slots matching preferences Diner Book a Table Secure a reservation for a specific date, time, and party size Diner Pre-order Meal Choose dishes ahead of time to speed up service upon arrival Diner Cancel Reservation Release the booking if plans change (possibly avoiding a fee) Diner View Reservation History Review past bookings and receipts Restaurant Staff Manage Reservations View, confirm, modify, or cancel incoming bookings Restaurant Staff View Pre-Orders See what dishes have been ordered in advance to prepare the kitchen Payment Gateway Process Payment Securely handle deposits or full payments for bookings
Example 2: SecureATM – Next-Generation ATM Network
-
Brainstormed Actor–Use Case Pairs (partial list after AI + refinement):
Actor Use Case Name High-Level Goal Retail Customer Withdraw Cash Obtain physical currency from their account Retail Customer Check Account Balance View current funds without needing a teller Retail Customer Transfer Funds Move money between their own accounts or to another person Small Business Owner Deposit Check Add funds to account by scanning a check at the ATM Bank Operations Team Replenish Cash Cassettes Load additional currency into the machine Bank Operations Team Monitor ATM Status Detect and respond to faults, low cash, or hardware issues Fraud Detection System Analyze Transaction Evaluate each transaction for potential fraud in real time
Notice how “Authenticate User” is not listed as a top-level use case here—it is usually treated as a supporting sub-goal (later modeled with «include») rather than an independent goal the customer pursues for its own sake.
Example 3: CorpLearn – Corporate E-Learning Platform
-
Brainstormed Actor–Use Case Pairs:
Actor Use Case Name High-Level Goal Employee / Learner Enroll in Available Course Join a relevant training program Employee / Learner Complete Learning Module Progress through assigned or self-selected content Employee / Learner Take Assessment Demonstrate knowledge and earn credit toward certification Employee / Learner View Progress & Certificates Track learning status and download proof of completion HR / Training Administrator Upload New Course Content Add or update training materials in the platform HR / Training Administrator Assign Mandatory Training Require specific employees or teams to complete compliance courses Manager View Team Training Progress Monitor which team members have completed required learning Compliance Officer Generate Compliance Report Produce auditable evidence of training completion for regulators
Key Guidelines for Effective Brainstorming
- Use goal-oriented naming — Start with a verb that reflects what the actor wants to accomplish (e.g., “Book a Table” not “Table Booking System”).
- Keep use cases high-level — Avoid implementation details or UI steps (save those for detailed flows in Module 4).
- Focus on value — Every use case should deliver observable, meaningful value to its primary actor.
- Distinguish primary vs. secondary actors — Primary actors initiate the use case; secondary actors support it (e.g., Payment Gateway).
- Don’t worry about completeness yet — This is the divergent phase; refinement and relationships come next (Module 3).
By the end of this brainstorming step, you will have a curated, actor-centered list of high-level use cases that captures the essence of what the system must enable. This list becomes the direct input for AI-generated Use Case Diagrams and the backbone for all subsequent detailed modeling—ensuring the entire project stays aligned with real user goals rather than developer assumptions.