learning, increased understanding, decisions, motivation, and teamwork. These products are specifically planned ahead of time.
During your workshop, participants use one model to test another, and in so doing uncover missing and erroneous requirements. Because each requirements model connects in some way to another, you can also use one model to elicit another. Participants can more easily see connections, and they quickly learn to iterate across multiple models in the workshop, which leads to more complete requirements.
The following are real examples of the work products created in facilitated workshops (Gottesdiener, 1999):
- In a half-day midpoint debrief (retrospective), a beleaguered project team created an action plan for correcting critical project problems, re-established how and when team communications will occur and redefined several key roles, including that of the project sponsor.
- In two hours, workshop participants generated 119 business events, classified them and then removed those not in scope during their requirements scoping workshop.
- In a use-case modeling workshop, business participants were able to test their use case model and structural business rules using 55 scenarios in less than 90 minutes.
- In three hours, a team validated a medium-complexity data model and made decisions about the scope of the data about which business performance metrics would be based.
- In a four hours, a project team defined the deliverables necessary for the upcoming design phase, who owned, reviewed and created each deliverable, what their quality criterion would be, and mapped them into dependencies along a timeline.
Workshop planners need time to define what to deliver, what level of detail the materials should contain, and how the intangibles will be achieved. A useful guideline is that you’ll need at least one day of planning time to facilitate one workshop day. This is not insubstantial, but the benefits can be vast.
Other Uses for Workshops
Elements of requirements workshops, such as process planning, product delivery, and process roles, can be applied in other settings. For one thing, you can use facilitated workshops to launch a project, in order to deliver elements documented in the project charter or vision document. In fact, you might usefully create the scope-level requirements during the chartering process. Other good uses of workshops: strategic planning, process improvement, and problem solving.
Types of Requirements Workshops
You can use workshops to elicit, specify, review, quality-check, and reach closure on user requirements deliverables. Figure 1 shows a sequence of three types of requirements workshops. (Note that the deliverables are examples; they are numerous deliverables you can use in requirements workshops).
Although each project is unique, this diagram gives you a basis for defining the deliverables of any of the workshop types. For example, you might use multiple half-day workshops to deliver high-level requirements.
These workshops are preceded by an agreed-upon charter document or vision document and possibly a charter workshop. Typically, in a charter workshop, you’d deliver goals, objectives, a communication plan, roles and responsibilities, and perhaps some of the same deliverables of a scope workshop such as events, a context diagram and stakeholder classes.
You successfully refine user requirements, moving from a high level of abstraction to more fully intricate and detailed requirements. In a scope workshop , you take a birds-eye view of what user requirements should be included. The deliverables from the scope workshop clarify the items that need to be elaborated upon in your high-level workshop , which are in turn specified in the detailed workshop . You may combine workshop levels if your scope is fairly well-contained.
In practice, workshop categories can overlap. As you move through the workshops, you prioritize your requirements. In one of my workshops,