Essential use cases are part of Usage-Centered Design, as developed by Larry Constantine and Lucy Lockwood [9]. Constantine and Lockwood support use cases, and agree with many claims about their advantages. They also see limitations: ``In particular, conventional use cases typically contain too many built-in assumptions, often hidden or implicit, about the form of the user interface that is yet to be designed.'' This is problematic for UI design both because it forces design decisions to be made very early, and because it then embeds these decisions in specifications, making them difficult to modify or adapt at a later time.
Essential use cases were designed to overcome these problems. The term ``essential'' refers to essential models that ``are intended to capture the essence of problems through technology-free, idealized, and abstract descriptions''. Constantine and Lockwood define an essential use case as follows:
An essential use case is a structured narrative, expressed in the language of the application domain and of users, comprising a simplified, generalized, abstract, technology-free and implementation independent description of one task or interaction that is complete, meaningful, and well-defined from the point of view of users in some role or roles in relation to a system and that embodies the purpose or intentions underlying the interaction.
Figure: A conventional use case for getting cash from an automatic teller system. (From Constantine and Lockwood.)
Figure: An essential use case for getting cash from an
automatic teller system. (From Constantine and
Lockwood.)
Essential use cases are documented in a format representing a dialogue between the user and the system. This resembles a two-column format used by Wirfs-Brock [27]. In Wirfs-Brock's format, the column labels refer to the action and the response. In contrast, the essential use case format labels the columns user intention and system responsibility.
These new labels indicate how essential use cases support abstraction by allowing the interaction to be documented without describing the details of the user interface. Note that the abstraction does not really relate to the use case as a whole, but more to the steps of the use case. In this way an essential use case does specify a sequence of interaction, but a sequence with abstract steps.
Constantine and Lockwood give the examples shown in figures 
and
. The dialogue in figure is for a conventional
use case, described in terms of actions and responses. The dialogue in
figure is for an essential use case, described in terms
of intentions and responsibilities. The steps of the essential use
case are more abstract, and permit a variety of concrete
implementations. It is still easy to follow the dialogue, however, and
the essential use case is shorter.
Jacobson created use cases to support object-oriented software design; Constantine and Lockwood introduced essential use cases, and the larger framework of essential modeling, for user interface design and development. Our observation is that there is actually nothing about essential use cases that rules out their use for object-oriented software development, which means their advantages may also apply in that area.