• Home

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.

Graphical user interface, text, application, email  Description automatically generated

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.

Casual Format Use Case

Create TWO Casual Format Use Cases utilizing the Functional Requirements data from the Attachment 1, Requirements Definition deliverable. Utilize Microsoft Word®.

After reviewing the Attachment 2, consider the possible Use Case Names, actors, descriptions, triggers, and the normal course interactions of the actors with the hypothetical aviation-related Inventory Management System. For example, consider the case of an Airframe Shop Mechanic who uses a fictitious “AAA Aviation AntiCorrosion Spray” in her work. When the mechanic notices that the product is running low in the inventory, she might interact with the IMS to reorder the product.

In a Use Case associated with the above interaction, the Use Case Name is “Order Product.” The actor is “Airframe Shop Mechanic.” The description is “Airframe Shop Mechanic wants to order AAA Aviation AntiCorrosion Spray.” The trigger is “The AAA Aviation AntiCorrosion Spray product is running low in the inventory.” The Normal Course 1.0 title is “Order a product.”

Use Case names are verb-related because a Use Case describes an action taken by a user, such as making an input or requesting an output. Use Case names are NOT noun-related because Use Case names are NOT things. The actor is the user of the Inventory Management System. The actor is a person, a hardware device, or a software system that uses or integrates with the Inventory Management System to achieve a useful goal. For example, besides a clerk, manager, etc., (person), an actor could be a warehouse bar code scanning device or Point of Sale system that integrates with the Inventory management System.

Fill in the sections with your hypothetical data, overwriting the yellow-highlighted data. Submit the TWO Casual Format Use Cases in ONE document. Do NOT submit any exceptions data. A Casual Format Use Case does not contain exceptions data.

Casual Format Use Case

College of Business | worldwide.erau.edu

All rights are reserved. The material contained herein is the copyright property of Embry-Riddle Aeronautical University, Daytona Beach, Florida, 32114. No part of this material may be reproduced, stored in a retrieval system or transmitted in any form, electronic, mechanical, photocopying, recording or otherwise without the prior written consent of the University.

Requirements Definition

Functional Requirements

1. Functional requirement #1: Seats booking management

1.1. The system should allow user registration.

1.2. The system user interface should be easy to understand.

1.3. The system should notify customers on availability of seats reservations.

2. Functional requirement #2: Payment Management

2.1. The system allows the customer to choose the type of class of the seat.

2.2. The system allows customer to choose the mode of payment.

2.3. The system processes the payments of customers.

Non-Functional Requirements

1. Operational

1.1. The system should be compatible with both PCs and mobile devices to allow customers’ booking at any time.

1.2. The system should run in all browsers.

2. Performance

2.1. The system should have a response time of two seconds maximum.

2.2. The system should update availability of seats every minute.

3. Security

3.1. The system should ensure customer’s accounts and data are safe.

3.2. The system should ensure that users access exactly what they are intended to access.

4. Cultural & Political

4.1. The company requires that all the gadgets needed should be purchased from HP.

4.2. The system should offer translation functionality to enable usage of global customers.

Page 5 of 5

Casual Format Use Case

Create TWO Casual Format Use Cases utilizing the Functional Requirements data from the Attachment 1, Requirements Definition deliverable. Utilize Microsoft Word®.

After reviewing the Attachment 2, consider the possible Use Case Names, actors, descriptions, triggers, and the normal course interactions of the actors with the hypothetical aviation-related Inventory Management System. For example, consider the case of an Airframe Shop Mechanic who uses a fictitious “AAA Aviation AntiCorrosion Spray” in her work. When the mechanic notices that the product is running low in the inventory, she might interact with the IMS to reorder the product.

In a Use Case associated with the above interaction, the Use Case Name is “Order Product.” The actor is “Airframe Shop Mechanic.” The description is “Airframe Shop Mechanic wants to order AAA Aviation AntiCorrosion Spray.” The trigger is “The AAA Aviation AntiCorrosion Spray product is running low in the inventory.” The Normal Course 1.0 title is “Order a product.”

Use Case names are verb-related because a Use Case describes an action taken by a user, such as making an input or requesting an output. Use Case names are NOT noun-related because Use Case names are NOT things. The actor is the user of the Inventory Management System. The actor is a person, a hardware device, or a software system that uses or integrates with the Inventory Management System to achieve a useful goal. For example, besides a clerk, manager, etc., (person), an actor could be a warehouse bar code scanning device or Point of Sale system that integrates with the Inventory management System.

Fill in the sections with your hypothetical data, overwriting the yellow-highlighted data. Submit the TWO Casual Format Use Cases in ONE document. Do NOT submit any exceptions data. A Casual Format Use Case does not contain exceptions data.