we integrated prioritization with high-level modeling and then detailed modeling. I asked participants to write brief use case descriptions and then prioritize the whole set of use cases. From there, the participants created detailed use cases, scenarios, and business rules. In our last workshop activity, the participants revisited these priorities and adjusted the earlier list based on their deeper understanding.
Requirements workshops are often scheduled multiple times. Each workshop delivers a set of requirements, each of which is in a certain state or degree of completeness. You decide which products you need and tailor the outcomes appropriately. If time is of the essence, you might decide to deliver less precise user requirements, realizing that the trade-off will be more defects and rework during development. For projects in which quality is king, you’ll want to deliver a more comprehensive set of requirements.
Making the Business Case
Some organizations shy away from workshops, shunning the time it takes to plan and execute them. Others claim that the cost of gathering people together in the same place at the same time is cost-prohibitive. Yet, requirements workshops can provide a substantial return on investment, for example, $10 return on every $1 you invest (Jones, 1996).
Requirements workshops provide business value by reducing the time it takes to gather requirements, increasing team productivity, and reducing risks associated with software projects.
Aside from the hard data, requirements workshops contribute to customer and user satisfaction because they allow the people with the needs to participate directly in defining those needs. On one project, in which we built models like user interface prototypes during workshops in order to define requirements, not one high- or medium-priority defect originated with requirements.
The long-term prognosis for a project that uses requirements workshops is better because the workshops help build a healthy project community early in the project’s life. In addition to delivering requirements, workshops also facilitate the forming of healthy team interactions, trust, and collaboration. They show by example the value of maintaining active customer involvement in the software development process.
When Not to Use Requirements Workshops
You need to use requirements workshops under appropriate project conditions. If your project is small and low-risk, I don’t recommend using workshops. However, if your requirements are complex, and you value the side effects of collaboration—trust, mutual understanding, and participation—then requirements workshops may be for you.
Requirements workshops are most appropriate for business software or commercial software when you can get knowledgeable customers, users, or surrogates. Requirements for real-time systems are less visible to customers, so requirements workshops are probably not suitable.
Size matters, so be careful not to overload the workshops with too many people. The number of participants should not exceed 16 participants, unless you’re going to use two facilitators. Most workshops have between seven and 12 participants. Each person you add to the workshop can add more time or reduce the number of deliverables. Strive for the minimum number of participants who can represent the collective needs of customers, users, testers, designers, and analysts.
If you can’t identify a workshop sponsor, you won’t have the necessary commitment to ensure that the right players participate and prepare for a successful session. It isn’t feasible for some organizations to gather users or their surrogates at the same time and the same place. In that case, you might consider using collaborative software tools that allow people to gather in a different time–different place virtual environment. Be aware that you’ll need a skilled facilitator who can lead the process and also use the tool.
Requirements workshops require time to plan. If management won’t allow time