A general definition of a Use Case:
“A description of system behavior, in terms of sequences of actions. A use case should yield an observable result of value to an actor. A use case contains all alternate flows of events related to producing the ‘observable result of value’.”
“Yield value” is decidedly the unifying factor for what determines what a Use Case is or isn’t. It means that the Use Case must be a self-contained piece of work that when finished, adds value; or a transaction that gives value. So just a part of the flow of actions would break that unity. The Use Case must “stand alone” as the complete, and not partial, achievement of an actor’s goal.
It has also been repeated many times that the Use Case that the Use Case is the What of functionality, divorced from the How, design, interface or implementation details.
(Taken from a slide from Jim Heumann’s video Writing Good Use Cases)
Note: Based on the work of Ivr Jacobson, Kurt Bittner and others at IBM Rational Software.
AWebFactory note: This is a somewhat polemic requirement. There could be cases when you need to use the “precedes” stereotype.
The Use Case forms an important part of Requirements Management, and in defining the Requirements Baseline, which is the basis for agreement with the customer, the point after which all incoming requirements must be dealt with as part of Change Management.
The Use Case also forms the basis for the work of the development team in the disciplines of Analysis And Design, Architecture and Test. Very often, for example, the Use Case hierarchy is taken as the starting point for the Test Case hierarchy.
See Use Case Text
Content
Victor Kane (ProjectMaster) and awebfactory.com.ar