OSCAR
Module:<module name>
Use Case Document Template
Version 1.0
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 |
|
|
|
|
|
|
|
|
1 Overview
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
2 OSCAR Module <module name> Use Case Model
2.1 Summary
2.1.1 Business Need
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]
2.1.3 Basic Scenario and Functionality
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]
2.2 Conditions/Assumptions
2.2.1 Assumptions
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]
2.2.2 Successful End Condition
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
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
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 |
|
|
|
|
|
|
|
|
1 Overview
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
2 OSCAR Module <module name> Use Case Model
2.1 Summary
2.1.1 Business Need
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]
2.1.3 Basic Scenario and Functionality
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]
2.2 Conditions/Assumptions
2.2.1 Assumptions
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]
2.2.2 Successful End Condition
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
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.3 Users/Systems
Systems
External System – A system that is not owned by the client that invokes this Use Case through exposed interfaces.
Specific Client System(s) – A client functional module that interacts with this Use Case. The set of functional modules that interact with this Use Case include: <List Input Module Names Here>
[Add text here]
Users
Specific Client System(s) – A client functional module that interacts with this Use Case. The set of functional modules that interact with this Use Case include: <List Return Module Names Here >
[Add text here]
2.4 Use Case Relationships
This section describes the sets of related Use Cases in the system.
[Add text here]
2.4.1 Use Case Relationship Diagram
[Add Relation ship Diagram here]
2.4.2 Use Case Relationship Description
If you are using Use Case Inclusion, Extension, or Generalization in your diagram, give a high level explanation of each relationship.
[Add text here]
2.5 Activity Diagram
[Add Diagram here]
2.6 Flow of Events
Describes the main flow of the Use Case and system responses.
Step | Actor | Process Step | System Response | Source Class Name |
1 | Actor for step, empty for system only steps | Step enacted by Actor, empty for system only steps. | Detail the steps involved in the main flow. (Alternate/Exception Flow) | Example Class |
|
|
|
|
|
2.6.1 Alternate Flows of Events
This section describes the alternative flow of events based on variations in the main Use Case scenario that still result in a Successful End Condition at completion of the Use Case.
Possibly additional steps (open other forms etc)
2.6.1.1 Alternate Flow 1
Base Step | Alt. 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.6.2 Exception Flows of Events (Negative)
This section describes the exception flow of events based on variations in the main Use Case scenario that result in a Failed End Condition for completion of the Use Case.
2.6.2.1 Exception Flow 1
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. |
|
|
|
|
|
|
|
|
Document