A CRC card is ostensibly an index card that is used to represent classes, their responsibilities, and the interactions between them. The term CRC card is also used to refer to a methodology for object oriented modeling based on their use.
Kent Beck and Ward Cunningham introduced CRC cards in a paper "A Laboratory for Teaching Object-Oriented Thinking" that was presented at the OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) conference in 1989. A tutorial on the subject can be found at http://www.csc.calpoly.edu/~dbutler/tutorials/winter96/crc_b/. The CRC card methodology was originally designed as a teaching tool but has proved useful as a modeling tool as well.
The three parts of the CRC acronym were felt by the authors of the paper to represent the essential dimensions of object oriented modeling. The term Responsibilities refers to the contract that the class under discussion offers to the rest of the world (Interface and Contract are similar concepts). Responsibilities model the things that a class can do. Services, Methods, or Operations will result from these. The term Collaborators refers to the classes whose services the class under discussion will use. Kent Beck tried unsuccessfully to use ther term Helpers instead of Collaborators to indicate classes that were supporting the class under discussion. It is widely believed that the terminology was chosen because CRC are the initials of Ward Cunningham's son.
Why use CRC cards?
They are portable. No computers are required so they can be used anywhere. Even away from the office.
They allow the participants to experience first hand how the system will work. No computer tool can replace the interaction that happens by physically picking up the cards and playing the role of that object.
They are a useful tool for teaching people the object-oriented paradigm.
They can be used as a methodology themselves or as a front end to a more formal methodology such as Booch, Wirfs-Brock, Jacobson, etc. Although CRC cards were created for teaching, they have proven useful for much more.
They have become an accepted method for analysis and design. The biggest contributing factor to their success is the fact that they provide an informal and non threatening environment that is productive to working and learning.
The exact format of the card can be customized to the preferences of the group, but the minimal required information is the name of the class, it's subclasses and superclasses, it's responsibilities and the collaborators for each of those responsibilities. The back of the card can be used for a description of the class. During the design phase attributes of the class can be recorded on the back as well. One way to think of the card is that the front contains the public information, and the back contains the encapsulated, implementation details. As a class is defined a card is made for that class with its name entered. When a class is assigned to an individual that has only a class name on it, the individual (or the group) selects an initial set of responsibilities for the class. This initial set should be whatever (if anything) is immediately obvious.