Not to be confused with a user story, a use case is a particular type of prototype that we use to model our system. More specifically, use cases allow us to model the interaction and behaviours of the system in response to any other actor that interacts with it.

Three Flavours Of Use Cases

Depending on the scope and complexity of the project you are prototyping, three different flavours of use cases are available. These include the Brief, Casual, and Fully Dressed varieties. While each describes how the system interacts with a particular actor (or set of actors), they have unique characteristics.

• The Brief Use Case is drafted as a short paragraph. The paragraph must identify which actor or actors interact with the system. It must include information about what the actor does and how the system responds. This flavour of use case is short compared to the other two varieties. Importantly, it outlines the main flow only. A brief use case assumes that the system and actor work together perfectly (a best-case scenario).
• The Casual Use Case is similar to the brief use case, except that it is more detailed and incorporates alternative flows. An alternative flow is something the system would need to do in response to the system or actor not behaving or working the way that is expected, or in response to an error. For example, this might include the system providing messaging to the user if it fails to connect to the database, or messaging to inform the user that their login credentials are wrong.
• The Full Use Case is far more structured than either of the other two flavours of use cases. In this case, the use case is structured as a table that includes several different row headings (including, for example, pre-existing conditions, primary actor, etc.). It has a main flow that is a numbered list of bullets describing in detail what the system does in response to the actions of an actor. Alternative flows are also listed (and numbered) so anyone reading the document will know where they branch off from the main flow.

Building Use Cases

To begin developing your use cases, review the list of must requirements or your set of user stories. Select one requirement or user story, and expand it to include what the system might do in response to the user or actor.

When you first draft your use case, think only of the best-case scenario. Assume that everything and every actor works in the way that you expect. Each bullet or sentence should also describe one thing an actor or system does. Keep things simple and clear.

Once you are happy with your main flow and assuming you are developing a casual or fully dressed use case, consider where the system or the actor might do something unexpected or wrong, or where an error might need to be addressed. Develop an alternative flow that describes what the system and actor would do. After you have completed drafting the alternative flows, and if you are building a fully dressed use case, review the main and alternative flows to identify the primary and secondary actors.

For all use cases:

• Give each of them a name or ID that you can reference within other use cases. For example, you may have use cases that include 1) Create An Account, 2) Log Into The System, and 3) Update My User Profile. For use case 2, you can identify that the use case assumes use case 1 has been completed. Similarly, use case 3 would state that it assumes use case 2 has been completed. Note – for use case 3, you wouldn’t have to indicate that use case 1 was completed as this is assumed by use case 2.
• The main and alternate flows must end in a stable state. That is, the system should be functioning properly. Stable doesn’t necessarily mean actor success. For example, a stable outcome could be the system informing the user that they have entered an invalid username and password, and then returning them to that part of the process where they need to re-enter their credentials.

An example use case is presented below in Brief, Casual, and Fully Dressed formats.

Note, in the brief use case example:

• “connected to the main server” is a pre-existing condition,
• both the system and the actor are described as doing things, and
• the use case ends in a stable state.

You should notice that the casual use case looks very similar to the brief use case, save for adding the alternate flow (bolded, and shown in red). Further, you should notice that:

• other use cases are referenced (specifically 1.0 Create an account, and 3.0 Reset forgotten password),
• both the main and alternate flows end in a stable state.

The fully dressed use case contains all of the information that the casual use case contains, however, you should notice how it introduces as many (or all) of the alternative flows as possible. It also explicitly states who the actors are and pre- and post-conditions. You should also note how the numbering of the alternative flows picks up directly from the numbering of the main flow. You can imagine the main and alternate flows as an if/then/else statement. If something is working the way it should, then follow the main flow, else, follow the alternate flow.

Of course, the flavour of the use case used will depend on the project size and perhaps where you work. Bigger more complicated projects will likely use the fully dressed use case format. Simpler projects may rely on the brief use case.

Review Questions