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.
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.
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.
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.
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.
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