While we have described the cards and roleplay as involving use cases, we in fact typically work with a refinement of use cases known as essential use cases. This refinement was developed by Constantine and Lockwood as part of ``Usage-Centered Design'' [5], a process for developing user interfaces. They make an important observation:
``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.''
Constantine and Lockwood define essential use cases as ``a simplified and generalized form of use case''. They use the term essential because these use cases: ``are intended to capture the essence of problems through technology-free, idealized, and abstract descriptions''.
The abstraction in an essential use case does not 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. For example, figure 5 shows an ordinary use case for a banking system, detailing specific concrete steps in the dialogue such as insert card and read magnetic stripe. Figure 6 shows an equivalent essential use case that begins with the more abstract ``identify self''. Also, note that the ordinary use case labels the roles ``user action'' and ``system response'', stressing an actual concrete interaction. The essential use case instead takes a more abstract yet also more rich approach, by casting the user part of the dialogue as ``intention'', and the system part as ``responsibility''.
We have adopted this form of use case for our cards and roleplay for several reasons. The abstraction keeps essential use cases brief, and so able to fit on an index card. Also, the abstraction helps avoid unnecessary debate about irrelevant implement details, so allowing more rapid progress to be made. The focus on intention and responsibility also has important consequences.
Figure 5: An ordinary use case for getting cash from an
automatic teller system. (From Constantine and Lockwood.)
Figure 6: An essential use case for getting cash from an
automatic teller system. (From Constantine and Lockwood.)
Our experience with essential use cases has shown that the simple benefits are realised, and there are also more profound effects. As we had hoped, the abstraction does keep the use cases brief enough for an index card, and also helps avoid premature debate about implementation.
On a deeper level, we have seen there is heuristic merit in casting the user role as expressing ``intention'', and the system role as expressing ``responsibility''. Together, these lead to use case dialogues that better reflect the real motivation of the user, and better capture the requirements of the system, while at the same time avoiding premature design decisions.
We have found there are some adjustments needed in working with essential use cases. One adjustment is that use case roleplay will itself be abstract, and so not as realistic as if it involved specific interface details. In our experience this has not been problematic, although teams do find it helpful to sometimes consider concrete enactments of the use case to check their understanding. Another possible adjustment is that essential use cases could easily accommodate system responsibilities that do not directly involve interaction. For example, the use case in figure 5 might well involve responsibilities to maintain account balance integrity and to audit trail entries.
The focus on the system part of the dialogue as documenting responsibilities has interesting and far-reaching implications for system development. When use cases have been determined, one of the later activities in object-oriented development is the design of the system as a set of collaborating classes and objects. One approach to determining this set is to focus on responsibilities: this is a key part of using CRC cards, and is used more thoroughly in responsibility-driven design [10, 11].
Responsibility is good heuristic for designing objects that involve behaviour and date working together, because the word ``responsibility'' suggests both a duty to do something, and the resources with which to do it. Responsibility also allows delegation, allowing large responsibilities to be managed by delegating smaller responsibilities to others.
Essential use cases capture the system role as a set of responsibilities. This means that when all the use cases are determined, we also have the set of responsibilities for the whole system. We can regard the system as a single object, and the responsibilities as the specification for the object. We can design as set of collaborating objects as a decomposition of the system object, with the system responsibilities distributed appropriately.
Techniques such as CRC and responsibility-driven design already address how to distribute responsibility. But these techniques begin with responsibilities associated with objects and classes identified using domain analysis. Essential use cases deliver a set of responsibilities specific to the system being designed, which presents valuable opportunities.
Ultimately, the system responsibilities and the object set responsibilities must match. There are two major implications. Firstly, we can begin CRC or responsibility-driven design with responsibilities informed by the essential use case responsibilities, as well as the results of domain analysis. Secondly, we can check the set of object responsibilities at any time to see if they indeed will meet the system requirements. Even if we rapidly explore design alternatives, or consider existing reusable design assets such as patterns, frameworks, or components, we will always be able to check that the objects work together to fulfill the responsibilities specified by the use cases. The first implication means better operational guidance in beginning design. The second implication means better traceability between design and requirements.