The Use Case

The Use Case
	Chapter 1. Foundations

We have a single, small use case. We have some opinions on what makes a useful use case in our Soapbox on Use Cases. There is a single actor, the “investigator”. The actor's goal is to see the expected results of using a particular strategy for a particular game. The typical scenario is the following.

Procedure 1.1. Basic Use Case

Actor
Specifies which game and betting strategy to test. The strategy may need additional parameters, like an initial budget, or stake. The game may require additional parameters, like betting limits.
System
Responds with a statistical summary of the outcomes after a fixed number of cycles (spins, or throws or hands). The number of cycles needs to be small (on the order of 200, to reflect only a few hours of play).

Soapbox on Use Cases

We feel that the use case technique is badly abused by some IT organizations. Quoting from Jacobson95, “A use case is a sequence of transactions in a system whose task is to yield a result of measurable value to an individual actor of the system.”

A use case will clearly identify an actor, define the value created, and define a sequence of transactions. A use case will be a kind of system test specification. A use case will define the system's behavior, and define why an actor bothers to interact with it.

A use case is not a specification, and does not replace ordinary design. We have had experiences with customers who simply retitle their traditional procedural programming specifications as “use cases”. We hypothesize that this comes from an unwillingness to separate problem definition from solution definition. The consequence is a conflation of use case, technical background, design and programming specifications into gargantuan documents that defy the ability of programmers or users to comprehend them.

There are a number of common problems with use cases that will make the design job more difficult. Each of these defects should lead to review of the use case with the authors to see what, if anything, they can do to rework the use case to be more complete.

No Actor. Without an actor, it's impossible to tell who is getting value from the interaction. A catch-all title like “the user” indicates a use case written from the point of view of the database or the application software, not an actual person. An actor can be an interface with other software, in which case, the actual software needs to be named. Without knowing the actor, you will have trouble deciding which classes are clients and which classes provide the lower-level services of the application.
No Value Proposition. There are two basic kinds of value: information for decision-making or actions taken as the result of decision-making. People interact with software because there are decisions the software cannot make or there are actions the actor cannot make. Some use cases include value-less activities like logging in, or committing a transaction, or clicking “Okay” to continue. These are parts of operating scenarios, not statements of value that show how the actor is happier or more successful. Without a value proposition, you will have no clue as to what problem the software solves, or what it eventually does for the actor.
No Interactions. If the entire body of the use case is a series of steps the application performs, we are suspicious of the focus. We prefer a use case to emphasize interaction with the actor. Complex algorithms or interface specifications should be part of an appendix or supplemental document. Without any interaction, it isn't clear how the actor uses the software.

We also try to make a distinction between detailed operating scenarios and use cases. We have seen customers write documents they call “detailed use cases” that describe the behavior of individual graphical user interface widgets or panels. We prefer to call these scenarios, since they don't describe measuable business value, but instead describe technical interactions.

This system use case is embedded in an overall cycle of investigation that forms a kind of business use case. From this overall view, the actor's goal is to find an optimal strategy for a given game. The procedure includes the following steps.

Procedure 1.2. Business Use Case

Actor
Researches alternative strategies. Uses IDE to build new classes.
IDE
Creates new classes for the simulator.
Actor
Uses the Basic Use Case. Runs the simulator with selection of game and strategy.
Simulator
Responds with statistical results.
Actor
Evaluates the results. Uses a spreadsheet or other tool for analysis and visualization.

We are addressing parts of this larger business use case. While not describing the detailed “how-to” of using the IDE to build the new classes, we will address the design of those new classes. Additionally, we won't address how to analyze the results.


Chapter 1. Foundations		Solution Approach