Human behavior is an important yet often overlooked aspect of use case development. The personal interactions between the writers can affect the resulting use cases as much as the techniques used to identify and write them.

Unfortunately, many development organizations seem oblivious to the importance that team composition has on creating good use cases. Instead, they treat the effort as a necessary evil that anyone, experienced or otherwise, can do. Management may not understand or support the use case concept, or developers themselves might consider writing use cases to be busy work—an unnecessary prerequisite to the “real work” of writing code. Even when an organization embraces use cases enthusiastically, it can fail to dedicate the resources necessary to do a good job or fail to control the number of people involved.

Team size is the most critical factor influencing the quality of the use cases. Not only is it inefficient to have numerous people defining the system, but also the compromises made to align numerous and competing system visions may lead to unsatisfactory results. Each use case writing team should be a SmallWritingTeam (p. 31), where the number of writers on any use case is limited to two or three people, to avoid inefficiencies or design by committee.

While you want to keep the use case writing team small, you still want to involve as many stakeholders in the writing process as possible, to ensure that the use cases meet all of your stakeholders' needs. However, talking with external customers can present an enormous challenge to a project. Some companies don't want outsiders to access their rank-and-file employees, and even internal organizational boundaries can get in the way, to the detriment of the final product. ParticipatingAudience (p. 35) resolves the competing issues of managing team size while involving all of the target audience in the use case development process.

Team composition is another factor influencing the quality of use cases. An unbalanced team, consisting of similar, like-minded individuals, will examine a system from only one point of view, frequently that of the software developers rather than that of the users. Unbalanced teams are often inefficient and can wander in search of an elusive goal. Including a domain expert or expert user can keep the team on track, but it can also inhibit a team from original thinking when the expert is overpoweringly dominant. Effective teams are BalancedTeams (p. 39), containing a complementary mixture of skills, expertise, and even personalities, where each participant provides a distinct view of the system being modeled.

A skilled team of men and women workers complete assembly on the interior of a fuselage section for a new B-17F (Flying Fortress) bomber, Seattle, Washington

You have a SharedClearVision (p. 80) for a system and are organizing teams to write use cases.

Musicians have a saying, “Two guitarists, three songs,” implying that any time two guitarists play guitars together, they somehow end up simultaneously playing three different songs. Musicians have a reputation for being self-absorbed, and often bicker over whose song to play, or how to play it. The more members in the group, the more likely these disagreements, as the musicians compete to “do their thing.” Many groups limit band size to avoid these problems.

You can experience similar problems when writing use cases, because everyone writing them wants to contribute their two cents' worth and be heard.

Use cases require the views and expertise of diverse groups. A set of use cases must capture the domain knowledge and experience of the people who will use the system, yet be precise enough for the development team to use as an input for system design. Large systems can be especially difficult to describe, because they can support many different kinds of users performing many different kinds of activities. In some situations, the number of people needed to contribute information and review the use cases can grow as large as 50 people.

Getting a large group of people together is difficult. The more people that must meet, the more difficult it is to find an agreeable meeting time. People who work on other projects or work in other geographic locations can't just pop down the hall for a quick discussion. Meeting with external customers often presents the biggest challenge, because their company may discourage such meetings or forbid them outright.

In theory, the more people you have working on use cases, the faster you can finish writing them. Throwing a lot of people at a problem is a common reaction to meeting tight schedule pressure. It is especially tempting with use cases because many people think that writing them is easy, and that anyone can do them. This approach might work when there is more work than people, but can make things much worse when a team is already adequately staffed.

Teams that are too large become inefficient. Teams having too many members tend to bog down over minor matters. Overstaffing a team can waste its members' time by minimizing their participation and giving them too little to do. As a result, the team either loses interest and slacks off, or members tend to overproduce, creating an artifact with too much detail and redundant or unnecessary information.

Large teams can lead to design by committee and feature bloat. Large teams are especially vulnerable to design by committee, where the project assumes a life of its own. “Groupthink” prevails, causing the team to lose focus and stray from the vision, resulting in a model bearing little resemblance to the intended system. Members add all kinds of unnecessary features, resulting in a model that fulfills all of the team members' desires without satisfying anyone.

Therefore:

The fewer the number of people who are responsible for the creation of use cases, the better. It is easier for a small team to meet, communicate, and reach a consensus. A team of two or three people is small enough to keep out of each other's way, yet broad enough to write meaningful use cases. You can use several SmallWritingTeams; however, you should appoint one person as the use case architect and give him or her the responsibility for maintaining a consistent vision through all the use cases.

At the same time, try to represent different viewpoints on each team. Create BalancedTeams (p. 39), using people with different backgrounds, skills, and personalities so that the teams don't fall into the rut of looking at the use cases the same way. Diversity is especially important for projects aimed at a widespread audience, because it is likely that the various users will use the product in many different ways.

You can maximize participation, while avoiding large teams, by using ParticipatingAudience (p. 35) and TwoTierReviews to involve more people in the process. These two patterns describe methods for consulting many different people without cluttering the use case writing process. These practices allow different interest groups to focus on the details they consider important, while shielding them from details raised by other stakeholders with different interests.

Examples

Facilitating Large Groups: No Design without Representation

In his article “Use Case Blue,” Andy Kraus (1996) describes the effort involved in facilitating a large group that was collecting use cases. He recounts six weeks of sessions, using an average of 15 to 20 participants, eliciting requirements for replacing the Automated Regional Justice Information System (ARJIS). It required the services of various people from 23 police departments and 16 individual contributors. While smaller teams might have been more desirable, business conditions and the complexity of the system forced them to use the large-group approach. During the course of their endeavor, they held meetings with 8 to 25 people in attendance. While fewer people would have been more manageable, Andy claims, “Only by having representation of the diverse ARJIS membership in the room at the same time could we flush out nuances to the requirements caused by the differing philosophies and operating procedures among the members.” But such an effort took its toll, as Andy also claimed that they encountered all of the problems that they were told to expect from having such a large group. For example, “Without knowing in advance what the real system actors were, it was impossible for us to predict which users would need to come to which sessions.” They solved the problem by holding a kickoff planning session to derive a schedule for future sessions.

This project was successful, but required a lot of effort to manage. However, some groups find that this type of approach requires too much energy to be effective.

Large Groups and Frequent Checkpoints

We know an expert in the field who was involved in a similar situation with a company that had arranged for an expert facilitator and 14 people (10 field representatives and 4 business analysts) to write use cases for an extended period of time, eventually yielding around three dozen use cases. Things started out slowly, as the group had to listen to people express their opinions one at a time.

Fortunately, the group had the flexibility to adjust their procedure as needed. They devised a branch-and-join process, using their group meetings for brainstorming sessions and administrative issues. They divided into small groups, based on who was best qualified to work on what use case. If only one person was qualified for a particular topic, he got someone to help. Once a group finished a draft of a use case, they passed it around for review, with the others penciling their comments on the same sheet. These reviews were especially effective because they localized all of the reviewers' comments to one sheet of paper, keeping the reviewers aware of the previous reviewer's thoughts, and making it easier to organize and apply their suggestions to the use cases once the review was complete.

The facilitator was somewhat uncomfortable with this distributed approach. However, the group consistently elected to do the work in small teams, as they found it much easier and far more efficient. Moreover, they greatly increased their throughput and decreased the duration of the effort by working on seven use cases at a time rather than one.

Armistice Day gathering in Lititz, Pennsylvania. The audience bow their heads in tribute to boys in the service.

You are a SmallWritingTeam (p. 31) creating use cases.

Buying stock in a company makes you a part owner, and entitles you to attend stockholder meetings and to vote on company issues. The company's board of directors is legally required to represent their shareholders' best interest, which can be difficult because companies may have millions of stockholders. It is impossible for the board to listen to everyone. To alleviate this problem, companies allow their stockholders to vote by proxy, where the stockholders can assign their right to vote to someone else. This way, one person can represent hundreds or even thousands of people at the meeting, keeping it small. However, stockholders who disagree with the direction the company is going can attend the meeting and voice their sentiments.

Writing use cases is similar because it is not always possible or practical to involve everyone you need every step of the way. Stakeholder input is invaluable because your goal is to develop a system that pleases your stakeholders, and they often know far more about their needs than you can possibly ever know. To model the system effectively, you must discover what they need, know, and want, and allow them to have a voice in the process. The true art is to know when and how to do this without having to involve them in every step along the way.

Many different groups have a vested interest in a set of use cases. Developers are not the only people depending on a set of use cases. Large development organizations consist of many different groups with various responsibilities, styles, and needs. Each of these groups relies on the same use cases to complete their portion of the product development process. Each one of these groups has its own use for the use cases and looks at the use cases differently.

If the customers don't like it, they won't buy it. Ultimately, customers are the final authority on your product, because they are the ones who have to pay for it. While you may think that your product is fabulous, they may hate it. They don't care how hard it was for you to build, or how much time you spent building it. They just care that it does what they want. If your product doesn't meet their needs, then it is a failure.

It is usually impractical to include your entire target audience in the use case development process. Several factors make it difficult to talk to everyone interested in your product. Large projects require the services of far more people than you can consult. Often, stakeholders reside in different geographical areas, making them extremely difficult to locate or talk with. Other companies may not like you talking with their employees, or your own company may want to keep your project under wraps for competitive reasons. In the case of off-the-shelf products, you don't really know who your stakeholders are, and can only guess.

Development organizations don't adequately represent end users. A common problem in software development is that the developers often assume that the users share their perspective of the system. Unfortunately, developers are often isolated from their customers, and don't really understand their needs. As a result, the systems that they develop are often hard for everyday users to use because they target the wrong audience. For example, a group of high-powered developers might prefer to use an interface requiring regular expressions as input. However, most people find regular expressions to be too abstract, and they would become extremely frustrated after trying to use this interface. Even other highly skilled users might not appreciate the more difficult interface, because they want an easy-to-use product that doesn't require much thought or a steep learning curve.

Therefore:

Include your customers in the use case development process from the start. If you are developing use cases as an individual effort, consult with your customers often and seek their input. If working as a team, then try to include a customer representative as a team member when you don't have a clear understanding of the product. His or her presence provides you with a wonderful opportunity to learn firsthand what it is that the customer really wants.

This kind of relationship makes it easier for you to keep your customers aware of any potential issues that may arise, and obtain their assistance immediately, rather than proceed through a time-consuming formal process. Most important, cooperation can foster a spirit of understanding as well as give customers a sense of ownership in the use cases, improving the chances that they will accept the final product.

While customers are the most important stakeholders, they are not the only ones. Internal groups such as quality assurance and documentation often depend on your use cases, and it is important that you consult with them as well. Treat all stakeholders as customers, and consider including internal stakeholders on your use case development teams when they can provide valuable insight into the product.

Try to represent the users' viewpoint when they are unavailable. Sometimes the users are inaccessible. Many organizations will not allow outside companies access to their employees, and even internal departmental boundaries can limit access. The reasons may be valid or frivolous, but don't fret or give up when you can't talk directly to the users. Instead, use other techniques to elicit this information. The book Software for Use (Constantine and Lockwood 1999) describes many practical techniques for obtaining user information without directly contacting users. These techniques include utilizing user surrogates such as domain experts and trainers, consulting with members of nonuser groups such as marketing or technical support, or relying on indirect sources such as manuals, records, or even questionnaires. While not as straightforward as direct user participation, these techniques offer a valid alternative.

Reviews, especially well structured TwoTierReviews (p. 64) that make good use of the customers' time, provide a good vehicle for sharing use cases with customers, and can even allow you access to those customers and users that you can't see otherwise.

Examples

Soliciting customer input has been a key part of requirements elicitation for years. Yet surprisingly, some teams don't do it. We know of one team that focused entirely on some complex requirement specifications, didn't talk to the end users, and ended up writing over 500 use cases before they threw in the towel. The project was shelved.

The Job Flow Engine

We find it amazing that people don't take the time to investigate the users' side of a project, because this technique is so helpful. One of the authors was part of a small project team developing a job flow engine to control the execution of some specialized programs across a set of distributed workstations. The team interviewed many potential users, discovered what they needed, and documented as use cases their various processes, both manual and automated. The resulting product was successful because it provided exactly the needed services, and allowed the users to automate correctly some complicated time-consuming processes. Without the use cases, the result wouldn't have been nearly so positive.

Making Movies

It should come as no surprise that soliciting customer input is a common practice in many industries, and was well established long before the first modern computer.

Customer consultation has been part of the movie-making process for decades. In the 1930s, MGM sponsored the Marx Brothers on cross-country vaudeville tours prior to filming A Night at the Opera (1935) and A Day at the Races (1937), so that they could use the audience as proving grounds for much of their material. If a joke bombed, they either changed it until it worked or they dropped it. They fine-tuned those lines that were somewhat funny, and kept those skits that brought down the house. Consequently, these two films rank among their all-time best. However, MGM stopped sponsoring these tours after A Day at the Races, and the quality of the brothers' subsequent films dropped significantly (Marx 1972, pp. 174–75).

To the Moon

In some instances, the SmallWritingTeam (p. 31) absolutely depends upon the ParticipatingAudience. For example, consider a trip to the moon. The Apollo Saturn V spacecraft contained over two million separate working systems, yet severe weight and fuel constraints prevented NASA from sending more than three people on the spacecraft. Obviously, there was no way that three people could comprehend that many systems, let alone be proficient enough to troubleshoot them when problems arose. To get around this problem, NASA assembled a large group of experts, simulators, computers, and communications equipment to assist the flight from the ground. Likewise, some use cases can be so complex that they cannot be written without vital participation from the audience.

Tightrope performers at a 4-H Club fair, Cimarron, Kansas

You are organizing SmallWritingTeams (p. 31) to write use cases.

A musical quartet consists of four people singing or playing different parts that blend together to create a unified sound. You would defeat the purpose of a quartet if you chose four singers to sing the same part. Instead, you would want singers with different ranges who could harmonize together, because it is this arrangement that gives a quartet its distinct and rich sound.

Writing meaningful use cases requires the creative input of several people having different viewpoints; otherwise, the results tend to be flat and narrowly focused. A homogeneous team often fails to appreciate the other stakeholders' needs, and produces inadequate use cases as a result.

Groups of individuals sharing a common technical background tend to focus on the same limited issues. This tendency is not surprising, as each member is trained to consider the same issues and use the same techniques to solve a problem. While their approach provides satisfactory solutions, it doesn't encourage the out-of-the-box thinking needed at this stage of product development. Although the members of this group are usually more specialized than most of their clientele, they often fail to think about the system from their users' viewpoint, which can be dangerous for a number of reasons.

Each profession uses its own specialized vocabulary, which people outside of that profession do not understand. Documents full of one profession's jargon can be very confusing for people with other backgrounds. Even if outsiders understand the generalities of this terminology, they usually fail to grasp its subtle implications and can overlook or misinterpret its key points.

Teams need different expertise at different moments. Teams often need subject matter experts at the start of a new project. Later, as the team members become more familiar with the subject, they need experts less, but they may need to know more about other technical areas as the project evolves to address the needs of new and different users.

Good teams are balanced so that each team member's specialties compensate for some other team member's weakness. Teams often fail without this balance. For example, athletic teams are highly specialized. Consider a championship baseball team, which usually includes great pitchers, solid hitters, and players with good defensive skills. Very few, if any, of the pitchers are expected to be good hitters, as their job is to challenge the opposing team's players and prevent them from hitting the ball. It is the job of the other eight players on the field to back up the pitcher by making good defensive plays and to score runs. Teams that are strong in all three of these areas routinely beat mediocre teams with one or two exceptional players.

Similarly, a team comprising members with complementary skills is better suited for defining use cases that will support many different user types, because they are more likely to address more issues. This balance is especially critical in today's world with its explosive technical growth, where no one individual can even begin to keep up with all the latest technologies. Software development improves as we improve people's personal skills and improve the team's collaboration.

Therefore:

Ignore the tendency to use only your best programmers or software engineers for writing all of the use cases. While domain experts and expert users can be essential for the more critical use cases, be careful about putting them on a team that they will dominate. Instead, use a healthy mix of articulate people with varying backgrounds and viewpoints. If you are writing use cases for several different organizations, try to represent the more important ones on some of your teams, especially when most of your potential system's users are nontechnical, and use ParticipatingAudience (p. 35) to fill in the gaps. If your product has significant legal issues, consider involving someone from your legal department, and so forth. Try to include people who think in low-level details as well as those who function at the big-picture level. Look for abstract thinkers and problem solvers, artists and technicians. The team must be diverse enough to provide combined field, corporate, and technical viewpoints.

Try to include people who are good at maintaining focus. They will know when to quit, to prevent feature creep and help the SmallWritingTeam avoid diving into bottomless pits. Otherwise, the more detail oriented people will inevitably write low-level use cases that attempt to resolve the system's technical issues rather than describe its behavior and how people will likely use it.

Using small, balanced writing teams and controlling audience participation is an easy way to improve the quality of your use cases. While not difficult, organizing such teams does require forethought, and it requires balancing several competing forces involving team size, audience involvement, and skills. There is no one perfect mix that always works; it is up to each development organization to balance these patterns to determine what team arrangements will work best with their particular circumstances.

We cannot say enough about the importance of involving your customers in the use case development process. One of the most significant benefits of use cases is that they model how the system delivers measurable value to its users. Being unable to talk to the customer, whatever the reason, increases your risk, so you should find some other way to gather this information. Larry Constantine (Constantine and Lockwood 1999) offers excellent advice on dealing with these kinds of circumstances in his book Software for Use.

Though the three patterns we just described complement each other well, they do create some tension with ParticipatingAudience (p. 35) and BalancedTeam (p. 39) trying to enlarge the group and SmallWritingTeam (p. 31) trying to shrink it. However, the intention behind SmallWritingTeam is to keep the process manageable. ParticipatingAudience provides a mechanism for many other people to contribute to the use case process without overwhelming it, and therefore it avoids the problems of excessively large teams. ParticipatingAudience also helps a group become a BalancedTeam by involving people with different backgrounds and viewpoints to influence the use cases without increasing the development team's size. The diversity these two patterns provide helps steer the teams toward using a common vocabulary, rather than a discipline-specific one.

To illustrate these points, consider what kinds of teams would be best suited for writing use cases for a project involving pharmaceutical manufacturing. These kinds of systems must meet exacting standards for purity and precision, as well as rigorous legal and accounting requirements. A pharmaceutical company manufacturing controlled substances must be able to account for 100 percent of the controlled substances they use, or they face unwanted visits from the Drug Enforcement Administration.

First, you would want to set up SmallWritingTeams, because you want the writers to exercise tight control over their use cases, and write with a high degree of precision. But you also need a high degree of ParticipatingAudience, probably more than usual, to verify that the resulting product meets all required standards and complies with the law. In this case, BalancedTeam has the greatest impact on the results because of the complexity of the problem and the number of technologies involved. Most likely, you would want to staff your teams with combinations of software developers, pharmacists, biochemists, and even lawyers, depending on the needs of the various use cases.

The biggest benefit of using BalancedTeam in this instance is that it forces the writers to use a common, understandable terminology in their use cases. Commonality is especially important in this situation because each of the disciplines involved in developing this product has its own exclusive and highly specialized vocabulary. ParticipatingAudience helps counterbalance this problem to some degree, but even then, one audience will likely have trouble with another's terminology. Software developers talk about stacks, queues, XML, Bridges and Visitors, while the biochemists describe chemical reactions such as “dehydrohalogenation” and use complicated chemical formulas. Lawyers also have a reputation for obtuse writing; imagine reading use cases like “the Line Supervisor actor shall henceforth be known as the party of the third part . . .”.

It's important, but team organization is only a small part of the picture. A team also needs to follow a good process to be able to identify and write quality use cases, which is the subject of the next chapter.