<Project Name>
Use Case Specification: <Use Case Name>
Version <1.0>
[Note: Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
Revision History
|
Date |
Version |
Description |
Author |
|
<dd/mmm/yy> |
<x.x> |
<details> |
<name> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table of Contents
7. Postconditions
(Success Guarantee)
10.1. First
Special Requirement
10.2. Second
Special Requirement
Use-Case Specification: <Use-Case Name>
[The description briefly conveys the purpose of the use case. The brief description is often a “3-liner”:”This use case begins when...,” “The system responds by…”, and “This use case ends when…”.]
[This section briefly describes the scope of the use case, usually “the system under design.”]
[“user-goal” or “subfunction”]
[This section describes the actor who calls upon the system to achieve a goal.]
[This section describes who interacts with the system during the course of this use case and what behavior do they expect from the system.]
[This section describes the conditions that must be true at the start of the use case and are important enough to describe to the reader.]
[This section describes the conditions that must be true at the successful completion of the use case and are important enough to describe to the reader.]
[This use case starts when the actor does something. An actor always initiates use cases. The use case describes what the actor does and what the system does in response. It is phrased in the form of a dialog between the actor and the system.
The use case describes 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 if the information is not defined. It is better to say the actor enters the customer's name and address. A Glossary of Terms (or a more formal Domain Model) is essential to keep the complexity of the use case manageable; you may want to define things like customer information there to keep the use case from drowning in details.
Simple alternatives may be presented within the text of the flow of events. If it only takes a few sentences to describe what happens when there is an alternative, do it directly within the flow. If the alternative flow is more complex, use a separate section to describe it; the Extensions subsection explains how to describe more complex alternatives.
Complex flow of events should be further structured into sub-flows. In doing this, the main goal should be improving the readability of the text. Subflows can be invoked many times from many places. Remember that the use case can perform subflows in optional sequences or in loops or even several at the same time..
A picture is sometimes worth a thousand words, though there is no substitute for clean, clear prose. If it improves clarity, feel free to paste flow charts, activity diagrams or other figures into the use case. If a flow chart 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 pages upon pages of text. Use the right presentation medium for your problem, but be wary of using terminology, notations or figures that your audience may not understand. Remember that your purpose is to clarify, not obscure.]
[The Extensions subsection shows alternative flows through the Main Success Scenario. Each extension represents alternative behavior usually due to exceptions that occur in the main flow.
Start each extension with an initial line clearly stating where the alternative flow can occur and the conditions under which it is performed. Numbering the extensions with identifiers Na…Nn will help reinforce where the exception fits in the Main Success Scenario: for example, it is clear that extension numbers 4a and 4b extend the Main Success Scenario at step 4.
End each alternative flow with a line that clearly states where the events of the main flow of events are resumed. This must be explicitly stated.
Using alternative flows improves the readability of the use case. Keep in mind that use cases are just textual descriptions, and their main purpose is to document the behavior of a system in a clear, concise, and understandable way.]
[A special requirement is typically a nonfunctional requirement that is specific to a use case, but is 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 or supportability requirements. Additionally, other requirements-such as operating systems and environments, compatibility requirements, and design constraints-should be captured in this section.]
[This section describes how often this use case occurs. This information is useful for prioritizing when this use case should be analyzed/designed and implemented, and it is also useful for determining the level of testing required for this use case.]
|
Issue |
Owner |
Status |
|
|
|
|
|
|
|
|
|
|
|
|