Page 225 -

192 Part 3 • the analysis Process

Event Source Trigger Activity Response Destination
Customer Customer Customer number Find customer record Welcome Web Customer
logs on and password and verify password. page
Send Welcome Web
page.
Customer Customer Item information Find item price and Item Response Customer
browses items quantity available. Web page
at Web Send Item Response
storefront Web page.

Customer Customer Item purchase (item Store data on Order Items Customer
places item into number and Detail Record. Purchased Web
shopping quantity) Calculate shipping page
basket at Web cost using shipping
storefront tables.
Update customer total.
Update item quantity
on hand.
Customer Customer Clicks “Check Out” Display Customer Verification Web
checks out button on Web page Order Web page. page
Obtain Customer Credit card Verify credit card Credit card data Credit card
customer information amount with credit company
payment card company. Customer
Send. feedback Customer

Send customer Temporal, hourly Send customer an Customer
email email confirming
shipment.

Figure 7.12
An event response table for an Internet storefront.

USE CASES AND DATA FLOW DIAGRAMS. In Chapter 2, we introduced the concept of a use case.
We use this notion of a use case in creating data flow diagrams. A use case summarizes an event
and has a similar format to process specifications (described in Chapter 9). Each use case defines
one activity and its trigger, input, and output. Figure 7.14 illustrates a use case for Process 3, Add
Customer Item.
This approach allows an analyst to work with users to understand the nature of the processes
and activities and then create a single data flow diagram fragment. When creating use cases, you
should first make an initial attempt to define the use cases without going into detail. This step
provides an overview of the system and leads to the creation of Diagram 0. Then you can decide
what the names should be and provide a brief description of each activity. List the activities,
inputs, and outputs for each one.
You should make sure to document the steps used in each use case. These should be in the
form of business rules that list or explain the human and system activities completed for each
use case. If at all possible, you should list them in the sequence that they would normally be
executed. Next, you can determine the data used by each step. This step is easier if a data diction-
ary has been completed. Finally, you need to ask the users to review and suggest modifications
of the use cases. It is important that the use cases be written clearly. (See Chapter 10 for a further
discussion of UML, use cases, and use case diagrams.)

Partitioning Data Flow Diagrams
Partitioning is the process of examining a data flow diagram and determining how it should be
divided into collections of manual procedures and collections of computer programs. You should
analyze each process to determine whether it should be a manual or automated procedure. Then
you can group automated procedures into a series of computer programs. It can be helpful to