Computer supported collaborative requirements negotiation

 
Daniela Herlea
Department of Computer Science
University of Calgary,
Calgary, Alberta, Canada T2N 1N4
danah@cpsc.ucalgary.ca
 
Abstract
This paper presents an initial study of using computer-based collaborative tools to support the distributed requirements engineering (RE) process. The study consisted of the design and informal evaluation of a virtual requirements negotiation environment. This environment was built using a particular groupware system called TeamWave Workplace and a particular requirements engineering model of interaction called LoReN (Locales for Requirements Engineering). The study aimed at identifying the extent to which the groupware tools in TeamWave support the process within LoReN. Aspects in which the collaborative tools in TeamWave support the negotiation of requirements and lessons learned from this study are discussed. 1. INTRODUCTION
While the naïve view of RE is that requirements are immutable facts about a situation that exist a priori and independent of the client’s perception (Brooks and Jones, 1996), our view is that requirements gathering goes beyond the one-way transfer of information from clients to designers. Specification of requirements is considered a knowledge acquisition task (Easterbrook, 1991) and we regard requirements as a negotiated product, socially constructed through a collaborative requirements negotiation process. The problem is that stakeholders in the process – including designers and clients - can work in environments that cross organizational and national boundaries, where the RE team members find themselves isolated from one another by distance and by time. One solution to this problem is to provide the networked team with groupware designed to support a distributed RE process (Herlea and Greenberg, 1998).

The research reported in this paper addresses the collaborative work in requirements engineering by discussing the interactional needs of the cooperating group. It is argued that solutions to interactional problems can be sought by building an understanding of the interaction involved in such a process. Initial studies of using groupware technology to support the requirements negotiation process with an emphasis on distance collaboration are then presented and discussed.

First, LoReN (Herlea, 1997), a model of interaction within RE meetings is presented. This model is then used to design an informal evaluation of a virtual requirements engineering environment. An investigation of the support offered to activities identified as major problems in RE (Potts, 1996), including domain knowledge acquisition and traceability is presented. From a negotiative perspective, the issue that arises here is that the participants in the process have multiple perspectives during the process (Easterbrook, 1991). Consequently, we focused on the ability of team members to express, discuss and negotiate multiple perspectives during requirements acquisition and traceability.

2. THE LOREN MODEL
A central notion in the research described has been that of a locale, drawn from the work of sociologist Giddens (1984), and used here to deconstruct the interaction within requirements engineering meetings. Locales refer to the ‘use of space to provide the settings of interaction, the settings of interaction in turn being essential to specifying its contextuality’ (p. 118). Hence, the reason of using the term locale is to emphasize the properties of settings and move the focus away from the physical characteristics of the space itself. We recognize requirements engineering meetings as locales for the requirements specification interaction. The individuals in such meetings form a social network and the use of the artifacts is part of, and provides affordances for, their interaction (Herlea, Shaw and Gaines, 1998). The study done by Bright, Maiden and Sutcliffe (1996) also reports on the affordances of the artifacts involved in a typical requirements engineering meeting.

However, there is more in a physical component of locale that affords collaboration: we relatively unconsciously use the inherent properties of space, such as body presence, movement and sensory mechanisms. These properties provide awareness of others in the shared workspace, mutuality being essential for achieving shared understanding in RE processes. As Giddens notes however, it is an error to consider locales just in terms of their physical properties; the human action is framed not only by spaces, but by the patterns of understandings, associations and expectations with which they are infused. It is the setting for the interaction and not the space itself that frames appropriate behavior in a locale. For example, a ‘house’ is something that keeps out the wind and the rain, but it becomes a ‘home’ where we live by its utilization in human activity.

The fundamental challenge in requirements engineering is the creation of a locale for the requirements specification interaction as part of the requirements engineering task (Herlea, Shaw and Gaines, 1998). In standard methodologies for requirements engineering, structured meetings (e.g. JAD sessions) facilitate this by arranging the artifacts in the room, by bringing a facilitator in the meeting and by establishing well-defined roles for the participants. All this can be seen as facilitating the creation of a locale for system specification which is then built through interactions involving the creation of artifacts, the development of understandings, and the learning of behaviors appropriate to, and supported by, the locale.
A RE locale is recognized in the framework developed by the NATURE project (Pohl, 1993). The interaction of such a process is regarded as taking place in a locale built within its three dimensional space (Herlea, Shaw and Gaines, 1998). In Nature, viewpoints (Jarke, 1996) are defined as artifacts produced as part of the social requirements engineering process. Here, building the locale means in fact the creation of a setting in which the resolution of these viewpoints enables the determination of conflicts as well as the development of shared understanding, key factors in RE from a social and cognitive perspective (Easterbrook, 1991).

LoReN is a model of interaction in requirements engineering process and is illustrated in figure 1. This model regards the participants in the requirements engineering process as forming a team with the collective goal of specifying requirements and that this team’s needs impose a structuring over the global process. The model is based on the assumption that the requirements engineering process can be defined in terms of four main activities: the requirements discovery, refinement, worldviews analysis and the validation of requirements, as illustrated in Figure 1. These parts of the process are drawn into sharper focus for its members at one moment in time. What is the focus becomes a locale for their work. Therefore, the model defines four locales corresponding to the interaction of these four activities. The interaction within and between these locales is the essence of the LoReN model.

The LoReN model stresses the existence of multiple perspectives during the requirements negotiation process. In RE research, a perspective is regarded as an explicit description of the world from a particular angle, and there is a relationship between perspectives and roles (Easterbrook, 1991). The complexity and interdependencies of processes within the requirements negotiation involve the team members in interaction of multiple locales. The model defines varying levels of membership and involvement into these multiple locales, according to the participants' roles in the process. Individuals get their work done by becoming members with a high level of involvement in a particular locale. Meantime, the individuals are involved in other social worlds (e.g. organization, family), with different levels of involvement. Taking into account the participation in and the participants' own view over multiples locales helps in understanding the emergence of multiple perspectives over the system.

This model has been used in evaluating groupware for support of the requirements negotiation process, as described in the following sections.
 

Figure 1. The four stages of LoReN model

3. GROUPWARE TOOLS IN SUPPORTING REQUIREMENTS ENGINEERING
This paper reports on initial studies of the support groupware tools give to the requirements negotiation process. While groupware for distributed collaboration is well studied in the area of Computer Supported Cooperative Work (CSCW), little attention has been given to how it can support the RE process. Still, a number of design factors are considered highly relevant to requirements negotiation (Herlea and Greenberg, 1998). They include support for: synchronous and asynchronous collaboration, telepresence and teledata. A short description of these requirements is given in the following paragraphs.

Synchronous collaboration lets distance separated people work together at the same time. Real-time communication and access to the shared workspace is important in RE, since conversation is the main vehicle for gathering, clarifying and validating the knowledge about requirements (Easterbrook, 1991).

Asynchronous collaboration is especially important when groups are distributed across time zones and when real time meetings are hard to schedule. In RE, team members can construct or analyze requirements individually and contribute them to the collective activity of the group for later discussion. Asynchronous collaboration is also important for group coordination, including setting up meetings, sending out reminders, tracking schedules, and so on.

Telepresence is defined as a "way of giving distributed participants the feeling that they are in the same meeting room" (Ellis, Gibbs and Rein, 1991). In RE, a sense of presence is necessary to help participants mediate and coordinate their real time discussions, and to achieve a common understanding of the work process (Macaulay, 1996).

Teledata is defined as a "way of having participants bring into the meeting the materials and on going work they wish to share with others" (Ellis et al., 1991). In RE, issues of concern include the ability to generate and share requirements representations such as text and graphics, to facilitate the input, storage, access and retrieval of information about requirements (e.g. results of brainstorming, lists of important items and decisions).

In our study, we chose TeamWave (Greenberg and Roseman, 1998) as a groupware system that meets these design requirements. It implements a room-based metaphor and combines the richness of specialized real-time groupware applications with a virtual environment that provides a persistent working and meeting space. A team can form a customized environment by creating rooms, by shaping their contents, and by mediating access to items by particular group members. Because it is cross platform (it runs on PC, Unix and Mac machines), it can serve teams that use different technologies. The system is suitable for both synchronous and asynchronous collaboration and allows the team members to work either co-located or at a distance. A full description of the system is given in (Greenberg and Roseman, 1998).

The following sections discuss an informal evaluation of TeamWave in supporting the requirements negotiation process, its setting, tasks and results. LoReN, as a particular model of interaction in requirements engineering, has been used in designing the study. The support TeamWave gives to particular activities within LoReN is addressed and limitations and lessons learned from this evaluation are discussed throughout the remaining of the paper.

3.1 The setting
The study has been conducted in the Knowledge Science Institute laboratory at the University of Calgary. One-hour sessions involved two participants at a time, performing two tasks specific to the requirements negotiation process. The participants collaborated synchronously and asynchronously using TeamWave, on Sun workstations. An audio link was assumed to be in place, due to the participants’ proximity. One session has been run over distance, between Calgary and Germany and it took about 2 hours. It deserves more attention, as it reveals interesting aspects when using TeamWave for collaboration over distance, without an audio link in place. The participants were given a questionnaire after each session. The next sections present the participants and the tasks they performed.

3.2 The participants
The study involved a number of 11 participants with work experience in the software industry. While all of the participants had the theoretical background, six had also the experience of being involved (to some degree) in requirements definition processes. In this study, the participants will be referred to using letters (A, B, etc.) and those with some experience in the requirements definition process will be referred to using letters annotated with a star (A*, B*, etc.). Information about the participants' gender and age can be found in Herlea (1997).

3.3 The tasks
TeamWave rooms can be customized ahead of time to support particular processes. Figure 2 illustrates the main view of the system – Planner Room - with which the participants were presented in the study. The idea was to make virtual rooms and their tools act as a spatial setting for interaction that frames and structures appropriate behavior in requirements engineering processes (Herlea, Shaw and Gaines, 1998; Herlea and Greenberg, 1998).

Figure 2. The planner Room
 
The ‘diagram’ in the room indicates an iterative process, where team members step through the stages of the LoReN model. Four ‘areas’ were defined to serve the specific activities in the process and to enable the investigation of the support TeamWave gives to the iterative cycle in LoReN. One purpose of the study was to identify the extent to which these areas can serve as virtual locales for the team interactions. The issue here is to what extent effective communication within and across locale is enabled in the system.

The way a virtual room has been set up in TeamWave makes people quit that room when contact with others in other rooms in needed. This means that the effective communication is sometimes hindered by the boundaries set by the room. In this context, the question is to what extent this is a limitation of the system in supporting the requirements negotiation process.

The study involved a scenario of negotiating requirements for a library management system. It addresses the existence of multiple perspectives during domain knowledge acquisition and traceability and it takes into consideration two different roles played by the participants in the study: the role of librarian and the role of borrower.

3.3.1 Task 1. The first task addressed the expression, analysis and negotiation of multiple perspectives during requirements acquisition. In order to investigate the support TeamWave offers to this activity, this task focused on the following issues:

This task involved two participants: one participant, playing the role of the librarian, and the investigator, playing the role of the borrower. They synchronously analyzed two different perspectives over the idea of a ‘book’, as illustrated by the two concept maps in Figure 3.
 
Figure 3. The Scope Definition Room which the participants used in task 1
In the Scope Definition Room, the Note Organizer tool has been used to state the role of the customer that brainstormed the description and the motivation behind it.

3.3.2 Task 2. The second task addressed the group collaboration during the requirements traceability, the identification and discussion of multiple perspectives while checking the accuracy of the negotiated requirements to date. During requirements traceability, it is often the case of learning about or negotiating different perspectives. In order to investigate the support TeamWave offers to this activity, this task focused on the following issues:

It involved participants playing the role of librarian, connected to the Worth Proceeding room (figure 4). The image tool has been used to retrieve the screenshot of lending transaction prototype and the two requirements documents in hypertext format used in this study: the informal document that contains the natural language, informal statements of requirements and the semi-formal document that contains the features of the new system based on the negotiated requirements.
Figure 4. The Worth Proceeding? room supporting requirements traceability
Any key concept in the semi-formal document is represented as a node and either it has its description attached to it or it has a link to its descriptive paragraph within the same document. Also, each definition of a key concept within the semi-formal document has a link within the informal document, to the informal requirement that motivates its definition. The two html documents are browsed using the Web Browser tool inside TeamWave.
The second task used the think aloud method. The reason was to get insight of how the participants access the requirements documents in evaluating the prototype in TeamWave; the participants' thoughts and questions helped in learning about what they were looking for, what their needs were and what could be improved.
After the tasks were performed, general questions addressing the size of the workspace and the layout of rooms used throughout the process, and of learning about possible improvements.
An interview was held while debriefing the participants. The issue addressed was whether it is worthwhile to use this virtual environment during the complex process of requirements negotiation.

3.4 Discussing multiple perspectives
This section discusses the support offered by TeamWave to the negotiation of different contributions during the requirements acquisition activity.

  • 3.4.1 Using the collaborative tools in the system. In a physical meeting, whiteboards, flip charts or overhead projector transparencies provide limited affordances for visibility, portability, duplication and persistence of information, and access to information in the artifact (Maiden and Bright, 1996). These weaknesses can be overcome by the use of electronic collaborative tools. In this context, Teamwave creates new affordances for manipulating the meeting artifacts.

    • With the concept mapping tools, the participants described particular parts of their knowledge during the first task. The concept maps in figure 3 embody representation schemas that participants used to structure their viewpoints (Easterbrook, 1991). With the note organizers, participants specify their position that forms the basis behind their perspective.

    The spatial properties of a room allowed the participants to structure and annotate the space, simply by moving relevant work artifacts close to one another. As in this example, the participants were able to explicitly place the role/argument text to partially overlap the concept map that it is related to. The concept map tool has been found useful in analyzing alternatives:

    ... it seemed like the right kind of tool for the conflict to be resolved because of the way it presented the information. (participant C*), while the outliner tool has been found useful in "organizing a set of attributes perhaps in a hierarchy" (participant J).
    Also, the concept map tool has useful features such as allowing participants to change the shape or the color of the nodes. gIBIS diagrams (Conklin and Begeman, 1987) can be created when analyzing decision alternatives.
    However, when a more complicated problem is being discussed, the room would run out of space and that may hinder effective communication in TR: I was always having to move things around to see them, especially because some tools couldn't be brought up above others. (participant J) Therefore, the size of the workspace and the manipulation of collaborative tools in the shared workspace is an important issue to consider when designing virtual environment for requirements negotiation. The issue here is the extent to which the virtual environment supports real time requirements engineering meetings that scale up to teams that produce and manipulate large numbers of work artifacts.

    3.4.2 Mutuality in the workspace. In this study, mutuality refers to awareness and presence in the shared workspace. On one hand, the virtual environment creates new mechanisms for awareness and presence in the workspace. The participants may be physically located at one workstation, in their own office, but can be virtually present in any room, collaborating on any task. The only observable activities participants engage at their keyboards are the movement of their fingers as they type or hold the mouse, and discussions with others during synchronous collaboration. But if their activities and conversations in the virtual were translated into the physical domain, they were a series of movements from one location to another in using physical artifacts such as whiteboards or flipcharts, in performing different tasks such as requirements elicitation or validation.

    On the other hand, designing for awareness in virtual environments is a challenge for CSCW in general (Gutwin, 1998) and in requirements engineering in particular, where the spectrum of presence-awareness options may need to be defined in more explicit units. The visible and tactile effects of actions are different in the virtual environment. The virtual workspace provides very limited support for the awareness of gesture, body presence, eye contact and gaze.
    In TeamWave, awareness information is provided by the awareness widgets: the list of participant in the system meeting and the list of the participants in each room. A more fine-grained awareness information is provided by telepointers, which act as surrogates for the participants’ hand gestures in the shared workspace:

    The ability to see where the other person's mouse pointer was pointing was a great help, since it allowed attention to be focused on a particular object without having to explicitly (verbally) identify the target of comments. (participant D*) We believe it is important that the participants were able not only to describe several perspectives, but also to develop mutually comprehensible requirements representations through real time negotiation and exchange. TeamWave has reasonable real time interaction and teledata features. The participants could gesture to items through telepointers and debate and clarify the captured perspectives through real time interaction.

    While the negotiation hasn't been regarded as affected by the absence of the visual contact with the other participant in the experiment:

    we managed to get through the tasks without seeing each other's faces (participant J), a new tool appeared as necessary for more complex situations that can emerge during the requirements negotiation: During a conversation I am very aware of the individuals body reaction to comments being made as well as to body reaction as a result of the trend of the conversation. I feel I am missing useful information if that is not there. Very much like a telephone conversation does not convey all the information. (participant L*) Negotiation in general is regarded as an activity where the major part of the task is 'reading the other person' (Buxton, 1991). During requirements negotiation, a set of tasks is performed. Some of them involve structured work, others involve discussions and analysis of different (sometimes conflicting) perspectives. Therefore, the requirements negotiation process involves sometimes "more technical" tasks or tasks "concerning conflicts of interests" (participant A*). Participant C* noted that the need of the video connection is in relation to the task at hand: depends on what you are doing … for very structured and detailed work, when you are focusing on ideas, maybe [the video link] is not as useful However, more research is necessary in order to identify the effectiveness of video technology for interpersonal communications in requirements negotiation. The issue here is how the shared person space and the shared task space relate during the requirements negotiation.

    As mentioned earlier, one of the sessions has been run over distance, with no other (audio or video) connection in place. It is important to note that the discussions during the remote session took about two hours only on the first task. The system proved to be slow during remote negotiation, especially when moving between rooms. The main point participant A* made is that

    the system is useful for solving technical problems. It may save time and money spent or traveling. However, in situations where "a lot of social skills" are needed, the communication channel provided in TeamWave might not be appropriate. It simply does not "address the real problem" (Participant A*). The issue here is that the computer is happiest in the world of explicit, concrete information. Central to group activity, however, are social, motivational, political, and economic factors that are rarely explicit or stable. Often unconsciously, our actions are guided by social conventions and by our knowledge of the personalities of people around us (Grudin, 1993).

    At this point, we are seeking answers to questions such as: How much of telepresence is necessary to achieve a shared understanding of requirements and perspectives, and to communicate effectively through the process? Is a facilitator knowledgeable in the RE process necessary in computer supported collaborative meetings?

    3.5 Tracing the requirements
    This section discusses the support offered to the collaboration during the second task, during the requirements traceability activity.
    By observing the participants in their attempt to match the features of the prototype with the set of requirements concerning the lending transaction, the general conclusion is that all of participants were able to check the accuracy of the requirements. However, a number of issues related to the requirements accessibility in TeamWave are addressed as follows.

    3.5.1 Accessing the requirements documents. The first issue relevant to groupware is how the system maintains repositories of requirements representations and supports the participant’s access to these repositories. In this study, the information about requirements was stored in html documents, the electronic documents providing thus new possibilities for collaboration compared to paper documents. They include fast and synchronous access to information, persistent record of the information, support for requirements traceability and easy access to past actions and decisions in case of a new comer in the process.

    The second issue relevant to groupware is how the group can collaborate during requirements traceability. This was achieved by allowing the team to structure a room in a way that brings together the participants and the artifacts required for tracing and discussing particular requirements, as illustrated in figure 4.

    The second task involved checking the accuracy of the prototype presented by the image tool against the information about the requirements stored in the html files. The ability to access both the original natural language statements and the more structured semi-formal set of requirements inside TeamWave has been found useful by most of participants:

    I'm far more comfortable with narratives explaining drawings. Having both documents together aids the understanding of the other. (participant E*) Following the hypertext links in the semi-formal document, the participants could trace the representation of the concept ‘book’ (a component of the lending transaction); also, the links associated to this concept were followed and the participants could learn about and discuss the two perspectives (containing the role and the argument of the originator) behind the concept ‘book’.

    A feature that TeamWave doesn't have but would be very useful when tracing requirements, is a "search tool", as participant H* suggested. It would be extremely valuable to be able to search for a requirement and find the list of rooms where the group discussed it. Also, the ability to actually "teleport" participants to the room where a decision has been taken regarding a particular requirement, would be useful in tracing requirements.

    3.6 The interview with the participants
    The interview held while debriefing the participants addressed the issue of whether it is worthwhile to use the virtual environment during the requirements negotiation process. The aim was to enable the investigator to learn about the participants' opinions on the difference and comparison between two situations of negotiating requirements: close interaction among participants, during face-to-face meeting in a physical room, and remote collaboration using TeamWave.

    The analysis of the two situations brought up some interesting aspects on: (1) the communication of ideas, (2) the reaching of agreement, (3) the focus on the tasks and (4) the requirements documenting. They will be addressed as follows:

    3.6.1. The communication of ideas. The discussion of the two situations took into consideration the system as it was tested, assuming that an audio link would be in place during the sessions, but no visual contact with others would be possible. In this context, the rich face-to-face communication medium has been found as providing valuable cues to the interaction within the requirements negotiation:

    In a meeting room, you are able to see what people's opinions are, by their body language (participant B) During requirements negotiation, "we use more than our voice to communicate" (participant C*) and "the emotional state visible in face-to-face communication are very important in negotiating" (participant G).
    Even if the system would be accompanied by a video connection "the distance would take away some of the empathy" during synchronous collaboration (participant C*).

    3.6.2 Reaching the agreement. As a consequence of the fact that communicating ideas is easier in a face-to-face situation, participant C* highlights the fact that "it is much easier to come to consensus in face-to face meeting". This might be attributed to the fact that "personalities come out differently in person versus over the network" (participant D*)
    During interaction over the network, as participant B noted, there might be the situation of misunderstanding of perspectives, even if consensus was thought as being reached:

    I would worry that not all the ideas were exactly the same, that they look the same to both people but the librarian has a different point of view … where the borrower sees differently … they come to an agreement … and when the system comes up and the borrower says 'this is nothing I thought of' 3.6.3 The focus on the tasks. When thinking of meetings in physical rooms, participant B recalled situations when extra discussions during the process would make members of the group be 'out of topic a lot'. In this respect, using the system has been found very valuable in keeping participants focused on the current task, fact that might speed up the process.

    However, participant D* brings up another aspect related to this issue. During remote collaboration, participants in the process "would not feel as much connected". There is a difference between having a scheduled meeting and a compulsory attendance, as opposed to just being connected from the remote workstation and jump on the task. While this is an advantage, allowing participants to work on the process any time, without traveling, participant D* describes the situation when participants are doing other things at the same time, like reading email or coding, just waiting for "something interesting to happen" at the other end.

    3.6.4 Requirements documentation. As noted before, the ability to store requirements and access them at a later date has been found as useful during the process of requirements negotiation:

    Like: The concept of being able to access documents, decisions, etc. quickly. (participant H*) The fact that participants could access requirements, the steps, the information about the perspectives and the analysis behind the decision was found of great help in providing structure to the complex and large amount of requirements: Yes, it would help by providing some structure to what we do, by allowing us to easily document our work (there is always the excuse that there is no time for that), by being able to return to previous discussions (since requirements negotiation is iterative) so that we don't have to revisit decisions that have already been made. And to do this in an intuitive and easy way. (participant C*) Therefore, in attempting to express the difference between the two situations, most of the participants highlighted the fact that TeamWave would be very useful in their working environment, where "people forget or postpone bringing documents" (participant H*). The ability to easily retrieve the information about requirements from previous meetings is very important during synchronous requirements negotiation meetings.

    In the same context, participant D* finds that the ability of participants to access the requirements documents during asynchronous sessions is valuable: members of the group "can get back to their desks and browse the information, then leave or answer questions".

    Therefore, the system has been found valuable in supporting the requirements negotiation process in terms of documenting information during meetings, either used in the same room, or remotely. However, participant B brought up an interesting aspect: the situation of "out of rooms" discussions. In order to be able to access all previous arguments and analysis regarding conflicts or multiple perspectives, dedicated use of it by the people on the team, including the documenting of the "out of rooms" discussions, is essential.

    The question "do you think that using the tool, remotely, would solve the problem of 'people cannot meet together'?", seemed a difficult one. Most of the participants recognized the fact that there are many issues in discussion: why can people not meet? what task are they supposed to work on? what is there experience in using computers? what is the context of the remote collaboration? In this framework, the general answer could be expressed as:

    "yes, using the system would solve the problem in terms of documenting requirements, discussions, points of view"
    "no, using the system would not solve the problem in terms of human communication during the process"     In this framework, the question "would you use the system in this situation?", seemed to be easier and the investigator got straightforward answers:  "Definitely. Extremely valuable" (participant C*)
    "Probably Yes. I would use it" (participant B)
    "Depends on the context" (participant D*)
    "Yes" (participant G, H*, K, L*)
    "Yes, if training for using the system would be provided" (participant E*)
    "Depends on the users" (participant F)
    "No. Too slow for the interaction" (participant J)         3.7 ‘Areas’ vs. ‘locales’
    A major thrust for this study was to get people with experience in the requirements definition process to use the virtual environment and have the opportunity to see how they collaborate during the process, whether effective communication is afforded by the system.

    In seeking support for an effective communication, the issue that arises is whether the areas defined in the system act as locales for the team's interaction during the process. While TeamWave supports the collaboration in a room, the collaboration outside the current room is limited: the system provides limited information about current actions in other rooms. In LoReN however, the awareness of actions in a locale and across locales is an important factor in building the shared understanding of requirements. This is a crucial domain CSCW designers should consider when designing requirements engineering virtual locales.

    In TeamWave, it is not possible to "see" the activities occurring beyond the walls of the current room or the change in requirements occurring in different rooms. There might be the situation when participants in one room would like to use the outline tool in organizing the information provided in another room by means of a concept map. This might help in the process of negotiating requirements (e.g. the attributes of a book expressed using the concept map tool in one room might be outlined using the outline tool in another room). As anticipated, this is not possible in TeamWave, due to the "hard walls" of rooms, which hinder the effective communication within the considered locales.

    Hence, the ‘areas’ lost the battle against ‘locales’ in this study. One way to overcome this problem and help an effective communication is to allow participants to open, inside the current room, one window for each external room and display the contents of the room. This allows them to become aware of the discussions at the meetings in diverse rooms, in a transparent mode.

    In spite of these limitations, TeamWave is a groupware system that provides the requirements definition team with a persistent virtual environment for structuring the work during the requirements negotiation, with more functionality than other existing groupware system do. TeamWave supports synchronous access to the workspace; the participants could access the requirements artifacts simultaneously, when identifying different perspectives associated with diverse roles in the process. TeamWave also provided an equal opportunity for participation to the task of defining a ‘book’; the participants could use groupware tools to structure the work in a real-time manner.

    Of special interest for this study was the support for distance collaboration. TeamWave has been found extremely useful for remote collaboration during requirements negotiation. The system provides a persistent workspace for the requirements artifacts; the participants could remotely manipulate the artifacts saved in repositories, during synchronous collaboration, as seen during the first task.; also, a late comer could review past contributions to the requirements documents, in an asynchronous manner, as seen during the second task.

    In summary, if an attempt to answer the question "To what extent does TeamWave support the requirements negotiation process within LoReN?" has been made, then the answer is:

    It supports the process. It increases its value. However, it does not replace the traditional face-to-face meeting setting. 4. CONCLUSIONS AND FUTURE WORK
    This paper presented initial studies in investigating groupware support for the interaction in requirements engineering processes. The groupware system Teamwave has been selected as it meets general design requirements for supporting group work in RE. However, its evaluation, as presented in this paper, revealed limited support to an effective communication. Lessons learned from this study make us believe that the list of design requirements presented at the beginning of the paper should be extended to require support for locale aspects, as described in LoReN, if effective groupware designs are to be developed. Building virtual locales for distributed requirements negotiation sessions is in fact the real challenge for CSCW designers in building support for such a remote process. Effective communication in the process is lost otherwise.

    We consider this research just a start in understanding the intricacies of the requirements negotiation collaborative work and the implications of designing requirements engineering virtual environments, of using computer based tools to afford distributed communication.
    Further research, which should include more studies of real work settings, are necessary in order to address further issues of concern:

    However, systems should be developed that support distributed requirements engineering (Herlea and Greenberg, 1998). At the same time, it should be remembered that the negotiation of requirements is a complex and subtle process, still little understood even in co-located meeting situations. Understanding the nuances of this process is crucial in order to develop groupware designs to support it.

    5. AKNOWLEDGEMENTS
    Thanks go to Mildred Shaw, Brian Gaines, Frank Maurer and Rob Kremer for reviewing and commenting on versions of this paper.

    6. REFERENCES:

    Bright, B.P., Maiden, N.A.M. and Sutcliffe, A.G. (1995). Requirements engineering: defining the needs for collaborative assistance, Technical Report, Centre for HCI Design, City University, June
    Brooks, L. and Jones, M. (1996). CSCW and requirements analysis: requirements as cooperation/requirements for cooperation, in P. Thomas (ed), CSCW Requirements and Evaluation, Springer-Verlag London
    Buxton, W.A.S. (1991). Telepresence: Integrating shared task and person spaces, Baecker, M.R. Ed. Readings in Groupware and CSCW. Morgan Kaufmann.
    Carmel, E., Randall, D.W. and George, J,F. (1993): PD and JAD: a transatlantic comparison, in Communication of the ACM 4(36).
    Checkland, P. (1981). Systems Thinking, Systems Practice. Wiley, Chichester, UK.
    Checkland, P. B. and Scholes, J. (1990). Soft Systems Methdology in Action. Wiley, Chichester, UK.
    Christel, M.G., and Kang, K.C.(1992). Issues in Requirements Engineering. Pittsburgh: Software Engineering Institute, Carnegie-Mellon University. CMU/SEI-92-TR-12.
    Conklin, J. and Begeman, M.L., (1987). gIBIS: a hypertext tool for exploratory policy discussion. Transactions on Office Information Systems 6(4). 303-331.
    Easterbrook, S. M. (1991). Elicitation of Requirements from Multiple Perspectives, PhD Thesis, Imperial College of Science Technology and Medicine, University of London
    Ellis, C.A., Gibbs S.J. and Rein, G. L. (1991). Groupware: some issues and experiences, Comm. of the ACM, January 9-23
    Fitzpatrick G., Mansfield T and Kaplan, S. (1996). Locales framework: Exploring foundations for collaboration support. Proceedings of the Sixth Australian Conference on Computer-Human Interaction, New-Zeeland. IEEE Computer Society Press. Los Alamitos, California. 34-41.
    Giddens, A. (1984). The Constitution of Society. University of California Press
    Greenberg, S. and Chang, E. (1990). Computer support for real time collaborative work. Congressus Numerantium. 75. 247-262.
    Greenberg, S. and Roseman, M. (1998). Using a room-based metaphor to ease transitions in groupware, Report 98/611/02, Dept Computer Science, Univ. of Calgary
    Grudin, J. (1993). Groupware and cooperative work: problems and prospects. Baecker, M.R. Ed. Readings in Groupware and CSCW. Morgan Kaufmann.
    Gutwin, C. (1998). Workspace awareness in real time distributed groupware. PhD. Dissertation, http://www.cpsc.ucalgary.ca/~gutwin/dissertation/
    Herlea, D. (1996): Users Involvement in Requirements Engineering, Proceedings of the 10th Annual Knowledge Acquisition Workshop (KAW96). Banff, Canada, 47.1-47.8
    Herlea, D. (1997): Groupware for Requirements Negotiation, Master thesis, http://www.cpsc.ucalgary.ca/~danah/thesis/thesis.html
    Herlea, D., Shaw, M.L.G. and Gaines, B.G. (1998). Locales for requirements engineering, Report 98/610/01, Dept Computer Science, Univ. of Calgary
    Herlea, D. and Greenberg, S. (1998): Using a groupware space for distributed requirements engineering, Report 98/614/05, Dept Computer Science, Univ. of Calgary
    Jarke, M., Meta models for requirements engineering, Proceedings of the 10th Banff Knowledge Acquisition for Knowledge-based Systems Workshops, Banff, Alberta, 1996.
    Leventhal, N. (1995): Using groupware tools to automate Joint Application Development, in Journal of Systems Management September/October
    Macaulay, L.A. (1996). Requirements Engineering. Springer-Verlag, London.
    Maiden, N.A.M. and Bright, B.P. (1996). Recurrent communication patterns in requirements engineering meetings, in Proceedings of WET ICE, Stanford, California
    Pohl, K. (1993), The three dimensions of requirements engineering, Proceedings of the 5th Intl. Conf. Advanced Information Systems Engineering
    Potts, C. (1996). Working group report on requirements engineering in and for networked enterprises", in Proceedings of WET ICE’96 Stanford, California
    Strauss, A. (1978). A social world of perspective. Studies in Symbolic Interaction 1(1978). 119-28.

    back to top