Guideline: Use-Case-Analysis Workshop
Topics
Introduction 
Performing Use-Case Analysis as a group activity is important in the early iterations as a team-building activity, and to establish a common vision of the architecture of the system. It represents an important transition point in the iteration, as it provides a bridge between the user's view of the system (represented by use-cases) and the system designer's view of the system (represented, at this point, by analysis classes).
In later iterations, or with an experienced team, Use-Case Analysis may be performed more as an individual activity, if at all. When there is a well-formed existing Design model, there may be less value in looking for new objects, since existing classes in the design are likely to account for any system behaviors required by new use cases.
Competencies Needed
The workshop should be organized as a brain-storming session, during which a wide range of competence is needed from various areas:
- Requirements
- Analysis & Design
- Architecture
- Test
- Domain issues
- Methodology issues in general
Keep the workshop small: more than 6-7 persons will inhibit the free and open participation of all members.
Equipment Needed
- A large white board to sketch on
- Plain A3 or legal paper; the size is depending on the largest format your copy machine can manage.
- Tape
- Sticky notes (in several different colors, if possible)
- White board pens (red, green, blue).
- Pencils (red, green, blue).
- Walls to which papers can be attached
Time Needed
Plan on at least a few hours per use case on average. Early on, they will take longer, but the time will go down as the number of new classes drops and the group gains experience.
Roles
The following responsibilities occur during the workshop. It is a good idea to rotate the responsibilities and let everybody try all responsibilities.
- Leader: leads the discussion, draws communication diagrams on the white-board. It is natural that the method consultant take on this responsibility at least at first, to get started; later the leader role should be rotated among team members to let them gain experience.
- Class "Owner": records information about a set of assigned classes. There will likely be several people with this role, each with a set of classes.
- Secretary: makes a copy of the communication diagram sketched on the large white-board, using the same colors as on the white board.
Running the Workshop
The team steps through the flow of events of the use case. For each behavior identified in the use case, an object is identified that provides the behavior. The object may be an instance of an existing class, or the class may need to be created.
The leader draws the communication diagram on the white-board, and everybody participates in the discussion.
When the use case has been diagrammed, a copy of it on an A3/Legal size paper should be made, using the same colors as the white-board diagram.
At the same time, the responsibilities of the objects are documented using A3/Legal paper, in the format described in the section "Tailoring" in Artifact: Analysis Class. Record the responsibilities, events, and classes collaborated with on sticky notes; this will make it easier to move responsibilities around.
Drawing Communication Diagrams
The following conventions make the diagrams easier to read and work with during the workshop.
- Draw all classes and links, and write object names, in blue.
- Write the text of the messages and what kind of information is sent over the links, on sticky notes, in green. This makes it easier to read and easier to move the messages around between objects as the object responsibilities are balanced.
- Write the numbering of the messages (i.e. the order of the flow of events) on separate sticky notes in red. This allows the sequence of events to be adjusted as the responsibilities of objects are re-balanced during the workshop.
Draw one diagram for the basic flow of the use case, and additional diagrams for alternative flows. For simple use cases, a single view may suffice for all.
Example Communication Diagram for Use Case Authenticate User in an Automatic Teller Machine.
