Eliciting Business Rules in Workshops (part 1)

by Ellen Gottesdiener

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.

Surfacing User Requirements

We often talk about how tough it is to capture user requirements, especially business rules. The term capture implies that requirements are imprisoned and taken over. In reality, user requirements need to be acquired and kept in trust by the software organization. The ultimate knowledge of user requirements, and the decision-making with regard to the quality of those requirements, rests with the business people who sponsor a software project. At the same time, though, business people need to understand the impact that software will have on operations and prepare for change.

User requirements have always been difficult to surface and clarify. Industry experts assert that defining user requirements is the most difficult task of software development. One of the biggest reasons is the communication gap between software and business people, which result in less than stellar customer-supplier relationships. Each side speaks using its own acronyms and shortcuts. Unless they've experienced each other's roles, they have trouble truly appreciating each other's legitimate concerns. This problem exists for both external software development organizations and software groups supporting internal business organizations. User requirements models help bridge these communication gaps.

User Requirements Models

User requirements are the needs that users have. User requirements can be expressed as functional hierarchies using text; for many business systems, models can be used to define user requirements.

A requirements model is a high-level blueprint for a software product. It takes the form of a diagram, list, or table, often supplemented with text that depicts a user's needs from a particular point of view. Examples of user requirements models include event lists, use cases, data models, class models, business rules, actor maps, prototypes, and user interface navigation diagrams.

Whatever its form, though, the primary purpose of a requirements model is to communicate. Defining requirements is a discovery process for users and customers. User requirements evolve from the process of users "trying out" their requirements through models.

Requirements models speak to both users and software people. As users create and modify the models, their understanding of their requirements changes and evolves -- in other words, the requirements become clearer.

Defining requirements with models works independently of software development methodology or technology. If you're using a more formal, disciplined development methodology, you're likely to need more models that contain greater detail. With less formal and prescribed methodologies, you'll create just a few models, and the models aren't likely to be very precise. In either case, models are useful. This is true if you're using more traditional technologies and languages or bleeding-edge tools.

An effective way to develop user requirements models is to use collaborative workshops.

Requirements Workshops

A requirements workshop is a structured meeting in which a carefully selected group of stakeholders and content experts work together to define, create, refine, and reach closure on deliverables that represent user requirements. The workshop process nurtures team communication, decision-making, and mutual understanding. Workshops are an effective way to bring together customers, users, and software suppliers to improve the quality of software products without sacrificing time to delivery. They tend to commit users to the requirements definition process and promote their ownership for the deliverables and, ultimately, the system.

Requirements workshops can bridge communication gaps among project stakeholders. Co-creating models in a requirements workshop expedites mutual learning and understanding. By asking focused questions in the workshop, the workshop facilitator helps participants define requirements at different levels of specificity. You might start with a scope workshop to outline the terrain, defining what the software will deliver and getting agreement on a starting set of functionality. If there's agreement on scope, you might begin with user interactions and evolve your detailed user requirements models from that point. In any case, workshops provide a forum in which customers and users can make informed decisions about delivery trade-offs and priorities.

A successful workshop requires the participation of key project stakeholders. Each workshop is treated like a mini-project that's woven into the fabric of a software or business project. Like any project, each workshop requires planning, role clarification, and infrastructure. It has a beginning, a middle, and an end. Deliverables are defined beforehand, but they'll change as the group learns.

Requirements workshops are based on the premise that a small group of knowledgeable, motivated people is more effective than one or two development "heroes." They're also based on the premise that, as Jerry Weinberg said, "One of us is not as smart as all of us." You tap the collective wisdom of the group to get your user requirements. This requires collaboration and facilitation.

Workshops:  Collaboration and Facilitation

Collaboration occurs when all members of a group or team share a common purpose, there's mutual trust, and everyone uses agreed-upon approaches for the work. The members operate like a jazz ensemble:  multiple voices interwoven, playing together and individually, generously, and inventively, sharing a single theme.

The most successful workshops are collaborative. This means that the participants share a common goal and join together to create deliverables that contribute to that goal. Collaboration doesn't just happen, though; teams don't just form and jell automatically. Collaboration needs to be engineered into a team's work. Requirements workshop participants should include a healthy mix of business and software people who share a common goal and have stakes in the same project. A key element of successful and collaborative workshops is that the participants agree to the workshop purpose, principles for participation, and products ahead of time. The participants also determine a decision-making process ahead of time; this permits the group to reach closure on their deliverables and the actions they will take after the workshop.

Workshops versus Meetings

The collaborative user requirements workshops I use for eliciting business rule and other user requirements are a modern-day variant of JAD (Joint Application Design). These are not "meetings" in the generally-accepted sense of that term. On the surface, collaborative workshops are like meetings in that both types of gatherings involve people meeting together at the same time, and both (presumably) follow a logical flow.

But there are significant differences. Among them is the presence of two people who fulfill two specific process roles:  facilitator and recorder. The facilitator is responsible for managing the group's activities, dynamics, and work products. The recorder (or scribe) documents the group's work as it proceeds. Often the recorder will be a technographer, capturing the group's work in a word processor or modeling tool. Neither facilitator nor recorder operates as a content expert nor collaborates in product creation. As a result, they are free to focus on the process.

Another important difference between a workshop and a meeting is that a workshop is authorized by a sponsor, who ensures that the right participants are present, verifies the workshop's purpose, and ensures that the workshop outcomes are implemented.

In effective collaborative workshops, energy is high, individuals respect one another, skills are complementary, and responsibilities and roles are clear both inside and outside the group setting. To maintain energy, creativity, and motivation, the facilitator uses interactive as well as parallel group activities. For example, in a user requirements workshop, subgroups may be formed to work on portions of a single deliverable, such as business rules. Alternatively, subgroups might be assigned to work on entire work products, such as one group working on use cases while another drafts a prototype 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.

A Real Workshop Example

In a two-day requirements workshop I facilitated, the team needed to deliver business rules, use cases, scenarios, prototypes and a data model.[gott01b] During workshops, I try to integration quality testing. To do this, I try to apply Jerry Weinberg's concept of "ego-less programming" to requirements. Weinberg's idea [wein71] was for participants to turn away from being defensive about their work products, focusing instead on the quality of the work. By "restructuring the social environment" -- using peers to objectively evaluate the work -- it's possible, Weinberg argues, to find not only defects but also ways to improve the product. Because my group placed a high priority on quality requirements, the team members were interested in implementing this concept. To do that, we used walkthroughs.

In a walkthrough, a producer -- the person who created the product -- describes the product and steps through its contents while the team jointly takes responsibility for evaluating its quality. In addition to learning from our own and each other's mistakes, an added benefit of using walkthroughs is that we tend to do a better job of creating the product in the first place.

Before the workshop, the team had decided that use cases would be a good way to represent user requirements. (A use case is functional requirements model that defines a specific use of the system, and can be represented in a diagram, in a text specification, or both.) The team had specified and documented a list of potential use case names and a set of scenarios. (Scenarios are descriptions of the system in action, including sample data, used to create test cases and, later, test scripts.) The group also drafted a glossary of terms, and the team's GUI designer created a set of screen mock-ups for each of the potential use cases.

At the workshop, participants created detailed use cases and wrote business rules. As the participants specified the use case steps our recorder captured them using a laptop. The steps were also posted on the wall in sequence, left to right, on big blue adhesive notes. Beneath each use case was a list of business rules. The team then used the scenarios to walk through each use case, along with its associated business rules and the prototype screens.

Here's how it worked.

Sarah, a business expert, played the role of a user. She selected a scenario and then walked through a use case posted on the wall, step by step. At the same time, Dave, the GUI designer, was poised at the overhead projector with a pile of prototype screens on acetates. Using an erasable colored pen, he wrote data from the scenarios on the acetate as Sarah walked through the steps. He not only modified the data on the screen shots but also rearranged and redrew rough screen shots to give Sarah the interface she expected to see at that point in the scenario.

We first worked through the "normal" flow of a use case. As we tested the use case with the data provided from each scenario, I would ask a question such as, "How do you decide which…?" or "How does the system select…?" or "What does the system have to know to...?" and so on. These questions were designed to test the business rules. When the group realized that a business rule was incomplete or unclear, the scribe recorded the revision under the use case steps for everyone to see.

After working through three or four normal scenarios, we attacked the exceptions:  those scenarios that would occur less often or those that would cause errors. We had posted the use case steps that had exceptions using different-colored adhesive notes. These exceptions appeared as branches off the normal use case steps.

Walking through the scenarios had already revealed that numerous business rules were missing. As we walked through an exception scenario, sometimes the participants realized that they needed to add another exception. These in turn yielded more use case steps, test data, and changes to the flow of the prototype screens. We kept track of the corrections on the actual models. You can also use a form to track all the defects in one place.

At the conclusion of each use case's walkthrough, we used a collaboration pattern I call "Decide How to Decide:  A Collaboration Pattern" [gott01a] to determine the disposition of each use case. Our scribe, working on his laptop, projected our Use Case Completion form on the wall. At this point, I polled the group for input. Using a predetermined decision rule, the sponsor made the final decision. As specifics were discussed, the scribe captured notes and the final decision on the form.

Workshops Deliver Products

As this example demonstrates, workshops (unlike classic meetings) deliver specific, predefined products. These include tangible products, which are the requirements models. Workshops also deliver important intangible products, such as mutual learning, increased understanding, decisions, motivation, and teamwork. These products are specifically planned ahead of time.

During your workshop, participants use one model to test another, and in so doing uncover missing and erroneous requirements. Because each requirements model connects in some way to another, you can also use one model to elicit another. Participants can more easily see connections, and they quickly learn to iterate across multiple models in the workshop, which leads to more complete requirements.

The following are real examples of the work products created in facilitated workshops: [gott99c] 

• In a half-day midpoint debrief (retrospective), a beleaguered project team created an action plan for correcting critical project problems, re-established how and when team communications will occur, and redefined several key roles, including that of the project sponsor.
• In two hours, workshop participants generated 119 business events, classified them, and then removed those not in scope during their requirements scoping workshop.
• In less than 90 minutes, business participants were able to test their use case model and structural business rules using 55 scenarios in a use-case modeling workshop.
• In three hours, a team validated a medium-complexity data model and made decisions about the scope of the data about which business performance metrics would be based.
• In a four hours, a project team defined the deliverables necessary for the upcoming design phase, who owned, reviewed, and created each deliverable, what their quality criterion would be, and mapped them into dependencies along a timeline.

Workshop planners need time to define what to deliver, what level of detail the materials should contain, and how the intangibles will be achieved. A useful guideline is that you'll need at least one day of planning time to facilitate one workshop day. This is not insubstantial, but the benefits can be vast.

Other Uses for Workshops

Elements of requirements workshops, such as process planning, product delivery, and process roles, can be applied in other settings. For one thing, you can use facilitated workshops to launch a project, in order to deliver elements documented in the project charter or vision document. In fact, you might usefully create the scope-level requirements during the chartering process. Other good uses of workshops:  strategic planning, process improvement, and problem solving.

Types of Requirements Workshops

You can use workshops to elicit, specify, review, quality-check, and reach closure on user requirements deliverables. Figure 1 shows a sequence of three types of requirements workshops. (Note that the deliverables are examples; there are numerous deliverables you can use in requirements workshops.)

Although each project is unique, this diagram gives you a basis for defining the deliverables of any of the workshop types. For example, you might use multiple half-day workshops to deliver high-level requirements.

These workshops are preceded by an agreed-upon charter document or vision document and possibly a charter workshop. Typically, in a charter workshop, you'd deliver goals, objectives, a communication plan, roles and responsibilities, and perhaps some of the same deliverables of a scope workshop such as events, a context diagram, and stakeholder classes.

You successfully refine user requirements, moving from a high level of abstraction to more fully intricate and detailed requirements. In a scope workshop, you take a bird's-eye view of what user requirements should be included. The deliverables from the scope workshop clarify the items that need to be elaborated upon in your high-level workshop, which are in turn specified in the detailed workshop. You may combine workshop levels if your scope is fairly well-contained.

In practice, workshop categories can overlap. As you move through the workshops, you prioritize your requirements. In one of my workshops, 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.

Benefits

Collaborative workshops have proven to be remarkably successful as a means to reduce risk, enhance quality, and increase productivity. They can reduce requirements creep by almost half. But that's only a few of their benefits.  They can also:

• Commit users to the requirements definition process
• Promote ownership for the deliverables and, ultimately, the system
• Shorten the requirements phase
• Eliminate non-essential requirements
• Form or reinforce effective communication patterns
• Build trust among project participants

By actively involving users in eliciting and testing requirements, successful workshops help you reduce defects in requirements -- and enhance team communications along the way.

The Business Value of Requirements Workshops

Not getting requirements right for your software will lead to big problems. The formal requirements phase takes about 5 percent of your software effort, but the accumulated time spent on requirements -- formal requirements plus creeping requirements -- takes as much as 30 percent of your time. [boeh81] [jone00]

Software products are notoriously error-prone. Many defects originate in the requirements phase [boeh87] [jone96b], and they cost a lot in rework. As a whole, the area of requirements, if not done well, is the aspect of a software development effort that can cost you the most in time, money, and customer dissatisfaction.

Here are some data:

• Problems with requirements -- specifically, frequent changes, missing requirements, insufficient user communication, poor specifications, and insufficient analysis -- account for the five top causes of poor software cost estimation. [davi95]

• Requirements are the major source of severe problems that generate expensive downstream changes. [leff97] [jone00]

• Requirements errors contribute to one-third of total delivered defects. [leff99]

• Requirements processes are the source of most (50 percent or more) serious quality problems. [wein97]

• Fixing requirements errors consumes 70 percent to 80 percent of a project's rework costs [leff97]. Overall, rework costs 40 percent to 50 percent of the total software development budget. [jone86] [boeh87] The result is that requirements errors consume 28 percent to 42.5 percent of total software development costs.

• Finding and fixing requirements defects after system delivery is often 100 times as expensive as finding and fixing them during the requirements and design phases. [boeh01]

• The development team can spend as much as 30 percent to 80 percent of their project effort reworking mistakes they made earlier. [faga76]

• Reworking a requirements problem costs 50 to 200 times what it would take to fix it during the requirements phase. [boeh88]

• The cost of rework is 10 to 100 times less if it's done earlier in the software life cycle. [mcco96]

• Scope creep is one of the most common, and sometimes the most common, source of cost and schedule overruns, and it is a major factor in project cancellations. [jone94] [lede92] [vosb84]

Well-designed and well-executed workshops are the most effective and stable way to define user requirements [jone00].  Data supports the assertion that the use of requirements workshops increases quality and reduces costs. Requirements workshops can:

• Reduce the risk of scope creep from 80 percent to 10 percent, and to 5 percent when combined with prototyping. [jone96a]

• Cut requirements creep in half [jone00].

• Cut the elapsed time of requirements specification by 20 percent to 60 percent, and total project effort by 20 percent to 60 percent. [augu91]

• Provide a 5 percent to 15 percent overall savings in time and effort for the project as a whole. [jone96a]

• Reduce defects delivered in software by 20 percent. [jone96a]

• Reduce project failure and cancellation rates by about 50 percent. [jone96a]

• As a customer-oriented requirements gathering practice, increase productivity by 10 percent to 50 percent. [vosb84]

• Provide a 10-to-1 return on investment ($10 for every $1 invested). [jone96a]

Summary

An effective and efficient technique for eliciting and verifying business rules and related requirements is to use workshops. Workshops not only deliver high quality requirements, but also form and build positive relationships among project stakeholders. To have a successful workshop, planning is critical. In the conclusion of this article, I'll discuss a framework for your workshop, as well as considerations for your workshop products.

References

[augu91] August, Judy H. Joint Application Design:  The Group Session Approach to System Design. Yourdon Press/Prentice Hall 1991).

[boeh81] Boehm, Barry. Software Engineering Economics. Prentice Hall PTR (1981).

[boeh87] Boehm, Barry. "Improving Software Productivity," IEEE Computer, September 1987, pp.43-57.

[boeh88] Boehm, Barry and Philip N. Papacccio. "Understanding and Controlling Software Costs," IEEE Transactions on Software Engineering, Vol. 14, No. 10 (October 1988), pp. 1462-1477.

[boeh01] Boehm, Barry, and Victor R. Basili. "Software Defect Reduction Top 10 List," IEEE Computer, 34, No. 1 (2001), pp 135-137.

[davi95] Davis, Alan M. 201 Principles of Software Development. McGraw-Hill (1995).

[faga76] Fagan, Michael E. "Design and Code Inspections to Reduce Errors in Program Development," IBM Systems Journal, Vol. 15, No. 3 (1976).

[gott99b] Gottesdiener, Ellen. "Capturing Business Rules," Software Development, Vol. 7, No. 12 (December 1999). Reprinted in Beyond Chaos:  The Expert Edge in Managing Software Development, Addison-Wesley ACM Press (2001).

[gott99c] Gottesdiener, Ellen. "Decode Business Needs Now," Software Development, Vol. 7, No. 12 (December 1999). Reprinted in The Unified Process Inception Phase:  Best Practices in Implementing the UP, CMP Books (2000).

[gott99d] Gottesdiener, Ellen. "Harvesting Business Rules in Workshops," DataToKnowledge Newsletter, Vol. 27, No. 2 (March/April 1999).

[gott01a] Gottesdiener, Ellen. "Decide How to Decide:  A Collaboration Pattern." URL:  http://www.ebgconsulting.com/publications.html#jad.

[gott01b] Gottesdiener, Ellen. "Collaborate for Quality:  Using Collaborative Workshops to Determine Requirements," Software Testing and Quality Engineering, Vol. 3, No. 2 (March/April 2001).

[jone86] Jones, Capers. Tutorial Programming Productivity: Issues for the Eighties, 2nd Edition. IEEE Computer Society Press (1986).

[jone94] Jones, Capers. Assessment and Control of Software Risks. Prentice-Hall (1994).

[jone96a] Jones, Capers. Patterns of Software Systems Failure and Success. Thomson Computer Press (1996).

[jone96b] Jones, Capers. "Strategies for Managing Requirements Creep," IEEE Computer, Vol. 29, No. 6, (June 1996), pp. 92-94.

[jone00] Jones, Capers. Software Assessments, Benchmarks and Best Practices. Addison-Wesley (2000).

[lede92] Lederer, Albert L., and Jayesh Prasad. "Nine Management Guidelines for Better Cost Estimating," Communications of the ACM, Vol. 35 , issue 2 (February 1992).

[leff97] Leffingwell, Dean. "Calculating the Return on Investment from More Effective Requirements Management," American Programmer, Vol. 1, No. 4 (April 1997), pp 13-16.

[leff99] Leffingwell, Dean and Don Widrig. Managing Software Requirements:  A Unified Approach. Addison-Wesley (1999).

[mcco96] McConnell, Steve. Rapid Development:  Taming Wild Software Schedules. Microsoft Press (1996).

[vosb84] Vosburgh, J. B., et al. "Productivity Factors and Programming Environments," In Proceedings of the 7th International Conference on Software Engineering, IEEE Computer Society (1984), pp 143-152.

[wein71] Weinberg, Gerald M. The Psychology of Computer Programming. Xxx (1971). (Reissued as a Silver Anniversary edition by Dorset House in 1998.)

[wein97] Weinberg, Gerald M. Quality Software Management, Volume 4: Anticipating Change. Dorset House (1997).

standard citation for this article: Ellen Gottesdiener, "Eliciting Business Rules in Workshops (part 1)," Business Rules Journal, Vol. 3, No. 11 (November 2002), URL:  http://www.BRCommunity.com/a2002/b121a.html.