This chapter is from the book
This chapter is from the book
This chapter is from the book
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 products.
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. (See Chapter 9 for tips on designing your agenda; an agenda template is available on the book's Web site.)
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. (See "Using Focus Questions" in Chapter 9 for more about focus questions.)
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 if you use a term without explaining it.)
The glossary guardian keeps the glossary up-to-date during the workshop.
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.
Systems 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 systems 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.
Workshop Orientation Meetings
Under certain circumstances I like to arrange orientation meetings before workshops.
In one workshop I facilitated, participants came from around the globe. They had pre-work assignments and would be gathering in a central location for the session. Many of them had never participated in a requirements workshop, and few of them knew one another. We arranged a videoconference orientation meeting kicked off by the project sponsor. In this meeting, we reviewed the workshop agenda and clarified how to complete the pre-work. We also discussed important issues such as what to wear and how they would access their voice mail on breaks during the workshop. This 45-minute meeting helped to break the ice before the live workshop.
Here are some circumstances under which you should consider holding an orientation meeting:
Participants have pre-work assignments that may involve completing templates or doing complex research.
Participants don't know one another.
Participants would benefit from hearing suggestions for what materials to bring to the workshop.
You are meeting over a period of days or weeks.
Keep the meeting short, and be sure you have the project or workshop sponsor kick it off to set the stage.
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 to the facilitator.
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 rule 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 rule 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.
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 rule template is also critical.
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 Chapter 5), 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, a technique discussed in Chapter 9. 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 chapter), which helps participants understand the models they need to create.
Tips for Working on Posters
Print in thick, CAPITAL letters.
Write straight up and down.
Use plain block letters (not script).
Avoid black, except for numbering charts.
Use these colors for text: blue, brown, purple, green.
Use these colors for highlighting: orange, red, yellow, pink.
Be faithful to people's own words.
Use white space liberally.
Consider using the symbols shown in Table 7-4.
Table 7-4 Poster Symbols
|
|
Bullets (centered dot) to help items stand apart |
|
|
Stars for noteworthy items |
|
|
Circles to connect ideas and draw attention to items |
|
|
Borders to frame a page or blocks of text |
|
|
Arrows for sequences, cycles, and merging |
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 (see Chapter 9). 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, 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 the Web site 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.