Use-Case Name

Use-Case Name

Brief Description

State the role and purpose of the use case. A single paragraph should suffice for this description.

System or SubSystem

Give the name of the system or subsystem to which the use case applies.

Flow of Events

Basic Flow

This use case starts when the actor does something. An actor always initiates use cases. The use case should describe what the actor does and what the system does in response. The use case should be phrased in the form of a dialogue between the actor and the system.

The use case should describe what happens inside the system but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the actor enters customer information ”it is better to say that the actor enters the customer's name and address. A glossary is often useful to keep the complexity of the use case manageable; you may want to define customer information there, to keep the use case from drowning in details.

Simple alternatives may be presented within the text of the use case. If it takes only a few sentences to describe what happens when there is an alternative, do it directly within the flow-of-events section. If the alternative flows are more complex, use a separate section. For example, an alternative flow describes how to describe more complex alternatives.

A picture is sometimes worth a thousand words, although there is no substitute for clean, clear prose . If doing so improves clarity, feel free to include graphical depictions of user interfaces, process flows, or other figures in the use case. If a technical method, such as an activity diagram, is useful to present a complex decision process, by all means use it. Similarly for state-dependent behavior, a state transition diagram often clarifies the behavior of a system better than do pages upon pages of text. Use the right presentation medium for your problem, but be wary of using terminology, notation, or figures that your audience may not understand. Remember that your purpose is to clarify, not to obscure.

Alternative Flows

1. First alternative flow : More complex alternatives should be described in a separate section, which is referred to in the Basic Flow section. Think of the Alternative Flows sections as alternative behavior ; each alternative flow represents alternative behavior (many times because of exceptions that occur in the main flow). They may be as long as necessary to describe the events associated with the alternative behavior. When an alternative flow ends, the events of the main flow of events are resumed unless otherwise stated.

Alternative flows may, in turn , be broken down into subsections.

2. Second alternative flow : There may be, and most likely will be, a number of alternative flows in a use case. Keep each alternative separate, to improve clarity. Using alternative flows improves the readability of the use case and prevents use cases from being decomposed into hierarchies of use cases. Keep in mind that use cases are just textual descriptions and that their main purpose is to document the behavior of a system in a clear, concise , and understandable way.

Special Requirements

These are typically nonfunctional requirements that are specific to a use case but are not easily or naturally specified in the text of the use case's event flow. Examples of special requirements include legal and regulatory requirements, application standards, and quality attributes of the system to be built, including usability, reliability, performance, and supportability requirements. Other requirements, such as operating systems and environments, compatibility requirements, and design constraints, should also be captured in this section.

1. First special requirement

2. Second special requirement

Pre-conditions

A pre-condition of a use case is the state of the system that must be present prior to a use case being performed.

1. Pre-condition 1

2. Pre-condition 2

Post-conditions

A post-condition of a use case is a list of possible states the system can be in immediately after a use case has finished.

1. Post-condition 1

2. Post-condition 2

Extension Points

Extension points are named markers that reference a location or set of locations within the flow of events of the use case, at which additional behavior can be inserted.

1. Extension point 1

2. Extension point 2