Requirements-Gathering Collaborative Networks in Distributed Software Projects

Transcription

1 Requirements-Gathering Collaborative Networks in Distributed Software Projects Paula Laurent and Jane Cleland-Huang Systems and Requirements Engineering Center DePaul University {plaurent, Abstract This position paper explores the practices and challenges of distributed requirements gathering through case studies taken from the telecommunications, gaming, and factory automation domains. The social organization of the participants, their formal and informal collaborations, and adoption of relevant tools are modeled as requirementsgathering collaborative networks. The study identifies specific problems and challenges that were observed in the three case studies. 1. Introduction Today s global technology environment means that an increasing number of software products are deployed across geographical boundaries. This in turn requires stakeholders from remote locations to be included in the task of discovering and specifying requirements. Many organizations address this need through selecting a representative group of stakeholders and flying them into a central location for a series of face-to-face brainstorming sessions. A facilitator, normally a project manager (PM) or business analyst (BA) works with the stakeholders to define and prioritize requirements. These face-to-face meetings provide stakeholders with the opportunity to explore, articulate, prioritize and negotiate requirements in real -time. An alternate option utilizes technology to support remote collaboration. For example, forums, wikis [2,6,7], online services such as Rally, NetMeeting, econference, and EGRET, and online versions of requirements management tools such as DOORS TM, are designed to facilitate collaboration between geographically distributed stakeholders without requiring face-to-face meetings. Other media-rich tools attempt to reproduce face to face meetings in an online setting. This class of tools includes telephone conferences, and chat, and allow distributed stakeholders to work synchronously or asynchronously and share information as necessary. In their paper Research Directions in Requirements Engineering, Cheng and Atlee described this move towards online collaboration as part of a broader paradigm shift toward global software development [1]. This paper examines the practices and challenges, for conducting requirements elicitation and analysis activities in a purely distributed environment. The paper reports on the processes, social organization, collaborations, and tool support that were used in three different requirements gathering domains for a telecommunications, gaming, and factory automation project. 2. Requirements Gathering Collaborative Network Models (RGCNs) Damian, et al. [4] introduced the concept of a requirements-centered social network, (RCSN), and described it as a graph that illustrates the relationships and communication paths between project members working on an individual requirement. Each RCSN depicts a specific requirement with the nodes representing members of the development team and the arcs depicting a communication path. Damian et al used these RCSNs to study awareness and collaboration patterns of developers working on the same or related requirements. Our work expands on these concepts to model the process by which groups of stakeholders communicate during the requirements gathering process. Although prior research [3,4] has mostly concentrated on individual development team members, our models focus on project specific stakeholder roles, including that of customers, clients, etc. and development team members responsible for gathering requirements. Because these models capture a more generic picture

2 of project-level interactions, we refer to them as Requirements Gathering Collaborative Networks (RGCNs). These network models were derived from industrial case studies, as well as the authors industry experiences. The Centralized RGCN model, Figure 1a, represents the basic communication flow between the requirements gatherer (RG) and the stakeholders (S1, S2 Sn). Figures 1b-c depict Teams-Collaboration (TC) RGCNs, in which both formal and informal communication occurs between all types of stakeholders at all locations. However, an organization might be more likely to implement one of the Facilitated-Collaboration (FC) RGCN models, shown in Figures 1d-e, if cross-communication between distributed locations is not supported. The FC RGCNs facilitate a divide and conquer approach whereby different sites can be assigned different features. A given project is expected to encompass some hybrid version of these different models. 3. Case Studies Figure 1 Requirements-Gathering Collaborative Networks open-ended. Every interviewee answered our list of over 20 questions, summarized in Table 1. Each interview took approximately one hour, and was recorded and transcribed for later analysis. This paper reports some of the early results from three of these interviews. As part of each case study, the social structures of the project were examined and modeled through instantiating the generic RGCN s shown in Figure 1. These models were augmented with the notation depicted in Figure 2, to visually portray various communication techniques. To explore the actual use of these models in practice, we have been interviewing leaders of globally distributed requirements projects. Each of the interviewees were asked to think about one of their most recent projects in which they were responsible for eliciting and gathering the requirements from geographically distributed stakeholders. The interviews were conducted by telephone and were designed to be 3.1 Telecommunications Project The first case study was an application enhancement project for a telecommunications company. The project was a relatively small, nine month project conducted by two developers and two quality assurance (QA) specialists, and also included approximately 2-3 weeks of full-time work by the requirements gatherer. Despite its small size, this project had potential to be very profitable for the company. Figure 2. Communication Methods

3 TABLE 1. Summary of Interview Questions A. Project metadata questions (Not shown here) B. Requirements elicitation questions 1. What elicitation process did you use? 2. How were your requirements documented? 3. Did you use an automated tool, or any form of shared document? 4. Who, in terms of role, was responsible for entering the requirements into the database, spreadsheet, or other document? 5. As of today, approximately how many requirements have been generated for this entire project? 6. How many hours, in total, do you think were spent gathering these requirements? 7. Do you or your team produce a Requirements Specification document? Who is responsible for it? Where are they located? 8. How were stakeholders chosen for this project? 9. How do individual stakeholders participate in the requirements development and documentation process? What roles are involved? 10. How many geographic locations and stakeholders participate in this project? C. Requirements Management Questions 11. Did you experience or identify any stakeholder/requirement conflicts? 12. How were the conflicts handled? 13. How were requirements prioritized? D. Problems and Challenges 14. What specific challenges did you experience? 15. What specific successes did you experience? E. Cultural Issues 16. Did any cultural issues impact the project? Project Structure The requirements process was conducted across two primary sites in the USA by a remotely located Lead Interaction Designer. Each primary site housed one or more project managers and a developer. The social structure of the project, which is depicted in Figure 3, represented a distributed collaboration model in which all stakeholders had direct contact with the requirements gatherer. In this model, stakeholders within a site communicated and collaborated freely, but all inter-site communication was channeled through the requirements gatherer. The primary reason for this choice of model was that each of the sites was responsible for separate applications within the project, and so it was felt that they should work relatively independently. Communication between the Lead Interaction Designer and each of the remote sites was via teleconferencing and s. The Lead Interaction Designer was responsible for organizing teleconferences as well as for communicating with stakeholders via to create and maintain the requirements document. The stakeholders were empowered to prioritize requirements by consensus. However, a management escalation path was available for occasions when consensus could not be reached Challenges and Problems observed The primary problem reported by the Lead Interaction Designer was that little tool support was provided to help coordinate requirements, and as a result he had to manage and coordinate discussions related to the requirements in his folder. This led to a complaint that gets too cluttered. It s difficult to separate... regular messages from project-related ones. He further volunteered the suggestion that he would prefer some type of web-interface to track things. Although the two sites were working on different parts of the project, it would have been helpful at times for the distributed stakeholders to collaborate directly. However this type of inter-site collaboration was hindered by technology failings. For example, although Netmeeting was available for real-time sharing of documents, the project stakeholders used a mixture of PCs and Macs; and Netmeeting was not supported on Macs. AdobeConnect was also available and provided similar functionality to Netmeeting but when it was adopted, meeting time was frequently wasted by latecomers requesting IP addresses so that they could connect to the meeting. 3.2 Video Games Project The second case study examined an international video game project priced at US$500,000 per year Project Structure This project included five distinct sites, two in Europe and three in the USA. As depicted in Figure 4, each site housed a variety of stakeholders representing project leads, developers, artist representatives, and artists. Although each site was responsible for building games that targeted different markets; features were shared across products whenever possible. Communication between sites was conducted both formally and informally using a variety of phone, , teleconferencing, wikis, and shared repositories of data. One of the European sites had only one English speaker, and so it was relatively isolated from the other sites, and stakeholder communication was conducted entirely through the centralized project manager.

4 Figure 3. Telecommunications Organization The requirements documentation was created and maintained by the requirements gatherer (RG), who coordinated with stakeholders via company-public wiki web pages, , and a shared repository. Originally, SharePoint had been used, but was discarded for being too slow. The general software development process involved a modified agile approach in which all bug reports, feedback, and requests for new requirements were logged into the company s cross platform wiki. Discussions related to new requirements requests were then included in an issues meeting that occurred every three weeks. The stakeholders were empowered to prioritize requirements by consensus. Whenever possible, features would be shared across applications; however when consensus could not be reached, multiple versions of the software containing competing features were developed Challenges and Problems Because the language barrier meant that stakeholders at the Europe-2 location could not communicate directly with other locations the requirements gatherer had to conduct two rounds of requirements meetings. This increased the work effort of the requirements gatherer and meant that misunderstandings or conflicts could not be cleared up in a single meeting. Several problems stemmed from the desire to create an interactive agile environment with high levels of interaction between stakeholders. This specifically created problems when stakeholders had to remotely deal with requirements related conflicts. The interviewee, who served as the project manager, suggested that an executive decision maker should have been included as a stakeholder, in order to minimize this conflict. To support the desired levels of interaction, the project manager attempted to use a commercial product, TrackPro, which provides functionality for tracking and managing the status of various software development activities. However the overhead required to use this tool turned out to be infeasible for the 3-week develop-test-deploy cycles and so was abandoned. Figure 4. A Video Games Organization 3.3 Requirements Consultation The final case study represents a consulting project to customize and implement requirements for a purchased factory automation system. The project was estimated to cost from US$50 Million to US$100 Million Project Structure This project had an interesting structure in that there were two requirements analysts, one of whom was located in the USA while the second was located in Asia. Both analysts were from the US and communicated through regular exchanges and monthly face-to-face meetings. As depicted in Figure 5, subject matter experts (SMEs) with expertise in factory automation were located at two USA sites and one Asian site. The requirements analyst in the USA communicated directly with stakeholders at the US sites using both teleconferencing and , while the Asian analyst communicated with the Asian site via face-to-face meetings and . Neither of the requirements analysts were permanently located at the remote sites. In addition to meetings between the analysts and stakeholders, communication channels were established between stakeholders at the three sites. For example, SMEs at the Asian site, communicated via teleconferences with SMEs at the USA sites. The requirements analysts worked collaboratively to create and maintain the requirements documentation. In addition, a project librarian was located in the US, and was responsible for maintaining the requirements documentation in SharePoint. Stakeholders from all three sites contributed business justifications that were used by the lead requirements gatherer to facilitate the prioritization process. Requirements were transferred

5 Figure 5. Factory Automation Project from SharePoint to an in-house commercial requirements management tool for tracking purposes Challenges and Problems observed The interviewee, who represented one of the requirements gatherers expressed a strong preference for gathering requirements in person, as face-to-face meetings were good for capturing nuances of expressions, especially with respect to the Asian stakeholders. However, as this approach was not always cost or time effective, they relied upon teleconferencing. Video conferencing was seen as too technology dependent and not sufficiently advanced to support virtual face-to-face meetings. The problems introduced by bridging two distinct cultures and languages were primarily addressed through placing one of the requirements gatherers onsite in Asia. 4. Conclusions The case studies presented in this position paper illustrate several challenges that hinder the effectiveness of distributed requirements gathering. It is interesting to note that in general, project managers attempted to recreate traditional requirements processes in a distributed setting, by creating RGCNs that mimic the structures that would have been found in non-distributed projects. For example, the video gaming organization attempted to recreate the rich stakeholder interactions that would be expected in a typical agile project, while other projects attempted to recreate typical face-to-face meetings. Only one of the studied projects utilized a wiki to gather requirements. Although these case studies represent only the initial results from our larger survey of distributed requirements gathering projects, they suggest that a number of factors constrained the structuring and interactions that occur within RGCNs. First, specific barriers such as different languages limit interaction and force a restructuring of the RGCN that facilitates stakeholder communication indirectly through a central representative. Secondly, in some cases, project managers chose to isolate sites because the stakeholders were working on separate parts of the project, and direct interaction was deemed unnecessary. In a non-distributed project, this separation would be augmented through informal relationships across teams; however in a distributed project there are few opportunities for informal communication. As a result, no social or technical framework was created between sites, which made communication difficult even when it could have been beneficial to the project. Finally, in all three of the case studies, there were strong indications that technology limitations hindered collaboration between stakeholders, and meant that project managers had to opt for less sophisticated means of communication such as teleconferencing or ing instead of more interactive methods such as video-conferencing. These results report only the initial findings from our more extensive study of distributed requirements gathering processes. Our ongoing work involves a more extensive evaluation of the challenges and potential solutions for conducting effective distributed requirements gathering processes. 5. References [1] B.C. Cheng and J.A. Atlee, Research Directions in Requirements Engineering, IEEE Future of Software Engineering (FOSE 07), May [2] J. Cleland-Huang, H. Dumitru, C. Duan and C. Castro- Herrera, Automated support for managing feature requests in open forums, Communications of the ACM, [3] D. Damian, "Stakeholders in Global Requirements Engineering: Lessons Learned from Practice", IEEE Software, vol. 24, pp , [4] D. Damian, S. Marczak, and I. Kwan, "Collaboration Patterns and the Impact of Distance on Awareness in Requirements-Centered Social Networks", 15th IEEE International RE Conf. (RE 07), New Delhi, India, [5] D. E. Damian and D. Zowghi, "The impact of stakeholders' geographical distribution on managing requirements in a multi-site organization", IEEE Joint International Conf. on RE (RE '02), [6] B. Decker, E.Ras, J.Rech, P. Jaubert and M. Rieth, Wiki-Based Stakeholder Participation in Requirements Engineering, IEEE Software, pp 28-35, [7] P. Laurent and J. Cleland-Huang, Lessons Learned from Open Source Projects for Facilitating online Requirements Processes", 15th International Working Conf. on RE: Foundation for Software Quality (REFSQ 09), Amsterdam, Holland. June, 2009.