Finding the Business Events

Business events are things that happen and, in turn, make the work respond in some way. They may occur outside the scope of the work or because it is time for the work to do something. In either case, a communication from the outsiderepresented by the adjacent systemsmust let the work know that the event has happened, or a flow to the outside world must occur as the outcome of a time-triggered event. The resulting communication appears as an information flow on the context diagram.

Figure 4.2 provided the context diagram for the de-icing project. Take a look at it and note the information flows that connect the adjacent systems to the work. Some of these you have already seen when we discussed business events. For example, the flow called Changed Road is the result of the event that occurs when the Road Engineering department makes changes to a road. These personnel then advise the work of the change so that the scheduling work can update its own stored data about roads. The flow called Road Deicing Schedule is the outcome of a time-triggered business event: When it is time, the work produces a schedule of the roads to be treated and sends it to the truck depot.

Each of the flows that enters or leaves the work is the result of a business event.

Each of the flows that enters or leaves the work is the result of a business event and/or the resultant business use case. There can be no other reason for an external communication to exist. If you look at each flow, you can determine the business event or business use case that caused it. In some cases, several flows may be attached to the same business use case. For example, when the truck depot advises that a scheduled truck has broken down or will be withdrawn from service for some other reason (the input flow is Truck Breakdown), the work responds. Because one of the trucks is now out of service, the other trucks have to be rescheduled to compensate for the shortfall, and the resultant outgoing flow is the Amended de-icing Schedule.

Look at the list of events and their input and output flows shown in Table 4.1. Compare it with the work context diagram shown in Figure 4.2, and reconcile the business events with the data that flows to and/or from the work.

Table 4.1. Business Events and Their Associated Input and Output Flows for the Road Deicing Work

Event Name	Input and Output
1. Weather Station transmits reading	Weather Station Readings (in)
2. Weather Bureau forecasts weather	District Weather Forecasts (in)
3. Road engineers advise changed roads	Changed Road (in)
4. Road Engineering installs new weather station	New Weather Station (in)
5. Road Engineering changes weather station	Changed Weather Station (in)
6.Time to test Weather Stations	Failed Weather Station Alert (out)
7.Truck Depot changes a truck	Truck Change (in)
8.Time to detect icy roads	Road de-icing Schedule (out)
9.Truck treats a road	Treated Road (in)
10. Truck Depot reports problem with truck	Truck Breakdown (in)Amended de-icing Schedule(out)
11. Time to monitor road de-icing	Untreated Road Reminder (out)

Admittedly, you need some knowledge of the work to figure out the business events. To this end we advise you to start the process of determining business events during blastoff, when the key stakeholders are present. In most situations, you will find the business events are known to the stakeholders; in general, they can be observed when you look at the work.

Robertson, James, and Suzanne Robertson.Complete Systems Analysis: The Workbook, the Textbook, the Answers. Dorset House, 1998.

Each flow in the context diagram is attached to a business event, but it is the work's response to the event that is of interest to the requirements analyst. Let's investigate that topic next.