Use cases have become an indispensable tool for requirements elicitation and documentation. They have the advantage of being relatively easy to write and, if written well, they are relatively easy to read and understand. This advantage comes in part from the fact that they are created using ‘natural’ language text. They can and should be written in ‘the language of the user’. Each use case tells a story about how an actor will achieve a goal using the functionality available in the system. For many agile and iterative software development processes some form of use case or user story is the primary requirements artifact.

Many teams using use cases eventually discover two disadvantages: 1) natural language text unfortunately allows a great deal of ambiguity, and 2) reading and reviewing any non-trivial use case has the potential to become tedious. The combination of these two disadvantages can mean missed or incorrect requirements. A design and implementation based on a requirements specification with missing or incorrect requirements will almost certainly result in the delivery of ‘bad’ software from the users’ perspective and frustration for everyone involved in the project.

So, is there a cure for the tedium and frustration?

One way to reduce the tedium is to reduce the size and complexity of use cases, possibly even limiting the use case documentation to the user story or use case narrative. This can help reduce the tedium but it can also allow for increased ambiguity. The ambiguity will have to be resolved at some point, either through additional work in design or additional iterations through the requirements discovery process.

The Class-Responsibility-Collaboration Card is a tool originally conceived as way to teach object oriented principles that has gained acceptance as a useful modeling technique. Responsibility-Based Modeling and Responsibility-Driven Design both build on the concept that software components have responsibilities and collaborate to produce results of value.

CRC cards can be used with use cases and user stories to help eliminate ambiguity and reduce tedium and frustration. With a little creativity they may even make the process fun!

A use case can be thought of as a collaboration. The objects in the system will collaborate to produce the result of value. Each object plays a part in the collaboration. Each CRC card represents one object in the system. At a conceptual level the focus should be on the business objects, in other words, things that exist in the real world. It may make sense to introduce a user interface object and a controller, but avoid the temptation to introduce design level objects.

Getting to the point where you can start using CRC cards of course requires writing use cases or user stories and identifying the objects involved. A common technique for finding objects is to go through the use case identifying the nouns in the narrative text. This is not a bad technique, but don’t rely on it exclusively. Take some time to think about the business objects involved in the use case. If you can think of objects that are not represented by nouns in the narrative it may make sense to revise your narrative to include the new objects.

For each class of objects you identify, create a CRC card. Name the class and list the things the objects will do and the things the objects will know about. Also list the other objects the objects in this class will collaborate with. CRC cards have traditionally been created using index cards. The small size of the cards helps emphasize the importance of limiting the responsibilities of any one class. The cards are cheap and easy to lay out on a table and move around. Large post-it notes or self-stick flip chart paper can also be used and can be hung on a wall during facilitated sessions.

Now comes the fun part. Once you feel you have a pretty complete set of CRC cards for a use case, assemble a group of subject matter experts (SMEs). Even better, have the SMEs help with the identification of objects and creation of the starting set of cards. Pass out the cards so that each person in the room has a card or so that the card for each object is held by a person or small group. Ideally, the person holding the card should have some domain knowledge for the object represented by the card.

Have the group ‘act out’ the use case. You may find you need a card for the actor and, as noted above, you may need a card for the user interface and a use case ‘controller’. Walk through the use case steps. At each step, identify the objects and the interactions they are involved in. Is data being provided as input or output? Is some process taking place to alter the state of an object? Are any objects or interactions missing? Document everything and work through each alternative course of events. At each step of the use case, each requirement must be supported by some object. Keep the discussion focused on business objects at the conceptual level. Avoid the temptation to create design level objects that do not represent things that exist in the real world.

CRC cards can help add rigor to the process without making it tedious. The cards’ ease of use makes them ideal for agile modeling sessions but they work well with any technique that includes user stories or use cases. The idea of role playing may not work for all groups so be aware of the culture you are working in. Getting people up out of their seats, moving about the room, and interacting can help keep everyone engaged. Once a team gets used to doing this as a regular part of the process they are unlikely to want to go back to the old, tedious, and error prone ways.