Requirements Elicitation With Web-Based Focus ...

Requirements Elicitation With Web-Based Focus Groups Carla Farinha and Miguel Mira da Silva

Abstract. Requirements are the heart of Information Systems Development and represent major failure reasons of these projects, especially if its social nature is admitted. In this paper we present recent trends of research original from social sciences and propose a web-based focus group method to overcome many of the well-known problems. This method is well suited to the requirements elicitation problem because it promotes collaboration and consensual resolution of incoming conflicts. The proposal was evaluated with two real-world experiments whose results reveal the potential of the method. In fact, results demonstrate that dominant users are avoided and limitations of gathering people at the same place and time are eliminated.

1 Introduction Requirements are the heart of Information Systems Development since the earliest days of computing [3]. Requirements engineering is one of the most important and crucial process of development because requirements determine how the system will operate [8], [11], [32]. Nevertheless, problems still exist [6], [19], [26], [28], [29] and are major causes for the high failure rate of these projects [18]. Requirements Elicitation aims to identify requirements through intense communication between stakeholders and analysts. This complex and error-prone communication shows that stakeholders are not always clear describing what they need and analysts have difficulties understanding business concepts [1], [5], [26], [27], [28]. The errors in this activity become expensive and hard to fix [21], costing around 80-100 times less than if discovered at the implementation stage [3]. As a result, is usually accepted as a critical one [2], [11], [14], [16]. Many directions of recent research focus the social nature of Requirements Elicitation, leading to the usage of social sciences approaches [27], [32], including ethnography [9], [10] interviews [1], [11] or group work [12], [14], [15], [29].

Carla Farinha Opensoft, Rua Joshua Benoliel, 1, Lisboa, e-mail: [email protected] Miguel Mira da Silva IST / INOV, R. Alves Redol, 9, Lisboa, e-mail: [email protected]

1

2

Carla Farinha and Miguel Mira da Silva

We have been investigating the use of Focus Groups to overcome major problems of Requirements Elicitation [15]. We believe that group discussions provide all participants an overview of the global system and needs, making it possible to identify requirements and to negotiate conflicts more efficiently. This proposal was evaluated with Action Research that allows understanding and acting over the problematic situation, developing skills of organizational members to overcome that situation, and adding scientific knowledge [4], [7], [22], [23]. In this paper we present our most recent research in the field of requirements elicitation, including a proposal and results. The proposal consists on using webbased focus groups to allow the participation of all stakeholders in the identification of needs to an Information System. Our paper explains the proposal, presents an experiment and discusses the results. Our conclusions demonstrate that this method avoids limitations of the conventional focus groups, such as dominant users or difficulties gathering relevant stakeholders at the same time and place.

2 Requirements Elicitation Trends Information Systems development begin with Requirements Engineering that identifies, analyses, specifies, verifies and validates activities [3], [5], [25], [31]. The next sections present social approaches to elicit requirements as a recent trend of investigation and group work as promising approaches.

2.1 Social Approaches Requirements Elicitation is one of the most critical activities of the Requirements Engineering [28], [29], [32] for many reasons. First, the activity relies on a complex and error-prone communication between stakeholders and analysts. Second, stakeholders are not always clear about what they want or need. Finally, analysts have difficulties understanding the business concepts [3], [5], [26], [27]. The social nature of Requirements Elicitation has led research to the usage of social sciences approaches [6], [11], [12], [14], [16], [17], [22]. For example, Zowghi and Coulin [32] aggregated methods in 8 groups: prototyping, goals, scenarios, viewpoints, domain, ethnography, interview and group work. They categorized these groups as either alternative or complementary. Ethnography, interview and group work are the alternative groups that actively involve stakeholders. Ethnography is the observation of people in their natural environment. Results are descriptive translations of stakeholders’ activities and interactions [9], [13], [28]. Crabtree, Nichols, O’Brien, Rouncefield and Twidale [10] describe ethnomethodologically informed ethnography as a methodology for information science research, studying how it may be used to inform systems design. They reveal limi-

Requirements Elicitation With Web-Based Focus Groups

3

tations, including risk of incorrect interpretation [9], impossibility of identifying new requirements [29] or difficulty of generalizing results [27]. Sommerville [30] believes that ethnography is not complete, being useful as a complement. Interviewing is an informal interaction [32] where analysts gather high level requirements asking questions about the system in use and the system to be [19], [30]. Davey and Cope [11] consider interviews as best practice for requirements elicitation. Despite the improvements that their research results demonstrate, they admit that requirements elicitation is problematic and more research is needed about the nature of conversations in the field. Goguen and Linde [17] survey and evaluate techniques for eliciting requirements of computer-based systems, including interviews. They consider interviewing limited by the stimulus-response interaction and by the need of participants to share basic concepts and methods. Sommerville [30] states that interviewing is unsuitable to identify organizational requirements and constraints, but it could be used as a complementary method. Group work gathers stakeholders to collaborate reaching solutions about an identified problematic situation. There are many methods of group work, such as brainstorming, Joint Application Development, creativity workshops and Focus Groups. Typical limitations of group work are dominant participants, biased opinions, high logistic costs and difficulties on gathering stakeholders [25], [32]. In summary, Zowghi and Coulin [32] consider three main social and alternative groups of methods that dynamically involve stakeholders in requirements elicitation: ethnography, interview and work group. According to this research, ethnography is incomplete on covering the fundamental types of activities of requirements elicitation and has relevant limitations (not allowing the identification of new needs with daily work activities translation and not allowing the generalization of results). As a result, ethnography is a limited method [30]. Group work has many advantages over interviews: more complete overview with the discussion of representative stakeholders rather than with individual interviews; richer information than with individual interviews; and promotes discussion of conflicts to reach a consensual or agreed solution [32].

2.2 Group Work There are many group work methods, such as brainstorming and workshops, which includes JAD, creativity workshops and focus groups. Brainstorming engages different stakeholders in informal discussions to rapidly generate ideas without focusing on any one. It is often used to develop the preliminary mission statement for the project but not to explore requirements [32]. Joint Application Development (JAD) discussions focus needs of business and users rather than technical issues to make decisions. JAD differs from brainstorms since main goals of the system are already established before the discussion [32]. Davidson [12] studied 3 organizations in which JAD was used. Although they rea-

4

Carla Farinha and Miguel Mira da Silva

lized improvements in systems development, JAD was difficult to sustain in practice. The author admits that the research does not statistically represent all companies using JAD and it is possible that others achieved more substantial benefits. Coughlan [8] also presented two different studies of JAD in practice. Results demonstrate that JAD forces a rigid user-designer interaction and is weak at acquiring knowledge and fairly complicated to use if followed to the letter. Creativity workshops intend to encourage creative thinking after the system boundaries specification and before use cases specification to discover and invent system requirements. The workshops are incorporated in the RESCUE (Requirements Engineering with Scenarios for User-Centered Engineering) process that integrates different modeling and analysis processes in parallel through concurrent sub-processes [33]. Maiden and Robertson [33] used RESCUE creativity workshops to discover stakeholder and system requirements. Results show that the overall process was a success, providing outputs for subsequent requirements processes. Nevertheless, not all of the workshop sessions were a success. Focus Groups are discussion groups facilitated by a specialist that follows a guide to orientate the discussion around key questions [14], [21], [24]. The preparation of such sessions requires defining groups (size and composition) and procedures (number of sessions and moderator guide). This method differs from other group-based methods because of the group special characteristics: homogeneous and focused on key topics to collect inductive and natural information [24]. Engelbrektssonn, Yesil and Karlsson [14] studied methodological considerations with focus groups. They state that an efficient choice of participants and mediating tools are important to enhance the requirements elicitation activity but more research is needed to validate the results. Also, Farinha and Mira da Silva [15] have applied Focus Groups in real-world experiments to evaluate the use of Focus Groups to better elicit requirements of information systems. The results show that stakeholders discuss different perspectives about the system as a whole and collaborate to formalize the requirements according to their needs needs but dominant users and analysis costs were serious limitations. Kasirun and Salim [20] proposed a requirement elicitation tool based on a forum that employed Focus Groups. Results demonstrated that a web-based tool supports shared involvement and eases requirements elicitation but further research is needed to prove results. Resuming, many researchers have been studying requirements elicitation problem using social approaches, namely group work. However, all admit that the problem still exists and much more empirical work is needed [8], [12], [14].

3 Groupware Systems Requirements Elicitation involves intense communication activities [5], [27], demanding a high level of collaboration [37]. Nevertheless, it is difficult to gather stakeholders at the same time and place [2], [3], [12], [19], particularly in large

Requirements Elicitation With Web-Based Focus Groups

5

projects [35], [36]. This limitation increases the pressure to distribute projects globally [35], [36], [37]. This pressure increases with the belief that computersupported collaborative work, combined with an organizational restructuring, leads to more flexible and efficient organizations [34]. Groupware systems allow the cooperation of all stakeholders in several phases of the software process, including in requirements engineering. As such, these systems may be applied to the problem of requirements elicitation. Choosing then one of the many groupware systems demands defining types of tasks to accomplish, making an inventory of the existing software and hardware infrastructures and knowing the experience and capabilities of the team [38]. Herbsleb [35] studied a desired global development, arguing that coordination is a key. He considered challenges in several areas, including eliciting and communicating requirements, concluding that is needed a systematic understanding of what drives the need to coordinate and effective mechanisms for bringing. Whitehead [37] presented an overview of the goals of collaboration in software engineering, and a brief survey of existing collaboration tools, especially webbased tools. He concluded that there is no integrated web-based environment that covers the entire development lifecycle. He also concluded that an is important to understand the collaborative nature of software engineering combined with low costs of communications and high capabilities of communication platforms to improvements collaboration in the creation of software artifacts.

4 Web-Based Focus Groups We propose web-based Focus Groups with all stakeholders. The following sections will explain foundations for our choice and the context of experiments.

4.1 Foundations Requirements Elicitation trends show that group work has potential. Focus Groups were selected due to its characteristics: homogenous groups focused on key discussion topics to naturally collect information. Though no selection of participants is required in our web-based proposal that involves all stakeholders, these groups are Focus Groups because questions are focused, participants can freely express opinions and the facilitator controls the discussion. Web-forums were chosen because of the analysis of types of tasks to accomplish, the inventory of the existing software and hardware and the experience of the team with this collaboration tool. We expect to achieve a richer and complete overview of the system; promote cooperation to reach consensus over incoming conflicts. Also, we expect to over-

6

Carla Farinha and Miguel Mira da Silva

come well-known problems of Focus Groups, including dominant users, limitations of gathering stakeholders, biased opinions and logistic costs. Finally, we also expect to generalize needs involving all stakeholders instead of selected users and to reduce the complexity of session analysis since no transcriptions are needed. Our proposal was evaluated with Action Research that allows contributing with practical actions on the organization and generating knowledge about its context on real world situations. The method requires studying the problematic situation, proposing alternative actions, applying one of the proposed alternatives in practice and evaluating results [4], [7], [22], [23].

4.2 Context The proposal was evaluated on an enterprise of technological solutions that has around sixty employees and many clients, namely governmental clients. This enterprise has an old in-house Information System to manage its activities, including time reporting, project management and financials. These modules needed improvements and the project managers wanted to identify current needs. All stakeholders of each module were invited to participate, not only the experts. Hence, time reporting involved all the 60 employees of the enterprise while the other modules just involved managers and directors, that is, 14 employees. One discussion session was realized per module. The moderator guide was adapted to the web-based method. Two different techniques were evaluated: 1. Comment-oriented collaborative forum. This is a simple focus group session based on stakeholders’ comments but web-based. 2. Vote-oriented collaborative forum. This is a more complex focus group session based on stakeholders’ comments and votes and web-based. The comment-oriented collaborative forum was a web forum where each page corresponded to a question where stakeholders could write comments. Following the orientations of a focus group moderator guide, these pages had a sequential order to navigate and comment. Opening and ending questions were not included in this website. Users were recommended to follow this sequential order but could freely navigate on the website to comment other ideas. Anonymity was integrated in this forum so that stakeholders could freely express opinions. The vote-oriented collaborative forum was a web forum that allowed comments on questions and other participants’ ideas, votes on others’ ideas and creation of new discussion topics. Just key questions were initially provided so that stakeholders could start the discussion without an extensive discussion guide. No recommendations about navigation were given. Anonymity was not integrated to compare results with the comment-oriented collaborative forum.

Requirements Elicitation With Web-Based Focus Groups

7

These web forums were available for a certain period of time. The moderator guides were written by project managers with topics they considered important. Table I. Characteristics of the Collaborative Forums CollaborativeCommentForumOriented

Vote-Oriented

Module Characteristic

Time Reporting Project Management Financials

System

Web Forum

Web Forum

Web Forum

Participation

Comments

Comments and Votes Comments and Votes

Participation Period

20 days

20 days

20 days

# Questions of Moderator Guide 8

3

3

Sequential Navigation

Yes

No

No

Anonymity

Yes

No

No

Since the Focus Groups were web-based, no transcriptions were needed. Stakeholders’ comments and votes were resumed on a report delivered to project managers. This report included needs in a descending order, identified according to the number of references in the comment-oriented collaborative forum, or to the number of votes in the vote-oriented collaborative forum.

5 Results The comment-oriented collaborative forum involved all the employees (they all report time) to identify needs and improvements to the time reporting module. The vote-oriented collaborative forum involved 14 stakeholders of the project management and financial modules (project managers and directors) to identify needs and improvements to these modules. The main results are presented in Table II. The comment-oriented collaborative forum had eight questions, obtaining around 10.25 comments per discussion topic and fifteen identified needs. Anonymous comments made it impossible to measure the average comments per user and no vote system was available in this discussion group. Some participants also posted figures and graphics as images obtained from a design tool to exemplify their perspectives. The vote-oriented collaborative forum had three questions per module obtaining around 18 comments per project management discussion topic and around 11.30 comments per financial discussion topic. No other discussion topics were opened by the participants although they could do it. The average comments per user were 4.79 in the project management module discussion and 1.36 in the fi-

8

Carla Farinha and Miguel Mira da Silva

nancials module discussion. Moreover, the vote system verified around 7.14 votes per user. There were 33 identified needs to the project management module and 11 identified needs to the financials module. Table II. Measured Indicators Collaborative

Comment-Oriented Forum

Module

Vote-Oriented

Time Reporting

Project Management

Financials

Comments per topic

10.25

18

11.30

Comments per user

-

4.79

1.36

Votes per user

-

Identified Needs

15

Indicator

7.14 11

33

Another measured indicator was the number of comments during the discussion period. From Fig. 1 we can see that the comment-oriented approach had a regular participation over time. However, the vote-oriented approach had a higher participation on the last days of the discussion, especially in the last three days. Time Reporting

Project Management

Finacials

40 # 30 20 10 Days

0 1

3

5

7

9

11

13

15

17

19

Fig. 1. Participation during the discussion period

Employees were then asked about their participation: what reasons took them to participate or what reasons took them not to participate if this was the case. The received feedback involved 30% of the participants invited to the commentoriented collaborative forum and 50% of the participants invited to the voteoriented collaborative forum. The results are presented in Table III. Table III. Measured Average Indicators Feedback Type

Feedback

Requirements Elicitation With Web-Based Focus Groups Nonparticipation Reasons

No ideas, lack of time to participate and recent employees with no experience

Positive Aspects

Extensive to all employees, anonymity, simple participation rules, structured discussion and open comments about discussion topics

Suggested Improvements

Present just key discussion topics, give rewards to participants, support the vote system to avoid repeating ideas, suppress suggested answers, no anonymity to avoid unreasonable censures

9

6 Evaluation All the stakeholders considered that this initiative was important and relevant. Results show a higher participation rate in the vote-oriented collaborative forum. This forum had 14 stakeholders contributing with around 18 comments per discussion topic in the project management module discussion and around 11.3 comments per discussion topic in the financial module discussion. The timereporting discussion had around 60 stakeholders contributing with around 10.25 comments per discussion topic. Votes also counted as participations, which may explain this result. Typically, people avoid spending time on writing or exposing detailed ideas and the participants’ final feedback for the voting system highlights this fact. It is easier to vote than to write comments. Other positive aspects of this web-based proposal emerged. For example, asynchronous communication allowed participants to express perspectives along time whenever they could. Also, a geographically distributed space allowed users to contribute with their ideas from wherever they were. We also verified that users of both forums did not answer to all of the discussion topics. Moreover, the most answered questions in the comment-oriented collaborative forum were key discussion topics, while the most answered questions in the vote-oriented collaborative forum were questions to judge the existing modules followed by questions that required new ideas. This not only reveals that stakeholders prefer to directly answer key questions, but also that people are critical since there were more criticisms than comments about positive aspects or new ideas. Note that criticisms are also useful because it is possible to understand what is wrong and should be improved. The improvement requests were mostly technical requests. For example, users wrote that the existing modules are too slow, that some buttons should be available, that certain information is needed or that a particular navigation would be better than the existing one. This can easily be explained by the participants’ profiles: almost all participants are computer engineers and, as such, they understand the problems behind the existing modules and tend to express technical opinions. This is clear since the comments of less technical users were also less technical.

10

Carla Farinha and Miguel Mira da Silva

As with anonymity, it may have promoted free answers but it may also have lead to less participation and conflicts. Anonymity brought unexpected criticisms that otherwise could not have been revealed. These criticisms also brought conflicting perspectives that were discussed, always reaching consensus. On the other hand, the collaborative forum without anonymity had more comments per user indicating a commitment sense of identified users. The lack of conflicts may mean that users agreed to each other or that they did not feel free to disagree. Some participants believe that anonymity allows free expression of ideas without fear of consequences while others think that anonymity brings unreasonable criticisms. In Fig. 1 we see that the comment-oriented collaborative forum had more regular participation than the vote-oriented one, which had more participation at the end of the period. This fact may be explained because votes also count as participation and at the end of the period there were more comments to vote. Actually, this voting system helps users not to repeat ideas and to prioritize needs. It is also possible to vote when comments are available, incrementing the participation rate. Results prove that our proposal helps overcoming identified limitations. First, simultaneous participations allowed dominant users to expose their ideas not stealing the participation time of other participants. Second, the web-based version made possible the participation of all stakeholders from different locations and at different time. Third, since all stakeholders could give their perspectives and reach consensual conclusions, it is possible to generalize results. Finally, the written version of this approach avoids translations, avoids forgetting relevant needs, avoids wrong interpretations and simplifies the analysis process.

7 Conclusion Stakeholders enjoyed the initiative of freely expressing ideas in a simple and structured collaborative forum. They prefer the voting system than repeating others’ ideas and the discussion of key questions than starting with trivial and irrelevant discussion topics. Anonymity on the one hand helps users to make more censorious comments but, on the other hand, seems to take out the participation commitment and to discourage the disagreement of ideas. As such, some participants would prefer anonymity while others think that comments should be identified to avoid unreasonable and thoughtless criticism. We conclude that this proposal allowed quickly eliciting needs from all stakeholders. This paper demonstrates that a web-based focus group approach to elicit requirements not only is cheaper and quicker than the conventional focus group session but also overcomes many problems of the conventional approach. It also seems well suited to the requirements elicitation problems since it promotes discussion among all stakeholders, giving richer information, revealing possible incoming conflicts, and encouraging their resolution.

Requirements Elicitation With Web-Based Focus Groups

11

Note that the demonstrated improvements are not meant to apply in general domains but in the maintenance/evolution of an existing Information System. More research work is needed to confirm these results, applying a similar approach in other projects. Moreover, from the feedback of stakeholders, other suggestions should be integrated in future web-based focus group sessions. First, rewards to participants should be given to encourage participation. Second, only key discussion topics should be initially provided but allowing to add new discussion topics. Third, the voting system should always be present. Fourth, suggested answers should be removed so that users do not feel biased to answer.

References 1. A. Al-Rawas and S. Easterbrook, “Communication problems in requirements engineering: a field study,” First Westminster Conference on Professional Awareness in Software Engineering, pp. 47-60, London 1996 2. D. Apshvalka, D. Donina, and M. Kirikova, “Understanding the problems of requirements elicitation: a human perspective,” Information Systems Development: Challenges in Practice, Theory and Education, Barry, C., Conboy, K., Lang, M., Wojtkowski, G., Wojtkowski, W. (eds.), 2009, Vol. 1, pp. 211-224, Springer 2009 3. D. Avison and G. Fitzgerald, “Information systems development: methodologies, techniques and tools,” 4th Edition, McGraw-Hill Higher Education (2006) 4. J. Bhattacharjya and J. Venable, “An Action Research approach to strategic information systems planning in a non-profit organization,” Quality and Impact of Qualitative Research. A. Ruth, (ed) 3rd Annual QualIT Conference, Institute for Integrated and Intelligent Systems, pp 29-39, Griffith University, Brisbane 2006 5. J. Burg, “Linguistic instruments in requirements engineering”. IOS Press, Amsterdam 1996 6. M. Christel and K. Kang, “Issues in requirements elicitation”, Software Engineering Institute Technical Report, Pittsburgh, PA: Carnegie Mellon University, Pittsburgh 1992 7. D. Coghlan and T. Brannick, “Doing Action Research in your own organization”, 2nd Ed, Sage Publications Inc., Los Angeles 2009 8. J. Coughlan and R. Macredie, “Effective communication in requirements elicitation: a comparison of methodologies,” Requirements Engineering, Vol.7(2), pp. 47-60 (2002) 9. A. Crabtree, “Ethnography in participatory design,” Participatory Design Conference 98, pp. 93—105, Seattle 1998 10. A. Crabtree, D. Nichols, J. O'Brien, M. Rouncefield and M. Twidale, “Ethnomethodologically-informed ethnography and information system design,” Journal of the American Society for Information Science, Vol. 51(7), pp. 666-682 (2000) 11. B. Davey and C. Cope, “Requirements elicitation - what's missing?,” Issues in Informing Science and Information Technology (IISIT), Vol. 5, pp. 543-551 (2008) 12. E. Davidson, “Joint Application Design (JAD) in practice,” Journal of Systems & Software, Vol. 45(3), pp. 215-223 (1999) 13. A.Dix, J.Finlay, A.Gregory, R.Beale, “Human-computer interaction” Prentice Hall, Harlow, 2004 14. P. Engelbrektsson, Ö. Yesil and I. Karlsson, “Eliciting customer requirements in Focus Group interviews: can efficiency be increased?,” 7th International Product Development Management Conference, Belgium 2000 15. C. Farinha and M. Mira da Silva, “Focus Groups for eliciting requirements in information systems development,” UKAIS Annual Conference, pp. 20 (2009)

12

Carla Farinha and Miguel Mira da Silva

16. M. Geisser and T. Hildenbrand, “A method for collaborative requirements elicitation and decision-supported requirements analysis,” S. Ochoa, G.C. Roman, (eds) Advanced Software Engineering: Expanding The Frontiers of Software Technology, IFIP International Federation for Information Processing, 2006, Vol. 219, pp. 108-122. Springer 2006 17. J- Goguen and C. Linde, “Techniques for requirements elicitation,” International Symposium on Requirements Engineering, pp. 152-164 (1993) 18. T.S. Group, The Chaos Report. The Standish Group (2009) 19. R- Hossenlopp and K. Hass, “Unearthing business requirements: elicitation tools and techniques”, Management Concepts, Inc (2007) 20. Z. M. Kasirun, S. Salim, “Supporting collaborative requirements elicitation using Focus Group discussion,” International Journal of Software Engineering and Its Applications, Vol. 3(3), 59-70 (2009) 21. J. Kitzinger, “The methodology of Focus Groups: the importance of interaction between research participants,” Sociology of Health and Illness, Vol. 16, pp.103-121 (1994) 22. N. Kock, R. McQueen and J. Scott, “Can Action Research be made more rigorous in a positivist sense? The contribution of an iterative approach,” Journal of Systems and Information Technology, Vol.1(1), pp. 1-24 (1997) 23. V. Koshy, “Action Research for improving practice: a practical guide,” Sage Publications, Inc., London 2005 24. R. Krueger and M. Casey, “Focus Groups: a practical guide for applied research”, 3rd Edition, Sage Publications Inc., Thousand Oaks (2000) 25. J. Maté and A. Silva, “Requirements engineering for sociotechnical systems,” Information Science Publishing (2005) 26. B. Nuseibeh and S. Easterbrook, “Requirements engineering: a roadmap,” International Conference on Software Engineering (2000) 27. S. Pfleeger and J. Atlee, “Software engineering: theory and practice,” 3rd Ed., pp. 24-25, Prentice-Hall (1998) 28. J. Preece, Y. Rogers and H. Sharp, “Interaction design: beyond human-computer interaction,”. John Wiley & Sons, New York 2002 29. M. Saqid, M. Sahid and S. Ahmad, “Adding thread during software requirements elicitation and prioritization,” International Journal of Computer Applications, Vol. 1(9) (2010) 30. I. Sommerville, “Software engineering”, 8th Edition, Addison-Wesley (2007) 31. T. Tsumaki and T. Tamai, “A framework for matching requirements engineering techniques to project characteristics and situation changes,” Situational Requirements Engineering Processes (2005). 32. D. Zowghi, and C. Coulin, “Requirements elicitation: a survey of techniques, approaches, and tools,” Engineering & Managing Software Requirements, Aurum, A., Wohlin, C. (2005) 33. N. Maiden and S. Robertson, “Integrating creativity into requirements processes: experiences with an air traffic management system,” 13th IEEE International Requirements Engineering Conference, pp. 105 -114, Paris 2005 34. U. M. Borghoff and J. H. Schlichter, “Computer-supported cooperative work: introduction to distributed applications”, Springer Berlin Heidelberg, 2000 35. J. D. Herbsleb, "Global software engineering: the future of socio-technical coordination," fose, pp.188-198, Future of Software Engineering (FOSE '07), 2007 36. K. D. Todd and J. Cleland-Huang, “A dynamic approach for managing stakeholder credentials for lightweight, collaborative, requirements elicitation”, First International Workshop on Managing Requirements Knowledge, pp. 42-46, 2008 37. J. Whitehead, "Collaboration in software engineering: a roadmap," fose, pp.214-225, Future of Software Engineering (FOSE '07), 2007 38. M. K. Brown, B. Huettner and C. James-Tanny, “Managing virtual teams: getting the most from wikis, blogs, and other Collaborative Tools”, Wordware Publishing, Inc., 2006