Consensus Requirements: Low- and High-Tech Methods for Discerning System Requirements from Groups of Osers Randolph G. Bias IBM Corporation IBM Corporation 11400 Burnet Road Austin. TX 78758 Southbury. CT 06488 Thomas M. Lanzetta 150 Kettletown Rd. Jack Scanlon IBM Corporation zyxwvutsrq 500 Park Offices Drive Research Triangle Park. NC 27709 zyxwvut Abstract Two methods of gathering system requirements from groups of users are discussed. One method can be used anywhere, while the other requires some specific computer hardware and software. This latter, high-tech method has built into it a technique for prioritizing identified requirements. Also presented is an additional low-tech technique for gaining group consensus that can be used in any requirements-gathering setting. Introduction The fundamental step in the development of usable systems is gaining an understcanding of the user requirements. The "user requirements" domain can be represented by the questions: Who will the users be? What tasks will they zyxwvutsrq be carrying out with the system? How can the system best support these tasks? Gathering and refining user requirements is. ideally, an ongoing, iterative process throughout the product development cycle. This is true because. as technology advances. users' expectations and needs can change during the course of product development. Plus as product development progresses. and more and more concrete "nfestations of the product design are available (e.g.. user interface prototypes), these can zyxwvu he employed zyxwvutsrq as part of the requirements gathering process. and users can offer their reactions to these specific artifacts. In rare cases. the population of potential system users is small (say. users of space vehicles) or hoinogeneous (say. users of pacifiers). and user requirements can be gleluied confidcritly from a small sample of users. More often. the population of potenlial system users is heterogeneous. and zyxwvutsr so many users' viewpoints arc needed in order to caplure the full range of user requirements. In the interest of efficiency, then, it becomes necessary to ask groups of representative users about their system requirements. In this paper we explore the gathering of system requirements from groups of users. We describe one low-tech method (the use of focus groups) and one high-tech method (based on the use of Decision Support Centers. or DSCs) we have employed. Further, we discuss two methods used to discern the consensus of groups. Here again, we present a low- and a high-tech method. The high-tech method is part of the DSC-based method. and involves anonymous, real-time ranking of identified requirements. The low- tech method. involving the expenditure of poker chips, is generalizable to any setting of user groups. Focus Groups Nearly four decades old, focus groups represent an accepted tool used by marketing, advertising, communications. and organizational researchers. Focus groups, stemming from the "focused interview," involve a (usually homogeneous) group of people, a specific question (or set of questions), and a facilitator. To illustrate. we will highlight one focus group we used. to collect system requirements for upcoming LAN software products. We sought the help of IBM Marketing Representatives, in the field, in identifying customers who were representative of the projected user population. We found this customer set to be eager participants because. as likely later users, they foresaw the value of steering our product development in a particular direction. Focus groups are necessarily qualitative tools. Following accepted guidelines of focus group design (cf.. [l]). we used a manageable number of local participants ( 12. representing six different companies), all with the same job responsibilities. We employed a specific set of related questions about the function and features they would expect to need and want in future LAN software products they would purchase. We limited discussion to a half day. total, and we encouraged all to participate in the discussion. We believe we discovered, in four hours, many product requirements, including some we may not have discovered in more costly. time-consuming individual interviews. or even in a survey of a larger customer snmple. Further, via the synergy of the group discussion. we felt comfortable with our sense of the zy 191