CHAPTER 3
The XCellR8™ Approach:
The Event Process Model

The event process model (EPM), which gives essential details about a business event and the process that supports it, is the most important part of the system documentation for your business partners and users. Business partners and users think in terms of what the system does; system developers consider what data the system must have access to in order to support the business. Business requirements gathering is thus focused on defining processes and identifying objects and their relationships. Your users, however, will naturally want to focus on understanding the process. You can gain their support by creating event process models that demonstrate your understanding of what their systems must do. We’ll begin by explaining the components of an event process model.

Parts of the Event Process Model

An event process model is composed of a data flow diagram (DFD) and accompanying descriptive text known as a process description.

A DFD is a visual representation of the process that supports an event (Figure 3-1). It should show what triggers the event as well as the data that flow in and out of the process. The DFD shows the input, the process, and the output. An event that does not have a result (output) is a nonevent.

FIGURE 3-1: Data Flow Diagram for Receipt of an Insurance Claim

Actor. An actor is an external entity over which the target business system has no measurable control. It may be the source of the trigger to the process, or the final destination of a result from the process. An actor may be an external system with which the target system interfaces. In Figure 3-1, INSURED in the shaded box is an actor; he or she is an external entity. By submitting a claim, he or she becomes the initiator of the process. The submission of the claim is the trigger.

A DFD may show one or more than one actor or no actors.

Process and process name. The process is represented as a bubble. Its name begins with a verb, indicating action. In this example, the name of the process responding to the business event A claim arrives is Receive a Claim.

Object. In the above example, Insured, Claim, and Policy are all objects. An object is a noun—a person, place, thing, or concept. It contains essential information required by the business processes. An object defines specific data that may need to be stored or recorded in order to remember who, where, or what was processed. Objects participate in events.

An object is always given a singular name—such as “insured,” “claim” or “policy”—when it is identified as part of an event process model. Remember that the event process model is a model for an event. This implies that the objects identified in the model are the same objects that the business needs no matter how many times the event occurs.

The process description is a description of the tasks performed within the process. It should be written in nontechnical terms. A process description to accompany Figure 3-1 might look something like this:

A data flow represents the directional movement of information between a process and an object or an actor. It is always advisable to label the data flow itself to identify what data is going into or coming out of a process.

Figure 3-2 is another example of a data flow diagram for the event A customer makes a deposit into his or her bank account. The corresponding process is called Receive customer deposit.

FIGURE 3-2: Data Flow Diagram for Receiving a Customer Deposit

Note that we have named the objects in the singular form: Customer, not Customers; Deposit, not Deposits, and Account, not Accounts. This model illustrates the process for receiving a deposit from a customer, and it does not matter how many times the event happens. It could happen once, twice, or a hundred times. The same objects will be required to support it. Think of the Customer object as a file folder containing records of different Customers and Deposit as a file folder containing deposit records.

When you aren’t sure about what information may be needed to support an event, look at the event name to extract objects. For example, if the event name is A customer makes a deposit into his or her bank account, look for the nouns in the name, such as Customer, Deposit, and Account. If the event name is Order is delivered by vendor, look for the nouns: Order, Vendor, and the noun form of the verb in the event, Delivery.

Very often, users will give you information that might not seem relevant for the event you are analyzing. Don’t ignore this. Instead, ask the user, “What does this data allow you to do?” The answer to this question may lead you to another event, which may or may not be within the scope of the project. Never ask “why”—as in, “Why do you need that information?” Asking “why” tends to make your client defensive and does not help the progress of your session.

Business Event Triggers

When developing the data flow diagram, you must first identify the trigger to the business event. A trigger is something that initiates or starts a process. If the event begins with the phrase “It is time to …,” ask “When is it time to … ?” For example, if the event is It is time to evaluate customer feedback, ask “When is it time to evaluate customer feedback?” The answer might be, “We need to evaluate customer feedback as soon as it is received.” Therefore, the trigger of this event is Receipt of a customer feedback.

If the event is an external event, someone or something outside the process is initiating the event. For example, for the event Customer complains about the service, no response is required until a customer makes a complaint. The trigger to this event, then, is the customer’s submitting a complaint by mail, telephone, or any other means available. An event may have more than one trigger. Each trigger may require a different response.

A process may be shared by more than one event. In the above example, Customer complains about the service, the event could be restated as Customer submits feedback. The response to this event, the submission of feedback, might be the same whether the feedback is a complaint or a compliment.

Exercise: Creating Event Process Models for an Internal Technical Support System

Sterling Corporation (a fictional company) is instituting a new method for providing technical support to all employees. The system will allow the organization to track problems reported and measure performance based on the speed and accuracy of resolving problems. These are the business rules that will apply to the system:

Only active employees within the organization may report a problem. A problem report may pertain to hardware or software assigned to the employee.

A problem may be reported by phone or by email.

The problem report is to be logged by the technician who receives the call or email message.

The problem report should then be assigned to the first available technician who is qualified to solve the problem.

If the problem has not been solved within three hours from the time it was reported, it must be reassigned to the next available, qualified technician.

If a problem is reassigned to the original technician, the help desk manager must be alerted so that he can take further action.

When the company president (or her executive assistant) reports a problem, her problem must be assigned the highest priority.

A problem is not considered resolved until the employee reporting the problem agrees that the problem no longer exists.

Your mission:

1. Identify at least two events for this system.

2. Create an event process model for each event.

3. Identify objects and data attributes.

Possible Solution

(As you continue to analyze the events you identify, you will discover many more.)

Events:

Employee reports a problem (Figure 3-3).

Assign a problem to a technician (Figure 3-4).

A problem is resolved (Figure 3-5).

Employee Reports a Problem

Data Flow Diagram

FIGURE 3-3: Data Flow Diagram for Receiving a Problem Report

Process Description

For each problem report received from an EMPLOYEE,

Determine if Employee is recognized and active.

If not, reject the problem report.

If so, determine whether employee has already reported the Problem.

     If so, reject the problem report.

     If not, record the following information:

• Problem description

• Date and time the Problem is reported

• Date and time the Problem occurred

• Type of Problem (hardware or software)

  • • If hardware:
        –Hardware ID number

  • • If software:
        –Software name
        –Software version.

Confirm the receipt of the problem report.

This process description describes what the process should be according to the business rules and includes all the required information without using technical jargon. It does not talk about “how”—how the problem report comes in, how we determine if the employee is recognized and is active, how we would reject the problem report, or how we confirm receipt of the report. These questions are all answered when it is time to design the system. This does not mean, however, that you will completely ignore the design of the current system. The current “how” may, in fact, be the problem.

If you are required to write the requirements as system capability statements, you can extract these from the process description. You might write statements like these.

The system must be capable of:

Determining if an employee making a request for help is active

Determining if the problem has already been reported by the employee

Recording or logging the problem reported, including information such as problem description, date and time the problem is reported, date and time the problem occurred, and type of problem

Confirming receipt of the problem report.

As you can see, it is not necessary to write capability statements about processes because they are already identified in the process description. You may, however, need to write capability statements for nonfunctional requirements such as “The system must be capable of handling 24/7 problem reporting activity,” “The system must be capable of accepting problem reports via email,” or “The system must be capable of handling a minimum of 1,000 problem reports a day.”

Assign a Problem to a Technician

Data Flow Diagram

FIGURE 3-4: Data Flow Diagram for Assigning a Problem to a Technician

Process Description

For each problem report received,

Business rules are incorporated into the process description. At the hypothetical Sterling Corporation, there is a business rule stating that a problem should be assigned to the first available, qualified technician. The technician is considered qualified if he or she is able to solve a specific type of problem (hardware or software). Another business rule says that if no qualified technician is found, the help desk manager should be alerted so that he can decide to whom the problem should be assigned (alternatively, he might decide to handle it himself).

A Problem Is Resolved

Data Flow Diagram

FIGURE 3-5: Data Flow Diagram for Closing a Technical Problem

Process Description

For each Problem that has a Resolution,

Update the Resolution of the problem as final, and close the Problem. You can see that the process description does not just detail what to do in response to an event; it also describes under what circumstances the activity should be performed, as well as what information is required to support the business event.

Event Process Models in Everyday Situations

This approach can also be used for day-to-day occurrences such as dining out. Let’s take a look at a simple event from a restaurant’s perspective (Figure 3-6):

A Restaurant Receives a Reservation
Request from a Customer

Data Flow Diagram

FIGURE 3-6: Data Flow Diagram for Receiving a Restaurant Reservation Request

Process Description

For each Reservation Request received from a CUSTOMER,

If the restaurant must retain the customer information, a Customer object should be included in the data flow diagram. If not, the customer information may simply be included as part of the reservation object.

Let’s look at the same event from your (the customer’s) perspective (Figure 3-7):

It Is Time to Make a Restaurant Reservation

Data Flow Diagram

FIGURE 3-7: Data Flow Diagram for Making a Restaurant Reservation

Process Description

Each time YOU want to dine out,

Look at the last two data flow diagrams side by side.

FIGURE 3-6: Data Flow Diagram for Receiving a Restaurant Reservation Request

FIGURE 3-7: Data Flow Diagram for Making a Restaurant Reservation

Remember that a process is an action performed by someone or something. In Figure 3-6, the process is performed by the restaurant, whereas in Figure 3-7, the process is performed by the customer.

Creating Event Process Models for a Simple Purchase Order System

We will now create event process models for the following business events associated with a purchase order system.

Events:

It is time to order a product from a supplier (Figure 3-8).

The product arrives from a supplier (Figure 3-9).

Supplier payment is enabled (Figure 3-10).

It Is Time to Order a Product from a Supplier

Data Flow Diagram

FIGURE 3-8: Data Flow Diagram for Ordering a Product

Process Description

For each product order request received from the PROCUREMENT GROUP, determine whether the Product is a new or existing product.

Get needed information about the Supplier (as indicated by the PROCUREMENT GROUP) that will provide the Product.

Generate a Purchase Order that specifies the following information:

• Order date

• Buyer who authorized the order

• Product ordered

• Quantity ordered

• Supplier’s special price for the product

• Date by which product is needed

• Shipping address, if different from company address

• Supplier acknowledges the date receipt of PO.

Issue the Purchase Order to the SUPPLIER with a request to acknowledge receipt by a specific date, along with the date that the order is expected to be delivered.

Notify the PROCUREMENT GROUP of expected date of delivery.

In the above process description, we mentioned a lot of new data, such as the acknowledgement data. Where do these data belong? They belong to the Purchase Order object because these data are information that describes the Purchase Order. Note that suppliers do not always acknowledge that they have received purchase orders. It’s your job as a business analyst to define the business rules that govern the company’s processes, so if you believe receiving acknowledgement is necessary, you must set a business rule mandating that.

Now, what if the Supplier has offered the product at a special price? Typically, a special purchase price is temporary or contingent upon buying a minimum quantity of a product. How should this information be integrated into the event process model? We must keep it somewhere for future audits. Here’s how we might document it.

Product is an object with the following data attributes:

The Product Arrives from a Supplier

Data Flow Diagram

FIGURE 3-9: Data Flow Diagram for Receiving an Order

Process Description

For each shipment received from a SUPPLIER, determine whether the Supplier is known.

Issue an acknowledgement of Receipt to the SUPPLIER.

Note: This process might be different if users tell you that a Purchase Order is created only when the SUPPLIER is valid. In this case, you might not need to determine if the SUPPLIER is known. Simply determine if the Purchase Order is open.

At this point, some of you might say, “But we need to check the contents for damage or shortage before we can receive the product!” True, but consider that to be another event, and create a separate event process model for it.

Supplier Payment Is Enabled

Data Flow Diagram

FIGURE 3-10: Data Flow Diagram for Releasing Supplier Payment

Process Description

For each Receipt that is authorized for payment, find:

• The associated Purchase Order

• Information about the Supplier of the purchase

• The terms of payment.

Record the following information about the Supplier Payment:

• • Date paid

• • Amount paid.

Record the Supplier Payment against the Receipt.

Release the payment to the SUPPLIER.

Note that in this process description, a new data attribute has been added for the object Receipt: “authorized for payment.” This leads us to another potential event: A receipt is authorized for payment. Before authorizing a receipt, you might determine what the company should do if an acknowledgement of receipt of the purchase order is not received from the supplier, but the goods are received.

In Brief

One of the major factors that contribute to the success of a requirements-gathering session is the attendees’ participation and buy-in. To ensure buy-in, the analyst must understand what the users need. One tool that you, as the analyst, can use is event process modeling. An event process model is made up of two components: a data flow diagram and a written process description. The data flow diagram allows you to illustrate that you have heard what the users are trying to articulate—the process, the data, and the rules—with simple, easy-to-use symbols. If you do not have enough time or board space in the meeting room to write out a full process description for each event, you can create it later using the data flow diagram.

When defining and modeling a data flow diagram, you must identify all data (objects and their data attributes) required by the event—not all the data for the whole system. You might find data belonging to an object that are not required by the business event at hand but are needed by other events. This is a good time to identify other events that may need to be included in the scope of your project.

The process for a given business event has a logical beginning and a logical end. Rule of thumb: If a process looks too complicated, chances are you can still break the event you are documenting into even smaller pieces.