Too often, teams begin working on a project without having discussed just how they will collaborate. The team members make assumptions about the activities involved and how the participants will interact with each other. People have different communication styles, various understandings of the problem, diverse perceptions about just what "requirements" are, and so on. Many groups don't explicitly agree upon how they will make the myriad decisions that arise in the course of every project. Neglecting these issues can lead to mismatched expectations, ineffective collaboration, and hard feelings. It's well worth taking some time at the outset to discuss how the team will operate.

Janet begins by promising Paul that this analyst team will use more effective approaches to understanding his requirements for this application. Furthermore, we'll document what we learn in a way that serves as a suitable foundation for the development work that will follow. Janet also sets expectations for what we need from Paul if this collaborative effort is to succeed. Notwithstanding his previous frustrating experiences, the fact is that we have to start over with the process of exploring requirements. So, we're going to need time from Paul and perhaps his colleagues so that we can understand just what kind of a system would meet his needs. Paul reluctantly agrees to play along.

Paul is not the only stakeholder for the system, and the members of the Health and Safety Department won't be its sole users. We apply the concept of user classes to identify other groups of users who will have largely different sets of needs. Members of different user classes might need different functions or features, have various educational or skill levels, work in different locations, or have other distinguishing characteristics.

Based on input from Paul and the analyst team's understanding of Contoso's research environment, we identify the following four major user classes:

These user classes have certain needs in common. For example, both chemists and the chemical stockroom staff will place requests for new chemicals periodically and dispose of chemicals. However, each user class also has a distinct set of requirements for services they expect from the CTS.

Our next analysis challenge is to find the right individuals with whom to explore these needs. We must then consolidate those needs into a cohesive software requirements specification. This requirements exploration will include resolving requirement conflicts and setting priorities to reach the best balance of timely and cost-effective delivery of a useful—and usable—system.

In 1986, my small development group at Contoso realized we had to learn how to interact more closely with our users so that we could properly meet their software needs. We conceived the project role of product champion, a key user representative who works closely with the requirements analyst. The product champion serves as the literal voice of the customer for a particular user class. Product champions typically are experienced users and subject matter experts in their domain.

Our next step on the CTS project, therefore, is to identify champions for the four user classes. My previous group had created a list of possible product champion activities that the CTS analysts can present to each candidate champion so that they understand what they're getting into. Negotiating the exact responsibilities that each champion is willing to accept is an important part of crafting that vital collaborative customer-development partnership.

As the key manager on the spot and a hands-on user of the future system, Paul is the obvious product champion for the Health and Safety Department. Our project manager and lead analyst, Janet, will work with Paul to define his requirements. A member of the Purchasing Department named Jonathan is willing to present requirements for the CTS from his community's perspective. Our second analyst, Devon, agrees to work with Jonathan on Purchasing's requirements. Dana manages the chemical stockroom. She's the natural product champion for that user class, although she'll obtain additional input from the members of her staff who perform the day-to-day operations. Janet will do double-duty to lead requirements elicitation with Dana.

Finding a product champion for the chemist group is more challenging. Dana tries to help. "Before I became the chemical stockroom manager, I was a laboratory chemist," she tells us. "Therefore, you don't need to talk to any other chemists about their requirements. I can tell you everything you need to know."

Although Dana is sincere and means well, she is wrong. And it's really hard to convince her that she's wrong. The first problem is that she's no longer a member of the chemist user class. She is literally the best person in the world to describe the needs of the chemical stockroom staff. She isn't, however, a practicing chemist anymore. I learned long ago that it is best to have actual members of the user class participate in requirements development, rather than using surrogates or former members of that user class. In some cases, particularly on commercial product development projects, you don't have direct access to appropriate user representatives, so you must use surrogates, such as product managers or marketing staff. That isn't a problem for this internal corporate project, where we can arrange to work with actual users.

The second concern we have with Dana's offer is that she has a narrow and parochial view of the chemists' requirements. She is also very adamant about her opinions on such matters, and she is prone to crying when discussions get a bit tense or her opinions are not immediately accepted. (Dana isn't all that much fun to work with.) Relying on Dana's strong opinions alone would not provide the rich understanding of chemist needs that we need to get. So, we politely decline Dana's offer and go searching for a suitable chemist representative.

We find one! A highly experienced and respected chemist named Sarah offers to serve as the product champion. Although she isn't terribly sophisticated when it comes to computers, Sarah recognizes the value that the Chemical Tracking System will provide to her and her colleagues. It's common that the people best suited as representatives for their user class are already overextended in their own work and are reluctant to commit much time to requirements-related activities. We really luck out with Sarah, though. She promises to create time in her busy schedule for requirements elicitation discussions and review sessions. Since my own educational background is in chemistry, I will be the analyst working with Sarah to understand the requirements that chemists have for CTS.

We realize it's just not realistic to expect even an experienced chemist like Sarah to know the full spectrum of requirements for all the chemists at Contoso. She needs some help. We establish a backup team of five additional chemists drawn from various departments across the company. They will have many requirements in common, but these representatives know about specific needs that pertain to the kinds of chemical work going on in their own areas.

We don't expect Sarah alone to produce the chemists' requirements, or even Sarah plus the backup team. Each of our product champions is responsible for interacting with other members of his or her user class to collect ideas and get feedback on proposals. The product champion also will resolve requirements conflicts that arise between individual members of the user class, which makes the analysts' lives much easier. So, in this representative engagement model, the primary pipelines through which requirements flow are from each product champion to the corresponding analyst, with extensive interactions behind the scenes between the champion and other users. The analyst will need to work with the various product champions to resolve requirements conflicts that arise between the user classes.

Now we're ready to roll. Table 19-1 shows the complete cast of key participants in the requirements elicitation activities we are about to launch. But exactly how should we proceed?