Portions of this article are excerpted from chapters of the book titled "Requirements by Collaboration: Workshops for Defining User Needs" by Ellen Gottesdiener, copyright 2002, Pearson Education, Inc. See copyright info at end of article.

In part 1 of this article, I discussed the use of workshops to elicit and verify business rules and other requirements. In this concluding segment, I present a framework for the planning and design of a well-run workshop. I also discuss the critical success considerations for one element of the framework, the workshop products.

Mind Your Six P's

Everyone knows the six great focus questions:  who, what, when, where, why, and how.  Rudyard Kipling's poem "The Elephant's Child" refers to these questions as the "six honest serving men."  John Zachman [zach87] uses them as the "columns" of his systems architecture framework.  Journalists use them as guidance for writing a story.

I use these six elements as the framework for a successful workshop and call them the "six P's":  purpose, participants, principles, products, place, and process, as shown in Figure 2.

Figure 2. Requirements Workshop Framework

Purpose

*/ ?>

The statement of the workshop's purpose outlines the reason and justification for the workshop.  It explains why you're conducting the workshop and serves as a frame of reference.

It may seem obvious, but it's important to remember that a workshop delivers work products that are needed by the project.  Because the workshop's context is the project, the workshop's purpose is linked to the project's purpose, which describes the business reason for undertaking the project.  The statement of the project's purpose usually references the current business situation, the desired situation, the obstacles to achieving the desired situation, and the changes that are desired.  Similarly, the workshop's purpose describes the business reason for gathering the players together.  The link must be evident to all stakeholders.  It's hard to overestimate the benefits of well-defined purposes for projects and workshops.

Participants

*/ ?>

The people involved in a facilitated workshop are the workshop sponsor, the participants, a facilitator, a scribe, observers, and on-call subject matter experts.  Another term often used to describe the various people involved in collaborative project is role.  When you explicitly define the individuals who are to play each role, the group can better plan the session, the participants are better prepared, and the event is more likely to succeed.

Not all of these roles are necessarily present during a given workshop.  For example, the workshop sponsor may be present only at the beginning and end of the session.

Principles

*/ ?>

Also called ground rules, principles are guidelines for participation, or the codes of conduct that participants agree to follow.  Groups need these precepts to maintain socially acceptable behavior and to promote the goals of the workshop:  delivering the appropriate work products in the allotted time.  The principles serve as a process guide for the facilitator as well as the participants.

The facilitator works with the workshop sponsor and group to establish principles, which must be clear and acceptable to all participants.  The facilitator and participants are responsible for monitoring the adherence to the principles.

Product

*/ ?>

The work products, or deliverables, of a workshop take the form of text or diagrams.  For user requirements workshops, they are lists of business policies, use case text, use case diagrams, atomic business rules, and the like.  These workshop deliverables, in turn, serve as input to project activities, including design, development, or additional workshops, such as definition or design workshops.

To accelerate the delivery of workshop products, the participants need certain input products such as draft models, text, and documentation.  These materials may already exist or may need to be created before the workshop. In one requirements workshop, for example, I asked the team to produce prototype screens and a list of free-form business rules for each of the use cases that had already been drafted.  These additional input products proved to be critical in accelerating the delivery of higher-quality use cases.

Place

*/ ?>

The location of a workshop can influence the outcome.  If you're using a technique that requires the use of giant pieces of paper mounted on the walls, for example, the room needs plenty of wall space.  If the room is crowded, subteam activities might be impossible.  It's also important that the room have the space and amenities you need to serve refreshments.

Should you hold your workshop on-site near participants' work areas, or off-site?  It's good for participants to have easy access to files, documents, and materials, but it also means that they can be pulled away from the workshop to deal with e-mail, voice mail, or peer questions.

In evaluating the best place to hold the workshop, consider room size, wall space, support for refreshments, seating (a u-shape arrangement is best), availability of outlets, access to on-call subject matter experts (via physical proximity or phones), and access to phones during breaks and lunch.

Process

*/ ?>

Plan the workshop's activities so they follow a logical flow in which the outputs from one activity are used by the next activity in the session (or in a post-workshop project task).  An activity may consist of several steps in which members work individually, in small teams (subteams), or as a whole group.

To streamline the process and improve the quality of deliverables, it's a good idea to follow a collaboration pattern.  Collaboration patterns are recurring activities used successfully by collaborating groups.  They are high-level blueprints for the behavior that these groups undertake to accomplish results together.  Some of the collaboration patterns I have found useful over many years of workshop facilitation include "Decide How to Decide," "Wall of Wonder," "Expand and Contract," "The Sieve," and more [gott02]  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.

In the remaining part of this article, I discuss one element in particular, workshop products.

Workshop Products

Your workshop products include inputs and outputs.  The outputs include requirements and supplemental deliverables such as statements of issues and follow-up actions.  The inputs are any materials that jump-start workshop activities and prepare participants:  posters, templates, documents, workshop activity instructions, draft or predecessor requirements models, and the results of participant pre-work (see Figure 3).

Figure 3. Requirements Workshop Inputs and Outputs

Workshop Inputs and Outputs

*/ ?>

I discuss output products first because they are the basis for deciding which inputs you should use for your workshop.

Output Products

Your primary output products are the requirements models created by the participants.  (Later I discuss intangible workshop products, such as decisions about the state of the requirements.)  Along with your core requirements deliverables, you'll create supplemental deliverables, such as posters or documents that list actions or next steps, issues, and decisions.

In some cases, you may want to create supplemental workshop products to accelerate follow-up activities.  In one workshop, the participants created a communication plan for organizations to be affected by the software.  In another workshop, the participants identified risks and then created a risk mitigation plan and a post-workshop implementation plan.  As part of an activity to jump-start their requirements modeling work, another group created a set of posters depicting a vision of what work would be like after the system was in place.

Although your primary focus is the core deliverables -- the requirements models -- you should consider how supplemental deliverables can dovetail with project activities and help the team to communicate effectively.  Creating visually rich supplemental deliverables is fast and efficient.

The requirements models created by participants are sources for other project activities (such as design, testing, and coding) and for additional workshops (if you decide to produce requirements iteratively in a series of workshops).  For example, outputs such as detailed use cases, business rules, and sketches of screens would be inputs to design and coding.  You can use high-level requirements models -- such as context diagrams, event tables, stakeholder classes, and use cases produced in a workshop that follows the horizontal, or "width first," workshop strategy [gott02] -- as inputs to another workshop that adds more depth to those models.

To determine which requirements models to deliver, you need to do the following:

• Select model views that are aligned with the business problem domain.
• Use multiple models to increase the quality of your requirements.
• Mix text models with diagrammatic models to increase the speed of requirements definition and promote mutual learning.
• Pick multiple views and focuses to enhance the quality of your requirements.
• Define the appropriate level of detail for each selected model.
• Iteratively deliver the requirements.
• Prioritize the requirements deliverables.
• Decide whether you should partition requirements across multiple workshops.
• Clarify your doneness tests for delivering "good enough" requirements in the workshop.

The following subsections explore these topics.

Select Models Aligned with the Business Problem

*/ ?>

Model views -- behavior, structural, dynamic, and control -- provide differing perspectives of user requirements (e.g., structure, behavior, dynamics, and control).  Even though each business problem is unique, the generic set of heuristics presented in Table 1 illustrates how the business domain influences the types of requirements model that most strongly express user requirements.

Table 1: Heuristics for Selecting Requirements Models

Model View	Sample Domains	Suggested Models
Behavior	Operations, administration, inventory management, payroll, hiring, order processing, billing, accounting	Actor map and table Context diagram Domain model Event table Glossary Process map Prototype Scenarios Use cases Use case map
Structural	Data query and analysis, data extraction and reporting, customer relationship management	Business policies Business rules Context diagram Domain model Glossary Prototype Scenarios
Dynamics	Workflow problems such as document management, materials management, procurement, logistics, configuration management, imaging, loan management, credit application management, demand management, contract negotiation	Event table Glossary Process map Prototype Scenarios Statechart diagrams Use case map
Control	Logistics, claim adjudication, mortgage loan underwriting, financial risk, fraud detection, product configuration, power usage, clinical diagnosis, credit checking	Business policies Business rules Decision table/decision tree Event table Glossary Scenarios

This table is intended to be representative, not inclusive. No one view can express user requirements completely, so it's important to draw from several views.  For example, if users are handling the ordering task, behavior models are useful.  At the same time, they're interacting with business concepts and domains such as orders, cancellations, and customers, which are best captured in structural models.  As you can see from the table, a glossary should always be part of your requirements deliverables; in fact, a draft glossary should always be an input product (see "Draft Models" later in this article).

As you learn more about the models and use them in workshops, you'll begin to recognize which ones are more useful for the business problem you're trying to solve.

One project team asked me to review its requirements workshop plan.  The business problem was to create a flexible hierarchy of salespeople and commission schemes to be used globally.  The group's plan called for using use cases almost exclusively.  I asked them a few questions, such as, "Who will directly interact with the system?" "How frequently will they interact with it?" "What kinds of decisions do you want the system to make?" "What information does the system use?"

Their answers told me that little human interaction was needed and that the core characteristic of their business problem was to establish and manage commissions, salespeople, and zones (global groups).  The problem was best expressed not with behavioral models but rather with structural and control models.  Consequently, we refocused the model orientation from use cases to a data model, business policies, and business rules.

Use Multiple Models

*/ ?>

No single user requirements model can fully express the functional requirements for your project.  A solution is to use multiple models.

Delivering multiple models increases the comprehensiveness of your requirements because each model reveals aspects of another.  In addition, you can use one model to test the correctness of another.  This testing is aided with the use of a list of model quality assurance (QA) questions devised before the workshop.  Possible questions include the following:

• For each event in our event table, is there at least one associated use case?
• Which use case would handle this scenario?
• For each use case step, have all the business rules been defined?
• What data is needed to support this business rule?

The specific questions depend on which models you deliver and their degrees of detail, but you can see how one model acts to trigger elements of another model.  As illustrated in Figure 4, using multiple models allows you thread one model to another within a single workshop.

Figure 4. Threading Multiple Models Through a Workshop

Figure Notes: A structural model (such a context diagram or the glossary) relates to a dynamic model (such as the event table); a behavioral model (such as a process map) provides clues for a control model (such as business policies). Figure 4 also illustrates the concept of "chunking" the workshop deliverables into iterations.

You can arrange the sequence of your models differently, depending on what you have as a starting point (see "Draft Models" later in this chapter).  An example is presented later of a variety of sequences for arriving at business rules.

Mix Text and Diagrammatic Models

*/ ?>

Plan for participants to deliver a combination of both text and diagrammatic requirements models.  Weave both styles of products into your process design.  Text models are more precise and contribute to accuracy; diagrammatic models are fast to create and understand, something that promotes overall speed in the process.  The two styles also work well with regard to our two-sided brains, with the right side being more adept at dealing with things that are visual and random and the left side being stronger at linear and analytical tasks.

To put it a different way, a picture may be worth a thousand words, but the question is, Which thousand, and what do you mean by them?  You need words to answer that.

Consider mixing text with diagrams for each view you deliver. For example:

• Business rules and decision table or tree
• Use case text and a use case map
• An actor table and an actor map
• A glossary definition and a data model

Some models are strictly text-based and require visual models in order to elicit them.  Business rules and business policies are good examples.  You won't get too far asking business people, "What business rules do you need?"  Instead, you need visual models that will call up the business rules.  One way to overcome this problem is to represent business rules using a decision table or decision tree.  Another way is to start harvesting business rules using other models.

Models for Harvesting Business Rules

You can use all or part of a model to thread to another model.  For example, a single step of a use case gives you a thread to the data attributes needed by a data model and also to the business rules that must be enforced within that step.  To arrive at business rules, you can use a variety of sequences, including the following:

• Use case ==> events ==> business policies ==> business rules
• Use cases ==> actors ==> domain model (class model or data entities) ==> business rules
• Actor ==> decisions ==> business rules
• Actors ==> use cases ==> domain model ==> business rules
• Events ==> domain model ==> business rules
• Events ==> use cases ==> business rules
• Events ==> domain model==> life cycles ==> business rules
• Domain model ==> events ==> life cycles ==> business rules

Mix Focuses and Views

*/ ?>

Draw from various requirements model focuses (who, what, when, where, why, and how) as well as views -- structure, behavior, dynamic, and control (see Figure 5).

Figure 5. Model Views

Here's a typical combination:

• Use cases are a behavior view focused on how work gets done.
• An actor map is also a behavior view, but it focuses on who does the work.
• A data model or class model is a structural view focused on what information is needed.
• Business rules are a control view focused on why -- the decisions that software needs to make.

Eliciting a combination of models with different focuses helps you to detect requirements errors.  In one of my workshops, for example, the use cases that were created made the customer realize that at least 20 business rules needed to be defined more precisely before the requirements could be closed.  The model view can trigger creation of additional models that provide more focuses.  For example, if you choose a behavioral view of your requirements (say, use cases), you can use those use cases to harvest related models.

Define the Level of Detail

*/ ?>

Decide how precise each requirements deliverable should be.

Scope-level models are particularly important when there's a high risk of scope creep or conflict among users about requirements, or when the requirements aren't precise enough to support the start of design work.  In that case, if users and developers expect to make the transition to design at the end of a workshop that delivers that level of detail, you'll have many unhappy project team members.

A useful strategy for moving from scope-level or high-level requirements down to detailed-level requirements is to use iterations.  This involves working together to deliver a set of models at roughly the same level of precision, checking their quality, and then moving down to the next level of detail.  This approach is a top-down horizontal strategy [gott02].  Iterating in a top-down manner can accelerate the group's mutual understanding of the requirements and reduce rework within the workshop.

But you may not always want to elicit your requirements models in that top-down order.  If your project has a well-defined scope, the team should be ready to jump into high-level requirements.  In some cases (particularly if you're replacing an existing system), you'll start at a lower level of detail, with prototype screens and use case steps.  At other times, you'll iterate among the levels in a zigzag strategy.

Each project is unique.  To decide the best way to elicit user requirements in workshops, you'll need to consider factors such as team size, location, degree of customer and user involvement, past history with software development, existing documentation and software, and team modeling experience.

Iteratively Deliver Requirements

*/ ?>

As you consider each requirements model you want to deliver, begin to partition the model into its component parts.  For example, divide a detailed use case into its name, header information (such as the triggering event, event response, and initiating actor), and use case steps.  Next, group elements from your various models at about the same level of detail.

Figure 6 shows how a use case and its related requirements can be grouped in an iterative fashion to deliver business rules and other requirements.

Figure 6. Iteratively Delivering Requirements in a Workshop

Although this example shows four iterations, you can use two or three iterations.  This example moves from the high level to the detailed level, following what I call the vertical, how-first strategy, in which you drill down within one focus.  Note that if you choose this strategy, time will constrain how many use cases (and related requirements) you can deliver.

In iteration 1, participants begin with a named use case; they then define the initiating actor, the triggering event, and the event response.  In iteration 2, using the prior set of requirements, participants complete the use case header using a use case template.  They do this by writing a one-paragraph description of the use case, adding the locations of the actors, listing the associated business policies, and modeling the high-level domain model (class model or data entities).

In iteration 3, participants create a use case map to visually lay out the predecessor-successor relationships among the use cases.  (Creating a process map puts the use cases in the context of the workflow, giving the team the big picture of the set of requirements.  This map also allows the users to understand how the use cases can fit into their workflow.  This work is accelerated if a process map has been created before the workshop.)  Participants logically partition use cases into packages, which in turn they'll use to define releases or increments for delivery.

In iteration 4, the participants add detailed use case steps, define business rules for each step, list data attributes needed by the steps and their rules, and sketch prototypes for each use case.

At the end of each iteration -- which should take one to three hours, depending on the number of use cases -- participants should test the quality of the models they've delivered in order to reach closure on that set of requirements before moving on to another set.

Using a "divide and conquer" approach helps you to avoid workshop scope creep -- getting off-track during the workshop by moving up and down to different levels of detail.  It also gives you a basis for ordering group activities.  You also save time by eliminating the step of cleaning models up.

Input Products

Once you've planned your workshop outputs, it's time to determine what input products you need.  Using a set of well-thought-out input products speeds up your workshop and helps groups reach closure.

Input products include a variety of materials that prepare participants for the mental work they'll do, provide tools for jump-starting workshop activities, give guidance for creating higher-quality requirements models, and serve as doneness test resources. Input products can include the following:

• The workshop agenda
• Draft requirements models
• Systems and user documentation
• The results of pre-work
• Templates
• Workshop aids

The following subsections discuss each of these kinds of input product.

The Workshop Agenda

*/ ?>

The workshop agenda is an ordered list of activities planned for the session.  The agenda, which you send to all the participants before the workshop, should also include your other P's:  purpose, participants, principles, products, and place.

Draft Models

*/ ?>

Use predecessor requirements models or draft output models to jump-start your modeling work.  For example, if you're creating use cases in the workshop, you can use an actor table or an actor map as a mechanism to help you create a list of use cases.  By using focus questions about the predecessor model (for example, "What goals does this actor have for interacting with the system?"), you can elicit another related model.

You can also use predecessor and draft requirements in performing doneness tests on models.  For example, a list of scenarios created before the workshop can be used in testing use cases.  To test for doneness during the workshop, you can use pre-work such as user-created scenarios and prototype screens created by the software team by walking through them in parallel with use case steps.

A draft version of a model provides the basis for an activity to fix or finish it.  For example, you can use a draft event table or context diagram during an activity in which the group reaches closure on scope.  A rough version of a statechart diagram gives you a starting point for generating more states, which in turn triggers events and business rules.

At a minimum, you should create a draft glossary before a requirements workshop.  The terms in the glossary are the semantic basis for all your user requirements; the definitions are themselves fundamental business rules.

I like to ask one person to be the glossary guardian, the person in charge of keeping the glossary up-to-date during the workshop.  The job of the glossary guardian is to listen for business terms that haven't been defined or that might need to be clarified.  Allow everyone to tune in to terms; challenge each participant to also play the role of glossary guardian.  To make it fun, I sometimes announce a reward for anyone who stops the group when a term needs to be defined or clarified.  Reverse rewards can work, too, if you make them humorous -- for example, getting "banged" with a rubber hammer when using a term without explaining it.  Data modelers make excellent glossary guardians because they naturally think in terms of words and their connections, and they often seek precise definitions of business terms.

Universal Models

An alternative or supplemental draft model you can use as input is a universal model.  This generic business model is documented in books or available for purchase from consulting companies.

Universal models tend to be abstract.  They use generic business terms (business party, transaction, event, agreement) that you can use as starting points for modeling activities.  For example, if the universal model is represented as a data model, participants can list examples of each concept in the model or list subtypes to jump-start the modeling of their own domain model.

System and User Documentation

*/ ?>

It's a good idea to have documentation available that might be useful during the workshop.  This includes the project charter or vision statement, organization charts, operating procedures and guidelines, reference manuals, user documentation, help desk documentation, user job aids, training manuals and documentation, and system manuals and documentation.  Identify each document that might be useful, and be sure that someone is responsible for bringing it.

Pre-Work

*/ ?>

Pre-work involves specific assignments for participants to complete before the workshop.  Examples of pre-work include filling out a template that lists steps to complete a task, naming business rules in a specific format for a set of use cases, listing stakeholders and their functional areas, reviewing and commenting on a set of draft use cases, reading the project charter, listing key inputs needed by users, and drawing a poster that depicts an image of the future after the requirements have been met.

Asking participants to complete pre-work has one or more of these benefits:

• It mentally prepares participants for the type of thinking they'll do in the workshop.
• It provides research information and starting points to one or more workshop activities.
• It forces participants to seek information from other experts who might fill gaps in their subject matter expertise.
• Specifying some kind of pre-work signals that the requirements workshop isn't an ordinary meeting.

Pre-work is essential when you're operating under a tight time frame, when users are surrogates and not real subject matter experts, when participants hail from different business areas, or when you'll be working with detailed requirements.  Your workshop schedule must take into account the time for preparing pre-work.  For example, you may need to create a template with instructions (see "Templates" next).

Designing pre-work is one thing, but how do you get participants to complete it?  Your sponsor and your planning team can help.  For example:

• Have the pre-work assignments made by the sponsor or an influential planning team member.
• Provide information at least one week before the workshop.
• Conduct an orientation meeting to brief participants on how to complete the pre-work, particularly if their assignments are complex.
• Ask the workshop sponsor or project sponsor to send e-mail or voice mail to the participants requesting that they complete their pre-work.
• Have the pre-work responses sent to the workshop sponsor or a planning team member rather than the facilitator.

Templates

*/ ?>

Templates are standardized formats that you use during workshop activities to structure the contents of an output product.  Templates can be used for building the requirements models, prioritizing requirements, creating related deliverables (such as an action plan or a communication plan), debriefing the workshop, and assessing the team climate (if you incorporate team-building activities into the workshop).

Creating templates forces your workshop planning team to think deeply about project-specific deliverables.  It also helps participants to make the best use of their workshop time, and it helps you to provide precise, clear instructions about workshop tasks.

For one workshop, I worked with the planning team to settle on a template for the use cases.  For another, I created a business requirements matrix template for use during the workshop.  For yet another, I designed a simple form for capturing scenarios.  In another case, I devised a template for scenario testing our use cases and data model. In several workshops in which the subsequent software product had cross-functional impact, I used a communication plan template.  For most workshops delivering precise business rules, a business rules template is also critical.

Business Rules Templates

Business rules come in many forms and categories, including terms, facts, constraints, factor clauses, and action clauses.  There's no agreement on a standard set of categories for business rules -- nor should there be, because the rules should fit the business problem.  Some business problems are more business rule-based (for example, insurance underwriting), whereas others are more business rule-constrained (such as payroll).  Business rules are vital for high-quality requirements, and they also provide useful links to other requirements models.

You can capture your business rules as free-form statements generated by business people, but these statements tend to be ambiguous and not rigorous.  Each free-form business rule may decompose into numerous rules.  You must untangle each statement and resolve its internal inconsistencies.  Also, it's hard to trace such unstructured statements to other requirements models, and they create change control headaches.  If the rules are smaller and more discrete, you can more easily manage change.  To capture business rules atomically, it helps to have a business rule template designed for the purpose.

A business rules template presents standard, precise syntax for writing business rules.  The template should be designed so that the resulting business rules are declarative, atomic, distinct, independent statements.  The very process of tailoring a template to a particular business problem is beneficial because it requires you to understand the problem in great depth.  This means working directly with business customers to design and tailor the template.

Examples of useful business rules templates include the following:

• Each <business term> may <verb phrase> <business term>.
• When <event|condition is true>, then <action>.
• If <condition true>, then <condition true/conclusion>.

You can use your templates during the workshop to guide participants in writing business rules. 
Your template should include instructions (or it should be supplemented by a document work aid that has instructions) and perhaps examples of how to properly complete the template.  Templates can be created as word processing documents or can be drawn on posters.  If your recorder acts as a technographer (see part 1 of this article), she can input the group's work into a word processor.  You can then display or print the contents of all completed templates for participants to refer to or review during the session.

Templates help to ensure that you get high-quality, consistent information from participants.  This is especially critical when you use multiple subgroups working on different requirements for the same model at the same time during the session.  Templates also force you to clarify doneness tests because you must describe what each deliverable should look like.  If you can visualize what the group members must deliver, it's easier to design the collaborative processes to get them there.  Templates also help you to give precise instructions to the group during the workshop.

You can supplement the template with a completed example (see "Examples" later in this article), which helps participants understand the models they need to create.

Workshop Aids

*/ ?>

Workshop aids are tools for conducting activities in the session.  These aids include static posters for participants to reference, sample models, instructions or tips to use while working on the models, worksheets for documenting changes to models, and materials and supplies.
Posters

Posters are charts that are visible in the room.  Create your posters before the workshop, and place them on the workshop room walls using tape, pins, or tacks or by using sticky poster paper (posters on a pad with the top back prepared with repositionable glue).  You should prepare posters with the following titles:

• Workshop Purpose
• Workshop Products
• Workshop Agenda (the flow of activities)
• Issues or Parking Lot (titled and left blank)
• Input products
• Actions (titled and left blank)
• Decisions (titled and left blank)

Examples

Sample models use a "begin with the end in mind" philosophy:  They show participants what the end product should look like by providing simple but correct examples.  I've found these examples useful for almost every requirements model that employs a template, including use cases, business rules, and scenarios.  To create examples that are relevant to the problem, consult with your planning team or other subject matter experts.  Even an example that's wrong, but is correctly written or drawn, is useful for participants.

Instructions and Tips

Prefabricated instructions or guidelines can help you save time during the workshop.  Tell participants what they need to do for each workshop activity, and also give them written instructions (paper handouts or on posters).  This method gives everyone a reference point for completing activities.

Provide instructions, especially early in a workshop, for subgroup activities.  For example, instructions might stipulate that there should be a timekeeper, a recorder, and someone to make sure that the content of the work follows a template format.

It's a good idea to include tips for creating high-quality models.  In one workshop, I gave participants a list of good verbs to use in their use case names.  In another, I provided a list of verbs for them to use for data model relationships.  These kinds of tips help save workshop time.

Worksheets

Your recorder can use worksheets for tracking the disposition of and changes to requirements models.  When your recorder uses a laptop with a word processor or spreadsheet program (acting as a technographer), you can project the changes on a screen or print them for reference.  In several workshops that delivered use cases, I found a use case completion worksheet helpful (see my Web site -- www.ebgconsulting.com/ReqtsByCollab.html -- which has requirements workshop assets related to my book for an example.

A note of caution:  Don't assume that your readers will be able to understand your workshop aids.  Test any input products you create -- instructions, examples, tips, worksheets -- before you give them to participants.  Ask planning team members and a few of the participants to review the instructions and see whether they understand them.  Then, during the workshop, review the instructions and ask for clarifying questions.

Materials and Supplies

Materials and supplies include all the physical things you'll need to run the workshop:  items such as name cards, posters, cards or sticky notes, color markers, paper cutters, side-hole punches, a printer, and binders.  (A generic list is available on the Web site.)

Set up binders with dividers in which participants can store all the paper documents they'll work with during the session.  I like to supply tab dividers already labeled for things such as purpose, principles, and agenda.  The binders can also hold copies of modeling tips, activity instructions, templates, and examples.

After the workshop, participants can use the binders for reference and for storing hard copies of requirements and workshop and project information.  Binders save people time by helping them to avoid searching through large sets of documents.  They also help participants stay organized during the workshop, and using them sends a message that their work warrants a special storage place.

The Workshop Repository

The workshop repository is where you store the soft copies of your workshop products, pre-work, and post-workshop products.  You might use a project Web site, a requirements management tool, a network folder, or a combination of these.  Remind participants before, during, and after the session about the repository.  Arrange access for the participants, allowing them to deposit any pre-work there.

Summary

Workshops are an effective way to bring together customers, system users, content experts, and software suppliers to improve the quality of software products without sacrificing time to delivery.  Well run workshops deliver high quality requirements (including business rules), reduce risks associating with scope creep and lack of customer involvement, and also build solid IT-business relationships.

References

[gott02]  Gottesdiener, Ellen.  Requirements by Collaboration:  Workshops for Defining Needs.  Addison-Wesley (2002). 

[zach87]  Zachman, John.  "A Framework for Information Systems Architecture," IBM Systems Journal, Vol. 26, No. 3 (1987). 

---

"Gottesdiener, REQUIREMENTS BY COLLABORATION: WORKSHOPS FOR DEFINING NEEDS, © 2002 Pearson Education, Inc.
Reproduced by permission of Pearson Education, Inc. All rights reserved.

# # #