The use-case workshop is an organized brain-storming meeting. A wide range of knowledge needs to be represented:
Rational Unified Process
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 that you need are:
Two large white boards (one is sufficient but two is better)
Two colors of self-stick notes
White-board pens (multiple colors)
Walls on which to attach paper-preferably in a "war room" that you can use and leave undisturbed for two or three
Try to identify who or what will use the system. Start initially with actual people who will use the system; most
people have an easier time focusing on the concrete versus the abstract. As users are identified, try to identify the
role the user plays while interacting with the system - this is usually a good name for an Actor.
When identifying actors, be sure to write a short description for each actor; usually a few bullet-points capturing the
role the actor plays with respect to the system and the responsibilities of the actor will help later on when the time
comes to determine what the actor needs from the system.
When defining actors, do not forget about the other systems with which the system being designed interacts. The icon
for an actor is misleading here - it seems to imply 'person', but the concept of actor encompasses systems as well.
Focus first on finding the 'human' actors, though; most groups will do better when they focus on the familiar first,
then consider the more esoteric.
Don't worry about the structure of the Use-Case Model, or about relationships between actors; simply capture
the people or things which will use the system. Focus on identification, and be prepared to find a lot of actors. Don't
worry too much about filtering the list now; the identification of use
cases (see below) will do that.
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
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?
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 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. Note the User actor on the board and then proceed to the next actor.
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
Erase the cloud or icon from the whiteboard, and start to identify use
cases. Focus on concrete use cases - avoid discussion about include
and extend relations. 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
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:
Every actor should have at least one use case. If not, it may be because the actor is a duplicate (another actor
plays the same role) or because the actor is really not a direct user of the system. In these cases, if a
discussion of the merits of keeping the actor yields no strong reasons to keep the actor, the actor may be removed.
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. Refer to the requirements identified as key user
needs and features in the Vision 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 the 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 Rational Rose or Rational RequisitePro and generated into a Use-Case Model Survey
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 Requirements Specifier 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 Requirements Specifier to be able to detail the flow
of events of the use case.
During this session, there will be several Requirements on
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 Specifications.
Walk through the key Stakeholder Requests and each feature in the Vision document and verify that the use-case model covers them in the
appropriate way. Discuss which user needs or requirements are traced to which
Take the Vision document and read the first feature.
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 Requirements 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
They can be general requirements that can't be connected to any use case - put them on the list for the Supplementary Specifications.
They can be requirements that have been forgotten and require either new use cases or changes to the existing use
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?