A Primer On Use Cases

One common problem faced by business analysts is how to represent the requirements a new application or a newly proposed change to an existing application must fulfill to ensure that stakeholders, including developers, share a common understanding of requirements.

Unless requirements are adequately represented, many common requirements engineering issues become unavoidable. Some of these issues include an early focus on low-level abstractions and the subsequent burial of high-level requirements in superfluous details, to mention a few.

Use Cases: A Closer Look

Introduced in the late 80s by Ivar Jacobson, the use case is a method of defining software requirements that captures the functional requirements of a system by defining the interactions between two or more entities, called actors. A use case is commonly represented both in plain-text form and as a diagram, that captures all the different goals various actors have in using the system.

Visual Versus Text Form

The textual representation of a use case shows the interaction between the actors textually and at an appropriate level of detail. There are several set elements that every textual representation of a use case should contain:

-        Name: A good use case name is easy to remember and, at the same time, provides a succinct description that neatly summarizes the entire use case in just a few words.

-        Main scenario: The main scenario describes the steps that occur between the actor and the system when everything goes as it is supposed to. The main scenario should be kept as compact as possible to preserve clarity.

-        Alternative scenarios: Alternative scenarios describe all other paths an actor could take when interacting with the system. Two common types of alternative scenarios include exceptions and extensions.

o   Exceptions deal with everything that could go wrong or take an unexpected turn at any given moment during the actor’s interaction with the system.

o   Extensions deal with possible alternative goals that might come into play at any given moment during the actor’s interaction with the system.

When these elements are represented visually as a use case, depicting the actors and their connections to each use case, some information must be discarded for practical reasons. As such, use cases are kept intentionally simple. One however, needs to be mindful of when a textual representation of a use case is sufficiently clear by itself.

Use Case Map

A use case map is a combination of visual use cases that share the same data sets and are initiated by the same actor. Adopting a use case map structure can help to find missing elements in a use case diagram, such as missing actors, events and scenarios.