Sample Use Case Examples

Sample informal use case examples

We talked about informal use cases a while ago in our use case series. Over a series of posts, we are demonstrating the process of defining a software product. The next step, and subject of this post, is the creation of informal use cases to support the defined goals for the software.

In part two of our post on using tags to organize automated tests, we identified several market requirements, and identified the ones that we would incorporate as software requirements.

These then become our goals in MRD to PRD requirements conversion– and in this post, we will show how we can create informal use cases to support those goals (aka high level requirements).

Where do use cases belong?

In our introduction to structured requirements, we showed a basic model for describing requirements. Once goals are identified, we articulate the use cases that enable those goals.

Our product requirements (goals) were defined to be

1. Minimize time spent identifying broken and obsolete scripts.
2. Minimize time spent removing obsolete scripts from the suite.
3. Minimize the time spent managing the mapping of inspections to scripts.

The first step in creating informal use cases

The easiest way to start writing the use cases is to write the names of the use cases. Just write out the names (on paper, whiteboard, one-note – whatever works for you), using semi-descriptive prose. For example, for the third goal, we could identify the following two use cases.

• Developer adds a new script and maps to existing inspections
• Developer adds a new inspection and maps to existing scripts

Notice that in the names we have an actor and an action – this is a good consistent naming convention that makes it easy to understand exactly what we’re talking about. Now we can write the informal use case details for each of these.

Developer adds a new script and maps to existing inspections

The developer’s goal is to add her recently created script to the suite and associate it with a set of specific inspections, producing a set of test outputs. She may already have a set of inspections that she knows she wants to associate with the script. She is also opportunistic about leveraging other existing scripts to create new tests when they are relevant. She creates a reference to the script in the test framework. She then identifies the set of inspections that she wants to associate with the script and creates the associations. She reviews the set of associations, and either needs to change the set of associations, or is satisfied with the mappings. If she needs to add or remove some of her newly created mappings, she will identify the inspections that are to be modified and create those associations as well.

Developer adds a new inspection and maps to existing scripts

The developer’s goal is to add his recently created inspection to the suite and associate it with a set of existing scripts, producing a set of test outputs. He already knows, generally, what types of scripts he wants to map his inspection to. He does not have a specific set of scripts in mind for the mapping. The developer creates a reference to the inspection in the test framework. Then he reviews the existing scripts, and identifies the scripts to be mapped to his new inspection and creates the associations. He reviews the set of associations and either decides that he has too many, too few, or has the right amount. If he needs to modify the associations he does so and re-reviews, repeating until satisfied.

Two things to note about the process of creating the informal use cases above:

1. This is very fast – these took about 10 minutes each to create. It is a very small amount of time that has to be invested prior to validating the use cases with the users. During and after validation, these use cases can be modified, eliminated or replaced with other use cases. Having something concrete with a minimum investment of time both helps drive good decisions and saves costs.
2. These use cases are the result of iteration. We did not just type for ten minutes and move on. While writing the second use case, we noticed that we were not handling the possibility that the developer would initially create too many associations and need to go back and remove some of them. We updated both use cases to reflect this possibility.

More Example Use Cases

We occasionally add other example use cases, usually focused on a particular element of use case writing. Here are some that we’ve added since this article was originally published:

• How To Write Use Case Preconditions and Triggers
• Subordinate and Super-ordinate Use Cases
• How To Write Good Use Case Names
• Sample Use Case Example
• APR: Use Case Names
• APR: Use Case Briefs

Summary

Our next step is to validate these use cases with the actors identified in the use cases (developers). Once that is complete, we will define the functional specs for the software that enable these use cases.