We have used and admired CRC cards for some time, and when looking for a way to make use cases more accessible, we decided to take a similar approach. Our basic idea was to use index cards for use cases, and to somehow involve roleplay as well.
Use cases describe interaction with a system, but there are several ways to describe interaction. We chose the form of a dialogue between a user and the system. We particularly hoped this would facilitate roleplay, because a use case in dialogue form resembles a script. The script has two roles, user and system, so use case roleplay can simply involve two people, each with a part in the script.
We decided that each use case card should represent a single use case, and should show the name of the use case, and the dialogue script. To easily distinguish the two roles, we split the card with a vertical line down the centre, and write the user's lines on the left, and the system's lines on the right, as shown in figure 1. This layout resembles the two-column format used by Wirfs-Brock [12]. This kind of layout is especially good for functional requirements because it highlights how the system is used, and how the system behaves. Non-functional requirements can also be accommodated, simply by making brief notes at the bottom of the card, or on the reverse side.
Use case cards and roleplay assist primarily in elaborating use case ``bodies'', determining the steps of the interaction. Before that can happen it is first necessary to identify the use cases. This initially involves background analysis to come up with suggestions for the different ways users may interact with the system. In large system development, even use case identification can constitute an activity of significant size and scope. Our approach is to use analysis techniques to identify a wide variety of candidate use cases, and then prioritise them, selecting a few ``focal'' use cases that represent critical interactions.
We then start to work on these focal use cases by elaborating their steps with cards and roleplay. We generally suggest doing this with a small team of 3 to 6 people, similar to that recommended for CRC cards. We begin to work with cards by writing brief names for the focal use cases on the cards. For example, a banking system might have focal use cases called depositing cash, checking account balance, and withdrawing cash.
We then select a card and begin to work out the dialogue. We select people for the roles of user and system, and use an exploratory kind of roleplay rehearsal. The team works together on determining the steps in the dialogue. When ideas seem reasonable, the roleplayers ``play-act'' through the script, as shown in figure 2. The rest of the team audit, and afterwards the dialogue is discussed and improved where necessary. Increasing availability of document cameras means cards can easily be projected on a large screen for larger groups to follow. This process is applied iteratively until the team is satisfied the dialogue represents the way the user and the system should interact. Sometimes it helps to leave one use case and work with another, returning later to improve the earlier one.
The primary use of roleplay is for exploratory and iterative development of the use cases. We also use roleplay as a way of presenting use cases for review, however. Such reviews may be conducted by peer developers, by people working on other aspects of a project, or by stakeholders or experts in the system domain.
After the index cards and roleplay have helped determine the use case bodies, the full details may be recorded in requirements documentation or in CASE tool databases. The use cases can be used to drive system design and review, and again later in system testing and demonstration. The cards and roleplay may still prove useful in some later activities, where their immediate and lightweight nature support rapid review and exploration of interaction alternatives.
Figure 2: A team performing use case roleplay while others review the
dialog.