Work Guidelines: Use-Case Workshop

Organization of the Workshop

The use-case workshop is an organized brain-storming meeting. A wide range of knowledge needs to be represented:

Customer requirements
System design
Unit design
The Rational Unified Process
Testing

This means that the group will contain people with different backgrounds, knowledge and experience. Try to keep the group small (less than ten). A regular setting is to compile half of the group from the development team and the other half from user representatives. In the middle of this is the facilitator. The facilitator should play the role of a moderator – a catalyst for all ideas and wishes.

Tools

Tools that you need are:

Two large white boards (one is sufficient but two is better)
Easel charts
Tape
Two colors of self-stick notes
White-board pens (multiple colors)
Pencils
Walls on which to attach paper–preferably in a "war room" that you can use and leave undisturbed for two or three weeks.

Defining Actors

On the white board, draw a cloud or an icon of the system and then try to write down the users of the system. In the real world, it is not always as obvious who they are as you might think after having read any book on use-case modeling. This is not the case in the real world. Also, developers are oftentimes used to thinking about details in the system, not so much about the user's roles.

In administrative systems, it is usually a little bit easier to define users than it is for technical systems.

Try to look at the system with "a bird's eye view" and don't try to find the structure in detail. Be prepared to find a lot of actors (10 to 20). This is okay for now; later on, you will remove the ones you don't need.

An Administrative System

Ask this question: What are the roles in the organization that will use this system? Draw a stick man for each role that is suggested, and write a name below the stick man. Then list two columns of actors on the white board – one on each side of the cloud or icon that you already drew. Sometimes it can be useful to use the word role or user instead of actor.

Questions to ask:

Who will use this system?
What other systems will this system send information to?
From what other systems will we receive information?
Who starts the system?
Who will maintain the user information?

Instance or Class?

You may get questions like "Why isn't Tom the actor? It's always Tom who does that". You will then need to ask more questions to gain an understanding of what Tom’s role is. The name of the actor should reflect the role.

What is Tom's role?
Who else may is also able to perform that role?
Why does Tom have that role?

Many actors can be identified directly through their regular positions in the organization. A position in the organization could correspond to more than one role to the system. For example, Tom may be a regular depot worker as well as the person responsible for reorganizing the depot to create space for new products. Those two responsibilities may be two different actors to the system.

Some people will want to generalize to the extreme. They may suggest a User as an actor – and then suggest that is the only actor we need. True – but boring, and doesn't add much to the understanding of the system. Try to avoid discussing this suggestion if it comes up. Not the User actor on the board and then proceed to the next actor.

Tricks of the Trade

Ask everyone if there is anything missing.
Volunteer some bad suggestions. This way, the team can correct you and explain the exact roles of the system.
Always accept all suggestions – you can always remove duplicates and non-actors later on. To criticize someone’s suggestions will just kill the spirit of the meeting.

Defining the actors usually takes between 1 and 4 hours. The whiteboard should now list many actors, but make sure there is still room to add use cases. When the set of actors seems to be complete, it is time to start with the use cases.

Define Use Cases

Erase the cloud or icon from the whiteboard, and start to identify use cases. Focus on concrete use cases – avoid discussion about use-case relationships. Draw an ellipse and write the name for every suggestion. Draw arrows to the actors.

Use the fact that you don't know anything about their application as a strength. The participants of the workshop need to tell you what the system is supposed to do. You should ask a lot of questions about the system. When the participants provide you with explanations, use cases will appear.

Some people can understand the concept of use cases right away, and some people cannot. To put the concept into an easier perspective, get somebody to draw a system view. A system view is an abstraction of the system. For example, it can be a server with a database and a number of clients, or a number of circuit boards with their special tasks marked out. This view is usually easy to illustrate: one of the participants will generally take a whiteboard pen and show how the system will work. The system view will help to make the use cases extend from system border to system border, and will implicitly point at a number of different system states. Ask questions about these states, and some more use cases will appear. Check what will happen when different communications die – this can help you identify alternative flows in the use cases.

If you are working with a technical system, the system view is often something well-known to everyone and might be the best way to find actors. In this case, you might let them draw the system view before you start asking for actors.

If you are working with an administrative system, the system view may not be as obvious to everyone. In this case, a graph describing the manual routines may be more useful. The graph may describe how one business entity is moved from one person to another and what they are supposed to do with it. To visualize the process of order and delivery, the graph may show a schematic view of the customer office, our office, the storage and the customer storage.

Make sure that both the use-case model and the system view/business entity view are clearly visible to everyone. This is when having two white boards might come in handy.

Allow the use cases to have long names. A recently identified use case may have a name as long as a sentence – this will be a good start on the brief description of the use case, and then the name will be shortened later on.

There will always be a number of use cases that appear to have parts in common. Make sure everyone understands that this is acceptable for now. There is no point in structuring yet, since we don't know enough about the contents of the use cases. You should wait until after the flow of events has been outlined before you bring up any discussions about use-case relationships.

When the group agrees that the use cases on the board cover the functionality of the whole system, break for lunch.

Once you are back from lunch, review the results from the morning session:

Look at each actor: What are his/her tasks in this system? Task may be a better word than use case for people not familiar with the use-case modeling technique.
Look at each suggested use case: Do you understand the value the user will achieve with the use case? If the use case has a positive result, then the user will be more willing to do the use case.
Look at each suggested use case: Is the use case complete? Or is this just a small part of something bigger?

Questions to ask:

Check that every actor has at least one use case

Write Brief Description for each Use Case

Work with the use cases one by one, and create one easel chart for each use case. Draw an ellipse and write the name of the use case at the top of the chart. Take a pencil and ask the group to help you write a brief description of the use case. A brief description should be about 1 to 3 sentences. Sometimes it is useful to draw the actors connected to the use case. Try to leave about half the paper empty for the next step.

During this work, you will find out that there are some things that everybody thought were clear that are not actually clear at all. Read the Vision and Stakeholder Needs document and try to find if there are any requirements on this use case.

New use cases will appear. Some use cases will disappear. Put the use case papers on the walls. Try to organize them with one column per functional area. (Don't use the whiteboards for this –they are needed for the system view and actors and use cases.) If you can’t solve questions immediately, write them down on a self-stick note and place them at the appropriate use case. Use one color for questions.

When all use cases have an easel chart and a brief description, it is time for next mode. It is often wise to take some time discuss if this really all the use cases that are needed.

The model you have created so far may be documented in Rose or RequisitePro and generated into a Use-Case Model Survey report.

Step-by-Step Description of the Flow of Events for each Use Case

The way to start writing a use case is to structure the text first. There is no point in sitting alone and trying to structure the text without first obtaining input from the stakeholders.

Work with the use cases one by one. Write down the different actions in order. Don't try figure out how things will look in code structures, loops, for-while statements, etc. – just work with the basic flow of events, and don't worry about alternatives. Enumerate the steps 1, 2, 3, 4, … To help the group understand the required level of detail, you can say that you want 5 to10 steps in the basic flow.

Once you've agreed on the steps in the basic flow of events, walk through it and identify alternative steps. Enumerate the alternative flows A1, A2, A3, A4, …

During this discussion a lot of issues will be raised, many of which will not be solved until you get to Analysis & Design. Remember to write down all issues, together with any assumptions you need to make along the way. Some of the issues need to be resolved soon so that the Use-Case Author can detail the flow of events correctly, and some of them are things that you need to make sure are resolved before you start Analysis & Design.

What you have on each easel chart now should be sufficient for the use-case specifier to be able to detail the flow of events of the use case.

Capture Supplementary Requirements

During this session, there will be several statements about the system that you may not be able to readily capture in a use case. Typically, these statements have to do with general functionality, usability, reliability, performance, and supportability of the system. Keep a separate easel chart where you note these statements. They will form a basis for your Supplementary Requirements document.

Trace Requirements to Use Cases

Walk through the Stakeholder Needs document and verify that the use-case model covers it in the appropriate way. Discuss which user needs or requirements are traced to which use cases.

Take the Stakeholder Needs document and read the first requirement. Write its identity on one (or more if needed) self-stick note (use a second color to make it easy to distinguish requirements from issues). Put the note on the use cases that fulfill this requirement. Later on, you can enter these traceabilities in your RequisitePro repository.

There are always a number of requirement that can't be connected to any use case:

They can be specific requirements that have to be postponed to design – put these requirements on one paper (design requirements).
They can be general requirements that can't be connected to any use case - put them on the Supplementary Requirements chart.
They can be requirements that have been forgotten and require either new use cases or changes to the existing use cases.

Spend a few moments to review the structure of the room: Are there use cases with no requirements? Why? Is this use case not required? Or was this functionality forgotten by the person who wrote the requirement specification? (This is usually the case.) This situation has to be resolved. Is the customer aware that he needs this functionality? Is he willing to pay for it?

� Rational Software Corporation 1998

Rational Unified Process 5.1 (build 43)

Work guidelines: Use-Case Workshop