When Use Cases Aren’t Enough: Event Analysis

Although use cases are valuable for many projects, sometimes event analysis is a more effective requirements elicitation technique.

Photo by Author

I’ve been an enthusiastic supporter of use cases ever since I discovered what a valuable requirements elicitation tool they are. Use cases shift the elicitation participants’ focus from the product and its features to exploring what users need to do with the product. That usage-centric emphasis then leads to an understanding of the solution’s necessary capabilities and characteristics.

Use cases describe the goals that particular users wish to accomplish through their interactions with a system. The central element of a use case description is a step-by-step dialogue that takes place between the primary user, the system, and possibly additional users, systems, or components. Because of that use case structure, they’re effective tools for understanding interactive systems in which a user initiates a session to achieve a specific objective.

Valuable as they are, use cases aren’t the ideal tool for every type of product. A complementary requirements elicitation strategy is to explore the various events that a system or product could experience and how it should respond to each of them. The response depends on what state the system is in when it detects the event. Event analysis is particularly well-suited for middleware products and real-time systems that include both software and hardware components.

The Much-Hated Self-Checkout

As an example of how event analysis can supplement the insights from use case analysis, consider the store self-checkout machines that we all hate to use, except on those rare occasions when everything goes smoothly. Imagine you’re a business analyst (BA) working with various stakeholders to determine a self-checkout’s capabilities.

A good place to begin requirements elicitation is to identify various user classes for the product. The primary user class for a self-checkout is a store customer. Other user classes include a store employee who must assist with problems the customer encounters, as well as anyone who will install, configure, customize, and test the machine. Let’s focus on the customer user class.

I can think of only one use case for customers: Purchase Products. That’s the customer’s sole goal. Individual actions, functionality, or problems the user might encounter during a session, such as scanning a product or paying by credit card, are not use cases. They’re only steps in the process of achieving the user’s goal of purchasing one or more products with the self-checkout. A use case is a standalone task that delivers some value to the user upon completion.

The BA could indeed explore the Purchase Products use case with some customer representatives to learn how they envision interacting with the device to buy one or more products. That’s going to be a huge, highly complex use case! There are many optional pathways the user might encounter, called alternative flows. There are also many possible exceptions, things that could go wrong and prevent attaining the goal, as all of us who’ve used those devices know well. In addition, exploring how the customer imagines buying products won’t provide enough information to specify all of the self-checkout’s functionality, just the customer-visible functionality. Is there a better way to understand the requirements for such a product?

Self-Checkout Events

Event analysis is an alternative requirements elicitation technique that works well for real-time products like a self-checkout. An event is a change that takes place in the application’s environment and stimulates some response. There are several classes of events.

Business Event: Someone or something (users don’t have to be human beings) outside the business domain requests a service from the domain. The request often triggers the execution of a use case. A customer who decides to buy some products with the self-checkout is initiating a business event.

Signal Event: A system receives an input from outside the business domain, such as a control signal from a sensor or a particular data value from another system. When a self-checkout’s card reader detects a nearby contactless payment device like a credit card or phone, that’s a signal event.

Temporal Event: A preset time is reached, or a specified time interval has passed since a previous event or since the system entered a particular state. Suppose you place an unscanned item in your bag. The self-checkout will remind you to scan it first. If you don’t remove the item within a certain number of seconds, the device will suspend the checkout process and signal for help or take some other action.

Let’s see if considering various events the machine must detect and handle yields a richer requirements understanding. Here’s a partial self-checkout event list.

• System detects a nearby customer
• Customer scans their loyalty card
• Customer indicates they are using their own bag
• Customer scans an item’s UPC
• Customer scans a weighable item
• System detects a weight mismatch in bag
• Customer scans a coupon
• Customer requests to pay with cash
• No customer activity takes place for X seconds

Building a simple list like this is the first level of event analysis. The event list provides some insights into the system’s necessary capabilities and components. For example, if the device must detect when a customer is nearby, it needs some kind of camera or motion detector.

Representing Event Knowledge

The next level of detail is to elaborate the event list into an event-response table. The table identifies the state the system is in when it detects each event and describes the expected system response. Figure 1 shows a portion of an event-response table:

Figure 1. A sample portion of an event-response table.

Examine each event for possible exception conditions. What if the customer scans a product’s UPC but the item isn’t found in the system’s database? That’s happened to me. What if the customer notices that the price displayed after scanning doesn’t match the price shown on the shelf tag or in the weekly ad? A robust set of requirements anticipates as many exceptions as possible and specifies how the system should detect, respond to, and attempt to recover from each one.

Although these examples are simplified and incomplete, you can see how going down to this next layer of event detail reveals necessary system functionality and implies further system capabilities. For instance, if the device is to provide audible messages, it needs a speech synthesizer and speaker. Details about the volume, nature of the voice, and other characteristics will be specified in later requirements discussions or left to the developer as design choices, hopefully using prototype evaluations to validate proposed designs.

Beyond these textual representations of system events, it’s often valuable to draw a state-transition diagram to show the various possible system states and the combinations of events and conditions that lead to a change from one state to another. Names for similar visual models include state, statechart, and state machine diagrams.

I learned early in my software development career that no single representation of requirements will show all of the stakeholders everything they need to know. Diagrams let the reader step back from the details found in an event-response table, a set of functional requirements, or a stack of user stories to see the big picture at a higher level of abstraction. A mix of textual and visual representations communicates knowledge most effectively.

Users Won’t Know Everything

Even if the BA works effectively with appropriate representatives of the known user classes, they won’t get all the requirements information they need to fully specify the product. A customer probably wouldn’t think to tell the BA, “If the self-checkout detects that there’s an item in my bag that hasn’t been scanned yet, it should report the problem.” Similarly, a customer won’t say, “If the machine contains less than 99 cents’ worth of coins, it shouldn’t give me the option to pay with cash in case it needs to make change.” The BA adds a lot of value by filling in those sorts of gaps.

Consider timeouts, such as the “No customer activity takes place for X minutes” event. A timeout is essentially a negative temporal event. The system determines that nothing has happened for a specific period of time or since a previous event took place, and it must take some action as a result. A representative customer in an elicitation discussion is unlikely to say, “If I don’t do anything for a while, the system should ask if I’m still there or something.”

(As an aside, the timeouts for the self-checkouts at my local supermarket are too brief, in my opinion. More thorough prototyping with a more diverse set of representative customers might have led to better design choices that don’t cause the machine to complain to the customer so frequently.)

There’s probably also a lot of action going on behind the scenes that the customer won’t know about or care about. An example is inventory management, updating databases as customers purchase items. A security officer might want the self-checkout to include a video camera to look for—or deter—customers who leave without paying. The BA needs to learn about such unobvious functionality from other stakeholders and subject matter experts, not from direct users of the self-checkout. The BA must cast a wide net during requirements elicitation to avoid missing important information.

Complementary Techniques

As you can see, examining the events that a complex system can experience and how it should respond to each one is sometimes more informative than exploring only use cases. The structured techniques of event-response tables and state-transition diagrams organize certain types of information more efficiently than the flow-oriented nature of a use case.

So, should a diligent BA employ use cases or event analysis? Contemplate the nature of your product. Can you identify multiple user classes that want to accomplish a variety of objectives by interacting with the solution? Maybe start with use case analysis. Or does the product involve a limited number of complex interactions, with hardware components involved and a lot going on that the user doesn’t see directly? Event analysis is a better choice. The two aren’t mutually exclusive. You could begin by exploring use cases, and then build a separate, simple event list. Compare and see if you’ve missed anything.

Developers don’t implement use cases, user stories, or event lists. They implement bits of functionality that cause the solution to behave in certain ways when certain things happen. Keep in mind that with both use case and event analysis the BA must drill further down to a deeper level of detail at the right time, identifying that specific functionality that developers will implement.

For instance, the final row in Figure 1 says that the system terminates the session. What all does terminating a session involve? Someone needs to figure out those details. If that information isn’t eventually included in the requirements, don’t be surprised at what the development team delivers.

Note that none of the system responses described here for the self-checkout include “waste the customer’s time.” You get that for free.

Author: Karl Wiegers

Karl Wiegers is the Principal Consultant at Process Impact. He’s the author of numerous books, including Software Requirements (co-authored with Joy Beatty), More About Software Requirements, Software Development Pearls, and The Thoughtless Design of Everyday Things. Karl’s most recent book is Software Requirements Essentials with Candase Hokanson.