Chapter 13 Moving From A Buc To Aucs: Les Munday Universe, 2010

Analysis Through Pictures Moving From A BUC To AUCs
Version 0.1 Chapter 13
Chapter 13 Moving From A BUC to AUCs

In 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 be
partially automated.
Contents
13.1 Overview
13.2 The Rationale behind the Process
13.3 Process Details
13.3.1 Identify Objects For automation
13.3.2 Assign Activities To CUCs
13.3.3 Assign Actors To CUCs
13.3.4 Identify Supplementary Requirements
13.3.5 Convert CUCs To AUCs
13.3.6 Build An AUC Diagram
13.4 Example AUC
13.5 Potentially Impacted Objects
13.6 Summary
Updated: 8/20/2010 7:26 PM Les Munday Universe, 2010 Page 1 of 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 mainly
concerned 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 step
into 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 extent
that 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. (This
work 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 Process
CUCs 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 will
consolidated 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 or
it 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 Details
Figure 1: and Figure 2: show the Serve Customer BUC steps with highlights on those steps that
are to be automated.

Figure 1: Serve Customer BUC Steps1

Figure 2: Serve Customer BUC Steps2

[Step 8 has been broken into 2 steps, since it would have previously been only partially
automated.]
The following steps are the candidates for automation:
The head waiter arranges seating for the customer.
The head waiter hands the customer a menu.
The head waiter informs the table waiter 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 kitchen informs the table waiter.
The waiter fetches the head waiter to the table.
13.3.1 Identify Objects For automation
These steps are highlighted in the BUC activity objects diagram as shaded activities shown in
Figure 3:.

Informing Table Waiter : Waiter Request

: Greeting Greeting The Customer
Arranging Seating : Table Delivering To Table : Meal
Customer Eating
: Cloakroom Request Asking About Cloakroom
Preparing Bill
: Bill
: Customer Belongings Taking Customer Belongings
Delivering Bill
: Table Taking Customer To Table
Cleaning Table : Table
: Menu Handing Menu To Customer
: Token
: Payment
: Waiter Request Informing Table Waiter Taking Payment
: Receipt
Taking Order
: Order
Returning Customer Belogings : Customer Belongings
Delivering Order To Kitchen
Preparing Food Getting Head Waiter : Head Waiter Request

: Kitchen
: Meal
Resolving Customer Complaint : Complaint

Delivering To Table
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

Informing Table Waiter -> Waiter Request
Taking Order -> Order
Delivering Order To Kitchen -> Kitchen
Informing Table Waiter -> Waiter Request
Getting 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:.
Assign Customer To
Arranging Seating Table
Table
Initiate Menu Handing Menu To Customer Menu
Browse Menu Informing Table Waiter Waiter Request
Order From Menu Taking Order Order
Deliver Menu Order Delivering Order To Kitchen Kichen
Inform Meal Ready Informing Table Waiter Waiter Request
Request Assistance Getting Head Waiter Head Waiter Request
Figure 4: Activities Assigned CUCs

The candidate use cases will automate the functionality of the activity to which they are
assigned. 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 intended
function. From the description, primary and secondary actors are identified.
Assign Customer To Table – The system displays a restaurant layout that identifies whether a
table is occupied or not. The head waiter may assign customers to tables, set the table status
to ‘free’ or reserve and unreserved tables. Primary Actor – Head Waiter; Secondary Actors –
None.
Initiate Menu – When a customer has been assigned to the table and the customer initiates
communication with the system, it displays instructions for use to the customer, . Primary
Actor – Customer; Secondary Actors – None.
Browse Menu – 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 an item from a
category and have the display its description to the customer. Primary Actor – Customer;
Secondary Actors – None.
Order From Menu – The customer may select any number of items from a category for their
order. 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
customer’s selection. Primary Actor – Customer; Secondary Actors – None.
Deliver Menu Order – The system will allow the customer to place their order with the
kitchen. 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. Primary Actor –
Customer; Secondary Actors - Kitchen.
Inform Meal Ready – The system will allow the kitchen to inform each customer table when
their meal is ready for pickup and instructions for retrieving their order. Primary Actor –
Kitchen; Secondary Actors – Customer.
Request Assistance – Anytime that the customer has access to the system they may request
assistance from the head waiter. Upon receiving this request, the system will display a
message 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

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

Assign Customer To
Table
Head Waiter
Initiate Menu
Customer
Browse Menu
Customer
Order From Menu
Customer
Deliver Menu Order
Kitchen Kitchen
Inform Meal Ready
Customer Customer
Request Assistance
Customer Head Waiter
Figure 5: Candidate Use Cases With Actors

Note that the use cases are now candidate AUCs, and therefore the primary actor is the role that
initiates the use case (not necessarily the person gaining benefit).
13.3.4 Identify Supplementary Requirements
The following business rules need to considered, since they were applied to the steps from which
the CUCs were derived.
1. The table waiter will request the customer order within 5 minutes of being informed that
they have a new customer.
2. The meal will be delivered to the customer within 10 minutes of the customer placing
their order.
3. Menu items are categorized by ‘Starters’, ‘Entrees’, ‘Desserts’, Soft Drinks’, ‘Alcoholic
Drinks’.
These may be transformed into system supplementary requirements, as follows:
1. The system will respond to customer commands within 2 seconds. (It was calculated that
this requirement allows a customer to order a typical meal within 5 minutes and also
introduces usability requirements into the system.)
2. The system will inform the kitchen within 5 seconds of a customer placing an order. The
customer will be informed within 5 seconds when the kitchen has indicated that the meal
is ready for pickup. (The time for the kitchen to prepare the meal is not enforced by the
system, but the time before and after preparation of the meal may be.)
3. Menu categories will be customizable, with the minimum categories being ‘Starters’,
‘Entrees’, ‘Desserts’, Soft Drinks’, ‘Alcoholic Drinks’. All menu items are assigned to a
specific category. (An additional supplementary requirement may be derived for the
system; Menu Items and Categories may change on a daily basis. The system will obtain
the days categories and menu items from the restaurant database.)
The system supplementary requirements are not necessarily traceable to the business rules, but
they should be checked to ensure that no BRs are being broken by the implementation of the
system.
Supplementary requirements, such as the customization requirements, will mostly be derived
from stakeholder requests. [Introducing a supplementary requirement without a request from a
stakeholder is not a good idea. Supplementary requirements are owned by IT. IT should only
work from requirements that have been approved by a stakeholder.]
13.3.5 Convert CUCs To AUCs
The CUCs may now be edited to convert them into AUCs.

Figure 6: shows each of the CUCs on a use case diagram without actors. The CUCs are
connected to AUCs with ‘include’1 relationships, to represent that the functionality of the CUC
has been captured by the AUC.
CUCs::Assign Customer To
AUCs::Maintain Restaurant «include»
Table
CUCs::Initiate Menu
«include»
CUCs::Order From Menu

«include»
AUCs::Order From Menu

«include»
CUCs::Browse Menu
«include»
CUCs::Deliver Menu Order
AUCs::Request Assistance «include» CUCs::Request Assistance
AUCs::FulFill Menu Order «include» CUCs::Inform Meal Ready
Figure 6: Traceability Between CUCs and AUCs Diagram
1
This is not a proper use of the ‘include’ relationship.
2
For some reason, when copying activity diagrams, Visio insists on removing the labels from the control flows.
A Maintain Restaurant AUC will capture the functionality associated with assigning customers
to tables.
The ‘Initiate Menu’, ‘Browse Menu’, ‘Order From Menu’ and ‘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 are
added to the diagram and shown as being related to the now consolidated AUCs.

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
Head Waiter
Order From Menu
Customer Kitchen
Request Assistance
Customer Head Waiter
FulFill Menu Order
Kitchen Customer
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
archived – they do not need to change from this point on.

Traceability is now added from the BUC steps to each AUC, by relatng the AUC to the BUC
steps 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 named
Assign Customer To table.) This AUC is concerned with defining the status of tables in the
restaurant. For example, tables may be reserved, occupied or available.
Order From Menu (Priority 1) – This use case is concerned with allowing a customer to
select items from the day’s 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 of
restaurant 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 that
they 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 From
Menu’ 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:.

Figure 8: Use Case Details-1



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

Welcome Displayed
customerAssignedToTable
Displaying Instructions
menuSelected
customerCancelled
Displaying Menu Categories
Customer Cancelled
categorySelected
customerCancelled
categorySelected Selecting Category Items
orderUnconfirmed
Customer Cancelled
categoryCommandEntered
Command? itemSelected
Displaying Selected Item
orderSelected
customerCancelled
Displaying Order
Customer Cancelled Customer Cancelled
orderCommandEntered
Order Confirmed?
orderConfirmed
Displaying Customer Order Displaying Order To Kitchen
confirmedOrderDisplayed confirmedOrderDisplayed
Use Case Ends
Order Completed
Figure 11: Order From Menu Activity Diagram

The supplementary requirements are initially captured in subsequent sections of the AUC
document.
Figure 12: Use Case Supplementary Requirements

Figure 12: shows the performance, interface and other supplementary requirements as captured
by 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 class
diagrams.

Customer Displaying Instructions Table
Customer Displaying Menu Categories Menu
Customer Selecting Category Items Category
Customer Displaying Selected Item MenuItem
Customer Displaying Order Order
Displaying Confirmed Order Displaying Order To Kitchen
Kitchen
2
Figure 13: AUC Activities With Objects
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 the
AUC.
The object descriptions are as follows:
Customer – This object represents the user interface to the customer table.
Menu – This object represents the menu layout in terms of categories.
Category – This object represents an available category and all of the menu items that are
available within the category.
2
For some reason, when copying activity diagrams, Visio insists on removing the labels from the control flows.

MenuItem – This object contains a description of a selectable menu item.
Order – This object maintains the menu items that are selected (or deselected), by the customer,
along with a running total of their cost.
Kitchen – This object represents the kitchen display.
Table – Allows 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.

Chapter 13 Moving From A Buc To Aucs: Les Munday Universe, 2010

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 13 Moving From A Buc To Aucs: Les Munday Universe, 2010

Uploaded by

Copyright:

Available Formats

Analysis Through Pictures Moving From A BUC To AUCs

Version 0.1 Chapter 13

Chapter 13 Moving From A BUC to AUCs

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

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

Figure 1: Serve Customer BUC Steps1

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

Figure 2: Serve Customer BUC Steps2

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

Informing Table Waiter : Waiter Request

Arranging Seating : Table Delivering To Table : Meal

: Cloakroom Request Asking About Cloakroom

: Customer Belongings Taking Customer Belongings

: Table Taking Customer To Table

Cleaning Table : Table

: Menu Handing Menu To Customer

: Waiter Request Informing Table Waiter Taking Payment

Delivering Order To Kitchen

Preparing Food Getting Head Waiter : Head Waiter Request

Resolving Customer Complaint : Complaint

Figure 3: Candidate Automated BUC Steps

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

Initiate Menu Handing Menu To Customer Menu

Browse Menu Informing Table Waiter Waiter Request

Order From Menu Taking Order Order

Deliver Menu Order Delivering Order To Kitchen Kichen

Inform Meal Ready Informing Table Waiter Waiter Request

Request Assistance Getting Head Waiter Head Waiter Request

Figure 4: Activities Assigned CUCs

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

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

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

Order From Menu

Deliver Menu Order

Inform Meal Ready

Customer Head Waiter

Figure 5: Candidate Use Cases With Actors

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

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

CUCs::Order From Menu

AUCs::Order From Menu

CUCs::Deliver Menu Order

AUCs::Request Assistance «include» CUCs::Request Assistance

AUCs::FulFill Menu Order «include» CUCs::Inform Meal Ready

Figure 6: Traceability Between CUCs and AUCs Diagram

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

Order From Menu

Customer Head Waiter

FulFill Menu Order

Figure 7: AUC Diagram

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

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

Figure 8: Use Case Details-1

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

Figure 9: Use Case Details-2

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

Figure 10: Use Case Details-3

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

Displaying Customer Order Displaying Order To Kitchen

Use Case Ends

Figure 11: Order From Menu Activity Diagram

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