Purpose
The purpose of the requirements workshop is to:
-
Make the project team meet the stakeholders of the project.
-
Gather a comprehensive "wish list" from stakeholders of the project.
-
Prioritize the collected requirements based on stakeholders attending the workshop
To conduct a requirements workshop, means to gather all stakeholders together for an intensive, focused period. A
System Analyst acts as facilitator of the meeting. Everyone attending should actively contribute, and the results of
the session should be made immediately available to the attendants.
The requirements workshop provides a framework for applying the other elicitation techniques, such as the following: Guideline: Brainstorming and Idea Reduction, Guideline: Storyboarding, Guideline: Role Playing, Guideline: Review Existing Requirements. These techniques can be used on their own
or combined. All can be combined with the use-case approach. For example, you can produce one or a few storyboards for
each use case you envision in the system. You can use role playing as a way of understanding how actors will use the
system and help you define the use cases.
A facilitator of a requirements workshop needs to be prepared for the following difficulties:
-
Stakeholders know what they want but may not be able to articulate it.
-
Stakeholders may not know what they want.
-
Stakeholders think they know what they want until you give them what they said they wanted.
-
Analysts think they understand user problems better than users.
-
Everybody believes everybody else is politically motivated.
The results of the requirements workshops are documented in one or several Stakeholder Requests artifacts. Provided you have good tool support,
it is often good to allow the stakeholders to enter this information. If you have chosen to discuss the system in terms
of actors and use
cases, you may also have an outline to a Use-Case Model.
The facilitator needs to "sell" the workshop to stakeholders that should attend, and to establish the group that will
participate in the workshop. The attendees should be given "warm-up" material to review before they arrive. The
facilitator is responsible for the logistics surrounding the workshop, such as sending out invitations, finding an
appropriate room with the equipment needed for the session, as well as distributing an agenda for the workshop.
The facilitator leads the session, which includes:
-
Giving everyone an opportunity to speak.
-
Keeping the session on track.
-
For Requirements Management purposes, gathering input for applicable Artifact: Requirements Attributes
-
Recording the findings.
-
Summarizing the session and working out conclusions.
After the requirements workshop, the facilitator (together with fellow Role: System Analysts) need to spend some time to synthesize the findings and condense the information into a presentable
format.
The table below lists a collection of problems and suggested solutions that could come in handy for the facilitator.
The solutions are referring to a set of "tickets" that may sound unnecessary to have, but in most cases turn out to be
very effective:
Problem
|
Solution
|
Hard to get restarted after breaks.
|
Anyone who is late gets a "Late From Break" ticket, use a kitchen timer to catch peoples attention, use
a charitable contribution box (say $1 for each ticket used).
|
Pointed criticism - petty biases, turf wars, politics and cheap shots.
|
"1 Free Cheap Shot" ticket, "That's a Great Idea!!" ticket.
|
Grandstanding, domineering positions, uneven input from participants.
|
Use a trained facilitator, limit speaking time to a "Five Minute Position Statement".
|
Energy low after lunch.
|
Light lunches, breaks, coffee, soda, candies, cookies, rearrange room, change temperature.
|
|