Capturing and Refining Use Cases

First cut use cases

The first versions of use cases should reflect the high level style initial use cases usually have. The primary path that reaches the use case goal via the most expected sequence of interactions is written down. This primary path is written informally as a simple paragraph of text. No attempt is made to capture or document alternative paths. Often, an example of the primary path might be described with sample input and output data, or some simple pictoral representations might accompany the brief use case description.

Casual use cases

Intermediate versions of use cases written up after follow-on interviews or workshops are called casual use cases. They too are written in the form of descriptive paragraphs. However, there would typically be a refined version of the the original first cut paragraph to describe the primary path. There would then typically be an additional paragraph for each of the alternative sequences of interactions that branch off the primary path, and maybe merge back onto it again later.

Often at the same time as capturing alternative paths, we would also get some vision of what preconditions must be true before a use case is allowed to run. We also capture a list of expected testable postconditions, structured into two categories: success guarantees and minimal guarantees.

Alternative paths

An alternative path branches off the primary sequence at some point in that sequence known as the extension point. In order for the alternative path to be taken rather than staying on the original path, a branch condition must be true when the extension point is reached in the sequence. For example, our primary path description and one alternative path from the coke machine use case are given below:

“The thirsty person selects their desired drink from the selection of drinks available on the front of the coke machine. The machine responds by displaying a message, inviting the thirsty person to insert coins adding up to a displayed value. The thirsty person inserts coins to this value. The machine drops the selected can of drink into the collection hopper. The system adjusts its record of inventory, and its ledger tracking the cash balance in the machine.”

“When the user is inserting coins, if the coins they insert exceed the amount required to purchase the selected drink, the machine dispenses the right amount of change into the cash tray. It continues with the original sequence by dropping the selected can of drink into the hopper.”

Note how the alternative path states in written text what the extension point is, what the branch condition is, and after the description of the alternative path step(s), states where the alternative path remerges onto the primary path.


Use cases seldom are able to run completely independently of each other. There are usually interdependencies between them, including rules on which use cases must have previously run or reached a particular step in their sequences before a particular use case is allowed to run. System constraints or other non-functional requirements may also determine when particular use cases are allowed to run.

We capture this information as preconditions on use cases. These are written into the casual use case description templates as simple statements of things that must be true for the use case to run. For example, for our coke dispenser:

“Before a drink can be purchased, the coke machine must be enabled for use at the specified time of day, and must hold stock of at least one can of one kind of drink.”

Note that preconditions should be things that are testable in an implementation, not external preconditions over which the implementation will have no control. Hence:

“The thirsty person must have sufficient funds, and must be within arms length of the coke machine.”

would not be examples of meaningful preconditions!

Success Guarantees

Success guarantees are outputs or side effects that are observable or testable after a use case has finished, and has reached the use case goal. These usually include of course the goal of the use case, but often include some other observable side effects or outcomes. An example might be:

“The stock level of the selected drink in the inventory should be one less than it was on beginning the use case. The ledgered cash balance should have increased by the price of the drink dispensed.”

Minimal Guarantees

Alternative paths often describe controlled ways in which the actor might fail to reach their desired goal. They ensure that the desired behaviour of the machine in the presence of erroneous input sequences or other system state is implemented. Minimal guarantees are there identify postconditions that must be true after the use case is over regardless of whether the use case succeeded or failed to reach its goal.

Why do we capture postconditions?

​Recall that use cases are most of the way to being the source of test scenarios for an implementation of the use cases. By capturing the post conditions, we can further support their role as a source of test, since any tests developed can also test that the postconditions have become true once the use case is over.

Back to Use Case Editor documentation contents …