When Use Cases Aren't Enough

Project Type Limitations

My experience has shown that use cases are an effective technique for many, but not all, types of projects. Use cases focus on the user’s interactions with the system to achieve a valuable outcome. Therefore, use cases work great for interactive end-user applications, including Web sites. They’re also useful for kiosks and other types of devices with which users interact.

However, use cases are less valuable for projects involving data warehouses, batch processes, hardware products with embedded control software, and computationally intensive applications. In these sorts of systems, the deep complexity doesn’t lie in the user-system interactions. It might be worthwhile to identify use cases for such a product, but use case analysis will fall short as a technique for defining all the system’s behavior.

I once worked on a computational program that modeled the behavior of a multi-stage photographic system. This software used a Monte Carlo statistical simulation to perform many complex calculations and it presented the results graphically to the user. The user-system dialog needed to set up each simulation run was quite simple. (I know this because I built the user interface.) The complexity resided behind the scenes, in the computational algorithms used and the reporting of results. Use cases aren’t very helpful for eliciting the requirements for these aspects of a system.

Use cases have limitations for systems that involve complex business rules to make decisions or perform calculations. Consider an airline flight reservation system, one of the classic examples used to illustrate use cases. Use cases are a fine technique for exploring the interactions between the traveler and the reservation system to describe the intended journey and the parameters associated with it. But when it comes to calculating the fare for a specific flight itinerary, a use case discussion won’t help. Such calculations are driven by the interaction of highly complex business rules, not by how the user imagines conversing with the system.

Nor are use cases the best technique for understanding certain real-time systems that involve both hardware and software components. Think about a complex highway intersection. It includes sensors in the road to detect cars, traffic signals, buttons pedestrians can press to cross the street, pedestrian walk signals, and so forth. Use cases don’t make much sense for specifying a system of this nature. Here are some possible use cases for a highway intersection:

• A driver wants to go through the intersection.

• A driver wants to turn left when coming from a particular direction.

• A pedestrian wants to cross one of the streets.

These approximate use cases, but they aren’t very illuminating. Exploring the interactions between these actors (drivers and pedestrians) and the intersection-control software system just scratches the surface of what’s happening with the intersection. The use cases don’t provide nearly enough information for the analyst to define the functionality for the intersection-control software.

Use cases aren’t particularly helpful for specifying the requirements for batch processes or time-triggered functions, either. My local public library’s information system automatically sends me an e-mail to remind me when an item I’ve borrowed is due back soon. This e-mail is generated by a scheduled process that checks the status of borrowed items during the night (the one I received today was sent at 1:06 AM) and sends out notifications. Some analysts regard “time” to be an actor so that they can structure this system behavior in the form of a use case. I don’t find that helpful, though. If you know the system needs to perform a time-triggered function, just write the functional requirements for that function, instead of packaging it into a contrived use case.