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
-
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 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.
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 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?
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 cases.
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 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:
-
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 report.
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 use cases.
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 requirements).
-
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 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?
|