In the Use Case View, actors represent the external entities—people, roles, systems, or devices—that interact with your system to achieve goals. Identifying actors is a crucial first step in use case modeling because they define the boundaries of the system and help uncover the full range of functional requirements. Actors are not internal components; they are always outside the system boundary, initiating or responding to system behavior.
Actors can be:
- Primary Actors: Those who directly benefit from the system’s use cases (e.g., a customer placing an order).
- Secondary Actors: Supporting roles that the system interacts with to fulfill a primary actor’s goal (e.g., a payment gateway processing a transaction).
- Generalized Actors: Using inheritance to represent common behaviors (e.g., “User” as a base for “Admin” and “Regular User”).
To identify actors effectively in an Agile context:
- Start with stakeholder brainstorming: Ask “Who uses the system? Who benefits? What external systems integrate?” Collaborate in workshops to list roles without assuming technology.
- Focus on roles, not individuals: An actor is a role (e.g., “Doctor”), even if multiple people play it.
- Consider time-based or conditional actors: E.g., “Auditor” for compliance checks.
- Validate by walking through scenarios: For each potential actor, ask “What goals do they achieve with the system?” If none, they might not be an actor.
- Iterate: Actors evolve as requirements refine—add or refine them in sprints based on feedback.
This process aligns with Agile by keeping modeling lightweight, collaborative, and focused on user value, avoiding over-analysis while ensuring no key interactions are missed.
Practical Examples of Identifying Actors in Real-World Projects
Here are concrete examples across domains, illustrating how to spot actors and their roles:
- Online Banking System:
- Primary: Account Holder (views balance, transfers funds).
- Secondary: External Bank (for inter-bank transfers), Notification Service (sends alerts).
- Benefit: Identifying “Fraud Detection System” as a secondary actor early ensures security use cases like “Flag Suspicious Activity” are included, reducing risks in production.
- E-commerce Website:
- Primary: Shopper (browses, purchases), Admin (manages inventory).
- Secondary: Shipping Provider (tracks deliveries), Payment Processor.
- Practical: Workshop reveals “Guest User” as a distinct actor from “Registered User” → adds anonymous checkout flow, boosting conversions.
- Hospital Management System:
- Primary: Patient (books appointments), Doctor (views records).
- Secondary: Insurance Company (verifies coverage), Lab System (processes tests).
- Outcome: Recognizing “Receptionist” as an actor uncovers administrative use cases, streamlining operations.
- Ride-Sharing App:
- Primary: Rider (requests ride), Driver (accepts requests).
- Secondary: GPS Service (provides navigation), Payment Gateway.
- Agile impact: Iteration adds “Support Agent” for dispute resolution, based on user feedback.
- Smart Thermostat System:
- Primary: Homeowner (sets temperature).
- Secondary: Weather API (adjusts based on forecast), Utility Company (reports usage).
- Example: Identifying “Mobile App” as an actor? No—it’s the interface; the actor is the Homeowner using it.
- Library Catalog System:
- Primary: Patron (searches books), Librarian (adds items).
- Secondary: Inter-Library Loan System (borrows from others).
- Benefit: Actors help define boundaries—e.g., excluding “Publisher” if no direct integration.
- Fitness Wearable Device:
- Primary: User (tracks activity).
- Secondary: Cloud Sync Service (stores data), Companion App (displays stats).
- Practical: Brainstorming adds “Healthcare Provider” for data sharing → enables integration features.
- Inventory Tracking for Warehouse:
- Primary: Warehouse Worker (scans items), Manager (generates reports).
- Secondary: Supplier System (notifies restocks).
- Outcome: Clear actors prevent scope creep by focusing only on direct interactions.
- Event Management Platform:
- Primary: Organizer (creates events), Attendee (registers).
- Secondary: Email Service (sends invites).
- Agile: Feedback loop refines “Sponsor” as an actor for promotional use cases.
- ATM Machine:
- Primary: Customer (withdraws cash).
- Secondary: Bank Network (authorizes transactions).
- Classic: Ensures actors like “Maintenance Technician” are considered for non-customer use cases.
In Visual Paradigm, you’ll add actors to your use case diagram, connect them to use cases via associations, and use generalization for role hierarchies—all while keeping the model agile and traceable to requirements.
With actors identified, the next step is exploring use case relationships to organize and reuse behaviors efficiently.
