Casual Format Use Case

Use Case Formats and Elements

Use cases can vary considerably from one organization to another in terms of the content included, the format followed, and the degree of formality employed. In this section, we show two alternative use case formats that vary in terms of formality and detail.

Casual Use Case Format

To illustrate a use case in the casual style, we will employ a use case from the already‐completed Sales System at DrōnTeq. The Sales System was created several years ago to allow DrōnTeq customers to place orders for the commercial‐grade drones that DrōnTeq manufactures. In this example use case, customers order a base model drone and then may add or modify various features on the drone, such as batteries, motors, cameras, and other sensors. The process of ordering the customized drone involves four main steps: authenticating the customer (because DrōnTeq provides commercial‐grade drones and sells to commercial drone operators, it requires its customers to create an account before ordering); creating the preliminary order; getting shop manager approval for the requested optional features; and transmitting the approved order to the drone customization shop. The example use case focuses on the second step of this overall process: create a preliminary custom drone order. Refer to Figure 4‐1 as we describe the sections of the use case. There are numerous pieces of information in the use case, each with an important role to play in describing the response to the triggering event. We will describe each section starting at the top.

Use Case Formats and Elements

Use cases can vary considerably from one organization to another in terms of the content included, the format followed, and the degree of formality employed. In this section, we show two alternative use case formats that vary in terms of formality and detail.

Casual Use Case Format

To illustrate a use case in the casual style, we will employ a use case from the already‐completed Sales System at DrōnTeq. The Sales System was created several years ago to allow DrōnTeq customers to place orders for the commercial‐grade drones that DrōnTeq manufactures. In this example use case, customers order a base model drone and then may add or modify various features on the drone, such as batteries, motors, cameras, and other sensors. The process of ordering the customized drone involves four main steps: authenticating the customer (because DrōnTeq provides commercial‐grade drones and sells to commercial drone operators, it requires its customers to create an account before ordering); creating the preliminary order; getting shop manager approval for the requested optional features; and transmitting the approved order to the drone customization shop. The example use case focuses on the second step of this overall process: create a preliminary custom drone order. Refer to Figure 4‐1 as we describe the sections of the use case. There are numerous pieces of information in the use case, each with an important role to play in describing the response to the triggering event. We will describe each section starting at the top.

Normal Course

The next major section of a use case is the description of the major steps that are performed to execute the response to the event, the inputs used for the steps, and the outputs produced by the steps. The normal course lists the steps that are performed when everything flows smoothly in the system. This is sometimes called the “happy path” because there are no problems or issues that arise when the steps are able to be followed normally.

As you read through the steps, you can clearly understand the interactions that occur between the user and the system. The steps are listed in the order in which they are performed and you can see the “bird's‐eye” perspective illustrated in the steps, describing what an outsider could observe while watching the user and system interact.

Notice step 2, where a branching logical condition occurs. In this case, if the selected drone is out of stock, the customer is given the option of accepting the future availability date and continuing the order process. If that choice is rejected, the customer returns to step 1 to select a different drone model.

Postconditions

In this section of the use case, we define the final products of this use case. In our example, a confirmed order is stored in the Confirmed Custom Order datastore; an unconfirmed order is stored in the Unconfirmed Custom Order data store; and the shop manager is notified of a confirmed order requiring approval. These postconditions also serve to define the preconditions for the next use case in the series. In our example, that would be the use case that describes the Shop Manager's custom order approval process.

Exceptions

In order to be complete, a use case should describe any error conditions or exceptions that may occur as the use case steps are performed. These are not normal branches in decision logic, but are unusual occurrences or errors that could potentially be encountered and will lead to an unsuccessful result. As the use case is written and reviewed, the analyst should ask the user if there are any special situations or errors that could occur with each step. If there are, they should be explained as an exception. We want to be sure that the system does not fail while in use because of an error that no one thought about. As you probably know, in many systems, handling exceptions can require more coding effort than the normal and alternative courses. It is essential to try to identify these trouble spots during the analysis phase so we do not encounter unexpected error conditions and crashes during testing and implementation.

In our example, there are no exception conditions that have been identified.