Also Known As: Use Case Bodies, Use Case Cards
How can you describe what each use case involves.
Even when you've completed your Candidate Use Case List (1.2), identified the Focal Use Cases (1.3), and perhaps checked some Use Case Diagrams (1.4), you still don't really have much detail about what the use cases will involve: what information needs to be provided by actors, and what behaviour needs to be provided the system to successfully implement the use case.
The names of use cases only give you a rough idea of what the system is supposed to do. You still need to determine the detail of the interaction with the system. However you don't want to have to make decisions relating to technology (such has what I/O devices will be available, user interface requirements, and so on), despite pressure by the stakeholders to use particular technology (they will probably change their minds by the time implementation starts). And on top of that, you still have to come up with the details quickly.
To address these issues, you need to provide more detail about each use case; but, how much detail is too much? You could write detailed descriptions of what each use case will involve, but this will take lots of effort, produce a large amount of dense documentation that will be hard to manage, and probably of little use to the eventual development team.
Furthermore, to be able to write detailed descriptions of the interaction of each use case requires that you have already decided how each use case will be designed, if not already implemented -- whether this will be handled by a computer system, by a worker as part of a business process, by an application program, a web site, or a WAP phone. Unfortunately, if you are solely responsible for analysis (say the design is being outsourced to a graphics house and the implementation to India), then you don't want to have to do design that will be replaced later. If you are responsible for design, you can't really begin that until you have worked out what goals the design should meet to be usable -- that is, what users need to do to complete each use case.
Therefore: Write essential use case dialogues for each use case.
Essential use cases are part of Usage-Centered Design, as developed by Larry Constantine and Lucy Lockwood [8]. 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.
Constantine and Lockwood give the examples shown in figures 4 and 5. The dialogue in figure 4 is for a conventional use case, described in terms of actions and responses. The dialogue in figure 5 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.
Figure 4: A conventional use case for getting cash from an automatic teller system. (From Constantine and Lockwood.)
Figure 5: An essential use case for getting cash from an
automatic teller system. (From Constantine and
Lockwood.)
So we document each use case with a ``use case dialogue''. We write use cases on index cards, so we also call these dialogues ``use case cards''. A use case dialogue documents the chronological steps in the use case as the user and the system interact. We typically document the use case card with the users part on the left hand side, and identify this as the ``user intention", which reminds us to focus on the users real goals for the step. On the right hand side, we identify the system ``responsibility", stressing that the system too has goals incumbent upon it. The division down the centre can be regarded as the ``interface" between the user and the system, and serve as reminder that interaction is communication across this division.
We write the steps of the interactions under the assumption that the actor has already chosen to do this use case and has already told the system that the are doing it, so we don't need to include a separate step to start the use case.
We prefer essential use cases to conventional use cases because they allow a certain independence from technology choices in later or subsequent implementation, and also allows us to make progress quickly, without having to make difficult decisions otherwise necessary. Also, we believe their emphasis on system responsibility leads to better traceability between requirements and design.