Automated Requirements Elicitation for Global Software Development ...

180

Automated Requirements Elicitation for Global Software Development (GSD) Environment 1

Muhammad Ramzan, 1Asma Batool, 1Nasir Minhas, 1Zia ul Qayyum, 2 M. Arfan Jaffar 1

UIIT-PMAS Arid Agriculture University, Rawalpindi, Pakistan Gwangju Institute of Science & Technology, Gwangju, Korea

2

[email protected], [email protected], [email protected]

[email protected], [email protected]

Abstract. Global software development (GSD) outsourcing is a modern business strategy for producing high quality software at low cost. Most of the problems in Global software development (GSD) occur due to the lack of communication between stakeholders, time zone issues, cultural differences, etc. In this paper, our main emphasis will be to improve the Value-based requirement elicitation (VBRE) steps in GSD environment and also to overcome the major GSD environment problems while taking the process of requirement elicitation from valued stakeholders. Though this model works for every kind of project but, specifically it is good for generic software.

Keywords: Requirements Engineering, Global Software Development, Value Based Requirements Engineering

1

Introduction

Global Software Development (GSD) is an approach in which software development is performed in spite of cultural, temporal and geographical boundaries [1]. Global Software Development is considered as unexplored area which differentiates organizational forms in a very unique way from traditional global arrangements followed by many multinational corporations [18]. In GSD environment the software life cycle activities are distributed among teams across different limitations. GSD environment offers highly skilled personnel from different locations even on low cost, and, motivates many organizations to shift their business from one location to multiple locations where they get minimal cost, expenditure, quality work and around the clock service (24/7) [14]. Due to dispersed locations of teams, there are several risks/problems involved in GSD environment. Majorly include communication issues (time zone difference, distinct backgrounds, lack of informal communication, etc.), strategic issues (problem in task allocation), cultural issues, technical issues (problem in information and artifacts sharing), and knowledge management (poor documentation, etc) [2]. Requirement elicitation is also a question mark while working in GSD environment due to different locations of teams. This gets very tough job and causes problems such as incomplete requirements, misunderstanding of requirements, etc. GSD environment follows complete basic principles and steps of Software Engineering (SE) starting from requirement elicitation to maintenance of product. In today’s era, there are different kinds of parameters involved in Software Development. A Value Based Software Engineering (VBSE) has become known with the objective of incorporating value considerations into the full range of existing and known SE

T.-h. Kim et al. (Eds.): ASEA/DRBC/EL 2011, CCIS 257, pp. 180 – 189, 2011. © Springer-Verlag Berlin Heidelberg 2011

Automated Requirement Elicitation for (GSD) Environment

181

approaches, and of developing an overall framework [3]. The initial theory of value-based software engineering is ‘4+1’ and whole value-based software engineering is rotating around that theory. In this theory, engine lays in the center of all other four theories which determines that which values are important, and how the success is assured [3]. The method of finding out the reasons of software and then compiling them in proper document format to make it readily available for analysis and subsequent implementation is called Requirement Engineering (RE) [11]. Value represents the degree of importance or, in other words, value can be said as the amount that is fairly equivalent of anything else. In Value Based Requirement Engineering (VBRE), interests/goals of stakeholders are taken into account which may vary and conflict based on their perspectives of the environment [3]. Requirements engineers need to understand the creation of value for certain Software Company while also considering customer’s requirements [15]. Requirement gathering/elicitation is the first and major step in SE and the whole process of software development is based on this step. Requirement elicitation is the practice of obtaining the requirements of a system from users, customers and other stakeholders [4]. Thomas Satty [12] proposed statistical based technique called ‘The Analytic Hierarchy Process (AHP)’ for multi-criteria complex decision making problems. It can be used to value stakeholders on the basis of different parameters [13], like strength, influence, attitude, engagement level, experience, region etc. Requirement elicitation is non-trivial because one can never say that he has gathered complete requirements from the customer by just querying that what system should do. It includes face to face meetings, questionnaires, prototyping, use cases etc. Therefore, there are numerous difficulties and problems involved in this process. In [5], we have found that this paper addresses only the problems that are being faced during requirement elicitation while working in GSD environment and also, value based requirement elicitation are not taken into account at all. In this paper, we will present motivation towards value based requirement elicitation and present how value based requirement elicitation step can be made easy. We have got few steps from existing model to perform in a better way and to produce better results for the valued requirements. We will also present a model to elicit requirements based on stakeholder’s importance.

2

Related Work

Different scholars/authors have proposed different solutions to GSD environment problems such as Sang Won Lim, Taek Lee, Sangsoo Kim and Hoh Peter proposed a solution in The Value Gap Model: Value-Based Requirements Elicitation[10], and Gabriela N. Aranda, Aurora Vizcaíno, Alejandra Cechich, Mario Piattini proposed solution in Strategies to Minimize Problems in Global Requirements Elicitation[5]. The primary calculation of success of a software system is the extent to which it meets the purpose for which it was developed. Broadly speaking, software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation [11]. The critical success factor for software organizations is their ability to build a product that fulfills customer requirements and offers high value that provides enhanced comfort of market success [6] and [7]. As the end result/objective of a software organization is to increase the ROI, so there is a need to make the relationship between technical decisions and business strategy clear and unambiguous that leads to the value [8]. Boehm argues that


182

[7], software engineering (SE) is largely practiced in a value neutral way, i.e. every requirement is considered and valued equally, even though not all requirements are equal. There can be many ways to integrate different location’s attributes/characteristics with another location [9]. “Globalization” has become very major topic now-a-days and also has brought many advantages along for software development field [1]. Global Software Development (GSD) is a way in which the software development is performed beyond the boundaries such as contextual, organizational, cultural, temporal, geographical and political [1]. GSD environment needs more attention because in traditional software development, we do not give more attention to the factors which cause the different time zone, distance and cultural boundaries. Early rectification of the detections may improve the software development, reduce the cost and time consumption [16]. In GSD environment the software life cycle activities are distributed among teams across different boundaries. There is a need to globalize software development process in order to save time, cost and resources [9]. GSD environment offers highly skilled personnel with low cost. It is one of the reasons behind shifting software industry from co-located development to GSD [14]. This shifting brought some new challenges in software development. The problems arising from the geographical, temporal and socio-cultural distance are the main challenges for GSD environment. GSD environment erg to reduce these complexities and also needs to enhance the ability to focus on coordination of resources [17]. Sang [10] took SOA (Service Oriented Architecture) example to minimize the user value and system value. He claims that, initially, system value is higher than user value and fulfills users’ requirements. But with the passage of time, when user feels enhancements and changes in already developed service, then user value becomes higher than system value and user expectations are more. Then requirement gathering was performed against components based on user inputs i.e. which component is more important for certain user/group of users. The limitation of this model is that it works only for SOA based applications and limited to web services only. Aranda [5] argues that different steps can be performed to reduce the problems in GSD such as trainings to minimize the cultural differences, use of ontologies to reduce country wise problems such as different languages etc., use of asynchronous technology to overcome time zone difference etc. Here, the limitation with this solution is that, it works very well for simple requirement elicitation and does not consider value based requirement elicitation. Analytic Hierarchy Process (AHP) introduced by Thomas Satty [12] i.e. statistical based technique for multi-criteria complex decision making problems. It can be used to value stakeholders on the basis of different parameters [13], like strength, influence, attitude, engagement level, experience, region etc. In this approach, the stakeholders are filtered out in pair-wise fashion to determine the extent of how one of the stakeholders is more important than the others. For n number of stakeholders, AHP makes n (n-1) / 2 comparisons at each hierarchy level. In proposed model, we are working on value based software engineering and valuing our stakeholder using AHP in order to get their requirements efficiently. This model will cater every kind of project that is being developed by globally distributed teams but specifically for generic software.

3

Proposed Method

In today’s era, while talking about GSD environment, software decisions have pretty much significant effect on most software’s cost, schedule & value and gradually more in future. And value-neutral software decisions can dangerously humiliate project outcomes. Now-a-days, in software engineering, there is much different kind of parameters involved to which value-neutral cannot deal with and results in failure if applied. For example, value-neutral approach cannot handle most of the sources of software project failure. It is also difficult to make financially responsible decisions using value-neutral methods


183

because it treats every parameter equally. Therefore, financial matters cannot be given high priority/importance while using value-neutral methods. As many organizations are switching from local software development to global software development (outsourcing) and also value based requirements elicitation is a new concept in this field, we have decided to work to combine value based requirements elicitation and GSD. In past , most of the research so far done in GSD environment, the focus mostly remains to overcome the general GSD environment challenges such as communication, cultural difference time zone etc. Our focus is to take value base requirement elicitation in GSD. For the GSD environment, that will make the global phenomena of GSD environment more prominent and effective. Requirement elicitation is not only a major step in software engineering but also a key factor. And we will be targeting this key factor in our proposed model to elicit requirements from our valued stakeholders in an easy way out. We have taken few steps from existing model to modify it according to VBRE in order to produce better results in GSD environment. Complete architecture of the proposed framework ensures the filtration of valued stakeholders and removes the GSD issues if faced by those stakeholders and then elicit requirements from those valued stakeholders. Overall structure of our proposed framework is consisting of 5 steps as shown in figure 1 and figure 2. Basically these 5 steps show the flow of our work that how it will work. Each of these 5 steps, perform a valid functionality in proposed framework. We will discuss each and every step one by one in detail below.

FIGURE 1: GENERATION OF VALUE STAKEHOLDERS (STEP 1)

3.1

STEP 1(VALUE ASSIGNMENT TO STAKEHOLDERS)

The objective is to filter out the valued stakeholders from the complete list of all stakeholders by applying Analytical Hierarchy Process (AHP) against few parameters. For this purpose first we maintain a user profile of each stakeholder that contains information about that stakeholder. That information would be about culture, temporal difference, communication, timings etc. And now will define parameters against stakeholders e.g. time of availability, culture difference, role of stakeholder, mean of communication,


184

strengths, weakness etc. We will extract all this information from personal information questionnaire. When stakeholder will login to our system by putting his user name and password which is assigned to them, personal information questionnaire automatically send to all of them. This questionnaire will be same for all stakeholders and plays important role in identifying personal information and parameters; those will help us out in valuing stakeholders. 3.2 STEP 2 (GATHER INFORMAL REQUIREMENTS/ INITIAL REQUIREMENTS) After the identification of valued stakeholders, now the objective is to elicit valued requirements from valued stakeholders. In this phase, we will discuss existing technique/model that has been used to remove the challenges of GSD if faced during elicitation process.

FIGURE 2: ELICITATION OF VALUED REQUIREMENTS FROM VALUED STAKEHOLDERS


185

The input of this phase is a list of valued stakeholders and output will be the requirements in raw form that have been gathered from those stakeholders through electronic means. Stakeholder will select his/her project from different projects which are present at that time on our system. Then he is free to ask any type of question about his/her project and he can also describe his requirements in Word file relevant to that project but within threshold time. Threshold time is defined for the purpose of GSD environment as; we are trying to provide our users a time controlled system. This session will be closed for stakeholders after threshold time. They can login to observe the set of requirements place by different stakeholders and to see whether a refined questionnaire is uploaded or not by the management but cannot fix any of their requirements after threshold time. 3.3 STEP 3 (REQUIREMENT ENGINEERING PHASE) We can say step 3 is a requirement engineer’s phase. In this step, all set of requirements place by valued stakeholders are gathered at one place. At this time requirement engineer will purify those requirements according to project needs and will make an experienced questionnaire according to project scope which meets effectively the demands of all stakeholders. Now system analyst or team lead will check that questionnaire, construct it more polished if needs and build options against every requirement so that, stakeholder can choose any one of them. After embedment’s questionnaire uploaded for valued stakeholders and notifies them also through mail. We will send them questionnaires to fill and revisit their feedback in that questionnaire. It’s assumed that system analyst or team lead can make questionnaire more distinguished, but it’s up to project needs, any one of your employee who can work well and competently on that project you can place him/her on questionnaire improvement. 3.4 STEP 4 (STAKEHOLDERS’ FEEDBACK) If we get response from them within the specified threshold, good enough and we can proceed further to our model design. But, in case, we don’t get response from them within specific period of time, then we’ll analyze the received feedback. If that is below average, then we will extend our threshold limit and will wait until and unless we get at least average number of responses from valued stakeholders. 3.5 STEP 5 (FINAL REPORT AND GRAPH GENERATION) After getting response from stakeholders, we’ll check all the requirements and figure out that how many stakeholders have selected a same option against certain requirement. . If same value occurs for two options of one requirement, we will prefer the option whose stakeholder value is more than the other one. The following formula will be applied if one unnecessary option of requirements is selected by at least one valued stakeholder and some important options have been selected by more than one ordinary stakeholder. The formula is applied by selecting the number of frequency and value of stakeholders by AHP. At the end, ultimately, we will get the value of requirements by applying this formula (see table 1). For example we have considered a requirement i.e. R1: In which form you want to take the employees report? Tabular Diagram Graphical Charts


186

TABLE 1: SELECTING VALUE BASED REQUIREMNTS REQUIREME NT

NO. OF RESPONSES

VALUE OF STAKEHOLDER

RELATIVE FREQUENCY

WEIGHTED VALUED REQUIREMENT

Options 1

12

45

0.5217

23.4782

Option 2

5

76

0.2173

16.5217

Option 3

1

54

0.0434

2.34782

Option 4

0

32

0

0

Option 5

5

88

0.2173

19.1304

Sum=

23

1

Different stakeholder will give different response against this requirement. So our formula will calculate the number of responses and gives us better response which suits well according to our project. At the end report will be generated which shows the valued requirements in a sequence of their values. Figure 2 shows the graphical representation of the table 1.

100

No. Of responses

80 Value of stackholder

60 40

Relative frequency

20 0 options option option option option 1 2 3 4 5

Weighted valued requirement

FIGURE 3: GRAPHICAL REPRESENTATION OF VALUED REQUIREMENTS

After executing all of the above steps, we will have responses and feedbacks from valued stakeholders. Now, after analyzing those feedbacks and responses gathered through questionnaires and GUI based forms, we can elicit valued requirements in better way. We have referred the existing model (Gabriela et. al. 2008) to remove GSD problems. This technique will be used if GSD related issues are faced. If there are cultural differences that are medium or high, then training sessions will be conducted to bring awareness to the stakeholders about other’s cultures to remove the cultural differences between stakeholders. There can be plus points in other’s cultures that can be adopted. Theoretical evaluation of model, all the research in requirements engineering that has taken place up till now is either based on no value or if value is considered, then used value neutral method. In value neutral technique, every requirement has been given equal


187

importance whereas in reality and also according to current era, it is not true and feasible. There was no mechanism to give importance to certain stakeholders and, therefore, every stakeholder had the same importance level. Furthermore, the questionnaires those were used to send to stakeholders in order to elicit requirements from them, was the same for each and every stakeholders. We have used existing model to overcome the problems faced in requirements elicitation while working in GSD environment. We have devised a mechanism to filter out valued stakeholders from a bunch of raw data gathered based on few characteristics. Then we send stakeholders questionnaires. And, finally, elicit valued requirements from valued stakeholders. In short, this model works on value based software engineering and values every entity/requirement according to needs. This model is not only important because of work in value based requirements elicitation, but also overcomes the challenges of GSD environment.

4. CASE STUDY AHP (Analytical Hierarchy Process) is a strong and flexible decision making technique which helps in setting main concerns and reaching most favorable decisions in situations when quantitative and qualitative aspects have already been taken into consideration. AHP is a methodology that helps out in filtering the alternatives against certain criteria. Generally, it takes an alternative such that the number of input, and asks the criteria to process and filter that input. We have used 123AHP tool to filter out and valuing stakeholders. We have passed stakeholders, and number of stakeholders to this tool to value them. Plus we will be passing the criteria/parameters against which this tool will return us the valued stakeholders. The internal process of this tool is explained in the section below. First of all, this will ask the important parameters/ criteria and then compare each parameter/ criteria with other parameters/ criteria (e.g. P1 > P2). Then, each parameter will be compared with every stakeholder/alternative to identify how much certain stakeholder/alternative have importance on other stakeholders/alternative against that parameter (e.g. S1 > S2) (see figure 4). At the end of this process, this tool will return the result in the following way and we will get a list of valued stakeholders.

1. S4

(0,3021)

2. S3 3. S1 4. S2

(0,2822) (0,2282) (0,1875)

FIGURE 4: AHP RESULTS CONCLUSIONS and FUTURE WORK At requirement engineering process while working in GSD environment, requirement elicitation is difficult, and different stakeholders have different opinions and expectations


188

about the system. Problem occurs when stakeholders are not valued. Requirement gathering is a very tough job when teams are at dispersed locations. This model will minimize the difficulties and hurdles faced during requirement engineering process in GSD environment. Through this model, one can get clear picture of stakeholder’s requirement. In future work, we will prove worth and validation of our model through case study to formulate in detail. Our main emphasis will be to generate questionnaires based forms in order to get requirements efficiently from valued stakeholders that will show how easily and efficiently we can elicit requirements.


189

REFERENCES [1] A. Ali Khan and Z. Ullah Muhammad, “Exploring the Accuracy of Existing Effort Estimation Methods for Distributed Software Projects”, 2009 [2] P. Mohagheghi, “Global Software Development: Issues, Solutions, and Challenges”, 2004 [3] B. Barry, “Value-Based Software Engineering”, 2003 [4] S. Ian, P. Sawyer, J. Wiley and Sons, “Requirements engineering A good practice guide”, 1997. [5] N. Aranda, A. Vizcaíno, A. Cechich1 and M. Piattini, “Strategies to minimize problems in Global Requirement elicitation”, 2008. [6] A. Aurum, C. Wohlin, and A. Porter, “Aligning Software Engineering Decisions”, International Journal on Software Engineering and Knowledge Engineering (IJSEKE) 16(6), 795–818 (2006) [7] S. Biffl, A. Aurum, B. Boehm, H. Erdogmus and P. Grunbacher, (eds.): “ValueBased Software Engineering”. Springer, Heidelberg (2005) [8] B. Boehm, W. Sullivan, and K.J.Software Economics: A Roadmap.” In: Proceedings of The Future of Software Engineering Conference, pp. 319–343 (2000) [9] D. Šmite “Global Software Development Projects in One of the Biggest Companies in Latvia: Is Geographical Distribution a Problem”, In the SPIP journal, Wiley,; Vol.11, pp.61-76, 2006 [10] S. Won Lim, T. Lee, S. Kim and H. Peter proposed a solution in The Value Gap Model: Value-Based Requirements Elicitation [11] B. Nuseibeh and S. Easterbrook, “Requirements Engineering: A Roadmap”, 2000 [12] L. T. Satty, “The Analytic Hierarchy Process, “McGraw-Hill, New York, 1980. [13] A. Aum, “Engineering and managing software requirements”. Springer. [14] I. Lehtonen, “Communication Challenges in Agile Global Software Development”, 2009 [15] A. Aurum, C.Wohlin “A Value-Based Approach in Requirements Engineering: Explaining Some of the Fundamental Concepts”, 2007 [16] D. Zowghi,” Does Global Software Development Need a Different Requirements Engineering Process? “, 2003 [17] D. Šmite, J. Borzovs “Managing Uncertainty in Globally Distributed Software Development Projects”, University of Latvia, Computer Science and Information Technologies, Volume 733, pp. 9-23, 2008 [18] D. Smite, Doctoral Thesis: “Global Software Engineering Improvement”, University of Latvia, 2007