The Use Case Chronicles – Part 3: Insights and Tips for Writers

Here's the third part of The Use Case Chronicles, where after discussing what use cases are and how they're structured, I'll give some guidance and tips on how to find them.

Use cases might be like a giant wave crashing over you. When working with use cases, you will eventually ask yourself two main questions: how long can this go on for, and how can I describe ALL of it? In this article, you will find tips and templates to help you deal with this wide range of use cases.

Expanding the use case

You don't always have to describe a use case with all its details. In the book "Writing Effective Use Cases," Alistair Cockburn considers two templates: the casual use case and the fully dressed use case. Those are different levels of expansion of use cases, from simple to detailed ones:

• A simple top-level description – it’s likely to be less accurate and missing some details; mostly it identifies just basic elements (name, actor, association).

• A full and rigorous description – it uses one of the accepted full templates and identifies all elements of the use case (actors, scope, trigger, precondition, etc..).

  
  

  

Actually, these are two sides, and you can use various intermediary levels. Note that you don’t need to describe all use cases with the same level of expansion.

Creating levels of detail

You don't have to describe use cases all at once. Instead, use different levels of detail to avoid drowning in use cases.

Big picture + certain parts

For example, you can give a big picture and then describe certain parts of the system.

Levels in certain elements

One more point is that you can use different levels of detail when describing certain elements of the use case. For example, you can list alternative flows in the use case description and elaborate on them in another document.

Levels in the same scope

Another way is to describe the same scope of use cases but show more and more details.

For example, let's take a look at the simple example from The Use Case Chronicles – Part 2: Unveiling Use Case Structure for a mobile application for food ordering.

Here, I use a diagram to describe the top level without any use case details. Drawing helps to see all the connections between cases and the big picture.

Then, I describe some use cases and include more details such as Preconditions, Trigger, Goal, and so on. Some elements can be described as more casual, and some as more dressed up.

Identifying use cases

Identifying use cases can also be tough, sometimes I don't know what to hit on, and this is where the following strategy helps me. Actually, there are several methods for identifying use cases; they basically consist of the same questions but in a different order. The following is the order I have seen most often from different authors and found it to be the most convenient.

1. Identify the System

You can describe either a system or a part of it.

2. Identify the Actors

They can be determined by asking the following questions:

• Who uses the system?
• Who installs the system?
• Who runs the system?
• Who maintains the system?
• Who shuts down the system?
• What other systems use the system?
• Who receives information from the system?
• Who provides the information to the system?
• Is anything happening automatically in the system?

It is not necessary to use all actors in every aspect of the system description, but it is useful to consider all actors and ask all questions so that important actors are not lost.

3. What do actors want to get?

Then, examine the visible and observable value each actor wants to get to identify potential use cases. Key questions to help with this process include:

• What system functions does the actor require?
• What information does the system store? Who will create, read, update, or delete this information?
• Should the system notify actors of changes in the internal state?
• Are there external events that the system needs to be aware of? Who will inform the system of these events?

4. What are the associations and relationships?

When you have actors and use cases, you need to arrange and link them. Pay attention to the following points here:

• It is more convenient to structure the description from the actors' point of view, i.e. first place the actors and build their relationships, and then look at their associations with use cases.
• If there are too many use cases, you can:
  • simplify them by reducing the number of use cases and their descriptions
  • divide them into levels of detail
• Use case diagrams are based on functionality and should focus on the "what" rather than the "how."

5. General check

When you have described all the use cases, go through and read them all. Note the following points:

• Don't put in requirements that don't fit the purpose and format of the use cases; there's no need to try to cram everything in or adapt requirements that don't really fit the format.
• Check all intersections and junctions:
  • ensure that there are no conflicting use cases
  • ensure that multiple levels of detail are consistent both horizontally and vertically.
• For each use case, there is a clear understanding of the goal for which the actor triggers the case and how the case ends for the actor.
• The cases are described briefly and in a clear manner to ensure maximum comprehension. Useful case = understandable case. Formulate cases in a way that they are easy to understand and avoid complex grammatical constructions.

Conclusion

This concludes the third part of the Use Case Chronicles. These guidelines and tips help me in my work with use cases. Feel free to share your tips in the comments below!

Check out other parts of the Use Case Chronicles: Part 1: Who, What, and How to Use Cases and Part 2: Unveiling Use Case Structure.