UML Use Case Diagram

A use case describes event sequences for an actor to use the system. It is a narrative description of the process. A use case is normally actor or event based. An actor will begin a process or an event will happen that the system must respond to.

Elements of a Use Case Diagram

• Boundary - System boundary can be a computer system, organization boundary, or department boundary. The system functions and actory may change depending on the system boundary location.
• Actors - An external entity (person or machine) that interacts with or uses the system.
• Sequence of events description - This describes a high level process of what an actor will do with a system. An actor may perform an event to start the system. This description does not represent individual steps in the process but represents the high level process itself.

To create a use case:

1. Define the system boundary
2. Identify actors

The actor must be able to walk away happy.

Use Case Categorization

This describes the importance of the function to the system.

• Primary - These functions are required and are common main processes.
• Secondary - These functions are secondary to the system or rarely occur. Don't need these functions in this iteration. This type of use case is rarely done.

Use Case Description Level (Abstraction)

• Essential - A general description of the business process. Do not include technology information. Use the 100 year rule where the information would be understood 100 years in the past and the future.
• Real - Design oriented, shows reports, examples. Uses technological descriptions. Real use cases are undesirable during analysis and should only be used during analysis for specific reasons. Real use cases are handy for requirements gathering.

Normally high level essential use cases and expanded essential use cases are done during the analysis phase of a project. A high level real use case is rarely done and a expanded real use case is done during the design phase only if necessary.

Use case detail level

• High Level - Brief with no detail
• Expanded - More detailed with information about every step in the process. Don't describe how the system responds.

General guidelines

When writing use cases, consider:

• Audience
• Purpose
• Iteration

When making a use case diagram the following two questions should be asked:

• What is the purpose of the system?
• What does a person using the system hope to accomplish?