2.11. Event-Response Models

As we’ve said many times before, basing the requirements models for a system on the current implementation is not a great idea. The way the business is currently operating conceals the essential requirements for the system. So if the internal mechanisms of the system aren’t the best place to look for these requirements, you must look elsewhere. Looking outside the system may be rewarding.

Systems exist to provide services to the outside world. The services have one thing in common: They are provided as a response to some event that takes place outside the system. For example, in Figure 2.11.2, when customers decide they want a taxi, they do it outside the context of the taxi system. When they decide to make a payment for their account, again they make their decision outside the system’s context. Such a happening outside the system is called an event.

Each event produces a unique data flow. It must be unique because the system can determine which event has happened by the data content of the flow. Only by recognizing the event can the system produce the correct response.

Events are given a unique name. For example, the event shown in Figure 2.11.3 is called Customer wants a taxi. The name of the event provides you, the analyst, with an indication of what the response should be. When the name is descriptive, it provides you with a relevancy check when you must search through a system to discover the appropriate response.

Note that in the event-response model in Figure 2.11.5 (or in any other event-response model), the response is bounded by terminators and data stores. A terminator supplies data to the system, but the behavior of the terminator is outside the control of the system; you cannot predict when it will send its data. Similarly, if the system sends a data flow to a terminator, you cannot predict how long the terminator will take before it reacts. In the same way, when a data item is stored, you probably cannot predict how long it will remain there until it is retrieved. Both the terminator and the data store are time-delaying mechanisms.

The significance of time-delaying mechanisms surrounding the event-response is that the response itself takes place in its own discrete and continuous period. When the system is responding to an event, processing continues until the data flows reach the final data stores or terminators. Just as you ignore processor boundaries, you also ignore delays normally associated with crossing processor boundaries (waiting for an available operator to key in data, the time taken to print information, and so on).

Simply put, when a data flow enters the system, the event-response processing continues until the system has accessed all of the data stores concerned with the response and, whenever necessary, has sent the appropriate data flows to the terminators.

Another way for a temporal event to be triggered is by the passage of time in relation to stored data. For example, the dispatcher always calls for a taxi ten minutes before the booking time to give the selected taxi time to arrive at the customer’s pickup point. So an event happens whenever it is ten minutes before a recorded booking. The system’s response to this event is shown in Figure 2.11.7.

Temporal event-responses begin when it is time to provide a service. The processing for the response starts inside the system, usually with a process accessing stored data. The event-response finishes when the system sends one or more data flows to the outside world.

Some external events simply store the incoming data. Some, as part of their response, send data to the outside world. In other cases, responses to external events generate more than one outgoing flow. So each of your external events may be linked to one or more of the outgoing flows.

What about the output flows that are not linked to an external event? These are the products of temporal event-responses. Any flow whose name suggests a periodic production (for example, REMINDER and APPOINTMENT SCHEDULE in Figure 2.11.8) originates with a temporal event-response. By a process of inspection and elimination, you should be able to attribute the boundary data flows to their respective events.

A guideline for naming external events is to use this template:

• External event name = Terminator name + reason for the data flow

For example, using this template, the event that produces the data flow REQUEST FOR PATIENT RECORD is called Dentist needs patient record. A template for naming temporal events is

• Temporal event name = Time to + action that must be taken

In the dental system, this template gives you a temporal event called Time to produce appointment schedule.

Here are the events that were derived from the context diagram in Figure 2.11.8 for the MOe & LARry Dental system:

The numbers assigned to the events are arbitrary and do not indicate any kind of priority or time sequence. The associated data flows are listed to help you to account for all the events. The (in) or (out) following each data flow name indicates the obvious: whether the flow is into, or out of, the system. This notation makes it easier to account for all of the flows.

The purpose of the list is to help you keep control of your model. Some systems have several hundred event-responses, and controlling the complexity of the models for these systems can be difficult.

For each event in the event list, build an event-response model by linking all the processes that respond to the event. This task is simpler if you keep in mind that an event is either an external or a temporal event. The event-response follows the pattern for that type of event. Let’s look at these patterns.

Typically, the incoming data go through a series of checks and validations, and are then added to a data store. For example, in the taxi system, the customer was checked to see that he was not a known bad payer, and then the request was added to the BOOKING store (Figure 2.11.4). Sometimes, the system acknowledges the initial message by sending some data back to the terminator (for example, in Figure 2.11.5, the ACCOUNT PAYMENT is sent in response to the ACCOUNT VOUCHERS).

The external event-response usually includes some combination of storing data, and/or referencing previously stored data. Use the two patterns shown in Figures 2.11.9 and 2.11.10 as a guide. All external event-responses are variations on these themes.

Temporal events tend to be relatively simple. In this example (Figure 2.11.11), there is only one bubble, which is quite common, as most temporal events are simply reporting on stored information.

Now that you know what the models look like, let’s build an event-response model using the dental system example.

The information needed to build an essential model may come from several sources: the current physical model (if you built one), interviews with the users, sample reports, observations of the work as it is done, job descriptions, sample input documents, existing computer systems, and so on. Let’s start by looking at the current physical model as a source of event-response information.

The way to use this model is to link the processes that make up the system’s response to each event. This usually involves following the trail of processes through several diagrams. For example, Figure 2.11.12 shows the model that results from joining the processes that respond to event 3 Dentist needs patient record in the MOe & LARry Dental system.

Whenever you use the current physical model as input to building your event-response models, you’ll probably include processes extracted from several diagrams. Then you’ll notice a major advantage of event-response modeling: You have a cohesive unit that is small enough to examine in detail. It now becomes far easier to assess whether a process is a duplication, redundant, dependent on the current implementation, or part of the essential policy of the system. If any processes or data are not part of this policy, you must eliminate them.

If the system stores data, naturally enough, the data must come into the system via an incoming boundary data flow. In other words, there is an external event response that stores the data in essential memory. On the right-hand side of Figure 2.11.13, you see a temporal event-response retrieving the essential stored data. The essential rules apply: If the data are stored, the data must be essential and needed for the services provided to the outside world. Data are essential only if referenced by at least one other event.

The data flows to and from the terminators (the boundary flows) are initially considered to be essential flows. The reason for this is that when the context of the system is agreed, the boundary data flows are the data provided by or needed by the system’s services; that is, the terminators provide or expect these flows.

You’ve seen how the event-responses store or retrieve essential stored data. A problem can arise if an external event-response stores data from a boundary data flow, and no other event-response references that data. If this happens, you may not be able to change the actual physical data (the terminator will probably continue to send the data as always), but you must adjust the definition of the incoming boundary data flow to reflect the data that the system really needs. The new implementation of the system will ignore the unwanted items.

In the figure, there are some things to consider:

• The data flows REQUEST FOR APPOINTMENT and APPOINTMENT are boundary data flows; they enter and leave, respectively, the context of the system.

• The data added to STORED DATA must be part of REQUEST FOR APPOINTMENT or be calculated by the process; the data can’t come from anywhere else.

• The data content of APPOINTMENT must come from STORED DATA, or from REQUEST FOR APPOINTMENT.

As REQUEST FOR APPOINTMENT initiates this event-response, let’s examine its data content:

Request For Appointment = Patient Name
+ (Required Date)
+ (Required Time)
+ Dentist Name
+ {Required Service}

The date and time are optional, as some patients will take whatever appointment is available. The patient designates a dentist—either Moe, Larry, or Curly—and indicates if he requires certain serious services.

What happens to the data? The patient’s name is used to reference an existing patient or, if this is the first visit, to record a new name. This means there must be an entity in essential memory called PATIENT. There is no other information in the data flow about a patient, so the only thing we can say now is that there is an entity called PATIENT with an attribute PATIENT NAME.

The next two items in the data flow are used to negotiate an appointment with the designated dentist. If the patient requests any services, they must be related to the appointment. Using the information from the data flow, you can construct a model of the data used to support this event-response. The result is shown in Figure 2.11.15.

Now let’s examine the outgoing data flow:

Appointment = Patient Name + Dentist Name + Appointment Date
+ Appointment Time

All of the data in this outgoing flow can be retrieved from the data model (Figure 2.11.15), so it confirms our view of the stored data.

In the intermediate version of this event-response (Figure 2.11.14), we used the data store STORED DATA temporarily until we could identify the real data. Now that you know what the essential data are for this event-response, you can replace the temporary STORED DATA with stores that have the same name as the entities in the later version of the event-response data model. If you had already built a first-cut data model, you could use it to help you build the detailed event-response data model.

The event-response model shown in Figure 2.11.16 uses the stored data that you have determined to be essential. When your event-response model uses only essential data and shows only essential processes, then you have captured the real requirements. However, it is sometimes difficult to know if all the processes and data are essential. The following discussion gives some hints on building the essential viewpoint.

1. Audits verify that a process produces the correct result. Audits are built into systems because the processors used to implement the system are imperfect; they make mistakes, are dishonest, or whatever. However, the essential requirement eliminates all processor technology, and so eliminates all errors that can be made by the processors. Thus, there is no need for audits to check the processors.

2. Edits check the validity of data flows that travel from one processor to another. As you are ignoring processor boundaries, you can leave this kind of edit out of your essential event-response model. However, it may be necessary for the system to edit data it receives from the outside world, because you cannot influence the terminators, which are outside your context of study. So it is necessary to include “border guard” edits as the first line of defense. (Just as a border guard may check your passport as you leave a country, you may need to install a border guard edit to check a flow’s validity.)

3. Transporters are processes that move data from one processor to another, for example keypunching, scanning, or bar-code reading. These processes exist only because of the implementation; there is no essential policy involved.

4. Translators are processes that make the output from one process understandable to another; for example, an analog to digital conversion, or the printing of a report that is used inside the system’s context. These processes are not part of the policy; they exist merely because of the way the system happens to be implemented.

5. Backups are not needed. By removing the technology, you remove the potential for failure, and hence the need for a recovery method.

If you are in doubt about a process, try decomposing it into its primitive components. You’ll find it a lot easier to separate essential and implementation processes when they are at their lowest level.

It may seem radical to throw out processes that normally make up a large portion of most systems. However, keep in mind you are trying to do two things: You are trying to find the essential requirements for the system, and you are eliminating anything that could influence the future implementation of the system. Besides, you aren’t changing the current physical—that view still exists. You are merely taking a different view of the same system. Later, once you have a complete picture of the requirements, it will be time to build a view of the new implementation.

Note that in this example, the false data store (Ringo’s in-tray) doesn’t represent the end of the response to an event. The in-tray owes its existence to the current implementation that uses people, and the person in this case has a problem working fast enough to keep up with demand throughout the day. This false data store does not contribute to the policy of the system and should not be included in the essential event-response model. Similarly, files in which the input is batched before further processing are false. They are there for efficiency reasons only. As you do not yet know the future implementation, you don’t need to include these batch files.

However, be careful that you do not eliminate files when there is a genuine reason for batching data. For example, there are many event-responses for which it is necessary to collect data for a time before processing it further. For example, if company policy required the account payments in Figure 2.11.17 to be made once a month, the system would need to store the vouchers until it was time to process the payments. While that situation would make the in-tray necessary, it should be renamed to reflect the essential purpose of the data, rather than the implementation.

Let’s start with the PATIENT RECORDS data store. This store is created in another part of the system and is kept in record-number sequence. Record numbers are controlled by the filing clerk who tells the nurse whenever a new number has been assigned. The nurse then adds the record number to the PATIENTS FILE in the dentist’s office.

Whenever a dentist requires a patient’s record, he asks for it using the patient’s name (and, if necessary, address). The nurse has to look up the PATIENTS FILE, find the RECORD NUMBER, and give it to the filing clerk for retrieval of the patient record. The patients’ records are stored in record-number sequence because that happens to be convenient for the filing clerk. The nurse’s translation of name to record number is only necessary because of the implementation. If the data were stored in a manner that allowed it to be accessed by patient name and address, the translation step would be eliminated.

The filing clerk employed in this office is paid the minimum wage, and is prone to making errors. The nurse always checks that the clerk has retrieved the correct PATIENT’S RECORD. However, if you take the essential view, every process must work correctly (there is no technology to go wrong), and it cannot produce the wrong record.

So it appears that the two processes done by the nurse are there only because of the existing implementation, and can probably be eliminated. However, before you make them disappear, consider whether a process is doing any storage or retrieval of essential stored data. Let’s look at the definitions:

Request For Patient Record = * The address is supplied when there is a possibility of several patients with the same name *
Patient Name
+ (Patient Address)

Patient Record = Patient Name + Patient Address
+ {Visit Date + Visit Time
+ {Service Identification}}

By attributing the data elements from these two data flows, you can derive the event-response data model shown in Figure 2.11.19.

The essential purpose of the event-response is to use the incoming data flow to retrieve information about the patient. There is no record number in the incoming data flow, nor in the essential data model. The record number exists for the convenience of people who are not trusted to read names. In other words, someone in the past has chosen to use these people as the implementation, and process 1 exists only to support that choice; there is no policy attached to that bubble. As you are modeling the essential processes and not the current implementation, you can eliminate process 1 from your essential model.

You can eliminate the audit process (bubble 3) because it checks what a previous process has done. However, there is no essential requirement for a process to make errors, so there can be no essential requirement for a process to check for errors. Process 3 is also banished. You are left with the model shown in Figure 2.11.20. Note that you could have started with the essential data model and worked backward from there to build this essential event-response process model.

By now, you have the idea of essential event-response models, and it’s time for you to build some for yourself.

Service Performed = Patient Name
+ {Service Identification}
+ Visit Date

Appointment = Appointment Date + Appointment Time

Dentist = Dentist Name

Patient = Patient Name + Patient Address + Patient Telephone

Service = Service Identification

Visit = Visit Date + Visit Time

Our knowledge of the event-responses means we can add the correct cardinality to the data model. Naturally, if you had had this data model in the beginning (or if you peeked ahead and saw it), the event-response process models would have been easier to construct. Figure 2.11.24 shows how each event-response uses part of the system data model.

There is no one best approach to building the essential model. Our preferred way of working is to construct a series of event-response process models, together with their associated event-response data models. The reason we take this approach is that building a system data model to cater for all of the details of the events is too confusing because the scope is too large to focus one’s attention on the details. The event-response data model provides a way of focusing on the minute details of the data for one event. However, we can have the best of both worlds by amalgamating the event-response data models into one system data model (ideally, with a CASE tool to manage it). Another way to get started is to build at least a high-level version of the system data model first, then confirm it with the essential process models. This data model is useful as an inter- or intra-project communication tool. Either way works, so we have included both approaches in this book.

Once you are comfortable with the event-response modeling approach, you can build essential models with a very abbreviated current physical model phase. The most minimal approach is to start the essential event-response models without any current physical modeling at all. If at any stage you have trouble determining the essential response, then you simply build some of the current physical model before resuming your essential approach.

The suggested fast-lane approach* uses these steps:

*McMenamin and Palmer refer to a similar approach called “blitzing” in their book, Essential Systems Analysis (see the Bibliography).

1. Build the context diagram during initial interviews with the users.

2. Use the data flows in the context diagram to determine the events. There must be an event-response to account for every data flow. Add each event, together with its associated data flows, to the event list.

3. Alternatively, if your users find it easier to identify events without the context diagram, list the event, then add the associated flows to the context diagram.

4. For each event, ask, “What event happens if this event does not happen?” For example, Customer pays is one event. Customer does not pay within the allotted time is another. Add any resulting events to the list and new flows to the context.

5. For each event,

• Interview the users about the responses to the event and build a one-bubble essential event-response process model (also known as an essential activity model). Include only the essential processes and data.

• Draw the event-response data model.

• Write the mini specification for your essential activity model.

• If the process is too complex for one mini specification, use leveling to build a low-level model. Then, write a mini specification for each process in the low-level model.

• If you have trouble building the essential models, build a physical model of the current system’s response to the event. Do only as much physical modeling as you need to understand the event-response well enough to abstract the essentials.

6. Do a CRUD check (more about this below) to test your context diagram and to discover missing events.

A fundamental activity, on the other hand, is one of the key reasons for having the system. For example, we might have constructed the system to send invoices to our customers and to accept their payments. These fundamental activities don’t merely maintain the stored data, they are the reason for having it in the first place.

Sometimes it is difficult to differentiate between fundamental and custodial activities, and most event-responses are a mixture of fundamental and custodial activities. The reason for introducing this terminology is that certain events, which are mainly concerned with custodial activities, are sometimes hard to discover because users don’t think to tell you about them. Your CRUD check, as we’ll discuss in a moment, will help you to discover these missing events.

In other words, there must be enough event-responses so that each attribute of stored data is CRUDed. At least, that is the principle. However, beware that some attributes will not be updated, and some may never be deleted, but all are created and retrieved. Missing CRUD actions for an attribute means that you may not have captured all the event-responses or that you may have some redundant data. Take, for example, the attributes of the APPOINTMENT entity in the MOe & LARry Dental system. There is an event to create them, Patient needs appointment, and an event to reference them, Time to produce appointment schedule. However, they are not updated, nor are they deleted. This means that we have forgotten two events: Patient changes appointment and Patient cancels appointment. Typically, you will add these custodial events to the list, build the event-response models, and inspect them carefully to see if other essential data are needed.

As well as there being enough events to install the system’s stored data, there must be enough data to support the events that retrieve data. Any data element that is part of an output boundary data flow should be an essential stored attribute or should be derivable from essential data. Any data element that is used by an event-response must either be an attribute of an entity or relationship, or it must travel into the system through a boundary flow.

Beware that some attributes may be CRUDed by more than one event-response, so your audit should ask, “Are there any other conceivable uses of each attribute that have not been covered by one of the event-response models?” For example, in the MOe & LARry Dental system, the events Time to send appointment reminders and Dentist needs patient record both reference VISIT DATE. However, the references are for different reasons. The former is making a decision about whether it is now time to send a reminder to the patient, the latter is supplying the dentist with historical information about the patient.

“Hi, I’m Sid Edison and I fix radios. My customers bring me their broken radios. You know the kind of thing. They play their rock music at full blast until the speaker collapses. Or they don’t like something they hear and throw the radio across the room. Whichever way it’s broken, they ask me to fix it.

“I always tell them how much I think the repair’s going to cost. I either give them a firm quote for the work, or sometimes I charge them time and materials. In that case, I give them a note that explains the cost. I never start a repair job until I get an authorization from the customer. Sometimes, the cost of the repair is more than the radio is worth. I don’t want to do the work and then get stuck with a radio the customer won’t claim.

“Most of the repair jobs are pretty straightforward, but I get some tricky ones. I always look in my file for the manufacturer’s specification just to make sure. Sometimes, I have to send off to the manufacturer for the full specification for the model before I can finish the job. The manufacturers don’t charge for the specs, which is lucky. However, the parts suppliers charge for parts. If the repair needs some parts I don’t have in stock, then my technician has to order some new parts from the supplier. These usually take a day or two to arrive. I send a pick-up notice to the customer when the repair is completed.

“The parts suppliers bill me at the end of the month, and I pay at the end of the following month. Customers pay cash when they pick up their radios”

Draw the context diagram for Sid’s system, and make a list of all the events that Sid has described. Now add to your event list missing events that are concerned with custodial activities. It may help to sketch a preliminary data model while figuring out these events.

Build event-response process and event-response data models for at least three events. (Don’t pick the easy ones.)

Compare your answers with those in Chapter 4.7. You may prefer to do this exercise one part at a time. In that case, do the context diagram and the event list first, and confirm your answer with Chapter 4.7’s before listing the events for the custodial activities. Again, check your answer before building the event-response models.

Make sure that you are comfortable with event-response modeling before proceeding.

You’ve seen event-response process and data models that store and/or reference data. Sample models are shown in Figure 2.11.25.

When it stores the data, the process must create the relationships x and Y. Why don’t we show the relationships in the event-response process model? A suggested model appears in Figure 2.11.26.

This model is more comprehensive when it shows the relationships. However, if the relationships X and Y do not contain data, the flows to them are not real data flows (they contain no data), so we prefer to leave them out of our event-response process models and to use the mini specification to specify the creation of the relationships and the accesses to essential data. If a relationship contains data that are stored by the event-response, you should indicate the data flow and the relationship in your model.

The example in Figure 2.11.27 follows the rule that the only flows shown in the model are those containing data. In this case, entity B does not provide data for the process, nor do the two relationships. Because there is no data involved, you can omit the entities, flows, and relationships.

Sometimes, a process needs too many stores to fit comfortably in the model, as shown in Figure 2.11.28. The solution is shown on the right.

For example, in Figure 2.11.29, the incoming flow POLICY CANCELLATION is used when the customer wishes to cancel all policies. There is no data in POLICY CANCELLATION to tell the system which policies to cancel. So there must be a process to look at all possible policies to find those held by a particular customer. Compare that event-response to the one shown in Figure 2.11.30. In this case, the system knows from the data content of AUTO POLICY CANCELLATION that the customer wants to cancel a car insurance policy.

The response to each event is unique. That is, the collection of processes and data that make up the response are not exactly duplicated anywhere else in the system. However, a process that is part of one event-response may be duplicated as part of others. Similarly with the entities: The same entities are used by many different event-responses. Because they are part of one event-response does not mean they cannot be part of another.

The best way to deal with duplicate processes is to draw the process wherever it occurs. There is no point in amalgamating all the event-responses that include a duplicate process. If you do this, you lose the control advantages of event partitioning and end up with a large, unmanageable, incomprehensible model. Later, when you write mini specifications, you will avoid duplication by writing one specification and cross-referencing it to all the processes that it defines.

To connect the models, join those event-responses that share stored data. An example of a connected model is shown in Figure 2.11.31.

In most systems, you’ll find that the processes that use the same stored data have a strong functional relationship, so the joined event-responses usually fall into coherent groups. Using these groupings, you can reduce the number of bubbles in the model by leveling upward. This leveling effort must seek to minimize the interfaces. In fact, the processes shown at the top level should have no data flowing between them. They should communicate only through the stored data.

Instead of building a leveled model, you can choose to use the CRUD check to manage the inter-event interfaces. You will see more of this approach in Chapter 1.15 CRUD Check.

There are two types of events: External events happen outside the system, and temporal events happen when the system must do something at a specific time.

Every data flow in the context diagram is associated with one of the events in the event list. Each input data flow in the context diagram indicates an external event. An external event can also be associated with anything from zero to many output data flows. Output data flows that are not associated with external events are in response to temporal events.

The essential event-response model ignores any processing that is there because of the current (or future) implementation, and shows only the essential processing.

An event-response processes essential stored data and, in some cases, data derived from the essential stores. Each event-response has its own event-response data model. Alternatively, if you prefer to model the event-response processes without an event-response data model, you need to use a system data model.

All of the essential attributes should be CRUD checked (to assure they’re created and referenced, and possibly updated or deleted). This checks that all the events have been discovered and that all the data are relevant.

Event-response models can be built using the current physical model, or directly from the context diagram and user interviews. These models can be leveled upward to make a convenient system-level overview.