business use cases

8/8/2019 Business Use Cases

1/21

Analysis Through Pictures Moving From A BUC To AUCs

Version 0.1 Chapter 13

Updated: 8/20/2010 7:26 PM Les Munday Universe, 2010 Page 1 of 21

Chapter 13 Moving From A BUC to AUCsIn previous chapters we saw the difference between a Business Use Case and an Application Use

Case. This chapter discusses a process for deriving impacted AUCs from a BUC that is to bepartially automated.

Contents

13.1 Overview13.2 The Rationale behind the Process13.3 Process Details

13.3.1 Identify Objects For automation13.3.2 Assign Activities To CUCs13.3.3 Assign Actors To CUCs13.3.4 Identify Supplementary Requirements13.3.5 Convert CUCs To AUCs13.3.6 Build An AUC Diagram

13.4 Example AUC13.5 Potentially Impacted Objects13.6 Summary


2/21




13.1 Overview

The BUC contains business process steps that are described within workflows. Each of these

steps has the option to be automated. The Business Analyst (BA), Systems Analyst (SA) (often

the same person), Systems Architects and Business Process Owners (BPO) determine between

them which steps are to be automated. The systems analyst and architect roles are mainlyconcerned with determining the time and cost to automate the business process. The BA and

BPO will determine the return on investment (ROI) of automation, in order to decide if there is

value in automating a business process.

Once automated steps have been identified (and prioritized) the systems analyst copies each stepinto a candidate use case (CUC) diagram template. (The copying process is only temporary since

the CUCs are not maintained throughout the system lifecycle.) The systems analyst works with

the CUCs in order to derive functionality that goes into an AUC. Once an AUC has been scoped,

the CUCs whose functionality has been captured by the AUC can be archived (made read-only).The CUCs retain traceability to the BUC steps, but they do not need to be updated, nor does the

traceability. The CUC traceability is then transferred to the AUC.

(Note that since the CUCs are not maintained, changes to the BUC model are assumed to impact

the AUC model via the traceability links. If the changes to the BUCs are of such a large extentthat this is not possible, then the BUC To CUC process is started from the beginning.)

Impacted objects are added to the AUC details. These initially come from the business objects

that were identified during the creation of the BUC. The AUC will supply some additional

attributes and states for these objects, and may transform them into other system objects. (Thiswork does not discuss traceability between business and application objects. This is an activity

that may be easily added to the process if validation of the implementation of business data is

considered necessary.)

13.2 The Rationale behind the ProcessCUCs are created to represent the automated BUC steps. This is so that the steps may be

manipulated and traceability to the BUC is not lost. Automation of 1 BUC step may be identical

to, or be a partial implementation of another BUC step. The corresponding CUCs willconsolidated duplicate BUC steps into a single AUC and that AUC retains the traceability to

both steps. Traceability to the CUCs from the BUC steps is described graphically. AUC

traceability from the BUC steps is textual.

(Note it is assumed that a BUC step is never partially automated. Either it is either automated orit is not. This means that if only part of a BUC step is identified for automation, the step can be

broken in substeps, for automation and not automation, within the BUC.)

13.3 Process DetailsFigure 1: and Figure 2: show the Serve Customer BUC steps with highlights on those steps that

are to be automated.


3/21




Figure 1: Serve Customer BUC Steps1


4/21


5/21




Taking Order

Taking Customer To Table

Taking Customer Belongings

Asking About Cloakroom

Greeting The Customer

Delivering Order To Kitchen

Preparing Food

Delivering To Table

Preparing Bill

Delivering Bill

Taking Payment

Getting Head Waiter

Cleaning Table

Resolving Customer Complaint

Returning Customer Belogings

Customer Eating

: Greeting

: Cloakroom Request

: Customer Belongings

: Menu

: Order

: Meal

: Bill

: Table

: Payment

: Customer Belongings

: Token

: Head Waiter Request

: Complaint

: Receipt

Informing Table Waiter


Handing Menu To Customer

: Table

: Waiter Request

Delivering To Table : Meal

: Waiter Request

: Table

: Kitchen

Arranging Seating

Figure 3: Candidate Automated BUC Steps

The diagram shows that the following activities and their associated business objects are

candidates for automation:

Arranging Seating -> Table

Handing Menu To Customer -> Menu


6/21




Informing Table Waiter -> Waiter Request

Taking Order -> Order

Delivering Order To Kitchen -> Kitchen

Informing Table Waiter -> Waiter RequestGetting Head Waiter -> Head Waiter Request

Notice that step numbering is no longer needed, nor do we care if the step was in the basic

workflow or an alternate flow.

13.3.2 Assign Activities To CUCs

Each candidate activity is assigned to a Candidate Use Case (CUC), as shown in Figure 4:.


Delivering Order To Kitchen


Taking Order

Handing Menu To Customer

Getting Head Waiter

Menu

Order

Head Waiter Request

Deliver Menu Order

Order From Menu

Request Assistance

Browse Menu

Table

Kichen

Waiter RequestInform Meal Ready

Arranging SeatingAssign Customer To

Table

Waiter Request

Initiate Menu

Figure 4: Activities Assigned CUCs


7/21




The candidate use cases will automate the functionality of the activity to which they areassigned. The business objects identify the data that the CUC may have to handle.

Traceability from BUC steps to CUCs is now established. Prior to baselining the AUCs, if a

CUC is deleted this diagram is edited to fix the traceability. Similarly, if a CUC is created a

traceability link should be added to this diagram.The CUCs are transferred to a use case diagram and given a basic description of their intendedfunction. From the description, primary and secondary actors are identified.

Assign Customer To TableThe system displays a restaurant layout that identifies whether atable is occupied or not. The head waiter may assign customers to tables, set the table status

to free or reserve and unreserved tables. Primary ActorHead Waiter; Secondary Actors

None.

Initiate MenuWhen a customer has been assigned to the table and the customer initiatescommunication with the system, it displays instructions for use to the customer, . Primary

Actor Customer; Secondary ActorsNone.

Browse MenuThe customer requests the system display the menu. The system displays themenu index to the customer, which contains an overview of each menu category. Thecustomer 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 an item from acategory and have the display its description to the customer. Primary ActorCustomer;

Secondary ActorsNone.

Order From MenuThe customer may select any number of items from a category for theirorder. Items may be added or removed from the order. The system will display the items

selected by the customer to the customer, along with a running total of the cost of the

customers selection. Primary ActorCustomer; Secondary ActorsNone.

Deliver Menu OrderThe system will allow the customer to place their order with thekitchen. 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 customers order is displayed to thecustomer, 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. Thecustomer 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. Primary Actor

Customer; Secondary Actors - Kitchen.

Inform Meal ReadyThe system will allow the kitchen to inform each customer table whentheir meal is ready for pickup and instructions for retrieving their order. Primary Actor

Kitchen; Secondary ActorsCustomer.Request AssistanceAnytime that the customer has access to the system they may requestassistance from the head waiter. Upon receiving this request, the system will display amessage to the head waiter indicating which table is requesting assistance. The head waiter

may cancel the assistance request at any time. Primary Actor Customer; Secondary Actors

Head Waiter.

13.3.3 Assign Actors To CUCs


8/21




Figure 5: shows the CUCs transposed to a use case diagram and the primary and secondaryactors added.


9/21




Assign Customer ToTable

Browse Menu

Order From Menu

Deliver Menu Order

Inform Meal Ready

Request Assistance

Head Waiter

Customer

Kitchen

Customer

Head Waiter

Kitchen

Customer

Customer

Initiate Menu

Customer

Customer

Figure 5: Candidate Use Cases With Actors


10/21


11/21




Figure 6: shows each of the CUCs on a use case diagram without actors. The CUCs are

connected to AUCs with include1 relationships, to represent that the functionality of the CUC

has been captured by the AUC.

AUCs::Order From Menu

AUCs::Request Assistance

CUCs::Assign Customer ToTable

AUCs::FulFill Menu Order

CUCs::Browse Menu

CUCs::Deliver Menu Order

CUCs::Inform Meal Ready

CUCs::Order From Menu

CUCs::Request Assistance

include

include

include

include

include

include

AUCs::Maintain Restaurant

CUCs::Initiate Menu

include

Figure 6: Traceability Between CUCs and AUCs Diagram

1This is not a proper use of the include relationship.

2For some reason, when copying activity diagrams, Visio insists on removing the labels from the control flows.


12/21




A Maintain Restaurant AUC will capture the functionality associated with assigning customersto tables.

The Initiate Menu, Browse Menu, OrderFrom Menuand Deliver Menu Order CUCs are

closely related. These are combined into a single use case named; Order From Menu.

Request Assistance remain as independent application use cases.

Inform Meal Ready is captured with Fulfill Menu Order AUC. (This AUC will be concerned

with billing the customer, in a future iteration of the application.)

13.3.6 Build An AUC Diagram

The AUCs are transferred to their own AUC diagram. The actors that are related to the CUCs areadded to the diagram and shown as being related to the now consolidated AUCs.


13/21




Figure 7: shows the AUCs on an AUC diagram and the primary and secondary actors attached,as with associated primary and secondary actors.

Maintain Restaurant

Request Assistance

Order From Menu

FulFill Menu Order

Head Waiter

Customer Kitchen

Kitchen Customer

Customer Head Waiter

Cashier

Figure 7: AUC Diagram(Note that although the CUCs may have had several primary actors prior to consolidation into

AUCs, only the actor initiating the use case is shown as the primary actor on the AUC diagram.Any other primary actors become secondary.) The CUCs and their supporting diagrams may be

archivedthey do not need to change from this point on.


14/21




Traceability is now added from the BUC steps to each AUC, by relatng the AUC to the BUCsteps that it was derived from. (This traceability activity is performed in SharePoint and is

described in Chapter 19.)

The AUCs are now scoped by giving an overview description of their responsibilities, and

assigned a priority. Their descriptions are as follows:Maintain Restaurant (Priority 2)(This description is similar to that of the CUC namedAssign Customer To table.) This AUC is concerned with defining the status of tables in therestaurant. For example, tables may be reserved, occupied or available.

Order From Menu (Priority 1)This use case is concerned with allowing a customer toselect items from the days menu and add them to their order, which may be submitted to the

kitchen upon customer request.

Request Assistance (Priority 2)This AUC allows the customer to request the attention ofrestaurant staff.

Fulfill Menu Order (priority 3)- This AUC is concerned with aspects of serving the customer

after they have placed their order. This includes ensuring that their order is delivered and thatthey a billed correctly.

At this point in the life-cycle, the project has entered the Elaboration Phase (see RUP), and the

use cases may each be assigned to their own iteration.

Iteration 1 is going to implement all priority 1 use cases; iteration2 priority 2 and so on. For the

purposes of detailing the AUCs, only iteration 1 AUCs are considered. (That is the Order FromMenu AUC.)

The details of the Order From Menu AUC are shown in the following diagrams.

13.4 Example AUC

Section 2 of the AUC document contains details the use case, as shown in Figure 8:, Figure 9:Figure 10:and Figure 11:.


15/21




Figure 8: Use Case Details-1


16/21






17/21





The activity diagram for the Order From Menu use case is shown in Figure 11:.


18/21




Welcome Displayed

customerAssignedToTable

Displaying Instructions

menuSelected

Displaying Menu Categories

categorySelected

Selecting Category Items

Displaying Order

orderSelected

categorySelected

Displaying Customer Order

orderConfirmed

Displaying Order To Kitchen

confirmedOrderDisplayed

Displaying Selected Item

categoryCommandEntered

confirmedOrderDisplayed

Order Confirmed?

orderUnconfirmed

orderCommandEntered

Command? itemSelected

Order Completed

Use Case Ends

Customer Cancelled

customerCancelled

customerCancelled

customerCancelled

Customer CancelledCustomer Cancelled

Customer Cancelled

Figure 11: Order From Menu Activity Diagram


19/21




The supplementary requirements are initially captured in subsequent sections of the AUCdocument.

Figure 12: Use Case Supplementary Requirements

Figure 12: shows the performance, interface and other supplementary requirements as capturedby the AUC document.

13.5 Potentially Impacted Objects

Using the use case details, a potential set of impacted objects is identified. These are input to the

analysis and design activities, but will certainly change during modeling of the system with classdiagrams.


20/21




Displaying Instructions

Displaying Menu Categories

Selecting Category Items

Displaying Order

Displaying Confirmed Order Displaying Order To Kitchen

Displaying Selected Item

Customer

Customer Menu

CategoryCustomer

Customer

Customer

MenuItem

Order

Kitchen

Table

Figure 13: AUC Activities With Objects2

Figure 13: shows potentially impacted objects for the Order From Menu AUC. Each activity has

input data and an output recipient. The customer in this case, is an object retained by the system

to represent the customer initiating the use case, and is not the same as the primary actor of theAUC.

The object descriptions are as follows:

CustomerThis object represents the user interface to the customer table.MenuThis object represents the menu layout in terms of categories.

CategoryThis object represents an available category and all of the menu items that are

available within the category.

2For some reason, when copying activity diagrams, Visio insists on removing the labels from the control flows.


21/21



Updated: 8/20/2010 7:26 PM L M d U i 2010 Page 21 of 21

MenuItemThis object contains a description of a selectable menu item.

OrderThis object maintains the menu items that are selected (or deselected), by the customer,along with a running total of their cost.

KitchenThis object represents the kitchen display.

TableAllows the system to track where customers are located within the restaurant.

(It might be prudent to check that these objects capture all of the business object information in

the BUC steps that are being automated by this AUC.)

13.6 Summary

This chapter describes 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), and then working with the CUCs to turn the

automated steps into Application Use Cases.

Performance, interface and other supplementary requirements are identified for the AUC steps.Some of these may be derived from the business rules impacting the BUCs, others from

elsewhere (such as stakeholder requests).

Finally, potentially impacted objects are added to the AUC activity diagram.

The next step in the process is to build upon the potential objects that were discovered by

modeling the AUC with classes.

business use cases

Documents