Modeling System Events

Use cases and user stories aren't always helpful or sufficient for discovering the functionality that software developers must implement. This is particularly true for embedded and other real-time systems. Consider a complex highway intersection with numerous traffic lights and pedestrian walk signals. There are very few use cases for a system like this. A driver might want to proceed through the light or to turn left or right. A pedestrian wants to cross the road. Perhaps an emergency vehicle wants to be able to turn the traffic signals green in its direction so it can speed its way to people who need help. This information alone isn't enough for developers to build the correct functionality.

An alternative to eliciting use cases and user stories is to identify the external events to which the system must respond. An event is some change or activity that takes place in the user’s environment that stimulates a response from the software system. An event-response table (also called an event table or an event list) itemizes all such events and the behavior the system is expected to exhibit in reaction to each event. There are three classes of system events, as shown in Figure 1:

• Business event. A business event is an action by a human user that stimulates a dialog with the software, as when the user initiates a use case. The event-response sequences correspond to the steps in a use case or swim lane diagram.

• Signal event. A signal event is registered when the system receives a control signal, data reading, or interrupt from an external hardware device or another software system, such as when a switch closes, a voltage changes, another application requests a service, or the user taps his finger on a tablet’s screen.

• Temporal event. A temporal event is time-triggered, as when the computer’s clock reaches a specified time (say, to launch an automatic data export operation at midnight) or when a preset duration has passed since a previous event (as in a system that logs the temperature read by a sensor every 10 seconds).

FIGURE 1. Systems respond to business, signal, and temporal events.

Event analysis works especially well for specifying real-time control systems. To identify events, consider all the states associated with the object you are analyzing, and identify any events that might transition the object into those states. Review your context diagram for any external entities that might initiate an action (trigger an event) or require an automatic response (need a temporal event triggered).

 As an illustration, Table 1 contains a sample event-response table that partially describes the behavior of an automobile’s windshield wipers. Other than event 6, which is a temporal event, these are all signal events.

Table 1. Partial event-response table for an automobile windshield-wiper system

Note that the expected response depends not only on the event but also on the state of the system at the time the event takes place. For instance, events 4 and 5 in Table 1 result in slightly different behaviors depending on whether the wipers were on at the time the user set the wiper control to the intermittent setting. A response might simply alter some internal system information or it could result in an externally visible result. Other information you might want to add to an event-response table includes:

• The event frequency (how many times the event takes place in a given time period, or a limit to how many times it can occur).

• Data elements that are needed to process the event.

• The state of the system after the event responses are executed.

An event-response table that defines every possible combination of event, state, and response, including exception conditions, can serve as part of the functional requirements for that portion of the system. You might model the event-response table in the form of a decision table to ensure that all possible combinations of events and system states are identified and analyzed. However, the BA must supply additional functional and nonfunctional requirements. How many cycles per minute does the wiper perform on the slow and fast wipe settings? Is the intermittent setting continuously variable, or does it have discrete settings? What are the minimum and maximum delay times between intermittent wipes? If you omit this sort of information, the developer has to track it down or make the decisions himself. Remember, the goal is to specify the requirements precisely enough that a developer knows what to build and a tester can determine if it was built correctly.

Notice that the events listed in Table 1 describe the essence of the event, not the specifics of the implementation. Table 1 says nothing about how the windshield wiper controls look or how the user manipulates them. The designer could satisfy these requirements with anything from traditional stalk-mounted wiper controls to recognition of spoken commands: “wipers on,” “wipers faster,” “wipe once.” Writing requirements at the essential level like this avoids imposing unnecessary design constraints. However, it’s important to record any known design constraints to guide the designer’s thinking.

Modeling system events provides a powerful complement to usage-focused requirements elicitation techniques such as use cases and user stories. Depending on how far down you detail the event descriptions and their corresponding responses, you can employ event-response analysis as a system scoping tool, as a way to understand user requirements, or as a substitute for writing a bunch of “the system shall” functional requirements.

Authors: Karl Wiegers  &  Joy Beatty

Karl Wiegers is Principal Consultant at Process Impact, www.processimpact.com.  Joy Beatty is a Vice President at Seilevel, www.seilevel.com. Karl and Joy are co-authors of the recently-released book Software Requirements, 3rd Edition (Microsoft Press, 2013), from which this article is adapted.