Daniela Elena Herlea
Knowledge Science Institute
University of Calgary
Calgary, Alberta, Canada T2N 1N4


This paper describes a demonstration of the groupware system TeamRooms as applied to Requirements Elicitation process. TeamRooms may be used as a method of distance collaboration between the knowledge engineer, the developer who elicits the information, and the domain expert, the knowledgeable end-user.


Software requirements elicitation is the process where the customers' needs in a software project are identified. This process is regarded as one of the most important parts of building a software system because during this stage it is decided precisely what will be built. Well known requirements engineering methodologies are presented in (Herlea 1996) and the degree of the user involvement in the process of requirements negotiation is discussed.

Requirements definition is an iterative process where, through reflection and experience, users become familiar with the technology and developers become familiar with the work. For example, scenarios, prototypes or mock-ups provide the opportunity for the users to "experience" the new technology and for the developers to "experience" the work practice.

Cooperation between participants in the process is quite difficult, even if they meet in a physical meeting room. The process involves a social network of people with different professional backgrounds and different views over the system that must be built. If the participants in the process are in different organizations or different cities, meetings can be costly, inconvenient and infrequent. This leads to problems of communication, which can greatly impact the quality of the elicited requirements.

Participants in Requirements Elicitation Process

In the process of requirements elicitation there are four main categories of participants:

TeamRooms as a negotiation place for requirements

Using TeamRooms, participants located in different physical locations can share a computer workspace in which the work of the entire group is presented to each member with continuous real-time update. When a user starts up the system, he or she is prompted for a user name and a password. If he or she is among the work group permitted to use the system, he or she will be connected to the TeamRooms central server.

Rooms in the collaboration workspace

Simulating a real physical meeting space, TeamRooms has many rooms. Each room contains both generic communications tools (a chat tool and a backdrop acting as a shared whiteboard) and any number of applets needed to support the group's work. The rooms in the system were created to fully support the requirements gathering. Each room has a specific purpose in the process. Figure 1 shows existing rooms in the system. The participants may enter any room in the workspace, by clicking on the name of the room and work with other users in the same room. The following rooms are meant to support the collaboration over the electronic meeting space:

* Brainstorming Room, used to record all "quick ideas" generated throughout the meeting.

* Meeting Room, used as a general working space that gathers the participants in an informal environment.

* Work Agenda Room, used to keep an agenda of the meetings, used mainly by the facilitator.

* Documentation Room, used to record the elicited requirements.

* Scenarios Room, used to build scenarios of future situations.

* "Wish List" Room, used to store the initial list of requirements.

* Future Consideration Room, used to record the intermediary results of the process.

* Final Consideration Room, used to store the final document of requirements, used by the design team in implementing the system.

* Reports Room, used to communicate and inform about the design team progress.

* "Worth Proceeding?" Room, used to "test" the prototypes against the requirements.

* Read Me Room, used to leave notes for other participants in the process.

* Personal Rooms, used to store users' own artifacts.

The requirements negotiation process is about navigating this electronic workspace. There is no defined order to navigate the rooms. Requirements elicitation is an iterative process, where the users of the system participate in meetings and discussions held in different rooms, at different times; they enter the same room many times in the process' life cycle

Collaboration over the electronic workspace

Awareness of other users in the work space is very important in simulating the real physical space. Figure 2 displays the list of users currently connected to the group's server, as well as the room each user is currently working in. This facilitates locating the other users and making contact with them. The images are still pictures or snapshots taken one per minute.

Figure 3. Facilitator's Work Agenda

The facilitator, who acts as a chairperson of the meeting, has a critical role in organizing the work of the requirements negotiation team. He or she enables effective communication, works as a project manager for the elicitation team, can have the knowledge of the room and action of each participant in the working space. He or she can use the Work Agenda Room (figure 3) to keep an agenda of the meetings, lists of activities and organize the work using the an agenda of the meetings, lists of activities and organize the work using the Outliner or the Note Organizer applets to create a hierarchical activity structure, or a Concept Map applet to identify and set priorities. Awareness widgets help the facilitator in keeping the team on the right track. Under his or her directions, the team works to meet specific objectives, as stated in the structured Activities list (figure 3). Any room has a room radar overview that provides a miniature overview of the entire room when the user changes the location of his or her view onto the workspace to suit the needs of the immediate task. The room can be larger than the participant's display. The radar shows the position of each user's viewport in the room, telepointers indicating the location of their mouse cursor. Each time when a user navigates the room and manipulates applets, the radar tracks his actions.

The organization analyst plays a key role in requirements transfer process. He or she is regarded as the "problem solver". The requirements generation process may be divided into to separate transfer processes.

Firstly, there is a transfer process between the analyst and the customer representatives, the "problem owner". The users are encouraged to navigate many rooms in generating requirements.

The Brainstorming Room may be used to record all "quick ideas" generated throughout the meeting. Users of the system can enter this room and leave notes or ideas on the whiteboard or organize concepts using the Concept Map tool. This room excludes the facilitator's role as "intermediary". Participants may have direct control over the expression of their ideas.

The Scenarios Room may be used to build scenarios of future situations which involve the system to be developed. Scenarios are meant to reflect changes the new system brings about in the organization. The analyst helps the future users of the system to envision future changes in the work environment, to analyze the organizational policies, to gain understanding of the structure of the organization and to determine the scope and boundaries of the system. They can draw on the whiteboard, create activity structures using the Outliner tool or analyze relationships between activities and data, or data and users, using the Concept Map tool. Results of discussions may be stored in files. All participants in the process may retrieve these files later. In this regard, the Future Consideration Room may be used to keep track of the intermediary results.

Figure 4 illustrates the Future Consideration Room, a "storage and future retrieval" area. Exploring the users' environment, the capture team collectively investigates the target users' organizational setting and identifies and describes what they do. They produce documents recording the shared view of the users' environment. They create objects reflecting the users' workspace and save them in a database. Records in this database are files containing information that describes these specific objects. Any user of the system may retrieve these files and discuss the list of the users' needs. Later in the process, members of the team review and evaluate information they have previously generated in order to arrive to common decisions about the value, relationships, and structure of that information. They update this "user document", according to their understanding of the user environment.

Participants can click on the records of the database - objects in the users' environment - and find out what files contain the description of those objects. The File Holder tool enables participants to exchange files in real time. Any file editor would give the participants the opportunity to read and modify the content of the files, after they discussed the changes with the others in the room.

Figure 4. A "storage and retrieval" space for the user environment's objects

The Documentation Room may be used by the analyst to record the elicited requirements. Documenting the elicitation process may be a time consuming task in usual physical meetings. Using the Documentation Room into the electronic space, the analyst records all information that participants generated, all the analysis conducted, all of the decisions reached. The analyst may decide to use the help of files to store draft plans of the requirements document. This way the documentation files have a higher quality, they are easier and more quickly produced. Validating understanding of the user environment with the system customers and end users, and formulating requirements based on this existing "picture" may be done in the general Meeting Room. Any tool may be used to manipulate the existing information. Meeting Room is used as a general working space that gathers the participants in an informal environment.

Figure 5. User requirements: list of contents

As a next step, an initial list of requirements may be proposed and stored in a generic "wish list", in the "Wish List" Room. Figure 5 shows a list of contents for a set of issues related to the requirements document. This list of contents is stored using the Outliner tool that helps in analyzing the information. It enables users to build upon a previously generated list and refine it into a hierarchical structure. In their "discussion" participants are helped by telepointers (figure 5). They can see the other's cursor location on the document. In face to face meetings, hand gestures play an important role to communicate ideas. Telepointers are examples of a fine-grained awareness of others' action in the workspace.

The final document containing the list of requirements may be stored in the Final Specification Room. It is accessed mainly by the analyst who translates the users' terminology into technical terms.

Figure 6. Versioning the Outliner tool

The system supports a rich persistence mechanism, where any number of versions of one applet's state could be saved and retrieved at a later time. Versions of the applet's contents are automatically saved into a repository when the last user in a room leaves. Selecting the Versions option from the applet's menu (figure 6), the users may browse the entire history of requirements' list.Shared documents exist beyond the meeting session. This way, team members may work on tasks either individually or in a group, their co-workers being able to find their artifacts for later use or information.

At a second stage, there is a transfer process from the organization analyst to the system designers in order to produce an initial set of prototypes. This transfer process takes place mainly in the technical domain. The design team uses the Final Specification document to build prototypes that meet the elicited requirements. Throughout the iterative process of negotiating requirements customers should validate the performance of the prototype against the "wish list" of requirements. Design team may want to release reports on their work -- using the Reports Room --, communicating and informing about their progress, between releasing the actual prototypes. This enables them to get feedback on partial results.

During the prototype evaluation phase, the system enables participants to "test" the product on their workstations. They can use the "Worth Proceeding?" Room. The analyst collects participants' feedback on prototype functions and features, prioritizes modification requests. At the same time participants are able to collaborate, to exchange opinions. The image tool may be used to bring graphical images into the meeting space and discuss around them. A design team representative may run the application on his own workstation and send screen captures to all participants, as still images. The customers of the system may see if the system meets the functional or non-functional requirements.

The system supports collaboration within the requirements negotiation group and the individual work as well. Any user can create his own room. Users create Personal Rooms for themselves, as they do with WWW home pages. These rooms may serve as a personal work space, where the user can use different tools and save his artifacts or leave notes for the group members.

In the same manner users may leave notes for the other members in the group, using the "Read me" Room. They may work part-time for this project, working on their functional roles in the organization at the same time. Based on their schedule, they can meet and work in the working space, at different times and leaving notes for the others.


Gasson, S.(1995). User involvement in decision-making in information systems development. Proceedings of IRIS 18, Gjern, Denmark, Gothenburg Studies in Informatics, Report 7, pp. 201-17.

Goguen, J.(1992). Requirements Engineering: Reconciliation of Technical and Social Issues, tech. Report, centre of requirements Lab., Cambridge, U.K.

Herlea, D.(1996). Users Involvement in Requirements Engineering Process, Proceedings of the 10th Annual Knowledge Acquisition Workshop (KAW96), Banff, Canada. Nov.6-14, 1996

Keil, M. and Carmel, E.(1995). Customer-Developer Links in Software Development, Communications of ACM, May Vol. 38 No. 5, p. 33-44

Koltzblatt, K and Beyer, H.R.(1995). Requirements Gathering: The Human Factor, Communications of ACM, Vol. 38 No. 5, p. 30-32

Macaulay, L.A.(1996). Requirements Engineering, Springer, pp. 83-112

Mumford, E., and Hensall, D.(1979). A Participative Approach to Computer Systems Design, Associated Business Press, London

Potts, C., Takahashi, K., Anton, A.I.(1994). Inquiry-Based Requirements Analysis, IEEE, March , pp. 21-40

Roseman, M. and Greenberg, S.(1995). TeamRooms: Network Places for Collaboration

Roseman, M. and Greenberg, S.(1996, in press). Building Real Time Groupware with GroupKit, a Groupware Toolkit, ACM TOCHI