Defining the Use Case Model

To create a candidate list, look at several sources of information, for example:

• The context diagram for the system shows actors (i.e., external systems).  Explore how they might interact with the system. Use cases are very useful for understanding the user interface.  They should be reasonably stable (according to Jacobson) prior to prototyping.
• Review any workflow from BPE projects related to the system.  Start with the activities from that documentation as candidate use cases. 
• Use workshops, interviews, observation of users at work, and class behaviour cards to identify requirements, objects, and responsibilities at a high level. 

 

To identify the use cases for a problem domain consider all the possible ways in which users or other actors might interact with the target system. For example, consider the problem statement about the Automated Flight Reservation System and brainstorm some possible ways a traveler might engage the system:

• Traveler inquires about flights for a proposed travel itinerary.
• Traveler inquires about fares for a proposed travel itinerary.
• Traveler starts a travel profile.
• Traveler cancels a travel account.
• Traveler changes a reservation.
• Traveler requests a travel itinerary.

 

Identifying Actors

Actors may be identified early in the use case definition process, for example, from the context diagram to help identify candidate use cases.  However, it is useful to also review the use cases and to confirm that the actors for the system are described and the use cases for the actors defined.

From the various use cases, it is usually straightforward to identify the actors who will interact with the target system. Systems with human-computer interfaces will include one or more types of end-user actors. Systems that interact with other software or hardware systems will include appropriate software or hardware actors.

For example, the Automated Flight Reservation System might involve traveler, travel agent, and travel agency administration actors.

Validation and Verification with Use Cases

While the primary purpose of use cases is to provide a rigorous foundation for OOA, they have also proven effective for testing object systems. Since they are an integral part of the specification they can be used for system validation. Since they can also express business requirements, they can also be used for system verification.

The Objectory method (Jacobson's method), which originated use case analysis, recommends that testing activities occur throughout the development process. Consider use cases for integration testing, where one use case implementation is integrated and tested at a time.

Evaluating Use Cases

Consider these quality criteria for assessing use cases.

Tips and Hints

Don't get too detailed too early.  Understand the large pieces of functionality first, then consider the main functionality of each component. Use subordinate use cases to document exceptions and alternates. Do not clutter the main use cases.

Review the object model to ensure it remains an object implementation. Since the use cases are sequential, it is easy to produce a traditional process model.

Try to confine very detailed interaction sequences to small parts of the object model.  Use a fine level of detail only for very complex processing.