When Use Cases Aren't Enough

Event-Response Tables

A more effective technique for identifying requirements for certain types of systems is to consider the external events the system must detect. Depending on the state of the system at the time a given event is detected, the system produces a particular response. Event-response tables are a convenient way to collect this information (Wiegers 2003a). Events could be signals received from sensors, time-based triggers (such as scheduled program executions), or user actions that cause the system to respond in some way. Event-response tables are related to use cases. In fact, the trigger that initiates a use case is sometimes termed a business event.

The highway intersection system described earlier has to deal with various events, including these:

• A sensor detects a car approaching in one of the through lanes.

• A sensor detects a car approaching in a left-turn lane.

• A pedestrian presses a button to request to cross a street.

• One of many timers counts down to zero.

Exactly what happens in response to an external event depends on the state of the system at the time it detects the event. The system might initiate a timer to prepare to change a light from green to amber and then to red. The system might activate a Walk sign for a pedestrian (if the sign currently reads Don’t Walk), or change it to a flashing Don’t Walk (if the sign currently says Walk), or change it to a solid Don’t Walk (if it’s currently flashing). The analyst needs to write the functional requirements to specify ways to detect the events and the decision logic involved in combining events with states to produce system behaviors. Table 11-1 presents a fragment of what an event-response table might look like for such a system. Each expected system behavior consists of a combination of event, system state, and response. State-transition diagrams and statechart diagrams are other ways to represent this information at a higher level of abstraction. Use cases just aren’t enormously helpful in this situation.

Table 11-1. Partial Event-Response Table for a Highway Intersection

Here’s another type of project for which use cases aren’t sufficient. I enjoy watching auto races, probably because I raced stock cars myself (alas, with little success) as a teenager. Several shopping malls throughout the United States have NASCAR race-car simulators. These consist of small car bodies mounted on motion-control bases. The customer is a driver in a computer-controlled simulated race. Each driver’s view of the racetrack is projected on a screen in front of his car. The driver is racing against whatever other customers happen to be competing in that race as well as against several simulated drivers that the computer controls. The car body tilts and sways on its motion-control base during the race in response to the driver’s actions. A synthesized voice provides information to the driver over a speaker, warning when other cars are nearby and reporting the driver’s position and how many laps are left in the race. It’s a blast!

Defining the requirements for this complex system of interacting hardware and software components demands more than use cases. There aren’t that many use cases for the driver. He can press the accelerator and the brake pedal, turn the steering wheel, and shift gears, but these aren’t truly use cases—they’re events. A great deal of the product’s complexity lies not in the user interactions but under the hood (literally, in this case). An event-response approach will go much farther toward understanding the requirements for this kind of system. So although use cases are valuable for systems in which much of the complexity lies in the interactions between the user and the computer, they are not effective for some other types of products.