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
3. GROUPWARE TOOLS IN SUPPORTING REQUIREMENTS
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.
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).
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).
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:
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:
Discussing multiple perspectives
This section discusses the support offered by TeamWave to the negotiation of different contributions during the requirements acquisition activity.
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:
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:
While the negotiation hasn't been regarded as affected by the absence of the visual contact with the other participant in the experiment:
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
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?
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:
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.
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:
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:
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:
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:
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:
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:
Thanks go to Mildred Shaw, Brian Gaines, Frank Maurer and Rob Kremer for reviewing and commenting on versions of this paper.
back to top