With the Internet of things (IoT) growing ever-more prominent, software to control hardware devices and their interactions is becoming more common, more complex, more essential, and more of a security concern. Use cases and user stories aren’t sufficient techniques for discovering the functionality that software developers must implement for embedded and other real-time systems.
As an example of a real-time system, 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. User stories like “As a pedestrian, I want to cross the road so that I [like the chicken] can get to the other side” don’t really help developers implement 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. A signal event takes place when a switch closes, a voltage changes, another application requests a service, or a user touches an icon on a phone’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 a sensor’s temperature reading every 10 seconds).
We should consider one additional event category during requirements analysis as well: prohibited events. Identifying possible events that should elicit no system response, or perhaps generate some sort of emergency or defensive reaction, could help with security analysis of the requirements for real-time systems. When taking a usage-centric approach to requirements analysis, people sometimes look for “abuse cases” or “misuse cases” along with the expected use cases. Also think about disfavored user classes, users (human or otherwise) that you don’t want being able to access your system or perform certain actions, and how you can keep them out.
Security issues are such a concern with the IoT that I haven’t even hooked my new smart home thermostat up to my home WiFi network. Why should I give potential intruders yet one more access point to my electronic world? I’ll gladly take on the minor inconvenience of having to install firmware updates with a USB drive instead of wirelessly. I’m suspicious about my smart power meter, too, but at least it isn’t on my WiFi. If I were confident that system designers had considered — and handled — all the risks from such interconnectivities, I might feel better. But I’m not there yet. Event analysis is a good starting point for thoroughly understanding a system’s behaviors, as well as its misbehaviors.
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). (What?! You don’t have a context diagram for your system? Maybe do that first; this article can help.)
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.
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 complement — or perhaps even replace — written 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. You can also draw a state-transition diagram (or the similar state diagram or state machine diagram) to illustrate the possible changes in system state visually, at a higher level of abstraction with fewer details than the event-response table shows.
However, the BA still 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 with enough detail 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 or premature design constraints. However, it’s important to record any known design constraints to guide the designer’s thinking. Constraints could arise from hardware limitations, the physical operating environment, compatibility with existing devices and software, government regulations, and industry standards, among other sources.
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.
If you’re interested in requirements and business analysis, project management, or software quality, Process Impact provides numerous useful publications, downloads, and other resources.