inclusion | has definition A use case that captures commonality among a set of other use cases | |
has purpose to allow you to express a part of a use case so you can capture commonality between several different use cases | |
is a subtopic of 7.3 - Developing Use Case Models of Systems | |
is included in other use cases | |
is a kind of use case | |
represents a performing of a lower-level task with a lower-level goal | |
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 | |
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 used to develop requirements | |
is used to validate requirements | |
may have high political or commercial value | |
may have one or more preconditions | |
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 | |