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, there are three different flavours of use cases available. These include the Brief, Casual, and Fully Dressed varieties. While each of them describes how the system interacts with a particular actor (or set of actors), they have their own unique characteristics.

• The Brief Use Case is drafted as a short paragraph. Within the paragraph, you will quickly learn which actor or actors interact with the system. The paragraph must include information about what the actor does and what the system’s response is. This flavour of use case is short compared to the other two varieties. Importantly, it outlines the main flow only. That is, a brief use case assumes that the system and actor are working together perfectly (a best case scenario).
• The Casual Use Case is similar to the brief use case, except that it is more detailed and also incorporates alternative flows. An alternative flow is something the system would need to do in response to the system or an actor not behaving or working the way that is expected, or in response to some sort of 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 a number of different row headings (including, for example, pre-existing conditions, primary actor, etc.). It also includes 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) in such a way that anyone reading the document will know where they branch off from the main flow.

Building Use Cases

To begin developing your use cases, it might make sense to look at 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 that the 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 those points along the way where the system or the actor might do something unexpected or wrong, or where an error might need to be addressed. At each of these points, develop an alternative flow that would describe 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 simply identify that the use case assumes use case 1 has been successfully completed. Similarly, use case 3 would state that it assumes use case 2 has been successfully completed. Note – for use case 3, you wouldn’t also have to indicate that use case 1 was successfully completed as this is assumed by use case 2.
• It is absolutely essential that the main and alternate flows 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.

On the following pages, you will find the same use case presented 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 the addition of 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 what the pre- and post-conditions are. You should also note how the numbering of the alternative flows picks up directly from the numbering of the main flow. In some sense, you can imagine the main and alternate flows as the result of 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 use case that you use for your project will depend on the size of the project 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