In essential use cases, the dialogue specifies not just system response, but system responsibility. Some of the effects of this arise early, and in a similar but more complex way to those involving user intention. Other effects become clear only later in design.
In role-play, the user or actor role often allows identification with a known kind of person, thereby allowing some inspiration about intention. The system role involves identification with an unknown entity, giving less opportunity for motivation. It is known that the system should correctly interact with the user. However, this provides little leverage in discovering motivation, allowing identification, or determining desirable interaction.
To gain insight about any element of dialogue, one needs to consider the purpose beyond it. For the user, essential use cases employ the term ``intention'' to denote the purpose. This reflects that nature of the user as external but understandable, and intention is something we are able to estimate.
For the system, we must instead describe something internal to the system which will guide its design. This is what responsibility is all about: it is an expression of what needs to be done, without unnecessary detail of how it will be done. This a more subtle motivation than ``intention'', but when understood it does assist determining the use case, and it also assists role-play. The motivation for the user is the intention to accomplish goals; the motivation for the system is the responsibility to fulfill obligations.
Essential use cases harness abstraction to ensure the user interface is not designed too early, and can be designed to be independent of any particular user interface technology. In the user role, the focus on intention supports abstraction by avoiding the need to decide details of how the intention is expressed. In the system role, the focus on responsibility supports abstraction by avoiding the need to decide details of how the responsibility will be implemented.
Essential use cases do have some user interface heritage that must be addressed in the context of more general system development. In examples of essential use cases employed to develop user interfaces, the system responsibilities typically concern presenting some information to the user. In this way, the system plays its part in the dialogue. However, in more general system development, the system will have responsibilities that go deeper. For example, the banking system essential use case gettingCash shown in figure 2 clearly relates to the user interface, but says little about responsibilities relating to the accounts and money in the banking system.
Of course, ordinary use cases may also have this same weakness. If the use
case only documents the dialogue between the user and the system, important
context may not be obvious. For example, the ordinary use case in figure
also says little about the system role relating to accounts
and money.
With essential use cases, the focus on responsibility, rather than
response, addresses this limitation. It seems reasonable to extend
essential use case practice, and identify significant responsibilities
that are not directly concerned with communicating with the user. For
example, consider figure , where the essential
use case for gettingCash has been augmented to show system
responsibilities beyond communicating with the user. These do not
strictly follow the dialogue form, although they resemble dramatic
``asides'' that precede communication. Most importantly, they add to
the completeness and coherence of the scene, and aid system
development.
Figure: An essential use case for getting cash, augmented to
show system responsibilities not directing involved with user
communication.