Guideline: Requirements Workshop
This guideline explains how to plan and conduct a requirements gathering workshop.
Relationships
Main Description

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

Preparation for 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.

Before the Workshop

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

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.

Consolidate Results

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.

Tricks of the Trade

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.