What is a Use Case in UML Use Case Modeling?

What is a Use Case?

Whenever we discuss the requirements of a system, we recognize that one or more people or things are interested in the behavior of the system. These people are referred to as the stakeholders (actors) of the system.

The functionality of the system is defined by different use cases, each of which represents a specific goal (obtaining an observable value result) for a specific actor. A use case describes the interaction between one (the primary actor) or more (secondary actors) and the system in order to provide an observable value result for the primary actor.

Edit this Use Case Diagram example

Use Case and Use Case Scenarios

A use case is an interaction between an actor and a target system, when the actor uses it to accomplish a goal. Use cases have multiple paths that can be used to achieve a specific goal. They can be represented as narratives (use case descriptions) or visual models (use case diagrams).

The normal path is a set of unconditional steps that describe how to achieve the use case objectives and satisfy the interests of all relevant primary or supporting actors.  Each step is essential to achieving the use case objectives  and none of the steps can be skipped.

Cockburn calls it the “primary success scenario,” while others use terms like “happy scenario,” “basic flow,” and etc.

An alternative path is a conditional set of steps that is a replacement for one or more steps in another process (the alternative process is executed instead of another step), after which the use case continues to pursue its goal.

Use Case Variants

The technology has different kinds of use cases and variations.

• System use cases – The design scope is about the computer system to be developed. It is about an actor achieving a goal through a computer system; it is about technology.
• Business use cases It is about designing for the scope of business operations. It is about actors outside the organization achieving goals that are relevant to the organization. A business use case usually does not contain references to technology, as it is concerned with how the business works.
• Use Case 2.0 adapts techniques for the context of agile development methods. This technique enriches the practice of requirements gathering by supporting the narrative of user stories. It also provides use case “slicing” to facilitate incremental requirements and enable incremental implementation.

Primary and Secondary Actors

A Primary is a stakeholder who interacts with the system to achieve a specific goal. The primary participant is usually, but not always, the person who initiates the use case. This is not the case when the use case is actually triggered by an actor who represents the true primary actor, or when the use case is actually triggered by time. Sometimes (external) participants are required to provide services to the system. Such an actor is called a supporting actor. An actor can be a primary actor in one use case or a supporting actor in another.

Levels of Detail for Use Case Modeling

Cockburn recommends labeling each use case with a symbol to show the “target level”; the preferred level is “user target”

Goal Level	Icon	Symbol	Symbol
Very High Summary	Cloud	++
Summary	Flying Kite	+
User Goal	Waves at Sea	!
Sub function	Fish	–
Too Low	Seabed Clam-Shell	—

Cloud is the highest level, i.e. the enterprise level, where there may be only four or five use cases across the organization. Examples might be advertising goods, selling goods to customers, managing inventory, managing the supply chain, and optimizing transportation.
Flying Kite is lower than cloud, but is still high level and provides an overview. A kite use case might be at the business unit or department level and is a summary of a goal. Examples are for student registration, or if working with a travel company: making air, hotel, car or cruise reservations.
Wave at Sea is at sea level and is usually created for a user goal. This is often the most interesting for users and the easiest for companies to understand. It is usually written for a business activity that each person should be able to complete in 2 to 20 minutes for a blue level activity. For example, registering a continuing education student, adding a new customer, placing an item in the shopping cart, and ordering a checkout.
Fish use cases show a lot of detail, usually at the functional or sub-functional level. Examples include selecting a class, paying an academic fee, looking up the airport code for a city, and generating a customer list after entering a name.
Seabed clam-Shell, like the bottom of the ocean, are the most detailed use cases and are at the sub-functional level. Examples might be secure login authentication, adding a new field using dynamic HTML, or updating a web page in a small way using Ajax.