Chapter 12 Moving From A BUC to AUCs

In previous chapters we saw the difference between a business use case and an application use case. In this chapter we discuss a process for deriving impacted AUCs from a BUC.

12.1Overview

The BUC includes business process steps making up its workflow. Each of these steps has the option to be automated. The business analyst (BA), systems analyst (often the same person), systems architect and business process owners (BPO) determine between them which steps are to be automated. The systems analyst and architect roles are mainly to determine the time and cost to automate the business process. The BA and BPO will determine the return on investment (ROI) in order to determine if there value in automating a business process.

Once automated steps have been identified (and prioritized) the systems analyst copies each step into a candidate use case (CUC) template. (yes, we are copying, but only temporarily.) The systems analyst works with the CUCs in order to derive functionality that goes into an AUC. Once the AUC has been scoped the CUCs whose functionality was captured by the AUC can be discarded. The CUCs retain traceability to the BUC steps. Prior to being discarded, that traceability is transferred to the AUC.

Impacted objects are added to the AUC. These will initially come from the business objects that were identified during the creation of the BUC. The AUC will supply some attributes and states for these objects.

12.2The Rationale behind the Process

We create CUCs for the automated BUC steps so that they may be manipulated and traceability to the BUC is not lost. Automation of 1 BUC step may be identical or be a partial implementation of another BUC step. The corresponding CUCs will be consolidated into a single AUC and that AUC retains the traceability to both steps. Traceability for the CUCs is graphical. AUC traceability is textual.

12.3Process Details

The following BUC steps are those that were identified as being automated from the restaurant example.

·         The head waiter hands the customer a menu.

·         The table waiter is informed they have a new customer.

·         The table waiter asks the customer for their order.

·         The customer gives their meal order to the table waiter.

·         The table waiter takes the customer order to the kitchen.

·         The meal is ready and the table waiter is informed.

·         The customer asks the waiter for the bill.

·         The table waiter gives the customer the bill.

·         The customer makes a payment to the cashier.

·         The cashier gives the customer a receipt.

·         The customer is not satisfied with their meal.

·         The waiter fetches the head waiter to the table.

The following business rules apply to these steps:

·         The table waiter will request the customer order within 5 minutes of being informed that they have a new customer.

·         The meal will be delivered to the customer within 10 minutes of the customer placing their order.

·         The table waiter will give the customer their bill within 4 minutes of it being requested.

·         The cashier will process the customer’s payment within 2 minutes of the customer initiating payment.

·         Menu items are categorized by ‘Starters’, ‘Entrees’, ‘Desserts’, Soft Drinks’, ‘Alcoholic Drinks’.

Notice that we no longer need the numbering, nor do we care if the step was in the basic workflow or an alternate flow.

The steps have also been modified slightly in order to remove any manual parts.

The steps are prioritized and assigned to an iteration. The following diagram shows just those steps that are slated for iteration 1. I use a dashed line to indicate that these steps are going to be automated.

                                                                                   Figure 1:    BUC Steps For Automation

Note that the ‘Waiting For Food’ and ‘Customer Eating Food’ steps are not automated. For each automated step we create an equivalent candidate application use case (CUC) and place these on activity diagram. (I realize that it is getting crowded, but if we were using a modeling tool we might be able to create a new diagram and re-use the activities and use cases on that diagram.) We connect the use cases to their equivalent action step.

                                                                               Figure 2:    CUCs Tracing From BUC Steps

Now that we have our traceability in place we may work on the CUCs to turn them into AUCs. If a CUC is deleted we must revisit this diagram to fix the traceability. Similarly, if a CUC is created a traceability link should be added to this diagram. The following diagram shows the CUCs and their primary actor.

                                                                            Figure 3:    CUC Diagram With Primary Actors

Now we create a high level description of the application’s functionality within each CUC.

Handing Menu To Customer – The system is displaying the initial menu screen with instructions for the customer. The customer requests the system display the menu. The system displays the menu index to the customer, which contains an overview of each menu category. The customer may select a category and have the system display the items in that category. If there are too many items for a single page the system will indicate this and allow the customer to page through the items in that category. The customer may select any number of items from a category by inputting the number of each item into the system. The system will display the items selected by the customer to the customer, along with a running total of the cost of the customer’s selection.

Asking Customer For Their Order – Anytime that a customer is making a selection of items from the menu system, the customer will be able to select the order option. The customer’s order is displayed to the customer, along an itemized pricing of each item and a total cost. The customer is prompted to verify that everything is correct and that they wish to pay the total cost of the order. The customer may go back to the menu categories and make changes to the selected items, or the customer may confirm the order. Once the order is confirmed a message is displayed to the kitchen containing the ordered items and the table that they are for.

Waiter Is Delivering Food – Once an order has been placed in the pickup area the kitchen will inform the system of where the customer can obtain their food. The system will inform the customer where their food is located. Once the complete meal has been retrieved from the pickup area the system is informed and the system displays the initial menu screen to the customer.

Getting Head Waiter – Anytime that the customer has access to the system they may request assistance from a member of the restaurant’s staff. Upon receiving this request, the system will display a message to the system administrator indicating which table is requesting assistance.

Given these initial use case descriptions it is possible to update the CUC diagram with secondary actors.

                                                                         Figure 4:    CUC Diagram With Secondary Actors

Notice that as a result of writing down the high-level description of the ‘Waiter Is Delivering Food’ use case we discovered that the primary actor wasn’t the customer at all, but the kitchen.

Next we consolidate these CUC cases into AUCs and rename them appropriately. ‘Handing Menu To Customer’ and ‘Asking Customer For Their Order’ are closely related, so let’s combine these into a single use case. (We could move the common functionality concerning selecting items from the menu into an ‘included’ use case fragment. I discourage using ‘includes’ and ‘extends’ relationships, unless they either remove duplication from the use case model, or they add clarity to the model. The objective is to keep the model as simple as necessary, by keeping the number of elements in the model to a minimum.)

The following diagram shows the CUCs converted to appropriate AUC names and the consolidated CUCs.

                                                                                           Figure 5:    Initial AUC Diagram

We need to revisit the BUC activity diagram and clean up the traceability.

                                                                                 Figure 6:    Updated Traceability Diagram

The ‘Handing Menu To Customer’ and ‘Ordering from Menu’ steps both trace to the ‘Order From Menu’ AUC.

Once we have detailed the steps, the ‘Order From Menu’ AUC might look like the following:

12.4Example AUC

This section details the use case.

                                                                                           Figure 7:    Use Case Diagram

12.4.1  Name

Order From Menu

12.4.2  Description

This use case allows a customer to select any number of any items from the menu and request the system place those items as an order. The system updates the customer with a running total of their bill during the ordering process.

12.4.3  Primary Actor

Customer

12.4.4  Supporting Actors

Kitchen, Administrator.

12.4.5  Precondition(s)

The welcome screen is displayed. (This is a manual event that is performed by restaurant staff after the table has been cleaned and made ready for a customer.)

12.4.6  Successful Postcondition

The customer has picked up their food order.

12.4.7  Alternate Postconditions

The administrator is requested to investigate the food order.

12.4.8  Basic Flow

1.      The customer initiates communication with the menu system.

2.      The system displays the ordering instructions to the customer.

3.      The customer requests to display the menu.

4.      The system displays the menu categories to the customer.

5.      The customer selects a category.

6.      The system displays the menu items for that category to the customer.

7.      The customer selects items from the menu.

8.      The system displays the selected items and a running total of their cost.

9.      The customer elects to place their order.

10.  The system displays the order and requests confirmation that it is correct.

11.  The customer confirms the order.

12.  The system displays the order to the kitchen and displays the customer the confirmed order.

13.  The use case ends.

12.4.9  Alternate Flows

A.1   Customer Changes Page

14.  At step 9, the customer changes the page on the menu.

15.  The system displays the selected page menu items.

16.  The use case continues from step 7.

A.2   Customer Changes Category

17.  At step 9, the customer changes the menu category.

18.  The use case continues from step 6.

A.3   Customer Changes Order

19.  At step 11, the customer changes their order.

20.  The use case continues from 4.

12.4.10               Extension Points

None.

                                                                            Figure 8:    Order From Menu Activity Diagram

Note 1: I would question whether these four actions are displaying too much information. I have shown changing pages and selecting categories as alternative flows. I might also have combined these 4 actions into a single activity named 'Selecting Menu Items'.

12.4.11               Performance Requirements

We identify performance requirements for the system.

SUP.1   By default, all responses to the customer will occur within 2 seconds.

SUP.2   All responses to selecting menu items on a page will occur within .5 seconds.

SUP.3   When the customer places an order the kitchen staff will be informed within 30 seconds.

12.4.12               Supplementary Requirements

Finally we need to look at the business rules for the BUC and determine if any of these apply to our AUC.

SUP.4   Menu items will be categorized in the following order; ‘Starters’, ‘Entrees’, ‘Desserts’, Soft Drinks’, ‘Alcoholic Drinks’.

12.5Impacted Potential Objects

We identify an initial set of objects and some potential states. These will probably change when modeled in class and state diagrams during the analysis and design activities.

                                                                                Figure 9:    Activity Diagram With Objects[1]

Where an object might take a state, I have entered the state under the object name. For example, the Order Display may be either in a ‘Confirmed’ state or an ‘Unconfirmed’ state.

12.6Summary

We saw a process for automating a Business Use Case (BUC), by detailing the steps of the BUC with an activity diagram, identifying which steps are to be automated, assigning these to Candidate Use Cases(CUCs), then working the CUCs to turn them into Application Use Cases.

We identify performance requirements for the AUC steps and any supplementary requirements that may be derived from the business rules.

Finally, we add potentially impacted objects to the AUC activity diagram.