We have now observed many teams applying use case cards and roleplay. We have used the approach in working with more than twenty teams in industry, where the teams typically included non-technical staff such as business analysts and line managers. We have also introduced the approach in teaching and project mentoring at our university, especially in our undergraduate courses in object-oriented development and software engineering. Our experience has been very positive.
We had explicitly sought active and immediate engagement by team members, and that has happened as expected. As with CRC cards, the concrete element of the index cards, together with the behavioural element of the roleplay, together focus attention and command active participation. This alone is valuable because it ensures a focus on determining requirements that involves the whole team.
The index cards also help in a way that, as with CRC cards, relates to their simple nature as cards: they are discrete and concrete, and only a lightweight investment. Cards can be arranged or prioritised on a table top, needed cards can be selected while leaving others, and cards can held during roleplay. A card can be changed or discarded easily without disturbing others, and the change can made immediately.
Figure 3: A sample dialogue from roleplay of a use case in a theatre
booking system, illustrating how roleplay leads to early detection
of use case difficulties.
The advantages of roleplay go deeper. People, even non-developers, are good at following dialogue. Moreover, they are familiar with the dramatic device of roleplay and the willing suspension of disbelief on which drama depends. People are typically able to watch roleplay, and imagine the interaction with the finished system with real understanding. This is a form of fast prototyping, and it allows fast review and feedback that allows iterative improvement.
Bellin and Suchman Simone point out that CRC roleplay leads to unanticipated insights, and the same thing happens in use case roleplay. In CRC roleplay, the insights typically concern how best to distribute intelligence among a set of collaborating objects. In use case roleplay, the insights relate to how best to communicate across the boundary of the system.
The cards and roleplay technique themselves are not always sufficient in themselves to determine whether use cases are reasonable or not. There are many aspects to use cases, and developers need to be aware of the issues. In particular, developers need to be aware of studies about how use cases model systems [7, 1], and studies of what mades use cases actually useful [4]. Wirfs-Brock [13] discusses how good use cases resemble ``meaningful conversations'', and this especially relates to our technique. Roleplay makes the conversations come to life, and makes it easier to assess how meaningful they really are.
In our experience, one critical issue in determining requirements is simply determining the boundary of the system, distinguishing what the system should do from what it should not do. It can be very difficult reach the agreement necessary to make such distinctions while involving all the people involved, analysts and stakeholders.
Use case cards and roleplay have proven very useful in determining the system boundary. Our approach is to apply an approach familiar in design: we regard the system as a ``black-box''. The internal workings are not specified, but the way the system is used is specified by the use cases. The two-column dialog form of each use case card clearly shows the role of the user distinct from the role of the system, and the line dividing these roles is the boundary of the system.
There are several ways in which use case roleplay assists to determine the system boundary. In early exploratory roleplay, it can quickly become clear if team members differ in their understanding about what the system is required to do. People reading the same analysis documents can come up with different interpretations, and it is especially common for differences to arise between technical designers and business analyst or domain experts. It is important to detect and resolve such differences early, and determining actual interaction sequences for roleplay tends to expose these differences.
The exploratory roleplay can also expose unreasonable assumptions about both the user and the system roles. For the user, it can become apparent that actions specified in a use case are inconsistent with how an actual user is likely to behave. For the system, it can become apparent the required behaviour is not possible because critical information will not be available. Figure 3 illustrates anomalies can be detected while roleplaying. Actually play-acting the roles seems to make such anomalies more obvious than if the use case was just read carefully.
To resolve such anomalies, the use case steps may have to be modified, or the use case may need to be structured in a different way. Such changes may require modifications made to other use cases, and may even require even creation of new use cases. The important result is that problems can be identified and fixed at this early point, rather than at later more expensive points in development.
Roleplay also makes use case interaction understandable to observers outside a development team. This is especially useful in presenting use cases to stakeholders. Roleplay is quick, immersive, and very accessible. Without heavy investment, it makes is possible to discuss issues, compare alternatives, and possibly detect flaws.
To support use case roleplay and discussion about the system boundary, we have found use case diagrams helpful. We use a UML [8] use case diagram that shows actors (the UML term for users) as stick figures and their involvement with use cases as ellipses. We also explicitly show the system boundary, depicted as a box surrounding the use cases, with the lines between the actors and the use cases crossing the boundary, as shown in figure 4. The convention of showing the system boundary in use case diagrams was used by Jacobsen [6] but does not typically feature in UML. The depiction of the system boundary is helpful in visualising the system as a unit, and the boundary line is consistent with the line dividing the user and the system on the use case cards.
Figure 4: A use case diagram, explicitly showing the boundary
around the system object.