A Framework for Improving Requirements Engineering in Global ...

GlobReq: A Framework for Improving Requirements Engineering in Global Software Development Projects: Preliminary Results Mahmood Niazi, a, b, c, Mohamed El-Attar b, Muhammad Usman d and Naveed Ikram c a

b

School of Computing and Mathematics, Keele University, Keele, ST5 5BG, UK Department of Information and Computer Science, King Fahd University of Petroleum and Minerals, Saudi Arabia c Faculty of Computing, Riphah International University Islamabad, Pakistan d International Islamic University Islamabad, Pakistan

ABSTRACT CONTEXT: Previous work suggests that half of the companies that have tried global software development (GSD) have failed to realise the anticipated outcomes, the root cause of which is often related to requirements problems. Despite the importance of this problem, little research has been carried out to improving requirements engineering process in the GSD projects. OBJECTIVE: In this paper an ongoing project is discussed which will bring together the work of researchers and software development experts to develop a framework for the requirements engineering process of global software development projects (GlobReq). Managers of GSD projects will be able to use GlobReq to plan a requirements engineering process suitable for a specific GSD project. In this paper the need for such a framework along with the proposed methodology, novelty and the preliminary results are discussed. METHODOLOGY: The basis of the GlobReq framework is Sommerville et al’s framework of 66 requirements best practices as well as our empirical study with GSD organisations. INITIAL RESULTS: The initial findings from 5 organisations are interesting to observe that not all 66 RE best practices are perceived as high value practices for GSD projects.

Keywords: Global Software Engineering I. INTRODUCTION In global software development (GSD) a company (client) contracts out all or part of its software development activities to another company (vendor), who provides services for remuneration. GSD has been growing steadily and an 18-fold increase in the outsourcing of IT-enabled business processes is projected [19]. Over the last decade, many firms in Europe have outsourced software development projects to other countries such as India, China and Russia. There are many reasons for software development outsourcing [3]. Client organisations benefit from offshore outsourcing because vendors in developing countries (offshore vendors) usually cost one-third less than onshore vendors and even less when compared with in-house operations [11]. Moreover, offshore vendors improve their skills and service quality with the experience of offshore outsourcing projects, learning new ways to satisfy the clients’ needs. However, there are many risks in an outsourcing process [8]. Significant failure rates have also been reported in GSD

Proceedings of the EASE 2012 - Published by the IET ISBN 978-1-84919-541-6

projects [5]. Nam et al. [12] investigated 93 client companies and found that 36 did not intend to continue their relationships with vendors. King [9] reports that JP Morgan decided to perform many software activities that it previously outsourced, and did not renew its $5 billion contract with IBM. At the root of many failures is the increased complexity that outsourcing brings to development projects. This complexity results in: high coordination costs, information security problems, lack of direct communication [16], perceived loss of expertise in the outsourced activity [6], cultural misunderstandings [10] and infrastructure problems [1]. Although a variety of software development tasks are outsourced previous work suggests that most of the factors contributing to the failure of outsourcing are related to requirements [15]. This is not surprising given that the requirements engineering (RE) process has a huge impact on the effectiveness of all software development processes [18]. A previous UK study of non-outsourced projects found that out of 268 documented development problems, requirements problems accounted for 48% of all software problems [7]. In another study of GSD projects, RE problems in multi-site software development organisations were identified [4]. The evidence is clear: problems in the requirements phase have a wide impact on the success of software development projects [7; 18] but have an even greater impact on the success of GSD projects [4]. Sommerville et al. [18] suggest a requirements framework that includes 66 requirements practices. They suggest these 66 requirements practices will lead to RE process improvement and ultimately business benefits [18]. We propose to adapt and customise this framework of practices specifically for GSD projects. The 66 requirements practices are classified as basic, intermediate and advanced. There are 36 basic practices concerned with the fundamental activities required to gain control of the RE process; 21 intermediate practices mostly concerned with the use of methodical approaches and tools; and 9 advanced practices concerned with methods such as formal specification used typically for critical systems development. The 66 RE practices are grouped into 8 major categories: requirements documentation, requirements elicitation, requirements analysis and negotiation, describing

166

requirements, system modelling, requirements validation, requirements management and requirements for critical systems. II. AIMS AND OBJECTIVES The overarching objective of this project is to develop a framework for the RE process of GSD projects. For this purpose we aim to conduct an empirical study to gather data on GSD projects. The GlobReq framework will assist software practitioners in identifying and selecting which RE practices are useful for GSD companies. To achieve this we address the following research questions: RQ1. Which RE practices can be effectively used in the GSD projects? In order to address this RQ we will: x Determine what the most important of all the RE practices advocated by Sommerville et al. are for GSD projects. x Identify any additional RE practices important for GSD projects that may lack from the list of Sommerville et al. [18] practices. RQ2. How can we develop GlobReq? The basis of the GlobReq framework will be Sommerville et al’s framework of requirements practices as well as our empirical study with GSD organisations. We will collect detailed empirical data from GSD organisations to construct and validate the GlobReq frameworks. The criteria “user satisfaction”, “ease of use” and “better requirements” will be used for the development of GlobReq. RQ3. How can we evaluate the effectiveness of GlobReq? The evaluation of the end product is important in order to show up areas where the end product has deficits. The evaluation assists in future planning and decision making. In the evaluation process the lessons learned and results are used to enlighten the future projects. III. RESEARCH METHODOLOGY A. Data Collection Initially five GSD organisations have agreed to collaborate in this project. Each of the participating organisations has nominated a requirements stakeholder to liaise with the researchers to plan and execute the research. These requirements stakeholders were selected on the basis of their experience in the fields of RE and GSD. It is further important to acknowledge that the experiences of those requirements stakeholders have been solicited who were tackling real GSD issues on a daily basis. In-depth interviews with requirements stakeholders were the main data collection method. Each requirements stakeholders was asked to choose and rank 66 RE practices against four types of assessments that have been developed previously [13; 18]. These assessments are: x High Perceived Benefits: A practice has a documented standard and is always followed as part of the organisation’s GSD process i.e., it is mandatory.


x Medium Perceived Benefits: This means that the practice is widely followed in the organisation’s GSD process but is not mandatory. x Low Perceived Benefits: Some GSD projects may have introduced the practice only for that project. This practice is described as ‘low’ perceived benefit. x Zero Perceived Benefits: The practice is never or rarely applied to any GSD projects. From this list, we have the ‘perceived benefit’ associated with each RE practice, i.e. the degree of importance placed on a RE practice by requirements stakeholders based on their experience from previous GSD projects. B. Data Analysis In order to analyse the perceived benefit of each identified RE practice, the occurrence of a perceived benefit (high, medium, low, zero) in each interview was counted. By comparing the occurrences of one RE practice’s perceived benefits obtained against the occurrences of other RE practices’ perceived benefits, the relative benefit of each RE practice was identified. We have also used this approach to identify high and low valued RE practices and software process improvement de-motivators in our previous research [13]. For most of the data analysis, we have used statistical analysis. We believe that the presentation of data using statistical analysis is an effective mechanism for comparing and contrasting within, or across groups of variables. We assert that “perceived benefits” of a particular RE practice can be used as a judgement criterion for determining the degree of importance placed on a RE practice by requirements stakeholders. This is because where requirements stakeholders from different organisations perceive a RE practice as having high-perceived or medium-perceived benefits, then that practice should be considered for its importance in a RE process of GSD projects. The information about relative “perceived benefits” can help researchers and requirements stakeholders better understand various RE practices within the GSD initiatives. IV. INITIAL FINDINGS Initially five GSD organisations participated in this project. In Appendix A we have presented the preliminary results of data collection and analysis processes. The results show that the most common ‘high’ value requirements documentation practices are RD1 and RD4. Documents that present an unfamiliar structure can be difficult to read, follow and update. Those without a summary can force readers to waste time in trying to interpret the document (RD1). Often, the accounting department will insist that a project will only be funded if a business case is made for the system, i.e., the system must meet an organisational business goal (RD4). RE3 is the most frequently cited ‘high’ value requirements elicitation practices. It is interesting to observe that RE10 is the frequently cited ‘low’ value requirements elicitation practice.

167

The most common ‘high’ value requirements analysis and negotiation practice is to define system boundaries (RA1). A development team will often insist on defining the system boundary of a new system in order to better understand the problems and scope of the system. This system boundary provides engineers with a starting point to estimate project effort. The majority of the respondents stated that their organisations consider use languages simply and concisely (DR2) as a ‘high’ value practice. We consider this an important practice because the template aids understanding and imposes some control and a pattern over the way requirements are expressed in natural language. The most frequently cited ‘high’ value systems modelling practices are SM3 and SM4. These results show the importance of modelling in RE. RV1, RV2 and RV3 are the most common ‘high’ value requirements validation practices. It is interesting to observe that use prototyping to animate requirements (RV5) is the frequently cited ‘low’ value practice. Given the right context, prototyping has been shown to be one of the most important requirements engineering techniques in project success [20] and should be used when appropriate. The results show that identify global system requirements (RM7) is the frequently cited ‘high’ value requirements management practice. Global system requirements set out desirable or essential properties of the system as a whole. We received mix responses for RE Critical Systems Practices, e.g. CS3, CS4, CS5 and CS9 are the most frequently cited ‘high’ value practices while CS2 and CS8 are the most frequently cited ‘low’ value practices. These initial findings are interesting to observe that not all 66 RE best practices are perceived as high value practices for GSD projects. More data will assist us to better design GlobReq. In the next section we have briefly described the GlobReq development process. V. FUTURE WORK A. GlobReq Framework Development and Evaluation The following initial criteria will be used for the development of GlobReq framework. We have used this approach successfully in previous empirical research with software development organisations [13; 14]. User satisfaction: stakeholders need to be satisfied with the results of the GlobReq framework. Stakeholders (e.g. requirements engineers, systems analysts, outsourcing project staff) should be able to use the GlobReq to achieve specified goals according to their needs and expectations without confusion or ambiguity. Ease of use: complex models and standards are rarely adopted by organisations as they require resources, training and effort. The structure and contents of


GlobReq should be simple, flexible and easy to follow. Better requirements: GlobReq should help to generate high quality requirements (e.g. less ambiguous, more comprehensive, consistent and feasible). Figure 1 shows that based on the initial criteria, data will be collected and analysed. Based on the empirical data, Sommerville’s Requirements Framework will be rationalised to GSD environments. GlobReq framework will be developed from the rationalised Sommerville Framework together with additional empirical data collected from GSD collaborators. The frequently cited RE practices with ‘high’ and ‘medium’ perceived benefits’ will be the basis of the GlobReq framework. Finally we will evaluate the RE framework using an expert panel review. Figure 1 shows the process that will be used to design the GlobReq framework. We will use an expert panel review to seek the opinions of software outsourcing experts about the GlobReq framework. The criteria described in “GlobReq framework development” will be used, i.e. ease of use, user satisfaction and better requirements as the basis of this evaluation. We will identify five GSD experts for the evaluation of the GlobReq framework. These experts will be selected on the basis of their practical and/or academic experience of GSD projects. These experts will be from other organisations (i.e. not from organisations who participated in the data collection process). We have made preliminary discussions with these experts and we are in the process of explaining their role in this project. B. Timeliness and Novelty The work proposed will bring together and advance the work that has been undertaken on frameworks and models for RE. Our contribution to improving RE in GSD projects will provide other researchers with a firm basis on which to develop different requirements processes that are based on an understanding of how and where they fit into the GSD activities. New requirements processes could then be developed targeting GSD projects. To the best of our knowledge this is the first attempt to investigate the most relevant RE practices for GSD organisations. Research suggest that problems in the requirements phase have greater impact on the success of GSD projects [2; 4]. It is important to discover which RE practices will benefit a GSD organisation, as research has shown that effective RE processes should lead to business benefit and help organisations in keeping delivery times and product quality under control [18]. Despite the importance of RE, little research has been conducted on developing ways to assist GSD organisations in designing effective RE processes. The outcome of this project will be a framework which can be used in the GSD projects. This framework should lead software development organisations to business benefits and should assist them in keeping product quality under control. This framework should also help organisations improve their

168

GSD capabilities. Improved GSD capabilities provide marketing advantage to organisations and help them to compete internationally. VI. CONCLUSION Many research outputs end up as shelfwear which never make it into industrial practice. The proposed GlobReq will reduce this trend in RE and outsourcing by identifying a well understood and rationale requirements process framework for software development outsourcing. The aim is to help companies avoid randomly implementing promising new models and frameworks just to see them discarded. We are well prepared to do this given the amount of industrial collaboration that we have participated in during the last nine years. The RE framework (GlobReq) will be available to researchers and software practitioners via a website. Companies will benefit by having access to the list of most relevant RE practices for software development outsourcing. This will provide software practitioners with an opportunity to implement required RE practices in software development outsourcing processes. ACKNOWLEDGEMENT We are thankful to King Fahd University of Petroleum and Minerals, Saudi Arabia for supporting this research project via a project number IN111030.

VII. REFERENCES [1] Barthelemy, J. The hidden cost of IT outsourcing, Sloan Management Review 42 (3). 60-69. 2001 [2] Bhat, JM, Gupta, M and Murthy, SN. Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing, IEEE Software 23 (5). 38-44. 2006 [3] Bush, Ashley A. , Tiwana, Amrit and Tsuji, Hiroshi. An Empirical Investigation of the Drivers of Software Outsourcing Decisions in Japanese Organizations, in press for publication, Information and Software Technology Journal 2007 [4] Damian, D., E. and Zowghi, D. Requirements Engineering challenges in multi-site software development organizations, Requirements Engineering Journal, published by Springer Verlag. 8 (3). 149-160. 2003 [5] Foote, D. Recipe for offshore outsourcing failure: Ignore organization, people issues, ABA Banking Journal 96 (9). 56-59. 2004 [6] Gonzalez, R., Gasco, J. and Llopis, J. Information systems outsourcing risks: a study of large firms, Industrial management and data systems 105 (1). 45–62. 2005

Specify criteria for GlobReq framework [20] development

Data collection and analysis

Rationalisation and structuring of results

[7] Hall, Tracy, Beecham, Sarah and Rainer, Austen. Requirements Problems in Twelve Software Companies: An Empirical Analysis, IEE Proceedings - Software (August). 153-160. 2002 [8] Khan, Siffatullah, Niazi, Mahmood and Rashid, Ahmad. Critical Barriers for Offshore Software Development Outsourcing Vendors: A Systematic Literature Review. 16th IEEE Asia-Pacific Software Engineering Conference, APSEC09. Penang, Malaysia. 2009 [9] King, W. Outsourcing becomes more complex, IT Strategy and Innovation - ISM Journal 89 - 90. 2005 [10] Kobitzsch, Werner, Rombach, Dieter and Feldmann, Raimund, L. Outsourcing in India, IEEE Software March/ April 2001 78-86. 2001 [11] McLaughlin, L. An eye on India: Outsourcing debate continues., IEEE Software 20 (3). 114-117. 2003 [12] Nam, K., Chaudhury, A., Rao, Raghav and H., Rajagopalan, S. A Two-Level Investigation of Information Systems Outsourcing, Communications of ACM 39 (7). 36-44. 1996 [13] Niazi, M, Cox, K. and Verner, J. An empirical study identifying high perceived value requirements engineering practices. Fourteenth International Conference on Information Systems Development (ISD´2005) Karlstad University, Sweden August 15-17. 2005 [14] Niazi, Mahmood, Cox, Karl and Verner, June. A Measurement Framework for Assessing the Maturity of Requirements Engineering Process, Software Quality Journal: in press for publication 16 (2). 157-298. 2008 [15] Oza, Nilay V. and Hall, Tracy. Difficulties in managing offshore outsourcing relationships: An empirical analysis of 18 high maturity Indian software companies, Journal of Information Technology Case and Application Research 7 (3). 25-41. 2005 [16] Pyysiainen, J. Building trust in global inter-organizational software development projects: problems and practices. International Conference on Software Engineering: Global Software Development Workshop. 2001 [17] Sommerville, I., Sawyer, P. and Viller, S. Improving the Requirements Process. Fourth International Workshop on Requirements Engineering: Foundation of Software Quality. 71-84. 1998 [18] Sommerville, Ian and Ransom, Jane. An empirical study of industrial requirements engineering process assessment and improvement, ACM Transactions on Software Engineering and Methodology 14 (1). 85-117. 2005 [19] United-Nations. World Investment Report. The shift towards services, New York and Geneva. 2004 [20] Verner, J., Cox, K., Bleistein, S. and Cerpa, N. Requirements Engineering and Software Project Success: An Industrial Survey in Australia and the US, Australian Journal of Information Systems (to appear Sept 2005). 2005

Development of GlobReq framework

Evaluation of GlobReq framework via experts panel

Figure. 1 The GlobReq framework development process


169

Appendix A: Preliminary Results of an empirical study ID

RD1 RD2

Define a standard document structure Explain how to use the document

Type of Assessment (n=5) H M L Z 5 3 1 1

RD3 RD4 RD5 RD6

Include a summary of the requirements Make a business case for the system Define specialized terms Make document layout readable

3 4 1 3

RD7 RD8

Help readers find information 1 4 Make the document easy to change 1 2 Requirements analysis and negotiation practices

RA1 RA2 RA3

Define system boundaries Use checklists for requirements analysis Provide software to support negotiations Plan for conflicts and conflict resolution Prioritise requirements

RA4 RA5 RA6

Requirements Documents Practice

5 1

1

RE7 RE8 RE9 RE10 RE11 RE12 RE13

2 3

1

1

DR1

1

2

2

2

2

2

1

1

1 1

SM1 SM2

System Modelling Practices Develop complementary system models Model the system’s environment

3 3

1

1

RM3 RM4 RM5 RM6 RM7

Define change management policies Identify global system requirements

2 4

2 1

RM8

Identify volatile requirements

2

2

RM9

Record rejected requirements

1

1

2 3 1 1

Assess System Feasibility Be sensitive to organisational and political consideration Identify and consult system stakeholders Record requirements sources Define the system’s operating environment Use business concerns to drive requirements elicitation Look for domain constraints Record requirements rationale Collect requirements from multiple viewpoints Prototype poorly understood requirements Use scenarios to elicit requirements Define operational processes Reuse requirements Describing Requirements Practices

1 2 1

1

1 2 1 1

1 2 2 2

3 1 1 2

3

2

3

1

DR4

2

2

1

3

2

1

RV4 RV5

1

RV6 RV7 RV8

Write a draft user manual Propose requirements test cases Paraphrase system models

1

2

3 3 4

2

Use diagrams appropriately

RV1

1

2 2

DR3

RV2 RV3

2

5 3 3 3

4

1

2 2

Type of Assessment (n=5 H M L Z 4 1 3 1 1

DR2

Supplement natural language with other description of requirement Specify requirements quantitatively Requirements validation Practices Check that the requirements document meets your standards Organise formal requirements inspections Use multi-disciplinary teams to review requirements Define validation checklists Use prototyping to animate requirements

1 1 3 2

Requirements Elicitation Practices

Define standard templates for describing requirements Use languages simply and concisely

DR5

Model the system architecture 4 Use structured methods for system 4 modelling Use a data dictionary 2 Document the links between 2 stakeholder requirements and system models Requirements Management Practices Uniquely identify each requirement 3 Define policies for requirements 1 management Define traceability policies 3 Maintain a traceability manual 2 Use a database to manage requirements 1

RM1 RM2

1

3

2

SM5 SM6

1

RE3 RE4 RE5 RE6

1

RA8

SM3 SM4

2 2

1 1

RE1 RE2

3

Classify requirements using a multidimensional approach Use interaction matrices to find conflicts and overlaps Assess requirements risks

RA7

1 1 4 2

ID

CS1 CS2 CS3 CS4

1

CS5

1

CS6 CS7 CS8 CS9

1 1

3

2

3 3

1 2

1

1 1

2 1

2 3

1

3 3 1

2 1 3

Requirements Engineering for Critical Systems Practices Create safety requirement checklists 2 2 Involve external reviewers in the validation 1 2 process Identify and analyse hazards 3 1 Derive safety requirements from hazard 3 1 analysis Cross-check operational and functional 3 1 requirements against safety requirement Specify systems using a formal specification 2 2 Collect incident experience 2 2 Learn from incident experience 2 1 Establish an organizational safety culture. 3 1

1 2 1 1 1 1 1 2 1

H=High, M=Medium, L=Low, Z=Zero


170

1