Writing Effective Use Cases, Part II

In my previous article (Writing Effective Use Cases), I gave some basic ideas on authoring. To address the issue of how to shorten the time it takes to adequately define use cases for a complex system, I will resurrect an old method – the facilitated workshop. Facilitated workshops are a proven effective method for focusing the attention of key personnel on a problem. They provide the opportunity to drive deeper and in a shorter period of time than any other technique, if led effectively. Facilitated workshops are not a new concept; IBM trademarked and copyrighted the concept with Joint Application Develop (JAD) workshops 20 years ago. Boeing Computer Services published a competing method, calling their workshops "Consensus". The key factors to facilitated workshops are:

• Facilitate the Analysis (prepared templates, structured brainstorming, simplified modeling)
• The Right People (experts in the business domain, and empowered to make a decision)
• The Right Time (one- to two-week heads-down focused workshops)
• The Right Place (away from daily distractions, organized toward facilitation)

Templates should be defined loosely, with the objective to categorize the information and remind the analyst on what information to gather. Templates that are too detailed tend to not get filled in by the domain experts. Instead of one or a few templates with lots of detailed data to fill in on each, create multiple templates with each focusing on a few key topic areas. This allows for further structuring of meetings into discussion sessions that can drill down into information that might be provided by a few key people (allowing further structuring of these sessions along the lines of what/who/when).

Structured Brainstorming: Large group discussions can easily turn into free-for-alls, overwhelming anyone trying to capture the multiple (often competing) ideas thrown out. Many analysts prefer one-on-one or small group sessions specifically to avoid these free-for-alls. However, there are topics that require consensus from a larger audience. The way to channel these larger discussions is simply to structure the conservation. Some will say that structuring brainstorming stifles the brainstorm, but this approach attempts to encourage ideas while facilitating the capture of the ideas.

The typical rules for brainstorming apply, but to add structure to the session, start by limiting the conversation to one person at a time. This rule is simply to allow the facilitator the chance to capture each idea. It is important to capture all of the ideas – in the words of the speakers (not the words of the facilitator). It is critical that the speakers “own” their concepts. When a facilitator rewords someone else’s statement, he or she takes away that critical ownership component. And the last thing any analyst needs is for a domain expert to disown a project (after the project fails) by saying, "Those were your requirements, not mine."

The facilitator should work the room, drawing every person into the discussion and eliciting ideas from everyone. As stated previously, the general rules of brainstorming apply, so no judgments for or against the ideas are made on this first pass-through. Once all of the ideas are captured, post all pages of the flip chart side-by-side on the wall in front of the audience so that everyone can clearly see all of the ideas. Then take a second pass through the ideas to eliminate any truly redundant ones – still not making any judgments. Once the list of ideas has been trimmed down for redundancy, then (and only then) the group can deal with the ideas according to the reasons for having the session (group, categorize, align with goals, discuss in greater detail, etc.).

Discussion vs. Analysis: A point about facilitators. In my view, use case definition-related brainstorming sessions should be led by an experienced systems analyst who can keep the participants focused on the topic, either by stopping discussions that have ventured down a rat hole or by recognizing when an idea is not fully fleshed out and encouraging further discussions. A non-analyst facilitator not understanding what it takes to design and write software code will likely miss the signals for when more discussion is needed, allowing the group to carry their conversation wherever they want to take it. The group comes away from the session feeling great, because their thoughts have been fully voiced, but the information collected may not give the engineers what they need to build the resultant system.

Modeling with Domain Experts: Few domain experts have experience with the multiple modeling techniques used in software engineering, so asking them to produce such techniques often results in a blank stare response. However, I have found great value and cooperation when I facilitated modeling and diagramming techniques in focused use case definition workshops. As mentioned previously, it’s best to prepare ahead of time by simplifying the model notation to a few key and easily understood objects. Then create templates for collecting the textual data behind each key object in the model.

Start the modeling session with an overview of the modeling technique and an explanation of the key notation objects. For example, I first did this with Data Flow Diagrams (am I dating myself?). I simplified the model notation to Actors, Processes, data flows and data stores. Using flip charts, I worked my way through a series of DFDs with a large group of domain experts. I controlled the modeling conventions, but used the model to direct their thinking. The results were a much deeper set of requirements for me and immensely deeper ownership from the domain experts. The level of understanding they gained in the complex process of writing software was key to the success of the project.

Few analysts use DFDs any more, but the lesson remains and can be adapted to any requirements-level modeling technique. Every mathematician knows that models are not perfect, but they can drive the conversation deeper, keeping the conversation more focused, and much faster than a textual requirements gathering discussion.

Facilitation: To facilitate a use case definition workshop requires a special blend of discussion session leadership and analysis detail attention. Discussion leadership is a basic function of the facilitator role, ensuring that all essential information is thoroughly discussed. To do this effectively means to listen carefully to what one person says while encouraging others to add their thoughts, without allowing any one person to dominate the conversation. It may even be necessary to actively draw a participant into the conversation, continually ensuring that all ideas are captured. The role is not simply to be a scribe, but to facilitate the capture of ideas.

Empowerment: When working in a focused workshop setting, it is critical that participants be empowered to fully represent the domain they are at the workshop to represent. Decisions of one direction over another will often arise. If participants are empowered to make binding decisions, then real progress is made. If the group must halt while a decision is made from outside the group, then the wrong participant is present and the whole idea of focusing the time of key personnel is rendered moot.

Resist this temptation to split workshop time. A better way to lessen the impact to other commitments is to define the project scope such that workshops can be formulated around a single (but smaller) topic. In essence, hold a series of smaller but full focus workshops rather than one long workshop.

Another consideration is that if priority does not exist to dedicate the time at focused chunks, perhaps the priority issue should be resolved first, because breaking up a session will only delay the efforts.

"Work"-shops: We call these working sessions “work”-shops for a reason. While it is true that one of the key skills of a systems analyst is their ability to capture the ideas of the domain expert – whether in bulleted brainstorm list, textual content or modeled in a diagramming nomenclature, there is no substitute for having the expert themselves write down the details of their ideas. Some experts will resist – preferring the analyst to do the authoring – while they sit in judgment over the document at some later (more convenient) time, thus ensuring plausible deniability.

When the experts write the details themselves, the details take on a whole new meaning, because of the ownership carried by the author. This is not an abdication of the role of analyst. The analyst still captures the key ideas and uses their analytical skills to channel the discussions and guide the domain experts through the various modeling techniques, drilling ever deeper and hooking the expert into the process itself so that they want to stay committed to the very successful completion of the project.

Templates are intended to ease the burden on the domain experts to write all of this content. The domain experts provide the subject content, the analyst guides the detailing process. In a workshop, this should mean that the domain experts have homework to do at the end of each day. While the experts are busy doing their homework, the facilitators/analysts are busy cleaning up that day’s data (retyping, sorting, categorizing, etc.), preparing for the next day’s session (building new templates, organizing the room, and planning what modeling techniques to conduct).

Sequestering: If possible, sequestering a team is an excellent way to eliminate distractions. Taking people away from their normal office location prevents them from being pulled out of the workshop to fight some other fire, or get sucked into their computer to do emails, or pulled away to answer a telephone call, etc. Speaking of telephones, tell everyone to turn off their cell phones (and blackberrys – turn them off, don’t just put them on mute). Any laptop computers brought into the session must only be used for session homework or research. It might be necessary to remind everyone that the point is to focus and complete the work as quickly as possible, while drilling into as much detail as possible.

Sometimes the best way to ensure this kind of focus is to hold the workshop in an offsite location, such as a hotel or conference center. Although this type of facility is more expensive, having amenities such as food service and business center services will allow even more focus.

For the basic room setup, set the tables in a large ‘U’ formation, so that each participant can see who is speaking. The facilitator controls the front of the room, so that everyone can see what is being captured, as well as preventing side conversations (which by nature, will not otherwise be captured).

Pick a room that has a broad enough blank wall to accommodate many 3 ft. by 5 ft. flipcharts, then face the open end of the ‘U’ at this wall. Flipcharts are better than whiteboards, because they don’t get erased. Have at least two easels set up.

Pick a room that is large enough to accommodate a separate workstation for a scribe (assistant to the facilitator) – away from and behind the group, so that transcription of the flipcharts can happen with only a slight delay from real time.

Pick a room large enough to allow participants to get up and stretch their legs. This is actually more important than it seems. A large room allows participants to recharge, adding significantly to the generation of good ideas.

Ed has been building software products for more than 20 years, with particular expertise in automating economic analyses, decision support and supply-chain management processes. He is currently a sales executive with Agilis Solutions and has provided strategic technology leadership in roles such as the vice president of engineering for Egghead.com, director of technology at Nike and director of software engineering at Boeing.

Contact the author.