Requirement Elicitation Framework for Global Software Development

Objectives/methods: In the development process of a software product the requirement gathering is the most significant part of this procedure. The very close interaction of all stakeholders is required to build quality software and in a global software development environment, daily or frequent meetings between all stakeholders are not possible and also costly. To achieve a common understanding of requirements is a challenging task in case of global software development projects. In this situation to get the right requirements is a complicated job. In this study, a framework is presented for improving communication during Requirement Elicitation using strategies and best elicitation techniques for them with Cased Based Reasoning in GSD environment. Findings/application: In this research, we have to use a case study of a real-time project. This has resulted in a framework for improving communication, selecting the best elicitation techniques and CBR for requirement repository in GSD environment. The framework provides a guideline to requirement engineers regarding issues in communication, best strategies and suited elicitation techniques to effectively elicit requirement is GSD environment.


Introduction
Requirement Elicitation is considered a crucial stage in the Software development life cycle and it becomes more complex when all stakeholders are globally distributed because in these cases communication between them is a big problem. 1 A system is built on the basis of requirements gathered so success or failure totally depends upon those requirements. It will be better to say that project success mainly based on value of requirements and quality of requirements is reliant on the method that is adopted in getting these requirements. 2 Agreeing to a survey conducted by ESPI during 1995 that 40-60% of software projects mistakes found can be followed back to the stage of requirement elicitation process and another survey conducted in 1994 by Standish Gather 3 reveals that 13.1% projects failure cause is incomplete requirement and 8.8% projects failure is due to changes in requirements.
Last decade's Global Software Development (GSD) has progressively become the common exercise in the industry of the software. GSD involves software development at geologically dispersed places with wellorganized coordination and asynchronous collaborations. GSD is designed to gain benefits of reduction in development cost, reduced time-to-market and better use of scarce resources. It requires even more attention when the stakeholders are located in different areas, has different languages and unfamiliar culture and values. Such a distributed environment causes many challenges for requirement engineers as well as developers. In such conditions, effective communication and coordination is the main challenge for efficient software development in a global environment. For GSD process not only face to face interaction but there are also many challenges which development team has to face. There are many frameworks suggested by different for requirement gathering processes for GSD that are not sufficient and not suitable as previous studies show these strategies have a lack of capabilities. To deal with the process of the communication problem and requirement elicitation analyst may select one available strategy or he adopts many strategies. 4

Challenges in GSD
Common challenges in GSD are:

Inadequate Communication
When we talk about GSD, communication is the main problem that affects directly the success or failure of the project. Because in Global Software Development communication is reduced it may take place between few people. Lack of communication may cause a wrong understanding of requirements and this can affect the whole project resulted in project failure or increased cost. If communication problems are tackled before the requirement elicitation phase, they will not affect the overall development process and cost will also be decreased.

Time Difference
Another challenge in GSD is the time zone difference. In GSD, the team is at geographically separated areas and timings usually do not overlap or overlap for a short time. This also becomes a barrier in outsourcing projects as synchronous communication is not possible. 5 This challenge cause delays in the projects.

Cultural Diversity
In GSD, stakeholders are from different geographical areas they have different cultures and values like religion, holiday, weekend, break timings. Cultural differences may not be avoided but stakeholders must be aware of other cultures. 6 In addition to cultural diversity in GSD, language differences may also be a deal. Usually, their native language is different and the level of common language knowledge is also different. These differences may cause a misunderstanding of words; expression in requirement gathering. This may cause delay or failure of the project due to wrong understandings. As explained earlier, it is better to detect misunderstanding and communication gaps as soon as possible so that their significances can easily be proscribed.

Background
Organizations are switching their workers to ensure trade and benefit where contracts are supposed to be less costly and the availability of skilled labor for better quality products. 7 Developing software is a thorny path that faces many challenges. Many of them hamper the value of applications that developers want to fix. 8 In reality, software performance is the most important factor for software development and is directly linked to a software project's success. When software engineering continued to expand its projects have become more complex as well as the development process. With the obvious benefits, decentralized teams still face challenges despite reliable and efficient communication patterns leading to project failure. The fact that groups encounter difficulties operating on a cooperative basis is usually attributed to weaknesses during the elicitation cycle. 9 This study is based on field study reports that explored RE challenges presented by stakeholders' geographic dispersal in a multi-site organization. The goal was to observe RE practice in global software development, to articulate recommendations for progression 10 and to give guidelines for future research on procedures and tools. Based on the empirical evidence, the author presented a model for distant communication and knowledge management, diversity of cultures and differences in time negatively influence requirements collecting, negotiation and specification. 11 Stakeholders in the GSD environment communicate with means of groupware tools. 12 The process of knowledge management requirement Engineering 13 is also vague and not be suitable for tackling RE for GSD. It is significant to oversee the changes during requirement elicitation process to achieve successful software but requirement change management is not so easy process when all the stakeholders are distributed. 14 Many research shows that the use of ontology 15 is effective technique but it is not good for GSD where changes in RE are exposed. So, we analyzed tools that are more frequently used in distributed environment news-groups, mailing lists, e-mails, forums, shared whiteboards, electronic notice boards, document sharing, videoconferencing, chat and instant messaging.
Many frameworks have been suggested by the researchers to facilitate the process of requirement elicitation in a geographically distributed environment. Several researchers address critical success factors such as the use of collaboration tools and technologies, good communication and other success factors 16 and many frameworks have been proposed 5,17 for improving the process of requirement elicitation in GSD environment. In all these frameworks were still not fulfilling the needs for the process of elicitation for successful software development. The author presents a collaborative environment to take in stakeholders during requirements elicitation with the help of online teamwork and the use of visualization techniques to stimulate stakeholders and consequently increasing their attentiveness towards requirements.
The Author introduces a procedure by combining different techniques to detect the issues which may happen during the requirement elicitation process like cultural difference, language difference, time difference and propose solutions to reduce them. The presented framework is a novel approach to facilitate the requirement gathering process in the GSD environment.
A number of surveys of software houses have been done to find the efficiency of requirements elicitation technique which is using GSD. According to the survey report prototyping, questionnaire interviews and scenarios are the most effective elicitation techniques in GSD. And propose an iterative global elicitation model.
In this research, by using the knowledge-based system a framework for requirement elicitation is proposed, which is very useful for knowledge documentation, smart assessment support, self-learning and particularly it is very useful for case based reasoning and explanation. By using this procedure of Artificial Intelligence (AI) expert system using different sources e.g. interviews, scenarios or use case requirements are gathered. Then, these are transformed into organized natural language by using ontology and this new issue/case is set forth to Case Based Reasoning (CBR).

Proposed Framework
The proposed technique is used to solve communication issues during the elicitation phase of requirement engineering in the GSD environment. The problems that may be faced by requirement engineers are due to communication, cultural and time differences. To handle all these issues and saving time for requirement engineers we propose this technique. Our techniques comprised of three parts. In the first part communication problems are identified than different strategies are applied to overcome these issues. In the second part, we have an expert system, where the prior experience of selected experts is used. In the third part, we have various elicitation techniques like interviews, scenarios, Questionnaires and prototypes. And then overall knowledge is managed where cased based reasoning is used to store it for future use as shown in Figure 1.

Communication Problems and Strategies
As communication problems are identified in GSD different strategies are applied according to each problem. As we mentioned earlier our focus is to define strategies to solve main issues in GSD. We select previously discussed issues in GSD through SLR and define a strategy against them. There are three strategies

Training Cultural Difference
Cultural differences can't be avoided but stakeholders can learn about different cultures. It is very rare that a stakeholder is already aware of normal behaviors in other cultures. To minimize these cultural difference following are the approaches

Cultural Mediation
It is about taking advantage of others who have visited sites before so they can better identify the normal behavior of foreign culture. Those peoples are called mediators.

Virtual Monitoring
This is based on virtual actors and simulation and it can be an interesting way for stakeholders to train about foreign languages and cultural familiarization. In GSD projects, language differences must also be a deal. Stakeholders may or may not share the same language.

Use of Ontology
In GSD projects, language differences must also be a deal. Stakeholders may or may not share the same language. If they are from the same country than understanding between them is not any problem. But misunderstanding may occur when they are from different countries, as a result of the fact that one word has more than one meaning or different words may have the same concept. Our proposal is to generate common vocabulary by using domain ontology.

Use of Groupware Tools
When time overlap is low, synchronous communication is difficult. Therefore, we recommend asynchronous groupware tools for communication. As they enable stakeholders to communicate while they are geographically dispersed. Groupware tools include email, faxing, wikis, online chat, social software, project management systems etc.

Expert System
Requirement engineer is experts, they gather information from the external environment and stakeholders. Experts collect information about a particular domain and current problems. We proposed that an expert's knowledge is helpful regarding the requirements gathering. The expert knowledge may be domain knowledge, Existing knowledge and prior experience. Domain knowledge is knowledge about the environment in which the targeted System operates. The expert may have already prior experience existing knowledge regarding the problem domain.

Effective Elicitation Techniques
The next step towards our framework is the selection of the elicitation technique that is performed after selecting the strategy with expert knowledge. There are many elicitations techniques for requirement gathering and each has its own advantages and disadvantages. In the GSD environment, all techniques are not suitable. The most effective elicitation techniques in GSD are prototyping, questioners, interviews and scenarios. So at this level most effective elicitation technique is selected according to the situation.

Knowledge Management Using Cased Based Reasoning
At this point system analyst has detail knowledge about the specific requirement. To maintain this knowledge we use an artificial intelligence technique known as case based reasoning. In which the repository of cases is maintained by specifying a case for each requirement. So finally it can be saved for future reference into case based reason. CBR at the elicitation phase reduced the burden and save a lot of time for requirement engineers.

The flow of the Proposed Framework
The detailed flow of framework presented in Figure 2 is presented as under • The first task in the proposed framework is to minimize communication problems defining strategies Muhammad Asgher Nadeem and Scott Uk-Jin Lee against them. Cultural differences cannot be avoided but stakeholders can be trained about culture. Stakeholders can be trained through cultural mediation, virtual monitoring, seminars and courses • If stakeholders are from different countries than language is a major problem of communication. We propose the generation of common vocabulary by using domain ontology. It will help to avoid errors and problems during communication.
• Synchronous communication is difficult when time overlap is low in this situation asynchronous groupware tools are selected for communication according to the cognitive style of stakeholders. • Finally, we combine these three strategies for the selection of technology which is more suitable for the team. • When a team of experts is selected our next step is to use expert knowledge. Experts may have a domain • Knowledge, prior experience and information regarding problem domain. If they have such knowledge, this knowledge will be extracted so all this information will be helpful for eliciting requirements. Either they have knowledge or not they proceeded to the next step. • The next step is requirement gathering through effective elicitation techniques. Interviews, questionnaires, prototyping and scenario all are effective in the GSD environment. One or more techniques can be selected according to a given situation. • After the requirements elicitation process completed, our last step is to maintain a repository of cases for each requirement. If a new requirement is already in the repository than new information is added in an old case and a new solution is saved in the repository.

Evaluation
To evaluate our proposed framework, we use a case study approach. We evaluate our framework on ERP solutions for the pharmaceutical sector being developed in a GSD based firm (X) located in Pakistan with offices in the USA and Germany. They are working in a collaborated environment like development, testing and requirement engineering teams are in Pakistan while marketing and QA teams are in the USA and Germany. They follow a typical change requirement elicitation process which is difficult to follow in the GSD environment. As there are many combination issues as described earlier like time, language and culture differences as shown in Figure 3.
We implement our framework for a project ERP solution that had to be deployed in the USA pharmaceutical Company (Y). After deployment of the project, we evaluate our proposed work with their typical elicitation process which they were already using. We ask an expert of that company for their reviews when the proposed model is implemented in their organization. Then reviews are collected from them about the requirement elicitation process with this proposed model and without using the proposed model. The difference between the performance id checked when they use the proposed model. According to the experts, the proposed model is a better approach for requirement elicitation for any organization. The technique of applying strategies to select the expert's team for requirement elicitation proved more effective in global software development. And the AI technique CBR, which is used to maintain the repository of all requirements, is an efficient approach. The panel consists of 10 experts including one is the project manager having 11 years of experience, a team leader having 8 years of experience, two software engineers having 3 and 4 year experience respectively, one software engineer having 6 years of experience, two Requirement engineers and one stakeholder, requirement analyst and QA.

Conclusion
Incomplete or wrong requirements gather during the elicitation phase can cause complex and expensive errors in the development of a project. The main aim of this research is to present a unique framework that would help to accommodate changes in requirements in global software development. We use strategies for communication issues, affected elicitation techniques and case based reasoning to maintain a repository for requirements. For the assessment of the proposed model use case study of a real-time project and expert views.
In the future, more case studies of medium and largescale organizations can be conducted for the Requirement elicitation process for further evaluation.