[Replace Use Case Template with a short meaningful name. The name should represent the goal of the use case. Avoid numbering schemes such as "Use Case 001".]
[Provide a sentence or short paragraph that clearly defines the
purpose or goal of the use case.
A use case should have only one goal. Using goals helps
specify the scope of a use case.]
[An actor is a role of an entity external to the system. Actors
can be humans, machines, or devices. "One physical object may
play several roles and therefore be modeled by several
actors".
A primary actor is one having a goal
requiring the assistance of the system.
A secondary actor is one from which the system needs assistance
to satisfy its goal.
One of the actors is designated as the
system under discussion.]
Priority: ...
[How critical is the Use Case to the system:
Performance: ...
[The amount of time the Use Case should take]
Frequency: ...
[How often the Use Case is expected to be performed]
[Preconditions indicate circumstances that must be true prior to the invocation of the Use Case. If preconditions have an ordered sequence, display them in an ordered list. If this Use Case depends on a previous Use Case's successful execution, list the previously executed Use Case in this section. If a precondition is not satisfied, the final state of the Use Case is undefined.]
[Each Use Case has only one basic course. The basic (or main) course is the sequence of steps that the Role or Actor is likely to take in order to accomplish the goal of the Use Case. The first step describes the action that initiates the Use Case.
Each step can optionally have alternate course(s), exception course(s), and/or postconditions. The postconditions of the last step is not necessary because the postcondition of the Use Case (validates that the Use Case goal was met) should be valid.
Steps can optionally refer to other Use Cases for "use relationships" or Collaboration Cases for traceability. Alternate and exception courses should be defined within the same Use Case.
Use relationships occur when you have a chunk of behaviour that is similar across more than one use case and you don't want to keep copying the description of that behaviour. Use it when you are repeating yourself in two or more separate uses cases and you want to avoid repetition.
Extend relationship occurr when you have one use case that is similar to another use case but does a bit more. Use extend when you are describing a variation on normal behaviour. ]
[OPTIONAL - Each Use Case has zero to many subflows. A Subflow is a sequence of actions within a Basic, Alternate or Exception Course that is identified with a unique name. A Subflow acts as a building block of Courses. Courses can (if applicable) be build up with Subflows.
For example if we have a set of closely related requirements that form a single goal and help to clarify the requirement more as if we moved them to individual Uses Cases.
All the rules of Basic Courses apply also to Subflows (i.e. they can have Alternate flows, Exception flows etc.)]
[OPTIONAL - Each Use Case has zero to many alternate courses. The alternate course is a different sequence of steps that the Role or Actor can take that also accomplishes the goal of the Use Case. The alternate course extends the basic course with additional steps. The title of each alternate course should appear exactly as written in the cross-referencing Basic Course step. Alternate courses may include exception courses and optional postconditions. NOTE: This is the same as the UML's "extend relationship" of Use Cases.]
[OPTIONAL - Each Use Case has zero to many exception courses. The exception course is a sequence of steps that the Role or Actor takes when the task is interrupted or a single postcondition that validates the exception course was taken. The exception course indicates the cause of the interruption, then indicates how the Role or Actor recovers. Exception courses must provide at least a postcondition for the step that validates the exception course that was taken. The postcondition that validates the goal of the Use Case is not necessarily true after the exception course has been taken. The title of each exception course should appear exactly as it is in cross-referencing Basic Course step. ]
Postcondition: ...
[Mandatory postconditions that validate the exception
course. ]
[The postconditions validate that the basic course and all alternate courses successfully achieved the stated goal of the Use Case. The postconditions are not necessarily true if an exception course was taken.]
Issues to be Determined or Resolved: ...
[OPTIONAL - List any issues that remain to be decided, or to be reviewed regarding this use case. These issues may include scope of the use case, task description, or user interface.]
Notes:...
[OPTIONAL - List any note that help in clarifying the Use Case, but that do not fit in any other standard Use Case field.]
Last modified: 2jun03