When Use Cases Aren’t Enough

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

Karl Wiegers
Analyst’s corner
Published in
8 min readFeb 17, 2024

--

A photograph of a supermarket’s self-checkout machine.
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…

--

--

Karl Wiegers
Analyst’s corner

Author of 14 books, mostly on software. PhD in organic chemistry. Guitars, wine, and military history fill the voids. karlwiegers.com and processimpact.com