Use Case Formats

The level of detail required in use cases differs from project to project, and even between use cases and scenarios within the same project.  A use case format that works in one situation may be totally unsuited for another. The key to maximizing efficiency and effectiveness is to capture the right amount of detail for each particular use case and scenario. (See [ADO04] for more information on use case formats.)

Some use cases need a high degree of detail. If the writers used a template, then they filled out all or almost all of its fields for each use case. High-detail use cases are best suited complex, novel, or safety-critical functionality, such as that found in flight control systems, telephone switches, and so forth where the risk of misinterpretation is high.

Other use cases need less detail. If the writers used a template, then they may have left many of the fields blank. Low-detail use cases are best suited for well understood, low complexity or less safety-critical functionality where most of the stakeholders have a strong background in the problem domain and the risk of misinterpretation is low. In these cases, simple brief descriptions or step-by-step outlines suffice.

Furthermore, not all scenarios are created equally.  Within the same use case, some scenarios are very well understood and a brief description is sufficient to ensure un-ambiguous interpretation.   Other scenarios may require more detail to capture the essential behavior un-ambiguously.

Finally, as explained in Guideline: Detail Use Cases and Scenarios, it makes sense to write use cases iteratively. Starting with the basic details, you can then identify the various alternative and error paths that the use case might follow so that you can evaluate, rearrange, or eliminate them, and then elaborate or fill in the details of the remaining scenarios.

Write use cases and scenarios in one or more of the following formats, progressively, until you reach the level of detail required:

• Use-case model overview: A format for understanding the “big-picture”
• Use-case brief descriptions: A format for writing summary use cases
• Step-by-step outlines: A format for writing less formal, low-ceremony use cases
• Fully detailed: A format for writing more formal, high-ceremony use cases

Use-Case Model Overview

Create a use-case model overview, which captures actors and associated use cases.

• Start by identifying the list of actors who will use the system, and then identify at least one goal for each. Actors without goals indicate that you haven’t adequately defined the system. The actor is beyond the system’s scope, doesn’t belong in the system, or is part of another actor.
• Likewise, leftover goals can indicate that the system is too complex and you're trying to accomplish too much, or that you haven’t adequately defined all of the necessary actors. Carefully evaluate the leftovers to see if you are just overlooking some detail, or whether they don’t belong in the system.
• Remove unassociated actors and goals from the model.

Sometimes, this overview may provide enough information to serve as the use-case model for very small, high-communicating, low-ceremony project teams. Usually, the use-case model overview is the first step of identifying use cases and system boundaries.

Use-Case brief descriptions

Write two to four sentences per use case, capturing key activities and key-extension handling.

• Expand the high priority use-cases by writing a two- to four-sentence use cases for each entry in the list.
• Briefly describe each use case’s main scenario and most important extensions.
• Include enough information to eliminate ambiguity for at least the main scenario.

Step-by-step outlines 

Write the step-by-step outline which describes the interaction between the actor(s) and the system.

• Key scenarios are detailed to describe the interaction
• Triggering events are specified
• Information exchanged is described

Fully Detailed

Complete all sections of the Use-Case Specification template.

• The main scenario is detailed
• All alternative flows are identified and detailed
• Special requirements are complete and un-ambiguous
• Pre- and Post-conditions are specified.