Significant Requirements Engineering Practices for Software Development Outsourcing

Size: px
Start display at page:

Download "Significant Requirements Engineering Practices for Software Development Outsourcing"

Transcription

1 Sgnfcant Requrements Engneerng Practces for Software Development Outsourcng Javed Iqbal, Rodna Ahmad, Mohd Harul Nzam Md Nasr Faculty of Computer Scence & Informaton Tech., Unversty of Malaya, Kuala Lumpur, Malaysa {rodna, Muhammad Asm Noor Department of Computer Scence, COMSATS Insttute of Informaton Technology, Islamabad, Pakstan Abstract The volume of software development outsourcng s growng enormously owng to the assocated benefts of outsourcng and lmtatons of organzatons. However, a large number of the projects outsourced for software development are faled to acheve antcpated results. In most of such cases, the reasons for falure are traced back to the Requrements Engneerng RE) process. In spte of ths state of affars, adequate efforts have not been made to avod the falure of outsourced software development projects due to RE process ssues. Ths research has been conducted wth the am of cultvatng the RE process for software development outsourcng by dentfyng the sgnfcant RE practces for ths process. The study s based upon Sommervlle and Sawyer s RE practces for sx key areas of the RE process. A survey research method has been used to collect data from 108 practtoners belongng to 18 natonal and multnatonal organzatons assocated wth software development outsourcng. After analyss of the obtaned data, we have dentfed the RE practces whch are sgnfcant n order to mprove the RE process for software development outsourcng and hence to acheve desred results. TABLE I. INTERNATIONAL IT OUTSOURCING MARKET REVENUE IN 2011 Rank Vendor Revenue n 2011 mllon dollars) Revenue %age 1 IBM 26, HP 15, Fujtsu 10, CSC 10, Accenture 6, Others 176, Total 246, Fg. 1 shows the percentages of these revenue shares dagrammatcally. Accordng to a smlar 2011 report by Gartner, the top fve revenue producers through ITO are IBM, HP, CSC, Fujtsu and NTT Data wth IBM agan on the top. Accenture, T-Systems, BT, Capgemn and SIS are the other fve companes on the lst of the top ten ITO revenue generator vendors for the year Keywords-software development outsourcng; IT outsourcng; requrements engneerng process; requrements engneerng practces. I. INTRODUCTION In IT outsourcng, an organzaton procures the servces of IT from external resources n order to perform software development and related actvtes [4]. As per a 2012 report publshed by the USA based IT research company Gartner, revenue of the nternatonal IT Outsourcng ITO) market has rased from $228.7 bllon n 2010 to $246.6 bllon $246,555 mllon) n 2011 wth a growth of 7.8%. IBM, HP, Fujtsu, CSC and Accenture are the top fve shareholders n ths revenue [24]. Table I provdes detals of the revenue generated by the top fve ITO vendors. These vendors own $69.9 bllon or a 28.3% share, wth IBM on the top. NTT Data, T-Systems, Atos, TCS and Capgemn are the other fve vendors on the lst of the top ten revenue generators through ITO durng the year Fgure 1. Internatonal IT Outsourcng market 2011-revenue shares. Accordng to Boehm [10], the major motvaton behnd outsourcng s lessenng the overall cost. Outsourcng causes have two classes. ): Outsourcng benefts such as reducton n cost, accessblty to hgh-qualty capabltes, process usefulness, outsourcng of non-core organzatonal actvtes and releasng nternal resources. ): Organzatonal constrants such as problems wth the management of IT functons, shortage of resources and requred sklls [5]. There are four dfferent scenaros of IT outsourcng:

2 a) When a contractor provdes servces at the locaton of the outsourcng organzaton. b) In the case of On Shorng Outsourcng or Domestc Outsourcng, servces are not provded at the outsourcng locaton but the contractor operates from the same country. c) Contractor provdes servces from another country: If servces are provded from the same regon/nearby country, t s called Near Shorng. If a vendor supples servces from a far off country, t s called Off Shorng. d) When multple contractors/vendors are nvolved: When stakeholders are geographcally dspersed, we call t Dstrbuted Software Development or DSD. When dstances among the stakeholders become global, t s called Global Software Development or GSD [4]. In Software Development Outsourcng SDO) the vendor performs some or all of the software development actvtes for the clent. The dea of SDO s becomng popular rapdly [7] [8]. It creates a state whch s a wn-wn stuaton for both the developed and developng countres [11]. Software rsk s a potental danger whch, f occurs, can cause undesred results [9]. In spte of all the technologcal advancements and the expendture of essental resources, the falure rate of outsourced projects s hgh. Hgh turnover of staff, resstance aganst change, hdden costs, expanson of scope, refutaton of the contractor from the servce provson, use of out-dated technology by the vendor, ssues of law, cultural dfferences, and hgh dutes and tax rates at the vendor s locaton are some of the most common rsks for outsourced projects. But rsks related to software requrements are the man reason for the falure of outsourced projects [6] [12]. Ths s not surprsng as Requrements Engneerng RE) s the most mportant phase of the software development lfe cycle [13] that affects the other software development actvtes sgnfcantly [14]. For outsourced projects where the clents and vendors are located at dfferent places [15], the requrements problems are expected to ncrease many tmes [16]. Lack of communcaton or mproper communcaton, dfferent workng hours, rare head to head meetngs, language ssues and dssmlar workng practces are some of reasons for requrements problems augmentaton n the case of outsourcng. That s why 40 percent of off-shore projects do not acheve expected benefts [17], and half of the companes tryng GSD are faled to attan antcpated results [18]. Accordng to Herbsleb [19], elctaton and communcaton of the software requrements s one of the four challenges of globally dstrbuted software development projects. Therefore, to acqure the antcpated benefts of SDO, sgnfcant RE practces for SDO must be dentfed n order to contrbute towards the enhancement of the RE process. Uncertanty of requrements and assocated rsks must also be addressed n order to mtgate overall project rsks [20]. Wth ths context, ths study ntends to answer the followng research queston: Research Queston: Whch RE practces are sgnfcant for outsourced software development projects? II. RESEARCH METHODOLOGY Takng nto consderaton the research purpose and avalable resources, a survey research method has been utlzed n order to attan data regardng sgnfcant RE practces for SDO. The survey s based upon Sommervlle and Sawyer s 49 RE practces [27] for sx key areas of the RE process whch are elctaton of requrements, analysng and negotatng requrements, requrements descrpton, modelng requrements, valdatng requrements and managng requrements. The survey research method s looked upon as an approprate way for the collecton of qualtatve or quanttatve data [1]. Usually, a combnaton of varous technques for data collecton such as ntervew and questonnare or any of these technques s used n a survey research method [2]. To gather the data about sgnfcant RE practces, the questonnare ncludes the closed format questons as well as the open format questons. The closed format questons are to select the ranks out of the four gven ranks) of benefts of RE practces for SDO. The open format questons are to ask from the respondents f they are usng the RE practces other than the gven RE practces related to a RE process area. The questonnare contans two parts. The purpose of the frst part s to collect data about the respondents experence, job nature and respectve companes. The second part s for data collecton about the sgnfcant RE practces. The respondents are project managers, software engneers, team leaders, qualty assurance managers, programmers, desgners, requrements engneers, analysts, manager operatons and other practtoners havng SDO experence wth 18 natonal and multnatonal organzatons. These practtoners can be dvde nto three categores of developers, managers and senor managers [22]. To mprove the questonnare layout, assess the language comprehenson and estmate the tme requred to complete the questonnare, two rounds of plot study have been conducted. Recommendatons have been ncorporated after the frst round. The second round has been carred out to ensure that the changes made are accordng to the gven suggestons. A total of 130 questonnares have been sent to SDO experts. Sxty 60) questonnares have been sent out through emals and seventy 70) questonnares have been dstrbuted and flled out durng face-to-face meetngs. The survey has been conducted by usng a sem-supervsed approach [3] n whch the objectves of the survey, questonnare format and varous queres regardng the questonnare are made clear ether personally durng faceto-face meetngs or through dfferent technques lke the Computer-Asssted Telephone Intervewng CATI) technque. After that, respondents are gven sutable tme to fll the questonnares on ther own. The total responses whch we have receved back through the emals are 45. Out of a total of ) responses, the 108T) responses have been selected for analyss based on the respondent s company profle, job ttle and relevant experence. We have requested the practtoners to rank the Sommervlle and Sawyer s RE practces for sx key areas accordng to the

3 perceved benefts of RE practces for SDO. The dfferent ranks or categores of perceved benefts are [18] [23]: Hgh Perceved Benefts: An RE practce has hgh perceved benefts f t s mandatory and always used. edum Perceved Benefts: An RE practce has medum perceved benefts f t s not mandatory but wdely used. Low Perceved Benefts: An RE practce has low perceved benefts f t s used only for some partcular projects. Zero Perceved Benefts: An RE practce has zero perceved benefts f t s never or rarely used. A. Crtera for the Selecton of Sgnfcant RE Practces for Software Development Outsourcng If, accordng to the responses of at least 50% of respondents, the perceved benefts of a RE practce fall n the hgh perceved benefts and the medum perceved benefts categores then that RE practce s consdered to be sgnfcant for outsourced software development projects. A smlar method, usng the crteron of consderng the opnon of 50% or more respondents for decson makng, has already been employed effectvely n precedng studes [21][22][23]. Raner and Hall [21] have dentfed key or mportant factors for software process mprovement by usng the prncple that f 50% or more respondents beleve that a factor has a major mpact then that factor wll be treated as mportant. By sgnfcant we mean mportant to be worthy of attenton or mportant enough to have an effect [30] [31]. To dentfy the sgnfcant RE practces for SDO, we have taken nto account the hgh perceved benefts category and also the medum perceved benefts category [18]. The ratonale for ths decson s that a RE practce havng hgh perceved benefts s always followed.e., t s mandatory. Hence such RE practce must have sgnfcance for SDO. Lkewse a RE practce wth medum perceved benefts s wdely followed although t s not mandatory. Thus the RE practces provdng medum benefts are frequently followed, therefore, such practces cannot be gnored and must also be consdered sgnfcant for SDO. For each RE practce, the Promnence Level ) represents the percentage of responses n hgh perceved benefts and medum perceved benefts categores and s calculated as gven n 1): = [H + M ) / T] ) III. RESULTS AND DISCUSSIONS Ths secton presents the dscusson on the obtaned results wth partcular reference to the research queston. Results and dscussons have been organzed under sx headngs based upon sx key areas of the RE process.e., ): Practces for Elctaton of Requrements, ): Practces for Analysng and Negotatng Requrements, ): Requrements Descrpton Practces, v): System Modelng Practces, v): Requrements Valdaton Practces, and v): Requrements Management Practces. Requrements Engneerng Practces REPs) have been dentfed by usng a unque Identfcaton Number ) from REP 1, REP 2, REP 3 to REP 49. A. Requrements Elctaton Practces Table II shows 13 n 1 =13) requrements elctaton practces represented by REP n n = 1, 2,, 13); the frequences of dfferent ranks denoted by H, M, L and Z = 1, 2,, 13) for hgh, medum, low and zero perceved benefts respectvely. n1 1 0 REP n n1 1 L Z ) n There are %) requrements elctaton practces. Practces wth at least 50 or practces about whch at least 50% of respondents thnk that the perceved benefts of these practces for SDO are hgh and medum, wll be consdered as sgnfcant REPs. As table II shows, wth the excepton of REP 2 and REP 9, the remanng %) elctaton practces meet the promnence crteron. So REP 1, REP 3, REP 4, REP 5, REP 6, REP 7, REP 8, REP 10, REP 11, REP 12 and REP 13 are sgnfcant requrements elctaton practces for SDO. REP 1 REP 2 REP 3 REP 4 REP 5 REP 6 REP 7 REP 8 REP 9 REP 10 REP 11 REP 12 REP 13 TABLE II. Practce Assess system feasblty. Senstvty to organzatonal and poltcal consderatons. Identfyng stakeholders of system and consultng them. Recordng requrements orgnatng sources. Defnng operatng envronment of system. Usng concerns of busness for dervaton of the elctaton of requrements. Look for doman constrants. Record requrements ratonale. Collect requrements from multple vewponts. Prototype the poorly understood requrements. Use scenaros to elct requrements. Defne operatonal processes. Reuse requrements from already developed smlar systems. REQUIREMENTS ELICITATION PRACTICES H M L Z

4 We are surprsed that only %) respondents out of the 108, stated beng senstve to the organzatonal and poltcal consderatons REP 2 ) as sgnfcant for SDO. The reason behnd ths approach may be that practtoners want to avod organzatonal poltcs consderng such poltcs above ther levels and dutes. We have also explored that the RE practce of collectng requrements from multple vewponts REP 9 ) has hgh and medum benefts for SDO accordng to the thnkng of only 46.30% practtoners. It seems that gatherng requrements from the pont of vew of multple sources such as managers, end-users and customers s consdered an extra tme takng actvty by the practtoners as the completon of projects n short tme s always preferred [28]. Therefore, n order to meet deadlnes and save tme practtoners do not consder ths REP as mportant for SDO. B. Requrements Analyss and Negotaton Practces Table III shows eght n 2 =8) requrements analyss and negotaton practces represented by REP n n = 14, 15,, 21); the frequences of dfferent ranks denoted by H, M, L and Z = 14, 15,, 21) for hgh, medum, low and zero perceved benefts respectvely. n2 14 n REP n L Z ) n 2 As shown n table III, out of eght 16.33%) requrements analyss and negotaton practces, seven 14.29%) practces are sgnfcant as they have s 50 or above whch means that accordng to 50% or more respondents these practces have hgh and medum benefts for SDO. So REP 14, REP 15, REP 16, REP 17, REP 18, REP 19 and REP 21 are sgnfcant requrements analyss and negotaton practces for SDO. TABLE III. REQUIREMENTS ANALYSIS AND NEGOTIATION PRACTICES Practce H M L Z REP 14 Defne system boundares REP 15 Use checklsts for requrements analyss REP 16 Use communcaton mechansm to support negotatons. REP 17 Plan for conflcts dentfcaton & resoluton REP 18 Prortze requrements REP 19 Classfcaton of the requrements through mult-dmensonal approach. REP 20 Usng nteracton matrces for fndng requrements conflcts and overlaps REP 21 Assess requrements rsks Only one REP whch s the usage of nteracton matrces to dscover conflctng and overlappng ssues among requrements REP 20 ) has and s consdered as nsgnfcant for SDO. Ths also confrms the prevous study regardng perceved values of REPs [23]. In the nteracton matrx, rows and columns are labeled wth requrements dentfers and cells of the matrx contan specfc and predefned values n order to ndcate that whether requrements conflct or not, overlap or not etc. As practtoners are normally not famlar wth ths tool, they may consder t needless to perform ther routne actvtes n spte of the fact that the use of matrces s really useful for requrements dentfcaton [25]. C. Descrbng Requrements Practces Table IV shows fve n 3 =5) requrements descrpton practces represented by REP n n = 22, 23,..., 26); the frequences of dfferent ranks denoted by H, M, L and Z = 22, 23,, 26) for hgh, medum, low and zero perceved benefts respectvely.. n3 22 n REPn L Z ) n 3 Table IV provdes data about the requrements descrpton practces. All the fve 10.20%) requrements descrpton practces.e., REP 22, REP 23, REP 24, REP 25 and REP 26 are sgnfcant or mportant for SDO as for all these practces s are 50 or above ndcatng that 50% or more respondents perceve them as havng hgh and medum benefts for SDO. TABLE IV. DESCRIBING REQUIREMENTS PRACTICES Practce H M L Z REP 22 REP 23 REP 24 REP 25 REP 26 Defne and use standard templates for requrements descrpton. Use smple, consstent and concse language to descrbe requrements. Use dagrams approprately. Supplement natural language wth other descrptons of the requrements. Specfy requrements quanttatvely where approprate

5 D. System Modelng Practces Table V shows sx n 4 =6) system modelng practces represented by REP n n = 27, 28,, 32); the frequences of dfferent ranks denoted by H, M, L and Z = 27, 28,, 32) for hgh, medum, low and zero perceved benefts respectvely. n REPn n4 27 L Z ) T L Z ) n 4 As shown n table V, we have sx 12.24%) system modelng practces.e., REP 27, REP 28, REP 29, REP 30, REP 31 and REP 32. Out of these sx modelng practces, only one practce whch s REP 27 developng complementary system models) s regarded as unmportant for SDO as the for the REP 27 s showng that 50% or more respondents do not consder ths practce as havng hgh and medum benefts for SDO. The remanng fve 10.20%) practces.e., REP 28, REP 29, REP 30, REP 31 and REP 32 possess s above 50. Therefore, they are sgnfcant or substantal system modelng practces for SDO. Ths s another strange fndng that developng complementary system models REP 27 ) s not consdered as a sgnfcant REP for SDO. Creatng dfferent models such as entty-relatonshp dagrams, data-flow-dagrams and class dagrams s always benefcal to make system specfcatons clear. The lkely cause behnd ths percepton of practtoners s that they use just a few models and are not nterested n the remanng models. Ths must be taken as matter of grave concern. REP 27 REP 28 REP 29 REP 30 TABLE V. Practce Develop complementary system models. Model the system s envronment. Model the system s archtecture. Use structured methods for system modelng. SYSTEM MODELING PRACTICES H M L Z REP 31 Use a data dctonary REP 32 Documentaton of the assocaton between stakeholder requrements and models of system E. Requrements Valdaton Practces Table VI shows eght n 5 =8) requrements valdaton practces represented by REP n n = 33, 34,, 40); the frequences of dfferent ranks denoted by H, M, L and Z = 33, 34,, 40) for hgh, medum, low and zero perceved benefts respectvely.. 0 n5 H 33 n5 33 REP n L Z ) n And also 5 We can observe from table VI that out of eght 16.33%) requrements valdaton practces, seven 14.29%) practces.e., REP 33, REP 34, REP 35, REP 36, REP 37, REP 38 and REP 40 have the least requred s. Only one valdaton practce that s REP 39 propose requrements test cases) s regarded as trval for SDO because the for ths practce s 47.22, and ths s nsuffcent to meet the requred crteron. So REP 33, REP 34, REP 35, REP 36, REP 37, REP 38 and REP 40 are sgnfcant or mportant requrements valdaton practces for SDO. Proposng test cases REP 39 ) s essental for fndng out requrements problems whch have a negatve mpact on the expected outcomes of the projects [26]. Accordng to our fndngs, ths s not a consderable RE practce whch contradcts an earler study regardng REPs [23]. Ths requres further nvestgaton nto whether ths s due to SDO ssues lke dstance, mproper communcaton, knowledge management and cultural dfferences or not. REP 33 REP 34 REP 35 REP 36 REP 37 REP 38 REP 39 REP 40 TABLE VI. Practce Checkng to verfy that the requrements document s accordng to your standards. Organzng the nspectons of requrements. Usng mult-dscplnary teams for revewng requrements. Defnng the checklsts for valdaton of requrements. Usng prototype n order to anmate the requrements. Wrtng a user manual draft. Proposng requrements test cases. Paraphrasng system models nto natural language. REQUIREMENTS VALATION PRACTICES H M L Z

6 F. Requrements Management Practces Table VII shows nne n 6 =9) requrements management practces represented by REP n n = 41, 42,, 49); the frequences of dfferent ranks denoted by H, M, L and Z = 41, 42,, 49) for hgh, medum, low and zero perceved benefts respectvely. n6 41 n REPn L Z ) n 6 As we can see from table VII that for requrements management there are nne 18.37%) practces. Only one management practce that s about recordng rejected requrements REP 49 ) has less than ) whch s not enough to become a sgnfcant practce for SDO. Ths also conforms to the results of prevous study on REPs [23]. One possble reason for not recordng the rejected requrements may be the fact that n several companes the recordng of rejected requrements s the decson of project managers. All the other eght 16.33%) practces to manage requrements have s above 50 ndcatng that more than 50% of experts consder these practces as havng hgh and medum benefts for SDO. Therefore, REP 41, REP 42, REP 43, REP 44, REP 45, REP 46, REP 47 and REP 48 are sgnfcant requrements management practces for SDO. Thus data analyss uncovers the fact that most of the REPs advocated by Sommervlle and Sawyer s study are sgnfcant for SDO as 43 REPs out of 49 or 87.76% REPs meet the requred crteron to become sgnfcant for SDO. Area wse percentages of the REPs and sgnfcant REPs have been shown n Fg. 2. TABLE VII. REP 41 REP 42 REP 43 REP 44 REP 45 REP 46 REP 47 REP 48 REP 49 Practce Identfcaton of each requrement unquely. Defnng polces n order to manage requrements. Defnng requrements traceablty polces. Mantanng the manual of traceablty. Usage of database for the management of requrements. Defnng polces to manage requrements change. Identfcaton of the global system requrements. Identfyng the volatle requrements. Recordng of the rejected requrements. REQUIREMENTS MANAGEMENT PRACTICES H M L Z Fgure 2. Area wse percentages of the Requrements Engneerng Practces and the Sgnfcant Requrements Engneerng Practces. G. Analyss of Attaned Promnence Levels For sx key areas of the RE process, we have dentfed 43 REPs whch are sgnfcant for SDO because of havng s equal to 50 or more. On observng the data about s we fnd that for one REP that s prortzng requrements REP 18 ), the s whch s dstant from rest of the data. Therefore, t s treated as an Outler and omtted from the data. After excludng havng value 93.52, we check the remanng s values for normalty. Table VIII contans the results of the two tests of normalty whch are the Kolmogorov-Smrnov Test and Shapro-Wlk Test. Keepng n vew our data set sze 42), the Shapro-Wlk Test s more sutable [29]. Therefore, the Shapro-Wlk Test has been used to assess the normalty of the data. From table VIII t s clear that n the case of the Shapro- Wlk Test, the p-value s.389 whch s greater than Ths shows that the s data s normal. If μ s the mean of the s x ) of sgnfcant REPs, σ s the standard devaton and N s no. of values n data set. Then N=42 x So 23 And x ) So TABLE VIII. Kolmogorov-Smrnov TESTS OF NORMALITY Shapro-Wlk Statstc df Sg. Statstc df Sg

7 Now µ± 1σ = , ) = 61.88, 70.58) µ± 2σ = , ) = 57.53, 74.93) µ± 3σ = , ) = 53.18, 79.28) The values of µ± 3σ reveal that n case of approxmately 99% of the sgnfcant REPs, s or percentages of the practtoners who consder these REPs as sgnfcant for SDO) le between 53.18or 53) and 79.28or 79). As for almost 99% of the sgnfcant REPs, ther correspondng s le between 53 and 79, therefore, we can say that the dentfed REPs are sgnfcant for SDO accordng to the percepton of 53% to 79% of practtoners or around half to 4/5 th of the practtoners. H. Selecton of low perceved benefts and zero perceved benefts categores A somewhat odd observaton about the responses from varous categores of practtoners s that n the case of almost all of the REPs, a suffcent number of practtoners have selected low perceved benefts and zero perceved benefts categores. The underlyng reason behnd ths phenomenon may be that for dfferent categores of practtoners, dfferent key areas REPs are mportant keepng n vew ther job nature. Accordng to the percepton of one class of practtoners say managers, REPs belongng to one key area are mportant, however, the same REPs can be treated as unmportant by another class of practtoners thereby resultng n the selecton of low perceved benefts and zero perceved benefts categores. IV. CONCLUSION AND FUTURE WORK In ths study, we have surveyed 108 software development outsourcng experts wth the purpose of mprovng the RE process for outsourced software development projects. The pertnent professonals have been asked to rank the Sommervlle and Sawyer s RE practces for the sx key areas of requrements elctaton, analyss and negotaton, descrpton, modelng, valdaton and management. The RE practces have been ranked as havng hgh benefts, medum benefts, low benefts or zero benefts for software development outsourcng accordng to the percepton and experences of experts. Based upon the experts responses, ths research dentfes 43 RE practces whch are sgnfcant for software development outsourcng. The study proposes that the dentfed RE practces must be gven due attenton n order to mprove the RE process for outsourced software development projects and attan the expected benefts of outsourcng ncludng cost reducton, avalablty of the state of the art capabltes and overcomng the ssues of a lack of resources and approprate sklls. Our future plan s the dentfcaton of addtonal RE practces whch are sgnfcant n order to ensure the success of outsourced software development projects. Workng further upon software development outsourcng, we also ntend to compare the sgnfcant RE practces percepton of the practtoners of one country wth the practtoners from another country. Based upon ther percepton and experence, the practtoners have ranked the RE practces accordng to the benefts of RE practces for SDO. We have not solcted from the respondents that why they have chosen a partcular rank hgh or medum or low or zero) for a RE practce. Lkewse, we have not nqured form the partcpants that f they are not followng some RE practces) then what they are dong n order to accomplsh RE process successfully. We have not explored the relatonshp between the not followed RE practces and the falure of outsourced software development projects ether. These matters can be nvestgated n another study. REFERENCES [1] M. Naz, M. A. Babar, and J. M. Verner, Software process mprovement barrers: a cross-cultural comparson, Informaton and Software Technology, vol. 52, ssue 11, pp , [2] T. C. Lethbrdge, S. E. Sm, and J. Snger, Studyng software engneers: data collecton technques for software feld studes, Emprcal Software Engneerng, vol. 10, ssue 3, pp , [3] S. L. Pfleeger, and B. A. Ktchenham, Prncples of survey research: part 1: turnng lemons nto lemonade, ACM SIGSOFT Software Engneerng Notes, vol. 26, ssue 6, pp.16-18, [4] R. D. Gbbs, Project Management wth the IBM Ratonal Unfed Process: Lessons from the Trenches, Chapter 1- Introducton to outsourcng, 1st ed., IBM Press, 2006, pp [5] O. Ishenko, Outsourcng of software development, Humboldt Unversty of Berln, Faculty of Economcs, Berln, [6] M. Naz, An nstrument for measurng the maturty of requrements engneerng process, Proc. of 6 th Int. Conf. on Product Focused Software Process Improvement, 2005, pp [7] S. Islam, S. H. Houmb, D. Mendez-Fernandez, and M. M. A. Joarder, Offshore-outsourced software development rsk management model, Proc. of 12 th Int. Conf. on Computers and Informaton Technology, 2009, pp , do: /ICCIT [8] P. Iyengar, Applcaton development s more global than ever, number G , Gartner, 2004, URL: pplcaton_dev.pdf, access date: September 15, [9] B. A. Aubert, M. Patry, and S. Rvard, A framework for nformaton technology outsourcng rsk management, ACM SIGMIS Database, vol. 36, ssue 4, pp. 9-28, [10] B. Boehm, A vew of 20 th and 21 st century software engneerng, Proc. of 28th Int. Conf. on Software Engneerng, 2006, pp [11] I. Perera, Impact of poor requrement engneerng n software outsourcng: a study on software developers experence, Int. J. of Computers, Communcatons & Control, vol. 6, ssue 2, pp , [12] N. V. Oza, and T. Hall, Dffcultes n managng offshore outsourcng relatonshps: an emprcal analyss of 18 hgh maturty Indan software companes, Journal of Informaton Technology Cases and Applcatons Research, vol. 7, ssue 3, pp , [13] J. M. Bhat, M. Gupta, and S. N. Murthy, Overcomng requrements engneerng challenges: lessons from offshore outsourcng, IEEE Software, vol. 23, ssue 5, pp.38-44, [14] I. Sommervlle, and J. Ransom, An emprcal study of ndustral requrements engneerng process assessment and mprovement, ACM Trans. On Software Engneerng and Methodology TOSEM), vol. 14, ssue 1, pp , 2005.

8 [15] D. E. Daman, and D. Zowgh, Requrements engneerng challenges n mult-ste software development organzatons, Requrements Engneerng, vol. 8, ssue 3, pp , [16] A. Sharma, A. Serebrenk, and M. Klabbers, Requrements qualty assessment for outsourcng, Master s thess ), Department of Mathematcs and Computer Scence, Endhoven Unversty of Technology, Endhoven, Netherlands, [17] B. Meyer, The unspoken revoluton n software engneerng, Computer, vol. 39, ssue 1, pp. 124, , [18] M. Naz, M. El-Attar, M. Usman, and N. Ikram, GlobReq: A framework for mprovng requrements engneerng n global software development projects: prelmnary results, Proc. of 16th Int. Conf. on Evaluaton & Assessment n Software Engneerng, 2012, pp , do: /c [19] J. D. Herbsleb, "Global software engneerng: the future of socotechncal coordnaton, Proc. of Future of Software Engneerng, 2007, pp [20] Z. Salaran, and H. Rashd, Improvng offshore-outsourced software development requrement rsk prortzaton, schedulng and predcton wth usng a fuzzy analytc herarchy process, Internatonal Journal of Latest Trends n Computng, vol. 2, ssue 4, pp , [21] A. Raner, and T. Hall, Key success factors for mplementng software process mprovement: a maturty-based analyss, Journal of Systems and Software, vol. 62, ssue 2, pp.71-84, [22] M. Naz, D. Wlson, and D. Zowgh, A maturty model for the mplementaton of software process mprovement: an emprcal study, Journal of Systems and Software, vol. 74, ssue 2, pp , [23] K. Cox, M. Naz, and J. Verner, Emprcal study of Sommervlle and Sawyer s requrements engneerng practces, IET Software, vol. 3, ssue. 5, pp , [24] Market share analyss: IT outsourcng servces, worldwde, 2011, Gartner, 2012, URL: access date: October 08, [25] T. Arao, E. Goto, and T. Nagata, Busness process orented requrements engneerng process, Proc. of 13 th IEEE Int. Conf. on Requrements Engneerng, 2005, pp [26] T. Hall, S. Beecham, and A. Raner, Requrements problems n twelve software companes: an emprcal analyss, IEE Proceedngs Software, vol. 149, ssue 5, pp , [27] I. Sommervlle, and Pete Sawyer, Requrements Engneerng- A Good Practce Gude, Chapter 2- Practcal Process Improvement, Wley, 1997, pp [28] R. Xan, MU. Lnglng, and L. Png, Project evaluaton wth tme, cost, and qualty consderatons, Proc. of 6 th Int. Conf on Fuzzy Systems and Knowledge Dscovery, 2009, vol.3, pp , do: /FSKD [29] R. B. D'agostno, A. Belanger, and R. B. D'agostno Jr., A suggeston for usng powerful and nformatve tests of normalty, The Amercan Statstcan, vol. 44, ssue. 4, pp , [30] access date: September 04, [31] access date: September 04, 2012.