CHAPTER 5

RUNNING A USE CASE/SCENARIO WORKSHOP

Ellen Gottesdiener

EBG Consulting Inc., Indiana, USA

APPLICABILITY

Many kinds of projects can use facilitated requirements workshops, although these sessions are used most often for business systems. They also work well for other applications where technical people are trying to implement the requirements of subject matter experts (SMEs). These applications include financial, accounting, logistical, human resources, and similar infrastructure applications. Additionally, products involving both hardware and software components such as lab automation systems, workflow, device management, manufacturing tracking and controlling, stock trading, gaming systems, and so on can benefit from this technique.

Workshops are not applicable in organizations that do not value strengthening the relationship and communication among business and technical people. Nor are they an advisable technique when the requirements can be wholly and correctly derived from technical staff or when management is unwilling to bear the expense of having subject matter experts gather in the same place at the same time for hours or days.

In organizations where certain individuals or groups direct the requirements toward a single, predetermined point of view, workshops likely will not be successful. The goal of workshops is true collaboration. They deliver justifiable decisions about requirements to meet end-user and customer goals, while at the same time balancing technical considerations.

Requirements workshops are less applicable in the following situations:

• The participants don't share a common goal.
• You don't have an experienced, neutral facilitator.
• Your facilitator is a key stakeholder in the outcome and thus has difficulty being neutral and focusing on the group process.
• Project or company politics hamper the players' ability to collaborate.
• Management has no intention of using or acknowledging the deliverables created in the workshop.

POSITION IN THE LIFE CYCLE

Requirements workshops employing use cases and scenarios are most applicable in the early phases of the life cycle. They excel as a technique for requirements discovery and validation and are a useful technique during design. In sum, workshops excel when life-cycle products are best derived by human collaboration and invention.

KEY FEATURES

The key features of workshops are customer collaboration, neutral process leadership, the use of multiple requirements models, and a process of iterating through the requirements process in a short period of time.

Customer Collaboration

Customer collaboration is at the heart of the workshop process. Direct end users (or appropriate surrogates) and business experts are essential participants. Workshops go beyond classic customer meetings or interviews, which focus on one-way information exchange. In workshops, all the participants—customer and technical—share a common goal and agree to join together to create the work products (such as use cases and scenarios) in the pursuit of that shared goal. Workshops rely on customer and technical people interacting, challenging, questioning, clarifying, specifying, prioritizing, and finally reaching closure on the requirements. Workshop participants are productive because collectively they have the right mix of skills and knowledge to create the work products. They act interdependently; relying on one another's knowledge, experience, skills, and perspectives.

To ensure that the workshop includes the right participants, you need both technical and business sponsorship. Management assists by kicking off or being part of the workshop closing activities (in the form of a participants' “show-and-tell” for the sponsor). In some cases, managers may even be full-fledged participants.

In a workshop, a neutral facilitator and a recorder act as process leads to ensure that everyone participates and that all points of view are understood and resolved. To maintain energy, creativity, and motivation, the facilitator uses interactive as well as parallel group activities. For example, subgroups may be formed to work on portions of a single deliverable, such as scenarios for a set of use cases. Or subgroups might be assigned to work on related work products. One group might work on use cases while another drafts prototype screens and yet another creates a high-level domain model. The subgroups then reconvene in a plenary (whole group) activity to share and critique their work.

Multiple Requirements Models

Several types of requirements models can be used during a workshop, depending on the problem domain. Many problem domains benefit from using use cases and scenarios as the hub for related requirements representations, including a list of actors, a glossary, domain models, business rules, and state charts. Of course, the use cases and scenarios elicited in workshops evolve through the life cycle into test cases.

The Iteration Process

In agile development projects, workshops are conducted early in each iteration to quickly identify high-priority use cases (or stories) before testing and coding begin. Depending on customer availability, one or more workshop events are held over a short period. Each workshop is well planned and builds on the prior session.

Between sessions, participants often work on refining the requirements by creating additional scenarios, atomic-level business rules associated with use cases, or other requirements deliverables such as nonfunctional requirements or documentation (particularly in regulated or high-process project environments). In other cases, prototypes are built directly from the workshop deliverables.

STRENGTHS

Direct, face-to-face collaboration in a structured, productive environment builds trust, enhances communication, and ensures quality requirements. This sets the tone for productive relationships among project stakeholders, customer and technical alike. The workshop process can be adapted to a wide variety of development styles and cultures, from agile development to highly process-oriented cultures.

Combining effective collaboration techniques with scenarios and use cases enables the requirements to “come to life” quickly. All the key stakeholders are together at the same time and place, so real needs (versus wants or “nice to haves”) surface quickly. The stakeholders are led to assign priorities based on business value and to reach closure following an agreed-upon decision rule and decision-making process. Compared with traditional approaches, such as interviews, observation, or multiple rounds of customer reviews of lengthy, tedious requirements documentation, these workshop techniques create a leaner, more agile requirements process.

Iterating through multiple models using subject matter experts accelerates the requirements process. Participates verify each other's work directly in the session, often using mini-walkthroughs and reviews. This approach reduces the risk of requirements errors and increases not only throughput during the workshop but also project community understanding of the requirements.

Decisions are made in real time using an agreed-upon decision-making process, reducing typical delays in reaching closure. In requirements workshops, project stakeholders learn from one another, enriching their experience and leading to more constructive team relationships.

WEAKNESSES

Facilitated use case and scenario workshops require involvement of project subject matter experts for blocks of time ranging from three hours to three days, an investment that may be problematic for some organizations. Additionally, some cultures eschew what they see as “too much” end-user or customer involvement. The need to agree on a process for making requirements decisions during the workshop is threatening to some cultures, in which either the IT group or the business group wishes to control decisions without exposure in a group setting.

If an organization typically holds a great many unproductive meetings, participants may overbook themselves, expecting to come and go during the workshop or even work on other activities. Because a requirements workshop is an intense, ongoing elicitation process, inattention or inconsistent attendance will hamper or prevent trust from being built in the workshop session.

Workshops rely on one or more skilled and neutral facilitators to guide the process, not only during the session but also beforehand during planning. Some organizations do not train people to develop these skills nor reward skilled facilitation, making it difficult to find in-house facilitators. Other groups are resistant to getting outside help by hiring an external facilitator, particularly when the political issues are painful or shameful. In other organizations, there is an over-reliance on using project members who have difficulty staying neutral rather than use facilitators from outside the project or organization.

TECHNIQUE

A collaborative (or facilitated) requirements workshop is a structured event in which a carefully selected group of stakeholders and content experts works together to create, correct, and document a predefined set of deliverables, or work products. (This technique is similar to an approach called JAD™, which stands for Joint Application Design or Joint Application Development.) The participants agree ahead of time on what the deliverables will be, and they often produce some of them before the workshop. In use case or scenario workshops, business and technology people assume the roles of various users of the system. Guided by use cases, scenarios, or both, the workshop participants act out examples of the system in use.

Workshops reflect the simple fact that the process of building software and defining its requirements depends on the collaborative brainpower of project stakeholders. Workshops provide a means for harvesting the collective knowledge, experience, and points of view of an often diverse set of project stakeholders.

Workshops rely on the following techniques:

• You follow a framework to plan and run a successful workshop. I refer to this structure as “the six P's”: purpose, participants, principles, products, place, and process.
• You have the right people in the room at the same time.
• Before the workshop, you create a starting point for project requirements. For example, you write a project vision or charter with a statement of scope, and you generate a draft list of use cases, scenarios, and actors, a context diagram, or some combination of these.
• You design a workshop process and write an agenda that consists of a series of logically related activities to create the requirements. In each activity, participants will use existing or newly created models or portions of models to generate the overall deliverables.
• Before the workshop, you define prioritization schemes and a decision rule for workshop decisions (including assigning priorities to the use cases or scenarios). You use this agreed-upon decision-making process throughout the workshop.
• You obtain senior stakeholder sponsorship of both the workshop and the decision-making processes.
• You elicit the scenarios or use cases in logical groups, progressing from small groups into multiple concurrent groups. In this way, you maximize the session's throughput.
• You use elicitation techniques such as role-playing use cases, modeling use case steps on a wall, or completing a scenario template.
• You integrate collaboration patterns, which are pre-tested, step-by-step instructions for groups who are working together on complex tasks.
• You clarify how the project team can declare that requirements are sufficiently complete to move onto prototyping, test, design, and build activities; this doneness test lets you plan the workshop deliverables and test for closure.
• You test the generated requirements for correctness and completeness by using mini-walkthroughs and reviews.
• You design a strategy to navigate through the requirements during the workshop.
• You iterate through the requirements using multiple, intertwined models.

A Word about Scenarios

Scenarios are used in many requirements workshops even when use cases aren't the best way to express requirements. For example, some business problem domains—such as reporting, rule-based decision-making, and data analysis—are less behavioral, so use cases aren't an appropriate way to represent the requirements.

Scenarios are always helpful for uncovering or testing requirements in the workshop. For example, in a series of workshops for a disability claim adjudication application (a rule-based problem domain), the participants used scenarios to test the correctness and completeness of business rules they had generated during the workshop.

Workshop Framework

Planning is essential. The planning framework—purpose, participants, principles, products, place, and process—helps the facilitator and planning team to design and run a successful workshop. They answer the questions why, who, how, what, where, and when, as shown in Table 5.1.

Role Playing

One sample technique that is useful for modeling use cases in workshops is to role-play them. In general, you can specify a use case using a sequential, stepwise description or using a left-side, right-side conversational approach originated by Rebecca Wirfs-Brock (Wirfs-Brock 1993). Using the latter approach, the “left side” represents what the actor does, and the “right side” represents what the system does in response. The use case describes the interaction between the two.

When workshop participants are creating this format for use cases, the facilitator can use a role-playing approach in which multiple people play various roles. A subject matter expert will likely be assigned the role of one actor. Another participant will act out the system role. Using scenarios invented in a prior workshop activity or as part of the workshop pre-work, the two people act out the scenarios. They may toss a Koosh ball (a soft or string ball) or some other item back and forth as the scenario proceeds. During the role-play, other support roles are necessary. The facilitator monitors the interaction while the recorder captures the conversation on a laptop, often projected on the wall for all to see so that the steps are captured correctly. This way of interacting in a workshop is not only productive but also fun.

Other roles are assigned to project team members responsible for specifying related requirements models such as the data or class model, business rules, and prototypes. For example, a data analyst's role is to listen to the interaction, record notes, and ask questions surrounding data elements. This same person may also be responsible for writing the business rules that are enforced in the use cases. Another person, often a developer, may begin to make sketches or dialogs to help envision the prototype to be built after the workshop.

Wall Modeling Use Cases: Storyboarding

Another way to elicit use cases using the sequential use case format is to capture them on the wall using a storyboarding approach. A storyboard is a series of continuing panels, sketches, or scenes depicting a plot or sequence of actions. In business, storyboards are popular for solving problems and creating collaborative plans. In a storyboard, the group uses text or diagrams to build a deliverable or set of deliverables by successively using individual, subgroup, and whole group activities. I like to call this technique the Wall of Wonder, an approach based on a storyboarding approach taught by the Institute of Cultural Affairs (Spencer 1989).

To model use cases on a wall as a storyboard, you might start with a well-named use case and a scenario. The facilitator asks participants a focus question such as, “What task, actions, or steps are needed to <goal or use case name, such as ‘sell ticket package’>? Please write down one per card or sticky note.” Next, participants take their cards to the wall and arrange them in sequence. Eventually, subgroups are formed in which team members work on different use cases at the same time.

For each set of steps arrayed on the wall, the facilitator asks questions to test the appropriateness of the sequence and may also elicit business rules and data elements. These are captured in a separate location, such as another wall or flipcharts nearby. The group then focuses on additional scenarios, adjusting the steps on the wall as needed.

Scenario Walkthroughs: Testing Use Cases

Scenarios are one of the most productive ways to test use cases. In workshops, one group might generate a set of scenarios, perhaps using a template as shown in Table 5.2. The values generated for the scenarios are used to create test cases and scripts, adding to the benefit of capturing the information.

Participants work in subgroups to generate details to complete a template for a set of use cases. If other models are employed, the template may be used for capturing business questions or information domains. To accelerate documentation delivery and reduce variability across subgroups, each subgroup might be supplied with a laptop in which the recorder enters the scenario details.

After scenarios have been generated, the subgroups test each other's requirements. For example, one subgroup might use scenarios to walk through use cases that another subgroup generated in a prior workshop activity (using a role-playing or storyboard technique) or even in a prior use case workshop. They might use a template, such as the one shown in Table 5.3, to find errors in each other's use cases. The entire group reviews the walkthrough findings, and then each subgroup returns to its set of use cases to correct or clarify the defects detected.

TABLE 5.2 Scenario template

Collaboration Patterns

As mentioned earlier, collaboration patterns are high-level blueprints for the behavior adopted by successful groups to accomplish results together. When groups collaborate in a facilitated workshop setting, the facilitator often establishes the collaboration patterns. With experience, the group learns to incorporate these patterns, reducing the need for the third-party facilitator.

For example, “Divide, Conquer, Correct, Collect” is one pattern that groups can use to elicit and test a requirements deliverable. Suppose the workshop wants to deliver a complete set of scenarios for a software product that has four or five feature sets. In the first step—Divide—the team is separated into subgroups, and each subgroup is given responsibility for generating scenarios for one of the feature sets. (The use cases will already have been written, either before the workshop or in an earlier activity.) In the Conquer step, the subgroups focus on creating detailed scenarios for each use case in their assigned feature set. They might use a template to ensure that they capture the desired level of detail. For example, the template might call for the scenario description, sample data, an assigned priority, and a specified degree of complexity.

TABLE 5.3 Scenario walkthrough template

In the Correct part of the collaboration pattern, the group tests the completeness of the scenarios in each feature set by using a different requirements model, a quality assurance (QA) checklist, or another requirements discovery tool. Examples of these models include a model called The Voice of the Customer (Pardee 1996) in which the participants identify so-called spokens, unspokens, expectors, and delighters. In this way, the group uncovers any missing scenarios.

In the Collect step, the group collects all the scenarios, maps them to use cases, and perhaps trims the use case list.

This final list of use cases—revised after scenarios have been generated for them—can then be tested. One example of a testing mechanism is to create a use case map or workflow diagram (a visual diagram showing the relationships among all the use cases) and then compare it to a business flow diagram.

Doneness Testing

Doneness tests are used to ensure that the requirements—use cases, scenarios, and related requirements appropriate for the domain—are captured to the predetermined degree of precision and correctness. Walkthroughs are one kind of doneness test. Another is to use quality assurance questions. Here are some examples:

• Do all the use cases fall within the scope we have defined for this project?
• Does each actor initiate at least one use case?
• Is each in-scope use case necessary to fulfill the project's goals and objectives?
• Does each scenario have one or more use cases that define it?
• Have we defined the business rules necessary to handle each scenario and associated them with it (or with the scenario's associated use case)?

Using a checklist of QA questions has additional benefits. The very process of creating and agreeing on the checklist helps business and technical people to clarify and define expectations for each deliverable clearly and precisely. Like walkthroughs, checklists also push participants to create high-quality requirements in the first place, or to clarify what constitutes “good enough” requirements.

Checklists can be used in the ‘Correct’ phase of “Divide, Conquer, Correct, Collect.” In that case, participants compare each requirement to the checklist questions and discuss and correct any discrepancies—right away if feasible.

Iterating Through the Requirements

In a workshop, the participants work on one model, such as use cases, and then shift to scenarios, the domain model, and business rules. Then they test the doneness of the requirements models. You might do all this in one workshop over one to three days, or you might spread these tasks over one or more weeks.

In the example shown in Figure 5.1, a set of four workshops is used to iteratively produce use cases, scenarios, business rules, prototypes, some nonfunctional requirements, prioritized use case packages, and a release strategy. These sessions might be held over a week or two and might take three to six hours each, depending on the scope of the project.

Often, participants work on requirements in preparation for the next workshop. For example, a developer or data analyst would likely create a draft domain model in conjunction with the prototype to be used as input to workshop 4.

In one series of workshops, each afternoon the developer drafted prototype screens to show participants during the next morning's workshop. Meanwhile, that same afternoon, the data analyst also added more details to the domain model, and the subject matter experts completed scenario templates for the use cases to be worked on in the next workshop gathering. They continued this process over the course of five days to complete the majority of their requirements during the week—half in the workshop setting, and half alone at their desks.

FIGURE 5.1 Workshop iterations

WORKED EXAMPLE

eTikets is an 18-month-old seller of online tickets. With decent profit margins on tickets, its niche is selling ticket packages for large parties of well-to-do people attending sporting events, auto races, theater shows, and concerts. The eTikets strategy includes moving into the European market, so it recently acquired a UK-based start-up in the same market space.

“We need to clarify and finalize the requirements for the first release of the next generation of the eTikets application,” said Leslie, the project leader for GobSmack, the code name for the project. “Let's do a requirements workshop to gather and prioritize our use cases. I think it will save time and help us collaborate on the release.”

The project team members faced several obstacles to solidifying their requirements and building their next release. They were adding new functionality and integrating US and European staff and infrastructure. They had a history of outsourcing requirements gathering, with resulting poorly defined requirements and disastrous outcomes in time and money. Key stakeholders were already disagreeing on how to approach the next release and what features should be included and why.

Leslie knew that defining and documenting crisp requirements, along with creating working prototypes, would alleviate many of the political, logistical, and technical issues the team faced with the GobSmack release. She was determined to get a good set of working requirements and somehow get everyone to collaborate effectively early in the project. Gaining the support of Jason, the VP of Product Development, she proceeded to make arrangements to conduct a series of requirements workshops.

Leslie decided to contract with Eli, an experienced requirements workshop facilitator. Using an outside facilitator was necessary because the passions and political issues around the release made it a problem for eTikets' own staff to be neutral. Jody, the business analyst, had a keen interest in facilitating in the future, so Leslie arranged for Eli to simultaneously mentor Jody in workshop design and facilitation.

Workshop Pre-Work

With Leslie as workshop sponsor and Justin as project sponsor, Eli began by asking Leslie to form a planning team of at least one technical person and one business person. Leslie's counterpart, Marc, a product marketing director reporting to Justin, agreed to help plan the requirements session. Because Marc had worked on the first release and had been charged with the market analysis for the GobSmack release, he would also be a participant in the workshop.

As facilitator, Eli knew he needed to get multiple perspectives on the needs of the project's stakeholders. He interviewed a number of the management stakeholders and a half-dozen members of the project community, including the lead architect as well as the UK-based product manager, a lead designer, the testing and QA lead, and three of the developers assigned to GobSmack. Eli also reviewed existing requirements and project documentation, run through a demo of the product, and reviewed the company strategy.

The workshop participants agreed to gather over four part-day sessions to allow them to do some requirements and prototyping work in between. Figure 5.2 shows the overall strategy for each day.

To maximize the use of time, the planning team asked Justin to document a product vision for GobSmack and write a two-page business case with goals, objectives, a next-generation Web site feature list, and the project sponsors. With these materials in hand, the planning team then drafted a few scope-level requirements to help jump-start the workshop: a categorized list of stakeholders, an actor table and a glossary.

The planners created a starting list of stakeholders: package sellers, customer service reps, ticket buyers, ticket brokers, shippers, credit card companies, internal travel agents, search engines, and so on. Their list of actors, drawn from the stakeholders, included customer service reps, an inventory manager, a marketing manager, ticket buyers, and ticket brokers. They used this list to draft an actor table that included a brief description of each actor. Their draft glossary included essential business terms such as ticket, inventory, event, package, global inventory, virtual order, created order, and a few other terms they were stumbling over and knew they needed agreement on.

Now the participants were ready for the first workshop.

FIGURE 5.2 eTikets workshops strategy

Workshop 1: Monday

Monday's first workshop was kicked off by Justin and several other key stakeholders. They took some questions and then left the room. Next, Eli reviewed the workshop process, including the agenda and decision-making rules.

The team members then reviewed the pre-work material, beginning with the list of stakeholders and actors. Their recorder, a QA specialist, displayed the documentation on the wall using a laptop and data projector. After some energetic discussion about the actors, numerous changes were made directly in the document. Unfortunately, some of the participants wanted to begin debating the importance of some features related to certain actors, but it was too soon for that kind of discussion. To head this off, Eli pointed out that the goal of these early sessions was to take a “mile wide, inch deep” view of release.

Eli next asked the 12 participants to form subgroups of three people each to review and revise the names and descriptions of the actors they were most familiar with. Eli was careful to give them a time limit of 25 minutes for this work to ensure that they moved along and didn't spend too much time debating small issues. After all the groups had completed work on their assigned actors, they reconvened as a whole group and shared the results.

The whole group reached closure on the relevant actors in GobSmack and then moved on to the glossary. Mutual understanding of some terms required structured discussion, largely because of the differences between the US and UK products and market approaches. For example, the terms package and order were revised and broken into several new terms and definitions. Again, the recorder updated these on the wall for everyone to see.

The participants continued by meeting in their initial subgroups to generate a list of well-named use cases. To help them, Eli handed out a “cheat sheet” for naming use cases. Each use case was written on an oval-shaped sticky note. There were 35 in all. After each subgroup exhausted its ideas, the participants placed all the use cases on a wall for viewing.

Now everyone discussed the use cases to uncover overlaps, duplicates, and out-of-scope use cases. For example, use cases such as “sell package,” “monitor events,” “monitor market value,” “transmit inventory to global inventory,” and others were agreed upon as being in scope. This winnowing process yielded a net list of 22 use cases.

Next, the same subgroups wrote brief use case descriptions based on the set of actors. They also used actor sticky notes to create actor-use case diagrams on a wall. One person in each subgroup was assigned to be the recorder for the group, and another was the timekeeper. Each recorder used a laptop to enter the use case descriptions into a simple use case template so that the documentation would be readily available. Using a portable printer in the room, the subgroups printed copies of the use case descriptions and made sure to display use case ovals on the wall with actor icons next to them.

After the whole group reviewed and revised the entire set of use case descriptions and diagrams, the participants then worked on happy scenarios (ones in which no errors, exceptions, or variations occur). Again they worked in subgroups, using laptops to enter scenario details into a scenario template.

In addition to the subgroup roles of recorder and timekeeper, Eli asked the third person to act as the “quality keeper.” This person's role was to ensure that all the elements in the scenario template were documented.

The participants had lunch together and took care of phone calls. After a brief break, they resumed their work.

The next task for the subgroups was to write business rules associated with the scenarios they had drafted before lunch. They wrote one business rule per index card. For this task, they did not use a template but instead used free-form business rules text. After they had worked on the business rule cards for 35 minutes, the cards were placed on another wall for everyone to see, discuss, and clarify.

The team members discovered some patterns among the business rules. Eli moved the cards into groups and labeled each group. The group names included “reservations,” “order shipment,” “seat assignment,” “discounting tickets or packages,” and “ticket liquidation.”

Some of the rules, such as rules concerning discounting, were controversial. As per the agreed-upon decision rule and decision-making process (Gottesdiener 2001c) regarding eTikets business rules, these controversies would need to be resolved in consultation with the project sponsors. Each disputed business rule was placed as an item on the “Parking Lot” poster, where the team put things that could not be resolved (or did not need to be resolved) immediately in the workshop.

To conclude their first workshop, the participants reviewed the Parking Lot items and discovered that some of the issues were no longer of concern, having been addressed during the session. Open issues were assigned to specific participants to resolve for the next day.

The workshop ended in the early afternoon with a workshop retrospective. In this structured analysis of their work products as well as the process, the participants decided that they wanted to do the following: continue with subgroups as much as possible the next day and make speakers get to the point more quickly by flashing red index cards when they felt they were off-track. (Eli had suggested this in the beginning of the workshop, but only a few of them had used it.) They also agreed to continue with frequent short breaks and to refer to and revise their glossary during the workshop so that they would stay in sync on new or revised terms.

Several participants took on assignments for the next day. Justin's task was to research some of the controversial business rules, and Tina, a developer and data analyst needed to revise the domain model based on the new understanding of terms. Leslie was to review the list of use cases that were out of scope, along with certain troublesome business rules, with the project sponsors to get their concurrence (and to ask them to return in the morning to share their decisions). The rest of the group needed to generate additional scenarios for some of the use cases that had only a few scenarios defined. All in all, the group members agreed that it had been a productive first workshop.

Workshop 2: Tuesday

Tuesday's workshop was aimed at ensuring that the group had a complete set of use cases and that each use case had enough detail that the developers would be able to build draft prototypes. The plan was to have them create a subset of the most important and riskiest scenarios. The other goal for Tuesday was to resolve business rule issues.

The workshop began with a visit from the sponsors to explain their decisions on the business rules regarding discounting, reservations, and shipment orders. Then the participants, led by Eli, used a Voice of the Customer activity to rethink the customer needs for the GobSmack release. This activity yielded four new use cases, including “prepare inventory info for accounting” and “set prices.”

The team formed four new subgroups, assigned one of these new use cases to each group, and took 15 minutes to draft use case descriptions. For this, they used the use case document on the laptop. Then they created the associated scenarios (using the template on the laptop) and business rules (one per card). Creating a simple state chart of the domains “ticket” and “package” proved most useful in generating new business rules and finding domain values that Tina needed to add to the domain model.

Next, the workshop participants generated a list of objective criteria for defining risk as well as customer priorities for the first 30-day iteration of the GobSmack release. Applying these criteria to assign priorities was surprisingly simple and uncontroversial. By creating their own criteria, the group was able to reach closure on the four most important use cases and related happy case scenarios.

This part of the workshop took only three hours, leaving them time during the rest of the day to do their post-workshop assignments. The developers set to work on a first-cut prototype of the prioritized use cases and scenarios. Marc updated the domain model, and the rest of the group worked on unhappy case scenarios (also known as negative scenarios) for the use cases.

Workshop 3: Wednesday

On Wednesday, workshop 3 began with a prototype walkthrough using the happy scenarios the participants had generated earlier. As the participants walked through the prototype, discussions broke out about the look and feel of the user interface. Eli knew that project members tended to have religious issues about the system's look and feel—issues that would be difficult to resolve and, in any case, weren't relevant at this point. So he interrupted the discussion, asking whether the points being made were related to requirements. With this reminder, the group regained its focus: using the prototype to verify the requirements. They discovered some subtle gaps in their business rules, along with additional data values related to differences between the UK and US implementations of the scenarios.

Now it was time to review the unhappy scenarios. As a result of this review, the team added more unhappy scenarios (mostly business rule violations) and drafted business rules for handling them. The group also added one- or two-sentence use case extensions to describe how to handle each unhappy scenario. Again, they reviewed the scenarios and used the criteria developed earlier to add six more high-priority unhappy scenarios to the prototype.

In post-work on Wednesday afternoon, the participants revised the prototype based on the day's work and revised the domain model. That evening, they enjoyed a nice dinner, relaxing and enjoying each other's company. By now, they had their own “in” jokes and were teasing each other, showing genuine appreciation of their various personalities and backgrounds.

Workshop 4: Thursday

Thursday started with another prototype review and walkthrough of the additional unhappy scenarios. Several more business rules were clarified.

Now it was time to step back and gain some perspective on where the project stood. Guided by Eli, the participants modeled the entire set of use cases (not just the first 30-day cycle, the topic of their prototype) as a workflow. Using the last available wall space, they arranged each use case post in predecessor/successor order.

When they finished, they had five sets of use cases grouped together. They tested the correctness and completeness of the order using some of their scenarios and then tweaked the flow. They then grouped the use cases into packages. Using arrows, they drew dependencies between the packages. Next, they prioritized the packages and arrived at a recommended release strategy, and this four-hour session drew to a close.

After lunch, the senior sponsors rejoined the session for the show-and-tell. They were impressed by the volume and quality of the work. They asked how long it would have taken if the team had not used a workshop approach, and the participants laughed. “Months!” said one. “Even if it took us weeks, we never would have really agreed like we were able to do here,” said another.

After the sponsors left the room, the team members reviewed and cleaned up their Parking Lot list. Then they conducted their final workshop retrospective.

COMPARISONS

Collaborative workshops are a flexible approach for discovering requirements. In addition to use cases and scenarios, these workshops can employ a variety of tools, including requirements walkthroughs, prototypes, contextual design, unhappy scenarios, and misuse cases. They are a natural fit with the low-fidelity and storyboarding techniques described by Suzanne Robertson in this volume, Chapter 3 for defining events, stakeholders, scenarios, use cases and a context diagram. Likewise, they can be adapted to elicit and verify work models and storyboards produced in several phases in Contextual Design (see Karen Holtzblatt, this volume, Chapter 10). The workshop-based approach described as scenario-based user needs analysis (see Joy Van Helvert and Chris Fowler, this volume, Chapter 4) while more prescriptive is similar to the framework and techniques described in this chapter.

Requirements workshops are perhaps the original agile requirements development approach. They are adopted by agile projects as an efficient means of capturing lightweight requirements, such as stories (see Kent Beck and David West, this volume, Chapter 13), or any requirements representations, such as use cases and scenarios, that strive toward minimal requirements documentation and reduced formalism in customer sign-off.

Walkthroughs of use case text (see Chapter 9 of this volume, Systematic Scenario Walkthroughs, by Neil Maiden) or a prototype are especially popular. To check for requirements errors or omissions, scenarios or a QA checklist (or both) can be used as the driving tool. A workshop is a good place for constructing low-fidelity prototypes (whiteboard sketches, flipcharts, or color posts), which in turn can be used to build high-fidelity prototypes outside the workshop. Then the high-fidelity prototypes can be used in a subsequent requirements workshop to verify and validate the requirements. In some cases when the technical staff is unfamiliar with the domain, they are encouraged to observe users interacting with the current product, if possible. This is akin to observations, a central component of the contextual design approach to requirements and design.

Requirements workshops also use unhappy scenarios as a matter of course. They are extremely useful in uncovering business rules, writing extensions to use cases, and planning releases or iterations.

Generating misuse cases, or the negative form of use cases in which the actor has some hostile or harmful intent (as Ian Alexander explains in this volume, Chapter 7), has also proven useful in requirements workshops. Some requirements workshops focus on authentication, authorization, and administration use cases, which are useful for helping the team to thoroughly understand the requirements. If you're specifying nonfunctional requirements, it's a good idea to create misuse cases, doing most of that work outside the workshop setting.

Requirements workshops must be tailored to deliver the requirements that are appropriate to the project, application, and culture. If your aim is to write lightweight requirements, such as simple use cases, business rules, or a domain model, workshops are an effective way to gather the requirements, prioritize them, and reach closure quickly and with customers entirely engaged.

A workshop approach can be adapted to result in well-run and efficient story-elicitation sessions (see Kent Beck and David West, this volume, Chapter 13) when more than two people are needed. This may be the case in projects whose scope is large or whose requirements are complex.

KEYWORDS

Facilitated Workshop

Collaborative Workshop

Requirements Workshop

Customer Collaboration

JAD

Joint Requirements Workshop

Use Case Workshop

Happy Case Scenario

Unhappy Case Scenario

Collaboration Pattern

Use Case Extension

Misuse Case

Workshop Retrospective

REFERENCES

Bens, I., Facilitating with Ease: A Step-by-Step Guidebook with Customizable Worksheets on CD-ROM, Jossey-Bass, 2000.

Doyle, M. and Strauss, D., How to Make Meetings Work, Berkeley Books, 1976.

Gause, D.C. and Weinberg, G.M., Exploring Requirements: Quality Before Design, Dorset House, 1989.

Gottesdiener, E., Specifying Requirements with a Wall of Wonder, The Rational Edge, November 2001a, http://www.therationaledge.com/content/nov_01/t_wallOfWonder_eg.html

Gottesdiener, E., Collaborate for quality: using collaborative workshops to determine requirements, Software Testing and Quality Engineering, 3(2), 51–59, 2001b.

Gottesdiener, E., Decide how to decide: a collaboration pattern, Software Development, 9(1), 65–70, 2001c.

Gottesdiener, E., Requirements by Collaboration: Workshops for Defining Needs, Addison-Wesley, 2002.

Gottesdiener, E., Requirements by collaboration: getting it right the first time, IEEE Software, 20(2), 52–55, 2003.

Kaner, S., with Lind, L., Toldi, C., Fisk, S., and Berger, D., Facilitator's Guide to Participatory Decision-Making, New Society Publishers, 1996.

Pardee, W.J., To Satisfy & Delight Your Customer: How to Manage for Customer Value, Dorset House, 1996.

Spencer, L.J., Winning Through Participation: Meeting the Challenge of Corporate Change with the Technology of Participation, Kendell/Hunt Publishing Company, 1989.

Wirfs-Brock, R., Designing, Scenarios: making the case for a use case framework, The Smalltalk Report, 3(3), 7–10, 1993.

Wood, J. and Silver, D., Joint Application Development, 2^nd ed., John Wiley & Sons, 1995.

RECOMMENDED READING

Ingrid Bens (2000) is a facilitator's guide loaded with generic techniques, tips, and tools. Although they are not described in a software setting, these tools can be adapted to chartering and requirements workshops.

Michael Doyle and David Strauss (1976) describe the basic elements of successful meetings in several chapters on how to be a good facilitator, recorder, and group member.

Don Gause and Jerry Weinberg (1989) provide a fun and straightforward look at the human side of requirements, with several pithy chapters devoted to workshop-like meetings.

Ellen Gottesdiener (2001) describes blow-by-blow examples in these three articles. One article (The Rational Edge) explains in detail how to use the room's walls in workshops and how to use focus questions to deliver use cases and actors. Another provides details on how to reach closure in workshops (Software Development). The other (STQE) focuses on how to integrate walkthroughs, reviews, and role-playing into requirements workshops.

Ellen Gottesdiener (2002) is a “how to” requirements workshop handbook useful to workshop sponsors, facilitators, and participants.

Ellen Gottesdiener (2003) outlines the value of requirements workshops, highlighting the roles played by various stakeholders.

Sam Kaner et al. (1996) provides practical, high-level guidance to new and experienced facilitators. The book includes a framework for participatory decision-making.

Jane Wood and Denise Silver (1995) update their classic 1989 on JAD, describing the phases and related participatory approaches. They also give an overview of tools and techniques as well as group dynamics.