6.15. Guideline: How to Find Use Cases
Use cases are defined to satisfy the goals of the primary actors. Hence, the basic procedure is:
1. | Choose the system boundary. Is it just a software application, the hardware and application as a unit, that plus a person using it, or an entire organization? |
2. | Identify the primary actorsthose that have goals fulfilled through using services of the system. |
3. | Identify the goals for each primary actor. |
4. | Define use cases that satisfy user goals; name them according to their goal. Usually, user-goal level use cases will be one-to-one with user goals, but there is at least one exception, as will be examined. |
Of course, in iterative and evolutionary development, not all goals or use cases will be fully or correctly identified near the start. It's an evolving discovery.
Step 1: Choose the System Boundary
For this case study, the POS system itself is the system under design; everything outside of it is outside the system boundary, including the cashier, payment authorization service, and so on.If the definition of the boundary of the system under design is not clear, it can be clarified by further definition of what is outsidethe external primary and supporting actors. Once the external actors are identified, the boundary becomes clearer. For example, is the complete responsibility for payment authorization within the system boundary? No, there is an external payment authorization service actor.
Steps 2 and 3: Find Primary Actors and Goals
It is artificial to strictly linearize the identification of primary actors before user goals; in a requirements workshop, people brainstorm and generate a mixture of both. Sometimes, goals reveal the actors, or vice versa.Guideline:
Brainstorm the primary actors first, as this sets up the framework for further investigation.
Are There Questions to Help Find Actors and Goals?
In addition to obvious primary actors and goals, the following questions help identify others that may be missed:
Who starts and stops the system? | Who does system administration? |
Who does user and security management? | Is "time" an actor because the system does something in response to a time event? |
Is there a monitoring process that restarts the system if it fails? | Who evaluates system activity or performance? |
How are software updates handled? Push or pull update? | Who evaluates logs? Are they remotely retrieved? |
In addition to human primary actors, are there any external software or robotic systems that call upon services of the system? | Who gets notified when there are errors or failures? |
How to Organize the Actors and Goals?
There are at least two approaches:use case diagrams p. 89
- As you discover the results, draw them in a use case diagram, naming the goals as use cases.
- Write an actor-goal list first, review and refine it, and then draw the use case diagram.
Actor | Goal | Actor | Goal | |
---|---|---|---|---|
Cashier | process salesprocess rentalshandle returnscash incash out… | System Administrator | add usersmodify usersdelete usersmanage securitymanage system tables… | |
Manager | start upshut down… | Sales Activity System | analyze sales and performance data | |
… | … | … | … |
Why Ask About Actor Goals Rather Than Use Cases?
Actors have goals and use applications to help satisfy them. The viewpoint of use case modeling is to find these actors and their goals, and create solutions that produce a result of value. This is slight shift in emphasis for the use case modeler. Rather than asking "What are the tasks?", one starts by asking: "Who uses the system and what are their goals?" In fact, the name of a use case for a user goal should reflect its name, to emphasize this viewpointGoal: capture or process a sale; use case: Process Sale .Thus, here is a key idea regarding investigating requirements and use cases:
Imagine we are together in a requirements workshop. We could ask either:
Prefer the second question. |
Is the Cashier or Customer the Primary Actor?
Why is the cashier, and not the customer, a primary actor in the use case Process Sale ?The answer depends on the system boundary of the system under design, and who we are primarily designing the system for, as illustrated in Figure 6.2. If the enterprise or checkout service is viewed as an aggregate system, the customer is a primary actor, with the goal of getting goods or services and leaving. However, from the viewpoint of just the POS system (which is the choice of system boundary for this case study), the system services the goal of a trained cashier (and the store) to process the customer's sale. This assumes a traditional checkout environment with a cashier, although there are an increasing number of self-checkout POS systems in operation for direct use by customers.
Figure 6.2. Primary actors and goals at different system boundaries.
[View full size image]
Other Ways to Find Actors and Goals? Event Analysis
Another approach to aid in finding actors, goals, and use cases is to identify external events. What are they, where from, and why? Often, a group of events belong to the same use case. For example:
External Event | From Actor | Goal/Use Case |
---|---|---|
enter sale line item | Cashier | process a sale |
enter payment | Cashier or Customer | process a sale |
… |
Step 4: Define Use Cases
In general, define one use case for each user goal. Name the use case similar to the user goalfor example, Goal: process a sale; Use Case: Process Sale .
Start the name of use cases with a verb. |