...
The following fields are validated:
[Add text here]
OSCAR
Module: <module name>
Use Case Document Template
Version 0.1
Status: Draft
Author: Alek Mirkin
Approved on Date <dd/mm/yyyy>
Approved by: <name, position>
Document Revision History
...
Version
...
Date
...
Changed By
...
Change
...
Number
...
[MM/DD/YYYY]
...
[Name]
...
[Summarize Changes Since Previous Version]
...
1.0
...
...
...
Initial Draft
...
...
...
...
...
...
...
...
...
This Use Case document is structured to describe each Use Case Model per the existing system in terms of:
Summary
Users
Relationships
Activity Diagrams
Flows of Events
...
Describe the actor’s goals(s) by executing this Use Case (i.e. what value does this Use Case provide to the actor).
This section should be completed using existing documentation, where available, otherwise Product will need to provide input for this section at review. This section is not a criterion for sign off.
Defined users:
[Add text here]
2.1.2 Description
High level (2-3 sentences) overview of what the Use Case accomplishes
[Add text here]
...
A scenario is a description of a specific interaction between a user and a system to accomplish some goal and is written from the actor’s point of view. Scenarios are instances of a use case, and represent a specific path through the use case. Thus, one may construct a scenario for the main flow through the use case, and other scenarios for each possible variation of flow through the use case (e.g., triggered by options, error conditions, security breaches, etc.). Scenarios are often presented in the form of a story and may be depicted using sequence diagrams. A use case can encompass multiple scenarios.
The primary scenario is written as if everything goes right. There are no bugs, errors, or problems encountered and there must be one primary scenario for each use case. Secondary scenarios represent variations in the specifics of the task or in the dialog sequence used to accomplish the task and can be documented as branches or alternative flows of events. Each scenario is a sequence of events that describes the functionality of the use case, essentially the list of steps to go through to accomplish the use case.
[Add text here]
...
Indicates statements that must be true or something that must occur in order for the Use Case to be successful. For example a typical assumption of a Login User Case would be “User Ids and passwords have already been established within the system”.
This section should be completed using existing documentation, where available, otherwise Product will need to provide input for this section at review. This section is not a criterion for sign off.
[Add text here]
...
Specify any end situations that meet the end goal(s). This is the final step in the main Use Case Flow of Events.
[Add text here]
2.2.3 Failed End Condition
Specify any end situations that do not meet the end goal(s). This is a list of the last step of any Exception Flows.
List
Some
reasons
...
Describe any preconditions that must be met before beginning this Use Case. If there are no valid preconditions, then use the following text for this section:
[Add text here]
...
Describe any post conditions that must be true at the end of the Use Case. If there are no valid post conditions, then use the following text for this section
[Add text here]
...
The following fields are required fields:
[Add text here]
2.3 Users/Systems
Systems
External System – A system that is not owned by the client that invokes this Use Case through exposed interfaces.
...
Base Step | Excpt. Flow Step | Actor | Process Step | System Response | Source Class Name |
|
| Actor for step, empty for non-interaction steps. | Step enacted by Actor, empty for non-interaction steps. |
|
|
|
|
|
|
|
|
...
2.2.4 Preconditions
Describe any preconditions that must be met before beginning this Use Case. If there are no valid preconditions, then use the following text for this section:
[Add text here]
2.2.5 Post conditions
Describe any post conditions that must be true at the end of the Use Case. If there are no valid post conditions, then use the following text for this section
[Add text here]
2.2.6 Validation
2.2.7 Required fields and functions:
The following fields are required fields:
[Add text here]
2.2.4 Preconditions
Describe any preconditions that must be met before beginning this Use Case. If there are no valid preconditions, then use the following text for this section:
[Add text here]
2.2.5 Post conditions
Describe any post conditions that must be true at the end of the Use Case. If there are no valid post conditions, then use the following text for this section
[Add text here]
2.2.6 Validation
2.2.7 Required fields and functions:
The following fields are required fields:
[Add text here]