<Project Name> | Document Version <0.1> |
|
|
Use Case Specification | Date: |
|
|
Template Name: UseCaseSpecification | Template Version: 0.1 |
|
|
3 Preconditions
[A precondition of a use case is the state of the system that must be present prior to a use case being performed.]
3.1 < Precondition One >
4 Postconditions
[A postcondition of a use case is a list of possible states the system can be in immediately after a use case has finished.]
4.1 < Postcondition One >
5 Basic Flow of Events
[This use case starts when an actor requests that the system do 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 the interaction between the system and the actors. 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 it is not defined. It is better to say the actor enters the customer’s name and address. The Domain Model is essential to keep the complexity of the use case manageable⎯things like customer information are described there to keep the use case from drowning in details.
Alternate flows must be described in the Alternative Flow subsection. Alternate flows must end with either “the use case ends” or “return to [a step in a flow].”
<indicate if Confidential>
copyright <COMPANY>, 2007
Page 4 of 9
