We began our exploration of essential use cases in object-oriented software development for practical reasons. We wanted to improve use case understanding and elaboration as a team activity. We were familiar with the CRC (class-responsibility-collaborator) technique for design [4], and decided to develop a similar technique for use case analysis. Essential use cases brought many characteristics beneficial in our new technique.
Like CRC, our technique involves using index cards and role-play.
Teams work together to determine candidate use cases, allocate one
card per use case, and write the name of the use case at the top. Each
card is then divided by a vertical line, with the left hand side for
the user and the right hand side for the system. (See figure
.) Teams then work in pairs exploring dialogue, with
one person playing the user, and another playing the system, together
writing the dialogue for the card. Pairs then role-play in front of the
team who review the use case.
Figure: An Essential Use Case Card
Essential use cases are a dialogue between a user and the system. This facilitates direct use of role-play, as the players can regard the use case as a script, and one team member plays the part of the user, and another plays the part of the system. The dialogue also helps because the the interaction is very visible. Wirfs-Brock points out that use cases can easily be seen as a ``conversations'', and this familiar form of interaction assists in the modeling process [28]. This has the important effect that the use case dialogue and role-play really help determine the boundary of the system, making it clear what is done outside and what is done inside the system.
We have now used this approach working with a number of development teams, both in industry and at our university, and have gained experience about the effects of essential use cases on aspects of the development process. Essential use cases are abstract, and this brings many benefits. The dialogue is brief, and so able to fit on a card, and the abstraction can also quicken the analysis process. In discussion and exploration, many specific ideas for interaction will arise. However, the benefit of abstraction is that no particular concrete interaction sequence need be determined at this early point. This allows useful exploration to help determine the essential use case, while avoiding the need to make time-consuming implementation decisions.
The abstract nature of an essential use case means that a direct role-play does not yield ``realistic'' dialogue. However, role-play in early stages of development needs to be lightweight, and realism is not critical. If concrete examples of abstract elements of the dialogue are needed to clarify issues, it can be useful to explore a concrete scenario, referred to as an ``enactment'' of the essential use case, representing a possible implementation.