use case | assists an architect with the first draft of the architectural model |  |
can be used to plan the development process |  |
can be used to structure user manuals |  |
can form the basis for the definition of test cases |  |
can serve as as part of the contract between the customers and the developer |  |
has definition A way in which a system can be used, described as a step-by-step sequence of actions, along with the system's response and certain other information |  |
describes the user's interaction with the system |  |
does not describe the computations the system performs |  |
give an architect an idea about which components will be needed and how they will interact |  |
has a use case name |  |
has actors the actors or actor who can perform this use case (optional) |  |
has goals zero or more goals |  |
has postconditions zero or more postconditions |  |
has preconditions zero or more preconditions which describe the state of the system before the use case occurs |  |
has related use cases zero or more use cases that may be generalizations, specializations, extensions or inclusions of this one |  |
has steps each step of the use case using a two column format, with the left column showing the actions taken by the actor, and the right column showing the system responses |  |
has summary |  |
includes only actions in which the actor interacts with the computer |  |
is a subtopic of 7.3 - Developing Use Case Models of Systems |  |
is used to develop requirements |  |
is used to validate requirements |  |
is a kind of subject |  |
may have high political or commercial value |  |
may have one or more preconditions |  |
may represent a high risk because for some reason their implementation is problematic. |  |
must be validated using requirements validation methods |  |
normally includes only actions in which the actor interacts with the system |  |
should be independent of any particular user interface design |  |