In his 1992 book[6], Ivar Jacobson defines a use case as ``a behaviorally related sequence of transactions in a dialogue with the system''. The general idea is to represent intended sequences of interaction between a system, even if not yet implemented, and the world outside that system. This idea is very powerful, for several reasons.
In the early stages of development, use cases help to focus on interactions as a way of eliciting intended or desirable system behaviour and so capture requirements and help determine specifications. This technique is effective because interactions can be described in forms very easy for people to recall or imagine, such as narratives or dialogues.
In the later stages of development, use cases help again because of the focus on interactions. The interactions can now be regarded as the embodiment of specifications that the system must meet. In design and implementation, a structure must be determined and created that will meet these specifications. In review and testing, use cases can be used to drive system behaviour for examination.
Use cases are based on sequences of interaction, and desirable interactions typically follow a structure of coherent progression, on a limited scale, toward a goal or sub-goal. This allows a useful partitioning of specifications. The partitioning into use cases is helpful in overall management throughout development, because use cases can be organised by selecting, grouping, filtering, prioritising, and so on.