Purpose
  • To make the project team meet the stakeholders of the project.
  • To gather a comprehensive "wish list" from stakeholders of the project.
  • To prioritize the collected requirements based on stakeholders attending the workshop
Guidelines: 

Topics

Preparation for the Workshop To top of page

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 brainstorming, storyboarding, role playing, review of 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.

Before the Workshop To top of page

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.

Conduct the Session To top of page

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 Requirements Attributes
  • Recording the findings.
  • Summarizing the session and working out conclusions.
See: Requirements Attributes.

Consolidate Results To top of page

After the requirements workshop, the facilitator (together with fellow system analysts) need to spend some time to synthesize the findings and condense the information into a presentable format.

Tricks of the Trade To top of page

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. 



Rational Unified Process   2003.06.13