requirements engineering practices in global software

Requirements Engineering Practices in

Global Software Engineering Organizations

A Study in the Banking Industry

Ahmad Yandriansyah Reza



THESIS

submitted in partial fulfillment of the

requirements for the degree of

MASTER OF SCIENCE

In

COMPUTER SCIENCE

by

Ahmad Yandriansyah Reza born in Jakarta, Indonesia

Software Engineering Research Group Department of Software Technology

Faculty EEMCS, Delft University of Technology Delft, the Netherlands

www.ewi.tudelft.nl

© 2015 Ahmad Yandriansyah Reza. All rights reserved.

Picture taken from http://techgage.com



Author: Ahmad Yandriansyah Reza Student id: 4313003 Email: [email protected]

Abstract

In this thesis we report on our investigation of requirements engineering (RE) practices

and challenges in global software engineering (GSE) settings. We conducted a literature survey

and a series of interviews/surveys to reach our goal. The subject of the research is the banking

industry in the Netherlands actively involved in GSE. More specifically, the goal of this research

is to find out what banking organizations have learned from RE practices when used in GSE

settings. Specifically, the project investigates how GSE teams handle RE problems especially in

the beginning of a project and attempts to identify the solutions in used in practice to deal with

such challenges. The overall conclusions are that the use of liaison officers, the use of the online

collaboration tools, and the use of a transparent RE process are the common practices that are

used by the banks in the Netherlands to overcome their RE challenges in GSE project settings.

Thesis Committee: Chair: prof. dr. ir. R. van Solingen, Faculty EEMCS, TU Delft University supervisor: prof. dr. ir. R. van Solingen, Faculty EEMCS, TU Delft Committee Member: Dr. Alberto Bacchelli Committee Member: Dr.ir. Jan Hidders

i

Dedicated to my parents and my family,

Love of my life

iii

Preface

I dedicate this thesis to my parents: my father and my mother (who just passed away during writing this

thesis), who always support me to study in higher degree. I also dedicate this thesis to my family: my

wife Ari Hardini, and my children, Salma and Fadli. They give me energy to complete my education in

The Netherlands.

Thank you for prof. dr. ir. Rini van Solingen for letting me do this thesis in Global Software Engineering, a

world of new opportunities in the brand new exciting software engineering perspective. Thank you for

Dr. Alberto Bacchelli for supporting me from start to finish in this thesis project.

Thank you also for prof.dr.ir. Geert-Jan Houben, for direction and support while I am studying in the

Netherland. Also for Dr.ir. Jan Hidders, the MS. track Information Architecture coordinator, who guided

me and gave me lot of advice in the thesis preparation.

Last, but not least, I want to say thank you to all my friends in the Netherland. We had a great time here

and I wish you all the best for your study and life.

Ahmad Yandriansyah Reza Delft, the Netherlands

July, 2015

v

Contents Preface ......................................................................................................................................................... iii

List of Figures ............................................................................................................................................. viii

List of Tables ................................................................................................................................................ ix

1. Introduction .......................................................................................................................................... 1

1.1. Research Context .......................................................................................................................... 1

1.1.1. Requirements Engineering .......................................................................................................... 1

1.1.2. Global Software Engineering ...................................................................................................... 1

1.2. Problem Definition ........................................................................................................................ 1

1.3. Research Goal ............................................................................................................................... 2

1.4. Structure of the thesis .................................................................................................................. 3

2. Theoretical Research ............................................................................................................................ 4

2.1. Introduction .................................................................................................................................. 4

2.2. What is Requirements Engineering? ............................................................................................. 4

2.2.1. Requirements Engineering Practices .......................................................................................... 4

2.2.2. Problems in Requirements Engineering Practices ...................................................................... 6

2.3. What and why is Global Software Engineering? ........................................................................... 8

2.3.1. What is Requirements Engineering in Global Software Engineering? ...................................... 10

2.3.2. Requirements Engineering Practices in Global Software Engineering Organization ................ 13

3. Literature Review ................................................................................................................................ 17

3.1. Literature Survey Preparation ..................................................................................................... 17

3.2. Literature Survey Result .............................................................................................................. 19

4. Research Methodology ....................................................................................................................... 21

4.1. Introduction ................................................................................................................................ 21

4.2. Methodology ............................................................................................................................... 21

4.3. Designing Interviews ................................................................................................................... 22

4.4. Designing Mini Survey ................................................................................................................. 23

4.5. Designing Public Survey .............................................................................................................. 24

4.6. Selecting Respondents ................................................................................................................ 29

4.7. Administering Interviews, Mini Survey and Public Survey.......................................................... 29

5. Interview Results for the Pilot ............................................................................................................ 31

vi

5.1. Introduction ................................................................................................................................ 31

5.1.1. Respondents Overview ............................................................................................................. 31

5.1.2. Key Facts of Organization.......................................................................................................... 31

5.1.3. Software Development Methodology ...................................................................................... 32

5.2. Interview Results ......................................................................................................................... 32

5.2.1. RE Problems and Solutions in Local Project .............................................................................. 32

5.2.2. RE Practices in Local Project ..................................................................................................... 33

5.2.3. Key Findings and Observation ................................................................................................... 33

6. Interview Results of Banks in the Netherlands ................................................................................... 37

6.1. Introduction ................................................................................................................................ 37

6.1.1. Respondents Overview ............................................................................................................. 37

6.1.2. Key Facts of Organization.......................................................................................................... 37

6.1.3. Software Development Methodology ...................................................................................... 37

6.2. Interview Results ......................................................................................................................... 38

6.2.1. RE Problems and Solutions in GSE Project ................................................................................ 38

6.2.2. RE Practices in GSE Organizations ............................................................................................. 40

6.2.3. Analysis of Key Findings and Observations ............................................................................... 42

7. Public Survey Results .......................................................................................................................... 53

7.1. Introduction ................................................................................................................................ 53

7.2. Public Survey Results .................................................................................................................. 53

7.2.1. Information Background ........................................................................................................... 53

7.2.2. RE Problems and Solutions ....................................................................................................... 55

7.2.3. Closure ...................................................................................................................................... 58

7.3. Analysis ....................................................................................................................................... 58

8. Conclusions and Discussion ................................................................................................................ 62

8.1. Conclusions ................................................................................................................................. 62

8.2. Discussion .................................................................................................................................... 63

8.3. Reflection of Thesis Process ........................................................................................................ 65

8.4. Validity ........................................................................................................................................ 65

8.5. Recommendations of Future Work ............................................................................................ 66

Bibliography ................................................................................................................................................ 68

A. List of Literature Survey Paper ........................................................................................................... 72

vii

B. Summary Pilot Test Interview (RE Practices in Local Organization) ................................................... 77

C. Public Survey Audience’s Profile ......................................................................................................... 86

viii

List of Figures Figure 1 A Generic Requirements Process Model [10] ................................................................................. 5

Figure 2 GSE impacts on requirements understanding [31] ....................................................................... 10

Figure 3 Thesis Research's Outline.............................................................................................................. 22

Figure 4 General Model of GSE Organization ............................................................................................. 49

ix

List of Tables Table 1 Research Questions .......................................................................................................................... 2

Table 2 Table RE Group Practices [10] .......................................................................................................... 6

Table 3 List of RE Problems Summary [17] ................................................................................................... 8

Table 4 Motivations in GSE [26] .................................................................................................................... 9

Table 5 Impact factors in GSE definition as its influence requirements understanding [31] ..................... 11

Table 6 Hofstede's five dimensions of culture [32] .................................................................................... 11

Table 7 Index of five dimensions of culture [32] ........................................................................................ 12

Table 8 Cultural Differences Solutions in Agile RE in GSE project [33] ....................................................... 12

Table 9 A Holistic Framework of Best RE Practices in Global Organization Setting [37] ............................ 13

Table 10 List of High Perceived RE Practices in GSE Organizations [39] ..................................................... 15

Table 11 Summary of Tools/Practices used in RE activities in GSE organizations [34] ............................... 15

Table 12 Research questions and its description ........................................................................................ 17

Table 13 Search Criteria .............................................................................................................................. 18

Table 14 Search Strategy ............................................................................................................................ 18

Table 15 Selection of Studies ...................................................................................................................... 18

Table 16 Result of Data Screening .............................................................................................................. 19

Table 17 RQ1 Analysis ................................................................................................................................. 19



Table 20 List of Interview questions ........................................................................................................... 22

Table 21 RE Practices, Activities and Techniques [43] ................................................................................ 24

Table 22 RE Process Indicators [43] ............................................................................................................ 24

Table 23 Public Survey Questionnaire and References .............................................................................. 25

Table 24 List of Banks’ Respondents ........................................................................................................... 29

Table 25 Local Organization Respondent's Profile ..................................................................................... 31

Table 26 RE Problems and Solutions in Local Organization ........................................................................ 32

Table 27 RE Practices in Local Organization ............................................................................................... 33

Table 28 Respondents' Overview................................................................................................................ 37

Table 29 Summary of Software Methodology ............................................................................................ 38

Table 30 RE Problems ................................................................................................................................. 38

Table 31 RE Solutions .................................................................................................................................. 39

Table 32 List of RE Practices in GSE Project Organizations ......................................................................... 41

Table 33 Summary of RE Flow in GSE Project Organization ....................................................................... 49

Table 34 Comparison between RE Practices in Local and Global Organization .......................................... 50

Table 35 Public Survey Audience's Profile .................................................................................................. 53

Table 36 Motivations in the global project ................................................................................................. 54

Table 37 Differences of RE practices in the global project and local project ............................................. 54

Table 38 Top three RE problems in a global project ................................................................................... 55

Table 39 Solutions of the most important problem in RE practice in a global project............................... 57

Table 40 Interviews findings confirmation ................................................................................................. 58

x

Table 41 Research Questions and Answers ................................................................................................ 62

1

1. Introduction In this chapter, we introduce the background of the master thesis project, the overarching goal

structured in research questions and the structure of the thesis.

1.1. Research Context The research conducted for this thesis is based on number of fields which will be describe here as

high level explanation, whereas the details of these fields would be explain in chapter 2.

1.1.1. Requirements Engineering

The definition of requirements engineering (or software requirement) based on SWEBOK (Software

Engineering Body of Knowledge) v3.0 [3] is activities in software engineering consist of elicitation,

analysis, specification, and validation of software requirements as well as the management of

requirements during the whole life cycle of the software product. It also explains the term

“requirements engineering” to denote the systematic handling of requirements [1].

An industry best practice is a technique or methodology that, through experience and research, has

proven to reliability lead to a desirable result. Example of a best practice: the Unified Software

Development Process represents the closest methodology to an industry standard for software

development, the Project Management Professional (PMP) from the Project Management Institute

(PMI) represents best practices in project management, and the Capability Maturity Model

Integration (CMMI) for Software is widely known for process improvement and reengineering.

Consistency and robustness are important to the success than having every bell-and-whistle;

therefore, only few methodologies are used and combined in a way that provides those benefits [2].

We are using the term RE best practices using Sommerville and Sawyer’s RE good practices [3] as

many researchers have accepted believe these RE practices as a well-defined guidance in RE

activities. We discuss these RE practices further in chapter 2.

1.1.2. Global Software Engineering

The definition of Global Distributed Software Engineering (GSE) is: the discipline of design,

implementation and validation of software products and/or components on at least two geographic

locations and at least two continents [4]. GSE’s well-known distinguishing features are distance,

time-zone differences, and cultural differences [5]. Several terms have the same meaning as GSE:

‘Global Software Development’, ‘Distributed Software Development’, and ‘Offshore Software

Development Project’. Although they have small differences, the principles are the same.

Chapter 2 covers more details about GSE.

1.2. Problem Definition In this thesis, we focus upon the pieces of context defined above and what happens when

combining them in the same environment.

2

RE aims to develop well –not perfect- requirements and manage them during development

with respect to risks and quality (C.Ebert, et al, 2008). RE practices aim to provide set good

of RE practices that has proven through experience and research, that if applied in the

organization will lead to a desirable result (Babcock.R,et al, 2007).

In conducting RE practices in GSE, there is an urge to improve RE practices into much better

level despite its’ constraints in GSE, e.g. distance, either physical distance or cultural

distance (Hashim Khan, et al, 2011).

Therefore, we phrase our problem definition as:

What are the lessons learned from GSE requirements engineering in industrial organizations

(in particular Dutch banking organizations) regarding their best practices and challenges?

1.3. Research Goal We structure our research using the following research questions:

Table 1 Research Questions

Main Research Question (MQ)

What are the lessons learned from GSE RE practices?

Sub Research Question 1 (RQ1)

What are the differences of RE practices in a local software development project compared to GSE project settings?


What are the challenges in RE activities in GSE project setting?


What are the proposed solutions of such challenges in RE activities in GSE project setting?

In Table 1, we see again that our main research goal is to find out what are the lessons learned from

RE practices in GSE organization (MQ). To answer the main research question, first (RQ1), we

explore the differences between traditional RE practice and distributed RE practice; second (RQ2),

we explore the challenges or problems that arise in RE practice in GSE. Also comparing problems in

the traditional RE activities to the RE problems in GSE, finally (RQ3), we investigate the solutions

that GSE team use to solve the problems arising from requirements engineering. We devise and

conduct interviews and a survey based on these research questions.

We conduct this thesis project to investigate the state-of-the-art of RE practices in GSE settings.

Therefore, we attempt to find out what are the lessons learned when using RE in GSE settings in

industry. Our initial scope was the banking industry in the Netherlands that conduct GSE in their

software development projects. In addition, we conducted limited interviews to local organization’s

personnel to learn how they practice RE in their daily GSE activities.

3

1.4. Structure of the thesis Chapter 2 contains theoretical research in the field of requirements engineering (RE), requirements

engineering practices, global software engineering (GSE) and RE practices in GSE. This theoretical

research will be the foundation under the remaining of this thesis.

Chapter 3 presents a literature survey about requirements engineering in global software

engineering.

Chapter 4 details our research methodology. We explain our methodology of interviews and

surveys, the selection process of our respondents. In addition, we provide details on how we

administered the survey.

Chapter 5 presents the result of interviews and mini survey about RE in local organizations. First, we

explain key facts of the respondents and organizations; second, we present analysis of the result,

findings and observations.

Chapter 6 explains results of interviews regarding RE in GSE banking organizations. First, we explain

key facts of the respondents and organization; second, we reveal analysis of the result, findings and

observations.

Chapter 7 explains the results of a public survey concerning RE in GSE. First, we explain the key facts

of the respondents’ profile; second, we reveal analysis of the results, findings and observations.

Chapter 8, the final one, contains our conclusion and discussion on the result of our research. We

also reflect on our process in the research and identify directions for future work.

4

2. Theoretical Research

2.1. Introduction A successful software project highly depends on how requirements are handled on the beginning of

the project. In this context, a global software development (GSD) project needs an effective model

on handling requirements because of its unique processes and settings.

2.2. What is Requirements Engineering? Software has been the heart of many organizations’ activity for a number of years. Software product

is created around the needs of specific stakeholders. To capture those needs into software product

there is an activity called requirements engineering (RE), which is the first phase of Software

Development Life Cycle (SDLC) process. The success rate for a software product depends on the

satisfaction of the stakeholders [6, 7]. Thus, the importance of RE absorbed the interest of many

researchers, with the goal of improving the RE process and practice.

These are several definition of Requirements Engineering in literature:

The term “requirements engineering” is widely used to denote the systematic handling of

requirements. Software requirements express the needs and constraints placed on a software

product that contribute to the solution of some real-world problem (SWEBOK v3, 2014) [8].

Requirements engineering is interdisciplinary function that mediates between the domains of

the acquirer and supplier to establish and maintain the requirements to be met by the system,

software or service of interest. Requirements engineering is concerned with discovering,

eliciting, developing, analyzing, determining verification methods, validating, communicating,

documenting, and managing requirements. The requirements itself is a “statement which

translates or expresses a need and its associated constraints and conditions” (ISO/IEC/IEEE

29148, 2011) [9].

Requirements engineering emphasizes the use of systematic and repeatable techniques that

ensure the completeness, consistency, and relevance of the system requirements (Sommerville,

1997) [3].

2.2.1. Requirements Engineering Practices

In this section, we examine the details of RE practices. Requirement engineering practices merge

from the activities in the RE process. Sommerville’s Good Practice Guide (GPG) contains both

descriptions of the requirements process and associated activities, practices and guidelines for

assessing and improving an organization’s implementation of the requirements process [10].

The objective of the requirements process is to deliver a requirement specification document that

defines the system to be developed. The requirements process is an iterative process, therefore

when a project is started; the first activity is to define requirements, which requires a reciprocal

process between stakeholders and development team. In addition, the requirements process is an

intensive communication process between stakeholders and development team. Thus,

communication between related parties is crucial to lead to a successful RE process.

5

Sommerville et al. [10] define the generic RE process model, which is the adaption from Boehm’s RE

spiral model [11] and Pott’s RE terminology model [12] (see figure below).

Figure 1 A Generic Requirements Process Model [10]

In this figure, there are three main processes:

1. Requirements elicitation

Requirements elicitation means that in this RE phase, a problem owner or a business user in

organization writes statements contains needs and problems to be given to the development

team. This process results in initial draft statement of requirements. It is not a final

requirements document, it may be incomplete, vague, and contains an early version of

requirements specification document.

2. Requirements analysis and validation

The requirements discovered during the requirements elicitation are integrated and analyzed.

The analysis is usually enriched with modelling using common practices in RE such as the

definition of use cases and user scenarios. This process results in the identification of missing

requirements, inconsistencies and conflicts in requirements. This phase concludes in what has

been defined as ‘the requirements problems’.

3. Requirements negotiation

The requirements problems need to be resolved. The analysts and stakeholders clarify their

understanding and negotiate a win-win situation. The result of this process may contain a trade-

offs and misunderstanding that lead to further elicitation, analysis and validation. Finally, when

the requirements are validated by related parties, the requirements document is released as

final requirements document specification.

6

The aforementioned steps are encapsulated in a process called requirements management.

Requirements management deals with requirements change management, verification and

validation, requirements tracing and documentation.

Sommerville incorporates the RE process into a Good Practice Guideline (GPG), which we use as our

reference to investigate RE practices in GSE organization in this thesis. The GPG contains 66 good

requirements practices assembled from common RE practices, existing standards, literature, and

practical experiments. The practices are organized according to the process deliverables and

activities to which they apply; they are depicted in following table.

Table 2 Table RE Group Practices [10]

RE Group Practices Description

The requirements document How to organize the requirements document in order to effectively communicate requirements to customers, managers and developers.

Requirements elicitation Practices to help discover the requirements from system stakeholders as well as from the application domain, and the system’s operational and organizational environments.

Requirements analysis and negotiation Practice help identify and resolve problems (such as unforeseen requirements problems. incompatibilities or missing information) with the elicited requirements.

Describing requirements Guidelines for writing by requirements so as to maximize readers’ understanding.

System modelling Guidelines for the development of the abstract system models which are necessary for the understanding and analysis and their implications for the proposed system.

Requirements validation Practices to help establish formal validation procedures concerned with checking for problems such as incompleteness, inconsistency or incompatibility. They are also designed to help ensure that requirements are verifiable and that quality organizations are adhered to.

Requirements management Guidelines for aiding the management of requirements information throughout the development life-cycle.

2.2.2. Problems in Requirements Engineering Practices

Problems in the traditional requirements engineering (RE) practices have been analyzed in various

software engineering (SE) studies. For example, El Imam et al. conducted a field study on the current

RE practices in the industry in Canada [13]. They showed that there are seven issues in RE practices:

1. Package consideration Should package be considered in the RE process? Packages should be considered in the RE

process except if there already a legacy system.

2. Managing the level of detail of functional process models How much functional process modeling is necessary in the RE phase? It depends on how well we

know our system and the level of uncertainty when to stop the modelling activity.

3. Examining the current system

7

Should the legacy system in the organization be examined? If so, how detailed should this

examination be? If there is a legacy system, it is should be examined. There are four criteria to

detail the legacy system: Modeling existing system should be detailed enough to allow

diagnosis, more effort is necessary for larger legacy system, it may be possible to reuse models

in the current system, the next staff could learn about application model if they model the

current system.

4. User participation Should users participate in the RE process? If so, how could they participate and which users

should participate? Users should always participate in RE process. The mechanisms that can be

used to promote user participation include:

Face-to-face meetings;

Workshops with users;

Communication with users through e-mail and/or conference calls;

Liaison groups (either based in the user organization or IS organization);

Off-site visits by senior analysts to user departments;

Users sitting on a project steering committee;

Users reviewing and approving documentation items;

Users performing some of the requirements engineering activities themselves (e.g., benefits analysis);

Users paying for the project out of their own budgets;

Users are being evaluated on the overall success of the systems development effort. 5. Managing uncertainty

How can uncertainty be alleviated or dealt with in the RE process? The answers are: 1) assign

suitable skilled people to analyst and architect positions, in particular the lead architect, 2)

assign suitable skilled people to participate in the RE process, especially the principal user, 3) if

the uncertainty is too high, consider to establishing the prototype of the develop system.

6. Benefits of RE tools How can benefits be gained from CASE (Computer-aided software engineering) tools or any

similar tools in the process of RE? An infrastructure must be there to support the

implementation CASE tools (e.g. training on methods and tool, CASE support group) and

organization must be willing and able to invest such infrastructure in place.

7. Project management capability What are the necessary skills of a project manager? Always assign a project manager of high

capability to the RE phase.

Supha et al. studies RE practices in small-medium enterprise in Thailand [14]. The research reveals

changing requirements and inconsistent/incomplete requirements as the main problems that

occurred in RE practice. Similar research RE practices in an organization are also being done in US

[15], India [16], Germany [17], Malaysia [18], Pakistan [19], Chile [20], New Zealand [21] and Finland

[22]. Furthermore, Daniel et al [17] provided list of RE problems that exist in local organizations (i.e.

organizations that does not conduct global software engineering) as follows:

8

Table 3 List of RE Problems Summary [17]

RE Problems

1. Incomplete and/or hidden requirements 2. Inconsistent requirements 3. Terminological problems 4. Unclear responsibilities 5. Communication flaws within project teams and with customers 6. Moving targets (changing goals, business processes and/or requirements) 7. Technically unfeasible requirements 8. Stakeholders with difficulties in separating requirements from previously known solution designs 9. Underspecified requirements that are too abstract and allow for various interpretations 10. Unclear/unmeasurable non-functional requirements 11. Missing traceability 12. Weak access to customer needs and/or (internal) business information 13. Weak knowledge of customer’s application domain 14. Weak relationship to customer 15. Time boxing/Not enough time in general 16. Discrepancy between high degree of innovation and need for formal acceptance of (potentially wrong/incomplete/unknown) requirements 17. Volatile customer’s business domain regarding, e.g. changing points of contact, business processes or requirements 18. “Gold plating” (implementation of features without corresponding requirements) 19. Insufficient support by project lead 20. Insufficient support by customer

2.3. What and why is Global Software Engineering? Globally Distributed Software Engineering (we mean GSE in this thesis) is the discipline of design,

implementation and validation of software products and/or components on at least two geographic

locations and at least two continents [4]. According to Carmel, a Global Software Team (another

term of GSE) is a team that is separated by a national boundary while actively collaborating on a

common software/systems project [23]. Smite et al. defined GSE as development of a software

artifact across more than one location [24]. In addition, Smite et al. [24] explained other GSE terms:

Insourcing: Leveraging company-internal human resources

Nearshoring: Leveraging resources from a neighboring country

Offshore insourcing: Leveraging company-internal resources situated in a different country

Offshore outsourcing: Leveraging external third-party resources situated in a different country

Offshoring: Leveraging resources from a different country

Onshore insourcing: Leveraging company-internal resources situated in the same country

Onshore outsourcing: Leveraging external third-party resources situated in the same country

Onshoring: Leveraging resources from the same country

Outsourcing: Leveraging external third-party resources

Sourcing: Leveraging resources

9

GSE is well known for several challenges in distance, namely communication, control and

coordination [25].

Global software engineering or global software development is a growing research field and

provides new knowledge in term of benefits and challenges. In the future, software engineering

problems in industry would likely seek the best potential solutions in global term, not only in the

local (traditional) term anymore. Carmel [26], one of pioneer in GSE field, observed many factors

that drive ‘traditional’ software organizations into global software organization. Carmel described

there are four categories which motivated organizations turn global: catalyst, sustain, size and

‘vision’ factors. The catalyst factors are specialized talent, acquisitions, reduction factors, globalized

presence, reduction in time-to-market, proximity to the customer. The sustaining factors are

development rigor, internal freshness, distance from distractions, professional cadre of software

globalists and experience. The size factors are scale and evolving synergies of scale. The ‘vision’

factors are location transparency and virtual organization [26].

Moreover, many organizations have distributed software development across geographies to

capitalize on global resource pools, attractive cost structures, and round-the-clock development to

achieve cycle-time acceleration and cater to local markets [27]. Furthermore, the use of global

software development teams has increased rapidly due to the limited pool of trained workforce; the

necessity to locate specific expertise close to the customer; the differences in development costs

and the promise of round-the-clock development [26] [28]. Conchuir et al. reported there are six

assumed benefits of GSE organization, they are: 1) reduced development costs, 2) leveraging time-

zone effectiveness, 3) cross-site modularization of development work, 4) access to large skill labor

pool, 5) innovation and shared best practice, and 6) closer proximity to market and customer [29].

The complete summary of motivations in GSE can be found in table 4. We will use motivations in the

table below to analyze our findings in chapter 6.

Table 4 Motivations in GSE [26]

Category Explanation Factors Catalyst Primary reason of an organization

turn global; motivation that comes from within organization

Specialized talent; access to large skill labor

Acquisitions;

Reduction factors; reduction cost

Globalized presence

Reduction in time-to-market; follow-the-sun or round-the-clock development

Proximity to the customer and/or market

Sustain Supporting reason after GSE organization is running; motivation to keep successful GSE project/organization

Development rigor;

Internal freshness; innovation and shared best practices

Distance from distractions

Professional recruitment

Experience

Size Growth of company’s size; the situation that force company to open branch over the world

Scale

Evolving synergies of scale

Vision Future reason; the way a company Location transparency; technology enabler

10

shape itself to challenge the future (by technology and organization’s structure)

to work distance or far away

Virtual organization; cross-site modularization of development work

2.3.1. What is Requirements Engineering in Global Software Engineering?

The RE practices in GSE setting is gaining the interest of many researchers. GSE is rising due to the

impact of globalization and the influence of information communication technology. Nowadays

organization seeks solutions outside the organization itself in spite of boundaries of distance, nation

border, culture and language. The GSE organizations practice software development in spite of the

separation of organization’s sites. The unique nature of GSE makes it a valuable field for research.

Problems found in the traditional RE practice are already complex enough (see section 2.2.2 above),

researchers are eager to find what makes RE activities in GSE organization works well. According to

Damian, the reality of distributed projects is that cross-functional stakeholder groups are tasked

with specifying and managing requirements across cultural, time-zone and organizational

boundaries, thus creating an unique set of problems not only when an organization opens

development centers across the world, but also when software development is a multi-

organizational business affair [30]. Furthermore, Hashim et al. reported factors of GSE that have the

main impact in the requirements understanding, which are culture differences, geographic

dispersion, coordination breakdown, loss of ‘teamness’, loss of ‘communication richness’ and time

zone difference are factors that affect requirements understanding in the global project [31]. The

paper is based on three interviews, conducted in two software companies working in the Telecom

Sector and having global projects. The authors made a model of factors that influence RE in global

project as depicted in figure 2.

Requirements Understanding

in GSE

Culture Difference

Loss of Communication

Richness

Loss of Teamness

Geographic Dispersion

Coordination Breakdown

Time Zone Difference

Figure 2 GSE impacts on requirements understanding [31]

Furthermore, Hashim et al. underlined the definition of the impacts describe in the figure 2, as in the

following table. We will use these definitions in relation to findings of thesis research as described in

chapter 6 and 7.

11

Table 5 Impact factors in GSE definition as its influence requirements understanding [31]

Nr. GSE Impacts/Factors

Code Definition

1 Culture Differences CD Different ways of thinking, solving problems, attitudes, commitment, language and style of communication and so on.

2 Geographic Dispersion

GD Geographic dispersion is like “out of sight out of mind” which has caused several problems like trust, motivation, less coordination, miscommunication and control.

3 Loss of Communication Richness

LCR As distance increases communication becomes more problematic and challenging, availability of technology infrastructure, lack of closer interaction, mode of communication and lack of face-to-face interaction.

4 Coordination Breakdown

CB It’s hard to meet personally everyone i.e. lack of interaction and lack of intense communication

5 Loss of ‘Teamness’ LT Lack of face-to-face meetings and hence trust is lost, culture diversity, difference in organizational standards, policies and development processes and language barriers

6 Time Zone Difference TZD As distance increases time zone difference increases which in turn causes many problems like arranging meetings, loss of intense interaction and co-ordination and mode of communication.

Cultural differences are studied by many scholars in GSE field as one of important factors for a

successful global project. By their nature, GSE projects involved many nationalities. Hofstede was

one of the first researchers who conducted research on cultural differences. She proposed five

dimensions of culture: power distance (PDI), collectivism vs. individualism (IDV), masculine vs.

feminine (MAS), uncertainty avoidance (UAI)and long-term vs. short-term orientation (LTO) [32].

The definition of these dimensions is depicted in following table.

Table 6 Hofstede's five dimensions of culture [32]

Dimensions Definition Power distance Power distance is defined as the extent to which the less powerful members of

institutions and organizations within a country expect and accept that power is distributed unequally

Collectivism vs. Individualism

Collectivism pertains to societies in which people from birth onwards are integrated into strong, cohesive in groups, which throughout people's lifetime continue to protect them in exchange for unquestioning loyalty, whereas Individualism pertains to societies in which the ties between individuals are loose: everyone is expected to look after himself or herself and his or her immediate family

Masculine vs. feminine Masculine pertains to societies in which social gender roles are clearly distinct (i.e., men are supposed to be assertive, tough, and focused on material success whereas women are supposed to be more modest, tender, and concerned with the quality of life. Feminine pertains to societies in which social gender roles overlap i.e., both men and women are supposed to be modest, tender, and concerned with the quality of life.

Uncertainty avoidance Uncertainty avoidance can be defined as the extent to which the members of a culture feel threatened by uncertain or unknown situations and try to avoid

12

such situations Long-term vs. short-term orientation

Long-term orientation is defined as persistence (perseverance) ordering relationships by status and observing this order thrift having a sense of shame. Short-term orientation is defined as personal steadiness and stability protecting your 'face'; respect for tradition; reciprocation of greetings, favors, and gifts

The index of survey conducted by Hofstede on different countries (summarized in just selected

countries and selected dimensions) is depicted in table 7. Table 7 Index of five dimensions of culture [32]

Country PDI IDV MAS UAI LTO

Netherlands 38 80 14 53 44 Germany 35 67 66 65 31 USA 40 91 62 46 29 India 77 48 56 40 61 China 80 20 66 30 98 Indonesia 78 14 46 48 -

Brockmann et al. observed that learning cultural differences could enhance RE activities in the global

project. This paper is based on an empirical study on agile requirements engineering ongoing in a

joint Chinese-German software development project for a Chinese regional bank. The research used

Hofstede’s dimensions and implementation of agile software methodology [33]. The authors

suggested the solutions in table 8, to the cultural differences between Chinese and Germans.

Table 8 Cultural Differences Solutions in Agile RE in GSE project [33]

Cultural Dimensions Suggested Solutions Power distance Self-organization and a lack of fixed hierarchical structures prescribed by agile

methods may be disturbing in cultures like China with high power distance. One solution is to adapt some of the agile roles, such as “Scrum Master” to better-fit hierarchical organizational structures. Instead of a democratically elected scrum master, the person with the highest status in the group would receive this title.

Collectivism vs. individualism

Agile methods advocate joint ownership of code and team responsibility. This can be a problem for some German team members, who have a high level of individualism. Here, team training workshops and group social events may be of help in increasing group cohesiveness.

Masculine vs. feminism

Cooperation, communication and pair programming advocated by agile methods can be hindered by a high value for masculinity, as in Germany. Masculine values such as competition and assertive behavior can be constructively redirected through conflict management techniques.

Uncertainty avoidance

A high level of ambivalence, as in China, can prove to be a major obstacle to agile requirements engineering methods. German developers, who expect clearly defined project requirements, express puzzlement at not understanding what their Chinese customers want. Frequent communication and cultural awareness training can help increase understanding on both sides.

Long-term orientation Frequent iterations and short-term sprints may be viewed as frustrating to Chinese team members, who highly value long-term orientation. Here, schooling and communication on the goals and effectiveness of agile methods may help in defining the iterations as steps toward an ultimate goal: software that works.

13

We will use cultural differences dimensions as explained above to analyze the research findings in

chapter 6.

Other RE activities in GSE are described as following. Cheng et al. reported that the success of a

software system depends on how well it fits the needs of its users and its environment [7]. Alnuem

et al. wrote that the requirements understanding is necessary because requirements engineering is

a foundation to a high quality software development [34]. Further, Laurent et al. indicated that

globalization has been recognized as a major research challenge in the requirements engineering

domain [35]. Herbsleb observed that, in the global development context, the inherent difficulty of

achieving a shared understanding of the requirements is amplified, because of both loss of context

and loss of communication bandwidth [36].

2.3.2. Requirements Engineering Practices in Global Software Engineering Organization

Many papers discuss requirements engineering practices in global software engineering

organization. The specific goals of these papers vary but they all investigate effective solution to

overcome distance challenges in a global project.

Constructing an effective RE practices in GSE setting organization is important because many GSE

organizations need to find better practices that fit into a global project perspective. These

organizations are looking only for theories about RE in GSE but also practices that work well in real-

world situation [37]. Therefore, many scientists tried to define a framework to illustrate the RE best

practices in GSE organization.

Bhat et al. attempted to make a holistic framework for RE best practices. This framework is based

on literature and real work experience of the authors. The framework is defined by strategic success

factors in GSE project and its impact on category of people, process, and technology. The strategic

success factors selected by the authors are share goals, shared culture, shared process, shared

responsibility and trust [37]. The complete framework can be seen in table 9. We are going to use

the terms in this table to examine findings in chapter 6.

Table 9 A Holistic Framework of Best RE Practices in Global Organization Setting [37]

Success Factors

Best Practices

People Process Technology Share goals Develop a stakeholder

viewpoint

Include team member satisfaction in the project success factor

Build the team vision collaboratively Use a human facilitator in integrated, rich communication media during decision making

Shared culture Provide cultural training to team members

Train team members on using

communication technology

Build consensus on formal operating norms or meetings, deadlines, and commitments

Facilitate communication sessions to allow every member to speak

Share requirements-specification templates

Establish technology accessibility and compatibility for all teams

Shared process Train team members to use Use distributed Quality Function Use electronic mediation

14

right processes, tools, and technologies

Deployment for requirements prioritization

Create a proper project structure clearly showing the value and dependency of each

activity and artifact

Adopt a standard way to work (for example, the CMM)

Maintain and share a project-artifacts repository

Share requirements specification templates

(computer conferencing) to enable remote participation of conflicting stakeholders during requirements negotiation

Shared responsibility

Develop practical performance metrics and project-reporting mechanisms

Increase visibility with frequent deliverables

Establish a requirements awareness system, outlining people’s roles and responsibilities

Trust Get team together at the formation stage for a face-to-face kickoff session

Build team vision collaboratively

Schedule ongoing informal meetings No practice available

Damian et al. examined collaboration, awareness, and distance in requirements – centered social

networks in industrial distributed software project. Their findings indicated that organic patterns of

collaboration involving considerable cross - site interaction exist, in which communication of

changes was the most predominant reason for interaction. Furthermore, the authors recommend

few practices that software practitioners may find useful in guiding the analysis or improvement of

requirements - driven collaboration in their own organization [38].

The work of Niazi et al. is the ambitious attempt to create a complete framework (named in

‘GlobReq’) in RE practices in GSE organization. The paper is based on empirical study with five GSE

organizations. The framework is devised from Sommerville et al’s 66 RE best practices. The study is

conducted by distributing survey into personnel in five organizations toward Sommerville’s best RE

practices. The research’s goals are to: 1) determine what the most important of all the RE practices

advocated by Sommerville et al are for GSD projects, 2) identify any additional RE practices

important for GSD projects that may lack from the list of Sommerville et al practices. The initial

findings for this research are showed in table 10. The results show that the most common ‘high’

value requirements documentation practices are ‘defining a standard document structure’ and

’making a business case for the system’. ‘Define the system’s operating environment ‘is the most

frequently cited ‘high’ value requirements elicitation practices. The most common ‘high’ value

requirements analysis and negotiation practice is to ‘define system boundaries’. The majority of the

respondents stated that their organizations consider ‘use languages simply and concisely’ as a ‘high’

value practice. The most frequently cited ‘high’ value systems modelling practices are ‘model the

system architecture’ and ‘use structured methods for system modelling’. ‘Check that the

requirements document meets your standards’, ‘organize formal requirements inspections’ and ‘use

multi-disciplinary teams to review requirements’ are the most common ‘high’ value requirements

validation practices. The results show that ‘identify global system requirements’ is the frequently

cited ‘high’ value requirements management practice. Hence, the authors found that not all 66 RE

best practices are perceived as high value practices for GSD projects [39].

15

Table 10 List of High Perceived RE Practices in GSE Organizations [39]

RE Practices Category High Perceived RE Practices Requirements Documents Practice Define a standard document structure

Make a business case for the system Requirements Elicitation Practices Define the system’s operating environment Requirements Analysis and Negotiation Practices Define system boundaries

System Modelling Practices Model the system architecture Use structured methods for system modelling

Requirements Management Practices Identify global system requirements Describing Requirements Practices Use languages simply and concisely Requirements Validation Practices Check that the requirements document meets

your standards Organize formal requirements inspections Use multi-disciplinary teams to review requirements

Requirements Engineering for Critical Systems Practices

Identify and analyze hazards Derive safety requirements from hazard analysis Cross-check operational and functional requirements against safety requirements Establish an organizational safety culture

Finally, Alnuem et al. studied challenges in requirements understanding in GSE organization and its

practical solutions. This work is based on qualitative case study in software companies in Saudi

Arabia that conducted GSE project. As it already mentioned, challenges in requirements are culture

difference, geographic dispersion, coordination break down, loss of communication richness, loss of

‘teamness’, and time zone differences. The paper reported that the following tools/practices are

used regularly to overcome challenges in GSE project: documents management, competence

management, video/audio conferencing, email/chat, visualization of requirements, telephone, job

rotation, visiting (face-to-face) /kick-off-meetings, terminologies, rewards, and trainings [34]. The

complete summary of the research is shown in table 11. We clearly see that email/chat and

telephone are the most common tools/practices that used in RE activities in GSE companies to

overcome challenges in the global project.

Table 11 Summary of Tools/Practices used in RE activities in GSE organizations [34]

Tools/Practices Culture Differences

Geographic Dispersion

Loss of Communication

Richness

Coordination Breakdown

Loss of ‘Teamness’

Time Zone Difference

Documents Management

Yes Yes Yes Yes - -

Competence Management

Yes Yes Yes - - -

Video/Audio Conferencing

- Yes - - - -

Email/chat Yes Yes Yes Yes Yes Yes Visualization of Requirements

Yes Yes - - - -

16

Telephone Yes Yes Yes Yes Yes Yes Job rotation Yes Yes Yes Yes - - Visiting (face-to-face) /kick-off-meetings

Yes - Yes Yes - -

Terminologies Yes - Yes - - - Rewards Yes Yes - Yes Yes - Trainings Yes Yes Yes Yes Yes -

There are other tools/practices mentioned in the paper, but are not used regularly by the companies

they survey with. The tools/practices are forums, motivation/trust building, standards, and liaisons.

We are going to use these solutions mentioned here to support thesis research.

17

3. Literature Review

3.1. Literature Survey Preparation According to Kitchenham et al., a systematic literature review (also mention as a systematic review)

is a means of identifying, evaluating and interpreting all available research relevant to a particular

research question, or topic area, or phenomenon of interest [40]. Individual studies contributing to a

systematic review are called primary studies; a systematic review is a form of secondary study [7].

We use similar method used by Scheneider et al. to conduct this SLR. The procedure consists of

three steps: formulation of research question, searching strategy and SLR execution including

inclusion, exclusion and extraction rules applied for all articles found [41]. In the following section,

we will explain these steps further.

a. Identification of the need for a review

We need to investigate whether the previous studies or researches have similar or different

approach related requirements engineering in GSE setting. On this reason, we gather a selected

amount of papers or books that fit to our study.

b. Specifying the research question(s)

We specified the research questions in table 12 below. The basic idea of performing SLR is to

identify as much as possible GRE research in term of requirements engineering. We use SLR as

preliminary study of thesis work regarding RE in GSE.

Table 12 Research questions and its description

Research Questions Description

RQ1 What is the area of study of RE in GSE based on literature?

To find out what is the common practice in GSE regarding RE, we need to categorized previous research of RE in GSE

RQ2 What are the deliverables in research of RE in GSE?

To find out the research contribution In the field of RE in GSE

RQ3 What is the research methodology of RE in GSE? The description of research methodology RE in GSE

c. Conducting Search

We selected four research databases that relevant with our research area: ACM, IEEE Explore,

Springer Link, and Google Scholar. We set up initial search strings, test it, and refined it into the

aforementioned databases.

The first group search strings are:

“Global Software Engineering” OR “Distributed Software Engineering” OR “Global Distributed

Software Engineering” OR “Global Software Development”.

The second group search strings are:

“Software Requirement” OR “Requirement Engineering”.

We combine both group strings and search it into the databases. Then, we look for conference

papers as well as part or chapter of books. Year of publishing is from 2000 until present. We prefer

18

English language documents. The complete search criteria are shown in table 13. The search

strategy is depicted in table 14.

Table 13 Search Criteria

Criteria Description

Keywords (“Global Software Engineering” OR “Distributed Software Engineering” OR “Global Distributed Software Engineering” OR “Global Software Development”) AND (“Software Requirement” OR “Requirement Engineering”)

Publishing Types Conference Papers, Journal, Chapter Books, Books Period of Publishing 2000 until present Language English

Table 14 Search Strategy

Source Specific Search Strings Extra Options Included

ACM (“Global Software Engineering” OR “Global Software Development”) AND “Requirement Engineering”)

Selection of publication year 2000 and conference paper from software engineering

IEEE Explore (“Global Software Engineering” OR “Global Software Development”) AND “Requirement Engineering”)

Combined with exact match case of string: “Globally Distributed Requirement Engineering”

Springer Link (“Global Software Engineering” OR “Global Software Development”) AND “Requirement Engineering”)

With refine search with computer science and software engineering discipline and language English only

Google Scholar (“Global Software Engineering” OR “Global Software Development”) AND “Requirement Engineering”)

Combined with exact match case of string: “Globally Distributed Requirement Engineering

d. Data extraction and data screening

We use screening criteria to select papers as specified in table 15. We exclude papers that contain

only either GSE or RE. We include the papers that contain both GSE and RE. We make inclusion of

papers within the context of requirements engineering in global software engineering (GSE) only,

which is the central topic of this SLR. We dismiss papers that are duplicate, unrelated topic, a

workshop, an opinion, or a guideline. The result of data screening or extraction is depicted in table

16. The complete information of this list can be checked in Appendix A.

Table 15 Selection of Studies

Phase Inclusion Criteria

Based on Search Containing search strings, English Language and from the year 2000 Exclusion upon Title Does not include proceedings comments, workshops or letters and

repeated works

Exclusion upon Abstract Discusses RE in GSE

Exclusion upon Full Text Paper type of complete research, research proposal, summary, and SLR

19

Table 16 Result of Data Screening

Source Results RE in GSE context Final Sorting and Validate

ACM 637 11 9 IEEE Explore 567 28 26 Springer Link 569 6 6 Google Scholar 28 6 6 Total 1801 51 47

3.2. Literature Survey Result In this section, we explain the result of our SLR to answer our research questions. RQ1 is described

as a categorization of each paper based on domain research of requirements engineering, which are

elicitation, analysis, specification, and validation of software requirements. We also found other

areas of study for example general process, organization structure, communication and risk

management. The complete result of RQ1 analysis is shown in table 17. Surprisingly, most of the

papers discussed general process of requirements engineering in GSE (26%). This can be explained

because general process of RE in GSE has not been standardized so that most researcher proposed.

The area of study about elicitation process in RE (21%) has also been choosen by the researchers

because the elicitation is the first activity in RE process. Then, next result is communication of

requirements, which is strongly related to elicitation process in RE (17%). Then, analysis of

requirements (11%) is the next topic. The rest of the area of study includes culture (7%), risk

management (4%), future direction of RE research (4%), validation of requirements (4%), and

evaluation of requirements activities (2%), decision-making (2%), and organization structure (2%).

Table 17 RQ1 Analysis

Area of Study Paper # Papers Percentage

Process [14][21][24][25][26][27][30][37][41][45][46][47] 12 26%

Elicitation [10][15][18][19][22][23][31][32][34][35] 10 21%

Communication [1][2][4][5][7][13][16][33] 8 17%

Analysis [8][9][28][36][40] 5 11%

Culture [12][17][44] 3 7%

Future Direction [42][43] 2 4%

Risk Management [6][38] 2 4%

Validation [11][39] 2 4%

Evaluation [20] 1 2%

Decision Making [29] 1 2%

Organization Structure [3] 1 2%

47 100%

20

RQ2 has a goal to investigate the deliverables of these papers. We want to know what is the the

state-of-the-art research in the field of RE in GSE. The result is shown in table 18. As we can see,

modelling is the most frequent deliverables in the research of RE in GSE (80%), followed by tools

(11%) and summary of RE in GSE research (9%). Table 18 RQ2 Analysis

Deliverables Paper # Papers Percentage

Modelling [1][2][3][5][6][7][8][9][11][12][13][14][15][16] [17][18][19][21][22][23][25][26][28][29][30][32] [33][34][35][36][37][38][39][40][41][44][45]

38 80%

Tools [4][10][24][27][31] 5 11%

Summary [42][43][46][47] 4 9%

47 100%

RQ3 has a goal to locate the common research methodology use in research of RE in GSE. The result

of RQ3 analysis is depicted in table 19. We found that the literature survey is the most used

methodology (35%), followed by case study (33%) and experiment (20%). The rest is combination of

interviews and case study (4%), survey (4%), case study and literature survey (2%), and interviews

(2%). The literature survey is the common practice in conducting research in RE in GSE because the

amount of literature in the field. Case study is likely used to prove the hypothesis found in the

theory or in the literature: the same reason is also applied to the experiment. Hence, these

methodologies are common used in the practice of RE in GSE research field.

Table 19 RQ3 Analysis

Research Methodologies Paper # Papers Percentage

Literature Survey [1][19][21][32][33][34][36][37][38][39] [40][41][42][43][44][46][47]

17 37%

Case Study [2][5][7] [12][14][15][16][17][18][23][25] [26][27][28] [45]

15 32%

Experiment [4][11][13][20][22][24][29][31][35] 9 19%

Interviews and Case Study [8][30] 2 4%

Survey [6][9] 2 4%

Case Study and Literature Survey

[3] 1 2%

Interviews [10] 1 2%

47 100%

21

4. Research Methodology

4.1. Introduction To obtain information on the current state of the practice with respect to reach the goals of our

investigation, we conducted semi-structured interviews. This is a common research method to

collect rich data on participants’ experience and perceptions [2]. This thesis research category

belongs to descriptive research. A research strategy that aims at obtaining a snapshot (description)

of specific characteristics of a specific group of individuals [42]. In this chapter, we will explain

methodology of this thesis research, designing interviews, mini survey, and public survey, overview

of our respondents’ profile, and administration of the research’s result.

4.2. Methodology Ours is qualitative research. Qualitative research is based on making observations that are

summarized and interpreted in a narrative report. Our research strategy is a descriptive research

strategy. According to F.J. Gravetter, et al., the descriptive research strategy is to obtain a snapshot

(description) of specific characteristics of a specific group of individuals. One of the descriptive

research designs is survey research design [42]. We selected survey research design because it

provides methods to obtain data from respondent in short of period time and relatively not

complex. The goal of the survey research design is to obtain an accurate picture of the individuals

being studied. Furthermore, in designing survey research, we have four issues: (1) survey questions

must be developed; (2) the questions must be assembled and organized to produce a well-

constructed survey; (3) a selection process must be developed to determine exactly who will

participate in the survey and who will not; survey participants must be representative of the general

group to be studied; (4) we must determine how the survey is to be administered.

The research methods used in this thesis are interviews and surveys. The flow of this thesis is similar

to the one described in Alnuem et al., but without companies feedback, as depicted in figure 3. Our

considerations are time and resource to do the thesis research, as we have only limited amount

time to do research while the material research is abundant, so we opted for personal interviews,

mini surveys, and public surveys, described in section 4.3, 4.4, and 4.5 respectively.

22

Literature Review

Interviews on Global RE Organization

Mini Survey and Interviews on Local

RE Organization

Analysis Grounded Theory

Discussion and Recommendations

Public Survey on RE in a Global Project

Thesis Outline

Figure 3 Thesis Research's Outline

4.3. Designing Interviews We plan to interview to several key people who involved in GSE activities, in particular those

responsible for gathering and managing requirements from stakeholders in GSE project setting. The

interviews structure is described in table 20. The questions would be mix of open-ended and close

questions. There are total of 21 questions interview questions with approximately 2 hours of

interview duration per person.

Table 20 List of Interview questions

No Categories Interview Questions

I Background Information

1. What is your name, position and how long your experience? 2. Have you ever been involved in Global Software Engineering (GSE) /Global

Software Development (GSD)/Distributed Software project in your organization? If yes, please describe your GSE project’s organization.

II RE Problems and Solutions

1. List top three of problems RE practice in in your organization in particular on GSE project setting. Please explain.

2. What is the solution of the previous problems of RE in GSE project setting. 3. What GSE characteristics have the largest impact on RE? Please explain. 4. Which tools do you consider that they most important to solve problems in

RE activities on GSE project setting? Please explain. 5. Do you have certain rules or procedure in your GSE organization in context

of managing requirements

II RE Practices RE General 5. What is your software development methodology?

23

6. What is the difference between RE practice in local and global software

development project?

7. What is the goal of requirements engineering activities in your organization

especially in GSE project setting?

8. What do you do on requirements phase in GSE software development

project?

9. Describe the flow of the requirements process in your organization, as if

from users or else.

RE Documents 1. How do you manage the requirements document? Please describe.

RE Elicitation and describing requirements

2. How do you carry out requirements elicitation or how do you describing

requirements? Please explain.

RE Modelling Requirements 3. How do you model the requirements? Please describe.

RE Analysis and Negotiation

4. How do you analyze and negotiate the requirements? Please describe.

RE Validation 5. How do you validate the requirements? Please describe.

RE Management 6. How do you manage your whole requirements processes? Please describe.

VI Closure 1. How important do you think RE is in your GSE development project?

2. How much you spend in RE in your GSE project compare to other phase of development.

3. If you have power to change one thing in RE process in GSE to much better level, what you do?

4.4. Designing Mini Survey We design a mini survey for local RE organization to investigate RE practice, activities, problems and

solutions in local project setting. We define questionnaire in mini survey based on key process in RE

which are: requirements elicitation, requirements analysis, requirements specification,

requirements validation and requirements management. RE practices including activities and

techniques are explained in table 21, which we summarized from work by A. Haron et al. [43]. In

addition, we also cover further information concerning the relation between RE processes, people,

deliverables and its indicators in table 22, from the same author [43]. Furthermore, we cover

questions of problems and solutions that exist in conducting RE in global setting. The list of

problems and solutions are collecting from various literatures.

24

Table 21 RE Practices, Activities and Techniques [43]

RE Practices Activities Techniques

Requirement elicitation Define the product , vision and project scope; Identify Stakeholder, customer and users; Select Product, Champion

Interview, Questionnaire & Survey, Explore, user scenario, Observation & social analysis

Requirement analysis Create analysis models, build, and evaluate prototypes; prioritize requirements

State machine, Fault Tree Analysis, Scenario-Based Approach

Requirement specification Regression Test, traceability, corrective maintenance

UML, IEEE Recommended Practice, Volere requirements specifications, other template specification

Requirement validation Review the requirements, create test cases from requirements

Formal inspection

Requirement management Manage requirements versions; adopt a change control process; provide requirements change impact analysis; store requirements attribute; track the status of each requirements

Usage of change management tool, traceability, repository, version control

Table 22 RE Process Indicators [43]

4.5. Designing Public Survey We use internet surveys method to conduct public survey [42]. The material that we use for public

survey is summarized from findings that we found from interviews in GSE organizations. The main

contents of this survey are: 1) RE problems and its solutions, 2) confirmation about findings in the

previous GSE organization interviews results. The goal is to gain information about the three most

important RE problems in a global project, their effective solutions, and confirmation to our findings

in the interviews. We design public survey as follows. We divided the survey into three categories: 1)

Information Background (we coded as IB); 2) RE problems and solutions in GSE project with list RE

Problems (P) and Solutions (S), what is top three RE problems and it solutions (PS), and set of RE

problems and it solutions questionnaires (REPS); and 3) Closure (C).

RE PROCESS PEOPLE DELIVERABLE INDICATOR

ELICITATION Stakeholder, Developer, Project

TeamA set of user needs Complete, sufficient, correct

ANALYSIS & NEGOTIATIONStakeholder, Developer, Project

TeamA set of requirements is agreed

Necessity, consistency,

completeness, feasibility

DOCUMENTATION Stakeholder, Developer, Project

TeamRE Practice and Technique

Unambiguous, complete,

correct,understandable,

consistent, concise,feasible,

quality

MANAGEMENT Stakeholder, Project Team,

ManagerRepository of artifacts Reliability, robust

VERIFICATION & VALIDATION Project Team, ManagerEstablish set of Requirements, Test

Cases

Conformance to standard and

policy

25

The information background section is divided into three subsection called personal information,

organization, and global project. We collected the set of problems in RE and the set of the solutions

in RE from theoretical research in chapter 2. Furthermore, we have some additions to set of

problems and solutions of RE in GSE based on our findings in this research (see chapter 6). Then, we

set up several open questions. In the closure, we ask the respondents about possible improvements

to the RE practices in the global project based on participant’s experience.

The complete summary of the public survey can be found in following table.

Table 23 Public Survey Questionnaire and References

Set of Questionnaire References

I. Information Background (IB)

a. Personal Information IB1. What is your position in the organization?

IB2. How many years have you been working in software development? b. Organization

IB3. Within your organization, have you ever been involved in a project that includes any of the following: Global Software Engineering (GSE), Global Software Development (GSD), Distributed Software, Offshoring, and/or Nearshoring?

IB4. What is your organization's business domain? IB5. If your organization's business domain is banking, what is its specific domain? IB6. What is the approximate size of your organization?

c. Global Project * IB7. Why does your organization conduct this project in a global setting? IB8. What is the difference when doing RE in a global setting compared to local settings? Why? IB9. What is the type of the project? IB10. What triggered the start of this project? IB11. Which of the following development life-cycles best describes the one used in the project? IB12. What was the duration of the project? IB13. Who are the stakeholders of the project? IB14. Who are the users of the project?

II. RE Problems and Solutions in a Global Project Set of Problems Description

No Problems Description

P1 Lack of customer and user communication

P2 Lack of developer communication

P3 Lack of training

P4 Inappropriate skills

P5 Lack of defined responsibility

P6 Unstable workforce (low staff retention)

P7 Poor time and resource allocations

P8 Complexity of application

P9 Undefined RE process

P10 Requirements provided (stated) by customers are not the actual requirements

[17, 21, 44] [19, 44] [17] [15, 17, 19] This study [15, 17, 21] This study This study [21, 22] [21, 22] [15, 22] [15, 21, 22] [45] [45] [17] [17] [17] This study This study This study This study [17] This study [17]

26

P11 Poor user understanding

P12 Incomplete / inconsistent requirements

P13 Requirements keep changing

P14 Inadequate requirements traceability

P15 Ambiguous requirements

P16 Misplaced requirements in a requirements document

P17 Cultural Differences

P18 Geographic Dispersion

P19 Loss of Communication Richness

P20 Coordination Breakdown

P21 Loss of ‘Teamness’

P22 Time Zone Difference

P23 Developer's lack of business understanding

P24 Understanding people's competences in distance

P25 Translating business requirements into Technical Requirements

P26 Different perception of requirements between stakeholders and team

P27 Different/Various suppliers/developers team involved in the project

P28 Requirements processes are not transparent

P29 Different software methodology used between internal and outsource partners

P30 A multitude of international stakeholders

Set of Solutions Available to solve problems description above: 1: Not effective; 2: mildly effective; 3: moderately effective; 4: strongly effective; 5: extremely effective

No Solutions Description 1 2 3 4 5

S1 Documents Management

S2 Competence Management

S3 Video/Audio Conferencing

S4 Email/Chat

S5 Forums

S6 Visualization of Requirements

S7 Telephone

S8 Job Rotation

S9 Motivation and Trust Building

S10 Visiting (Face to Face)/Kick off Meetings

S11 Terminologies

S12 Standards

S13 Rewards (Prizes and Salary Increments)

S14 Trainings (Culture, Language etc.)

S15 Liaisons (onsite representative/coordinator from

[17] [17] [17] [17] [17] [17] [17] [31] [31] [31] [31] [31] [31] [17] This study This study This study This study This study This study This study [34] [34] [34] [34] [34] [34] [34] [34] [34] [34] [34] [34] [34] [34] [34]

27

offshore development team)

S16 Requirements traceability matrix

S17 Requirements change management process

S18 Proper Project Management Office (PMO) to make RE processes more transparent

S19 Multidisciplinary requirements team

S20 Suppliers/Offshore/Outsource team alignment

S21 Test driven requirements specification

S22 Very detail requirements specification

S23 User stories for requirements specification

Questions: PS1. The most important problem concerning RE in a Global Project PS2. Other most important problem PS3. How effective are the following solutions to solve the most important problem PS4. 'Other' solution to the most important problem PS5. The second most important problem concerning RE in a Global Project PS6. 'Other' second most important problem PS7. How effective are the following solutions to solve the second most important problem PS8. 'Other' solution to the second most important problem PS9. The third most important problem concerning RE in a Global Project PS10. 'Other' third most important problem PS11. How effective are the following solutions to solve the third most important problem PS12. 'Other' solution to the third most important problem

III. RE Problems and Solutions in a Global Project

Questions: REPS1. According to your experience, what is the most effective solution for RE problems in a global setting? Why? REPS2. Is it the use of 'a liaison' officer to represent the offshore teams in the onsite team effective to solve RE problems in a global project? If so, which ones and why. A liaison officer is someone assigned from offshore team into onsite team to facilitate the connection between the two teams. REPS3. Is it the use of online collaborative tools such as videoconferencing, document repository, chatting, email, telephone effective to solve RE problems in a global project? If so, which ones and why. REPS4. Is it the use of a transparent process in RE effective to solve RE problems in a global project? If so, which ones and why. By 'transparent process' we mean a very structured RE process with clear steps that everybody in the project knows.

IV. Closure C1. Are there special activities you conduct to make RE processes/practices

This study This study This study This study This study This study This study This study [17, 18, 21, 34] This study This study This study This study This study

28

work well in a global project? If so, which ones and why. C2. What would you change in the current RE process in a global project to make it more effective? IB15. What is your name? IB16. What is your email address? IB17. Would you like to be contacted for future investigation on this topic?

[17] and this study [15] [15] [15]

We analyze the survey results by using ‘coding’ analysis, ‘one-way tables’, and ‘cross-tabulation:

two-way tables’ [46]. By ‘coding’ analysis, we mean that we scan the set of responses, themes are

developed which reflect the items noted in the material. By ‘one-way tables’, we mean that we

tabulate results, question by question. We do this to get at the glance of survey results. Then, by

‘two-way tables’, we mean that we break down the results into two-way tables showing the

response categories of one question as row headings, those of another question as column headings

[46].

About the analysis of the survey results, first, we categorize the survey results into four main

categories that are abbreviated in IB, PS, REPS, and C.

On IB category, we present survey results of personal information, organization, and the global

project. Furthermore, personal information contains role and number of years’ experience of our

audience. Organization contains business domain and size of our respondent’s organization. In the

global project, we present results of motivation in doing global project, differences between RE in

local compare to global, type of project, what is triggered the project, software methodology used,

duration of project, who are the stakeholders and users of the project. We collect and present that

information to get context of this global project that audience involved. In this category, we will

employ one-way table to present the results.

On PS category, we present survey results of the top three problems on RE in a global project and

what are the effective solutions to it. Because of the questions of solutions are presented with likert

type choices of answer, we will present our results with two-way tables. We ask audience these

likert questions type: 1: Not effective; 2: mildly effective; 3: moderately effective; 4: strongly

effective; 5: extremely effective. We would like to know what kind solutions are effective choose by

the respondents to the given top three problems RE in the global project. Therefore, we would

analyze the outcome of the survey and compare it to our interviews results.

On REPS category, we ask open questions, to confirm our main findings in the interviews results.

We measure the answers manually to see whether they are positive or -negative answers. Then, we

will perform coding (qualitative) analysis on the respondent answers.

On C category, we ask open questions, to gather additional information related to RE practice in the

global project. The focus here is to find out what is the uniqueness of RE in global setting. In

addition, we would like to know what the respondents think about the improvement RE practice in

current situation. We will perform coding analysis (qualitative) analysis on this category.

29

We acquire respondents for our survey in several ways: 1) in social media such as Linkedin and 2) in

professional contacts. We select Linkedin because this type of social media contains professional

groups that match our respondent’s profile. We prefer public respondents who have characteristics

such as role in Requirement Engineering field, having experience in global projects in particular

requirements engineering processes/practices, and working in banking industry.

4.6. Selecting Respondents We select as target respondents for the pilot interviews for the local organizations a bank in

Indonesia and for the global organizations, some banks in the Netherlands. Furthermore, in

particular global organizations, we target audience of the survey of people who hold position as

software engineer or related positions.

Why do we select banks as our respondents? The first reason is because the background of the

author who work in banking industry especially in software development for 10 years. Second

reason is that banks in the Netherlands have extensive experience in global. Lastly, conducting

research in banking industry is relatively new. The list of the Banks that we plan for our research

respondents are shown in table 24 below:

Table 24 List of Banks’ Respondents

Nr. Organizations Specialization Time of Interview

1 Bank B Central Bank October 2014

2 Bank I Commercial Bank 10 December 2014

3 Bank K Commercial, Investment Bank 9 January 2015

4 Bank S Commercial Bank 13 January 2015

5 Bank R Commercial Bank 19 January 2015

Our period of interviews was started on October 2014 until February 2015.

4.7. Administering Interviews, Mini Survey and Public Survey In administering the interviews and survey, we use in-person and internet survey technic to

distribute and collect data. F.J. Gravetter explained that the strengths and weaknesses of our choice

of administering the survey[42].

In-person interviews and surveys have number of strengths. First, they are efficient to administer

with groups. Second, they also have 100% response rate. Third, they are flexible to administer either

in groups or in individual interviews in term of execution and time. However, this type also has

weaknesses. First, conducting interviews is time consuming. The other disadvantage is we can face

risk of interviewer bias.

In other hand, internet surveys have certain advantages. First, they are efficient to administer to a

large number of participants. Second, we have access to large number of individuals with common

characteristics. Third, internet surveys can be individualized based on participant’s response.

30

However, this method also has impediments. First, they may have cost to use the survey’s website.

Second, there is risk that respondent’s sample may not be representative. Lastly, it probably cannot

control composition of the sample.

In general, survey has advantages such as flexibility, to obtain of a wide variety of different variables,

and to provide a relatively easy and efficient for gathering a large amount of information. In the

opposite, survey research has disadvantages such as low response rates and response bias. In

addition, responses to survey questions can also be difficult to analyze or summarize, for example

answers to open-ended questions. In addition, the information obtained is always a self-report. The

quality of a survey study depends on the accuracy and truthfulness of the participants. It is certainly

possible that at least some participants will distort information, or simply have no knowledge about

the topic when they answer certain questions.

31

5. Interview Results for the Pilot

5.1. Introduction We conducted pilot interviews to a local organization, namely bank B. Time of interviews is

described in section 4.6. Here we are going to explain the respondent’s overview, key facts of

organization and software development methodology that been used by this organization. The

interviews are done via online chatting tool. The respondents have approved that the interview to

be recorded for analysis purposes.

5.1.1. Respondents Overview

In this section, we describe the respondent’s profile of the pilot project. There are five respondents

who are interviewed by using online chatting tool (google hang out). Most of the respondents are

member of the application development team but in different business field. Most of them work as

system analyst; in addition, one of them has the highest position as head of application team. Their

experiences range between 4 years to 10 years. The summary of respondent’s profile is shown in

table 25.

Table 25 Local Organization Respondent's Profile

Organization Role/Position Years’ Experience Bank B 1. System Analyst

2. Senior System Analyst 3. Senior System Analyst 4. Head of Application Team 5. System Analyst

1. 9 years 2. 10 years 3. 10 years 4. 8.5 years 5. 4 years

5.1.2. Key Facts of Organization

As we mention in section 4.6, Bank B is a central bank. As a central bank, its main’s duty is to

maintain the monetary stability in a country. Therefore, information system plays important role in

order to support its duty. The role to manage the information system is helmed by department of

information system management. In addition, one of its tasks is to develop a system application,

where the requirements are triggered from business user’s department.

The flow of requirements processes from user’s department to IS department is through couple of

requirements engineering phases. Before the requirements phases begin, a forum is held to discuss

next year working programs application. In this forum, all users are gathering and submitting their

project’s proposal in incoming year. If all proposals are approved by board of director, then it will be

working projects for next year. First, the IS department receive user’s specification documents from

user’s departments. Next, the IS department will further gather (elicitation phase), analyze and

modelling the requirements, negotiate and validate together with the users, which is finally signed

into the final document requirements specification.

32

5.1.3. Software Development Methodology

Bank B follows waterfall as its software development methodology. The methodology has been used

in many years, the reasons because it simple and contains milestones that each of software

development phase can be monitored and to report of its status. In regard of outsource strategy,

the monitoring project is easier to manage by using waterfall methodology.

5.2. Interview Results Two main topics discussed in the interviews. The first one is RE challenges/problems and solutions.

The second one is RE practices. In addition, we asked about how to improve RE practices.

5.2.1. RE Problems and Solutions in Local Project

We have some findings about RE problems. The most occurring problem that respondents had

experience with is requirements understanding. The requirements understanding means either the

source of problems is coming from users such as unclear/incomplete requirements, such as users

cannot explain or translate the requirements into technical terms, or the source of problems is

coming from developers which has some trouble to understand business problems into technical

terms because of lack of business process understanding. In this case, the solutions are to create

many intensive discussions through interviews, meetings, and workshops in order to gather

requirements more clearly. In addition, developers also create some prototype of application so that

users can know exactly what they need in the system. The second most occurring problem is

requirements that keep changing in the middle of the coding phase. In this case, the solution is to

make agreement with users which scope are being done now and then, thus developers are making

phases in the project according to such requirements. The third problem is about developer’s

competency, which is lack knowledge about business process understanding in the organization.

Therefore, the solution is to make training and make “pair program” where developers are being

loan in user department in some period. This has a goal to study business process in that

department and to create relationship stronger to the users. The summary of these findings can be

found in table 26.

Table 26 RE Problems and Solutions in Local Organization

No RE Problems RE Solutions

1 Requirements are not clear either cause by users (how to translate business into technical) or by developers (how to understand business process problem into technical)

Intensive discussion and workshop, prototype

2 Requirements keep changing To limit development scope by period of time

3 Personnel Competence Training, making “a pair” program

33

5.2.2. RE Practices in Local Project

We devise 18 questions around RE practices in RE phases: elicitation, analysis & modelling,

negotiation, requirements document, validation, and requirements management. The results are

80% of the practices (14 of 18 practices) are used by the respondents in daily RE activities. In

addition, several tools are used in the requirements activities such as MS Word to create

requirements document’s template, MS Visio to create RE modeling, MS PowerPoint to create

prototypes and so on. However, there are not much online tools are mentioned and intensively

used. This is because the requirements activities are co-located so communication done by face-to-

face or directly person-to-person. The summary of the results of RE practices interviews can be

found in table below.

Table 27 RE Practices in Local Organization

No. RE Phase RE Practices Response 1

Requirements documents Define a standard document structure Yes

2 Use guidelines how to write requirements / explain how to use the document

Yes

3 Describing requirements Define standard templates for describing requirements

Yes

4 System modelling Model the system’s environment/architecture Yes 5

Requirements elicitation Use business concerns to drive requirements elicitation

Yes

6 Prototype poorly understood requirements No 7 Reuse requirements Yes 8

Requirements analysis and negotiation

Use checklists for requirements analysis

Yes

9 Prioritize requirements Yes 10 Use interaction matrices to find conflicts and

overlaps No

11 Requirements validation

Checking if requirements document meets organization’s standard

Yes

12 Define validation checklists Yes 13 Organize formal requirements inspections Yes 14

Requirements management

Define policies for requirements management

No

15 Define traceability policies No 16 Use a database to manage requirements No 17 Define change management policies Yes 18 Identify volatile requirements Yes

5.2.3. Key Findings and Observation

There are several key findings from interview results:

A. Managing good relationship between users and developers

Key of successful RE practices is to manage a good relationship between users and developers.

What we learn from the interviews results, top local RE problem (see table 26) is happening

because of lack of communication or miscommunication between users (or customers) and the

developers. The problem is the requirements are not clear enough so that difficult by the

34

developer’s team to continue develop the software. Therefore, to overcome these problems the

solution can be achieved through an intensive discussion between users and developers. It

means that communication is an important factor in RE practices. Local RE practices have a lot

advantages compare global RE practices, in term of rich communication, co-located

coordination, and real time monitoring.

We examine this finding further in literature. Coughlan et al. [47] studied that communication

issues in requirements elicitation are critical into next step of RE phases. Further, Coughlan et al

has stated, “relationships can be constructed that in turn provided strong foundations for the

requirements to emerge as part of highly interactive and involved RE process”[47]. Therefore,

stakeholder participation in RE especially requirements elicitation is essential to build

relationship between users and the development team. The difference between the paper and

the thesis work is the paper focuses on content analysis of stakeholders experience in

requirement elicitation, whereas this thesis focuses on the practices on RE in general. The other

difference is that the paper’s source data come from general organization, as opposed in this

thesis where we interviews Bank’s organization.

Glinz et al. [6] studied stakeholder’s roles in RE processes. Glinz et al stated that identifying the

appropriate stakeholders in RE where the RE specification is built is very important. Therefore

maintaining good relationship with the right person in the RE phase is critical, so we should be

able prioritizing the stakeholders in particular who is in charge and has the main impact in

developing requirements specification. The difference between the paper and this thesis is the

paper explains roles of stakeholders in RE in general, as opposed we focus on RE practices in

organization especially banking industry.

Saiedian et al. [48] made an extensive study explaining the relationship between users and the

developers. They said that to manage a successful RE practices (in particular RE elicitation) the

developers should understand their users by formulating customer-centered strategies and

communication techniques that encourage customer participation and shared consensus in final

RE specification. Moreover, the authors suggested taking more time to learn the users and their

environment yields many benefits. In addition to working together with users by understand

their need, it also create a better working relationship. Furthermore, by establishing a good

relationship, one breaks down “us” vs “them” mentality that exists in an organization, which in

turn will increase the quality of the outcome of the RE processes [48]. Our finding in the thesis

confirms these arguments and it is exactly what expected to be happened in local RE practices.

B. Managing knowledge awareness of business process of the organization by developers

It is important that developers have knowledge at least a little to the business process of the

organization. Because it will be essential when in the middle of the project, if something in the

requirements change and the developers team has to make sure it would not ruin the

developing process of the application. In that sense, the training of the IT persons is a way to

increase the knowledge, and in turn, it leverages the speed of RE process. We examine this

finding in the literature further.

Al-Rawas et al. [49] studied that knowledge acquisition during RE has crucial role to understand

the requirements. Further, the authors stated, “individual members do not have all knowledge

for the project must acquire additional information before accomplishing productive work”[49].

35

It has been well known in RE that the different knowledge between end users and the

developers create a gap in the requirements understanding. Furthermore, it creates “the

notations war”, where the software engineer and analyst is talking about system in terms of it

procedures and data structures, whereas end users prefer discussing system in general

behavior, functionality and applications. In other word, users prefer to discuss the system in

their understanding in business process. This create knowledge gap, that software practitioners

must learn business process further in order to fulfill the knowledge gap. In addition, the analyst

who works closely with users must choose the notations that will best describe the system that

easily understand by both parties, which are users and the developer’s team [49]. The difference

between the paper and this thesis research is that the paper focuses on communication in RE,

while the thesis focuses on RE practices. The respondents are also different; the respondents of

this paper come from general organization, while our respondents come from banking industry.

Bjarnason et al. [50] also confirm that knowledge gap between users and the developers create

communication gaps between both parties in result the requirements understanding is not

reach. Further, the authors stated, “common views and mutual understanding are necessary for

communication to be productive” [50]. Knowledge awareness of business process should be

possessed by developer’s team in order to identifying the communication gaps between users

and developer’s team, which in turn increase quality the requirements understanding. The

difference between the paper and this thesis is that this paper focus on communication gaps in

the RE, whereas the thesis research focuses on RE practices in general. The respondents also

different, where the paper has more wider audience, where in this thesis we choose

respondents from banking industry.

Saiedian et al. [48] describes activities that the developers should take to learn user’s business

process. They describe traditional techniques such as on-site observations of on-going activities,

open-ended interviews, and examination manuals, job descriptions, and organizational

hierarchies. In addition, to get best knowledge in business process, it would be better to gain

from experienced users throughout these techniques. In other word, select key persons from

users as the counterparts are essential in learning user’s business process [48]. Our findings

confirm these arguments. Thus, not knowing at least knowledge the user’s business process,

affect the quality outcome of RE processes.

C. Managing knowledge awareness of IT/IS by users

Users are also urged to increase their knowledge to IT/IS. Because without the knowledge of

IT/IS of the users, the expectation will be always very high and it will create huge gaps between

users and the developer’s team. The IT/IS knowledge here are the basic IT/IS knowledge such as

RE processes, basic database, project management, and system knowledge. There are ways to

increase the IT/IS knowledge for the users, for example, training, workshop, sharing session and

others. Thus, the knowledge awareness of IT/IS by users will create mutual understanding with

their counterparts from IT departments in creating requirements specification.

In Coughland et al. [51], one of possible cause of RE failure is lack of appropriate knowledge or

shared understanding (interaction, expectation). Further, the authors stated, “to foster

understanding between users and designers, there needs to be an exchange of domain

knowledge” [51]. This mean, both parties, which are the users and the developers have to have

36

reciprocal relationship in term of knowledge and understanding. Although Coughland et al. did

not mention explicitly the required knowledge should be possessed by users, they provide basic

framework to both parties in order to close knowledge gaps. The framework consists of user

participation and selection, techniques, communication activities, and user-designer interaction.

In user participation and selection, the authors mentioned that the knowledge that users have

in business domain need to be expressed in both written and oral communication. Moreover,

the user’s knowledge consists of tacit and explicit knowledge, where the tacit knowledge by the

users is much harder to express in the requirements. Our thesis finding complementary this

paper in the way users also need to increase their knowledge of IT/IS. In other work, El Emam et

al. [13] did mention specific skills that users should possess. The specific skills are: 1) familiarized

and experienced with computerized systems, 2) good knowledge of the application domain, the

business process, and the needs of the user organization; 3) good knowledge of the system

development processes, and their deliverables; 4) good knowledge of information system

implementation and management and change management concepts; and 5) ability to deal with

people and have good communication skills [13]. The similarity of this paper and with the thesis

is they both investigate the RE practices in the organization. However, this paper focus on local

project organization, as opposed this thesis focus on GSE project.

37

6. Interview Results of Banks in the Netherlands

6.1. Introduction To investigate current practice of RE in global software engineering setting, we conducted a series of

interviews. Time of interviews is described in section 4.6. Here we are going to explain the

respondent’s overview, key facts of organization and software development methodology that is

used by these organizations. The interviews are done in the respondent’s office. The respondents

have approved the interview to be recorded for analysis purposes.

6.1.1. Respondents Overview

In this section, we are going to describe respondents’ overview as the source of analysis in this

thesis. We have a total seven respondents from four organizations. The role and position of the

respondents are varied, from product owner, requirements-engineering specialist, project manager,

business analyst to on site’s developer coordinator in GSE projects. The working experiences also

varied from four years’ experience to twenty years’ experience. This gives us different perspectives

or views toward RE practices in GSE setting. The complete respondents profile is explained in table

28 below.

Table 28 Respondents' Overview

Organization Role/Position Years’ Experience Bank I 1. Product Owner

2. RE Specialist 1. 20 years 2. 6 years

Bank K Project Manager 18 years Bank S 1. Onsite Offshore Dev. Coordinator

2. Onsite Offshore Dev. Coordinator 1. 10 years 2. 8 years

Bank R 1. Business Analyst 2. Business Analyst

1. 4 years 2. 9 years

6.1.2. Key Facts of Organization

Our organization’s respondents as mentioned in section 4.6; all four of them are commercial banks.

They all have structure organization where IT department is part of an enterprise organization. The

IT department serves its’ IT function in the organization including software development. One of

their software development activities is conducting requirements engineering.

All four banks are conducting global software engineering. The main reason is that GSE offers

relatively cheap cost of development. The other reasons are that other parts of the world have skill

and capacity to develop the intended software system. Thus, all four banks are currently running

GSE in their organization for various reasons and purposes. The GSE model organization of these

banks is uniform that is both nearshore and offshore outsourcing (more details in section 6.2.3).

6.1.3. Software Development Methodology

All the banks have been rooted to classic waterfall methodology. However, recent challenges and

changes strategy of organizations made these banks change their software methodology to more

38

flexible and faster software development compare to when they used waterfall methodology. They

all choose agile methodologies in particular Scrum, so they can speed up software development.

This software development methodology is worth to mention because it is affected on how

requirements engineering practices are being done and conducted. Summary of software

development methodologies is shown in table 29.

Table 29 Summary of Software Methodology

Bank I Bank K Bank S Bank R Agile methodology by Scrum

Hybrid between waterfall and agile methodology

Agile methodology by Scrum

Agile methodology by Scrum

6.2. Interview Results There are two main topics that was being discussed in the interviews. The first one is RE

challenges/problems and solutions in GSE Project. The second one is RE practices in GSE

organizations. In addition, we asked about how to improve RE practices in global projects.

6.2.1. RE Problems and Solutions in GSE Project

In this category, the interview results show that the main problem of RE in Global terms is the same

as in local terms: Translation of requirements from business perspective into IT perspective. The

second main problem is that the requirements are not clear. The third problem is varied from

distance matters to internal team matters. The summary of RE problems in GSE projects is depicted

in table 30.

Table 30 RE Problems

RE Problems Type

Bank I Bank K Bank S Bank R

General RE Problems

Translation of requirements

Translation of requirements from business requirements into technical requirements

Requirements are not clear

Different methodology use by internal and outsourced

Translation of legacy system

Requirements understanding

Users do not know what they needs;

Layers of requirements process

Requirements are not clear

There is no direct communication to users

Politics

Different perception of requirements between stakeholders

RE Problems Culture differences Dependencies Language Cultural

39

related to global setting

between different offshore teams in different countries

problems; culture differences

differences; Cultural aspects;

Team work Miscommunication issues between different parties

Distance problems: miscommunication

Miscommunication;

Coordination between different teams

On the other hand, the solutions of these problems are varied. There is no a single solution that fits

to all RE problems in GSE projects. The solutions proposed by interviewees are intended to solve a

particular problem, specific to their content. For instance, to reduce cultural differences, one

interviewee proposed using stand-up daily meetings from the scrum methodology to bind all team

members in one forum. The summary of RE solutions in GRE project is depicted in table 31.

Table 31 RE Solutions

RE Solutions #


What: Translation

requirements from business

user to technical

user; Requirements are not clear

How: Using transfer knowledge sessions

How: User involvement and commitment in entire project

How: Frequent communication by standup meeting in Sprint

How: To solve miscommunication to the users is to visualize the requirements

What: Different

perception between

stakeholders in defining

requirements

N/A How: User involvement and commitment in entire project

N/A N/A

What: Distance Problems

How: Using daily standup meetings; Using screen sharing to explain details of requirements document; Intensive communication and coordination by videoconferencing

How: Take a proper project management office (PMO) program in the organization

How: Use On site coordinator

N/A

What: Cultural

Problems

How: Encourage open communication so that there is no more

N/A How: Use On site coordinator

How: There should one representative that bridge cultural

40

hidden misunderstanding

differences; Further, make more communication in team

What: Language Problem

N/A N/A How: Provide a Dutch / or Dutch spoken of onsite coordinator

N/A

What: Office politic

N/A N/A N/A How: There should be single point of contact;

What: Three layers

of RE process

N/A N/A N/A How: To simplify process into one layer

What: Different

methodology used by

internal and outsourced

N/A N/A N/A How: Initial meeting to discuss the same perspective on methodology used both internal and outsourced

6.2.2. RE Practices in GSE Organizations

As RE practices in GSE project, our interviewees responded to all five-area process in RE practices,

which are RE elicitation, RE documentation, RE analysis & negotiation, RE validation and RE

management (see table 32).

In term of elicitation for describing requirements, our respondents are using these methods: user

stories, user board, story point, prototype, screen design, organizing session with users, by natural

language, standard flowchart, use case, workshop sessions, and discussions.

In term of managing requirements documentation, our respondents are using these methods: by

organization’s document template, own RE’s document template, by requirements traceability

matrix, by JIRA board.

In term of modeling requirements, our respondents are using these methods: by usual flowchart,

use case, prototyping, test case, data modelling, sequence diagram, data flow diagram, UML

diagram, and user stories.

In term of analyzing and negotiate requirements, our respondents are using these methods: by

discussion to get same perspective, using backlog analysis, by escalate to board of director, by

escalate problem to problem owner, and by making small impact analysis.

In term of validating requirements, our respondents are using these methods: user approval by

email, by verbal communication, by formal review by stakeholders and signing requirements

document.

41

In term of managing the whole requirements process, our respondents are using these methods: by

using activities as part of Scrum, using requirements processes managed by JIRA, and by standard

software development phase.

In general, the interviewees are using MS Office to create and administer RE document

requirements specification. Further, to share these documents they are using MS SharePoint in their

internal networking system. In addition, JIRA tool is used for distributed task in requirements

specification for further development, e.g. design phase and coding phase. The complete RE

practices in GSE project setting can be found in following table.

Table 32 List of RE Practices in GSE Project Organizations

RE Practices Bank I Bank K Bank S Bank R RE elicitation Describing and eliciting

requirements by method: - User board - Story point - Prototype - Powerpoint

Describing and eliciting requirements by method: organize session between stakeholders to plan capacity

Describing and eliciting requirements by method: - natural language -standard flowchart using Visio diagram

Describing and eliciting requirements by method: - use case - workshop sessions - user stories - discussion using natural language

RE documentation By template.

By RE document standardization.

By using requirements traceability matrix : - MS Excel to form requirements traceability matrix - JIRA to assign requirements to developers

By JIRA board and IDE site. By using MS Word and JIRA board.

By using template in RE documents By using template and user stories in RE documents

RE modeling Model the requirements by: - Usual flowchart

Model the requirements by: - Use case - Prototyping - Test case

Model the requirements by: - Data modelling - Sequence diagram - Data flow diagram - UML diagram

Model the requirements by: - User stories

RE analysis & negotiation

By human to human communication in order to get the same perspective. By using Backlog analysis in part of Scrum activities. And using this to discuss with client.

By escalate to board of director

By discussing benefits and impediments of requirements to users By discussing benefits and impediments of requirements to users

By discussing benefits and impediments of requirements to users, and escalate problems to product owner. By making small impact analysis and discussing benefits and impediments of requirements to users

RE validation User approval by email, screenshot and oral. User approval by screenshot, verbal communication, by email. Basically informal approval.

User approval by formal signing requirements document

As onsite coordinator, the team in India is receive the RE documents by the client. As onsite coordinator, the team in India is receive the RE documents by the client, final

By formal review of stakeholders and by signing the RE document.

42

requirements depend on release period of sprint runs in scrum.

RE management The requirements process is done to transfer to offshore team. It is part of scrum methodology.

The requirements process managed by JIRA.

Standard software development phase.

-

6.2.3. Analysis of Key Findings and Observations

We have several key findings and observations as a result from the interviews. These findings and

observations consist the following:

1. Three main findings

A. The use of a ‘liaison’ to represent offshore team to onsite team effective to solve

cultural differences, lack of ‘teamness’ and ‘language problem’

We learned that the use of a ‘liaison’ can be very useful and practical to conquer distance

problems. Bank S has covered this solution for 7 years and the results are satisfying. The

explanation of a liaison officer in Bank S was as follows: liaison officers are coming from offshore

teams (India) to onsite teams (the Netherlands, Bank S). Currently, there are two teams at Bank

S divided based on the features selection on the projects. The two teams are headed by a

person that is in charge of the project to connect with the persons in the onsite team. The two

persons admitted their role is to connect with the team in the Netherlands, and the results so

far are effective to reduce the gap in communication between two teams. In addition, the two

also analyze and discuss requirements specification document given by colleague in Bank I.

Furthermore, as Bank I’s officer admitted the presence of the offshore team solves many things

in global development in term of distance problems such as reducing cultural differences,

improve lack of ‘teamness’ and language problem. Bank I is be able to explain face-to-face to

liaison officers’ of offshore team regarding requirements details such as business processes,

modelling, information flow and others. Moreover, the liaison officer teams will transfer

knowledge the information they receive to their colleague in the offshore team. It is much

faster to reconcile what problems and potential risks that may arise during the global

collaboration. Moreover, interestingly this solution is what Bank I wished for in the interviews.

Bank K has an indirect approach of this solution by having multidisciplinary teams and offshore

teams in one project team so that all interest and problems are discussed and solved. Bank R

has a similar approach with Bank S, although Bank R has someone that long lived in the

Netherlands that has been recruited by the offshore team as their liaison officer.

Let us review what literature says about this finding, including their research method and the

difference(s) with our finding. Carmel et al. [25] report the main role ‘cultural liaison’ is to

facilitate the cultural, linguistic, and organizational flow of communication and to bridge

cultures, mediate conflicts, and resolve miscommunication. The definition of ‘cultural liaison’ in

this paper means someone within the organization is assigned to travel to multiple sites in the

same organization. In addition, the same authors mentioned ‘bridgehead’ that the main role is

43

“act to understand the customer’s requirements specifications and translate them to the

offshore programmers. Perhaps more importantly, the face-to-face interaction reduces

miscommunication between customer and vendor”. The ‘bridgehead’ means someone from the

external organization (for example the offshore team) is assigned into an onsite team to bridge

distance’s problems. Thus, the difference between ‘liaison’ and ‘bridgehead’ in this paper is that

the liaison is a person coming from the inside organization to travel many organization’s sites,

whereas bridgehead is a person coming from an external organization to travel into the

organization’s sites. Carmel et al. proposed various tactical solutions to GSE problems based on

data from different software organizations around the world, the literature on global software

development, and the authors’ fieldwork. The differences between this paper and thesis

research are: 1) the domain data is different; 2) we are using non-technological firm a.k.a

banking industry; 3) focus of the research, we are focusing on RE activities in a global project.

Although most of the motivations are the same (for example, to reduce cost), there is one

motivation found in thesis research is unique which is to fulfill the need of the organization’s

own business process. For example, bank’s business compliance need to be adhered for all

branches in many places in the world and this is when RE in a global project is started. The

cultural liaison that been referred in the paper is an internal organization worker that has been

assigned into multiple sites to bridge the cultural differences, while in the thesis, the liaison here

means a representative from an offshore site to the onsite place to bridge requirements

translation, face-to-face communication, reduce language problems. Thus, what is meant with

the liaison in the thesis has close overlap with the definition of ‘bridgehead’ in the paper.

However, there is an additional advantage of the presence of the liaison (in the thesis), that is to

close gaps in culture differences between the two sites.

Also, Krishna et al. [52] mentioned that ‘bridgehead’ spends significant periods at the client

premises, exchange of staff on a long-term basis between cross-cultural partners, and staffing

and training issues. The papers suggest the solution based on five-year study on in-depth case

studies on outsources in North America, Western Europe, and Japan to software suppliers in

India. The solution in the paper is similar to what we found in this thesis. While the difference is,

the bridgehead’s person in the paper is someone who lives in the onsite country for a long time

before joining the company, while in this thesis we found that the person is coming directly

from the offshore team to the onsite place.

Ebert et al. [53] suggest to “rotate management across locations and cultures to create the

necessary awareness for cultural diversity and how to cope with it” and “set up mixed teams

from different countries to integrate individual cultural background toward a corporate and

project oriented spirit”. The paper suggestion is coming from a case study on a company

(Alcatel) that summarizes experiences and share best practices from projects of different types

and sizes that involve several locations on different continents and in many cultures. The

difference between this study and the thesis work is in terms of ‘rotate management’. In the

paper, rotate management means the person act as liaison are coming within internal

organization and assigned to multiple sites across the world, whereas in the thesis, the person

act as representative is coming from an external organization (offshore team) into the onsite

team to bridge distance’s problems.

44

To address the problem of inadequate communication, Damian et al. [54] suggest to use “a

human facilitator (or train a developer) and an integrated, richer communication media that

integrates data, video and audio channels, in the decision-making teleconferencing calls”.

Furthermore, to address the problem of cultural diversity, the authors suggest representatives

from field support centers worldwide, those who interact with actual users on a daily basis, visit

the development site at Sydney for mutual learning about the technology and specific customer

needs. Damian et al. report on a case study of seven months at the organization’s site in

Australia, between sites located in Australia, New Zealand and US. The difference between

work presented in the paper and this thesis is the solution suggested by the authors is based on

an expert opinion, while in this thesis the solution is based on findings in the interviews.

Hanisch et al. [28] reported in their paper that three system architects are relocated to the UK

site from New Zealand site to effectively working 20-hour days in order to coordinate the

information, requirements and design. Hanish et al. reporting is based on one case study

concerning a large software development project that was completed in just seven months

between users located in the UK and software developers from an international software house

based in New Zealand. The difference between this paper and thesis work is the duration of

personal working hours. While in the paper the working hours of the personnel is 20 hours to

manage time zone differences, however, the persons that were involved in a global project in

the bank in the Netherland, were be able to arrange time zone differences into specific time

allocation for meeting and exchange information so that working hours remained the same (8

hours). This long working hour’s period make personnel in the paper feel inconvenient and they

do not want to work in this same job in the future. However, we found that in the interviews,

the persons that work as representative offshore team are enjoying the work because of

appropriate working hours.

Brockmann et al. [33] suggested in their in literature review to send ‘ambassadors’ from one site

to another, or frequent rotation of team members between sites, these two methods could help

in team building and to increase cultural understanding. However, these solutions are not

suitable in their case study; therefore, they suggest the use of ‘proxies’. Proxies are defined as

‘bicoded’ individuals, able to operate equally at ease in two different cultures. A typical proxy is

someone born and raised in one culture, which has lived and studied for a number of years in a

different culture. A proxy who has internalized the values and associated behaviors of a second

culture can serve as an important bridge between two cultures. The report is based on a case

study in an ongoing joint Chinese-German software development project for a Chinese regional

bank. The paper focuses on investigating the cultural challenges involved in applying agile

requirements engineering methods in China. The difference between the paper and this thesis is

the suggested solution by the paper is the different type of ‘proxies’ person to ‘representative’

person found in thesis research.

A report from Holmstrom et al. [55] offer solution of “buddy system” and traveling system

between two sites members to “broaden their minds”. The paper is based on interviews at three

US based GSD companies operating in Ireland and all three sites coordinate with other remote

colleagues in, for example, India, Poland, China and Malaysia. The difference between this

45

paper and thesis work is the buddy system is a two-way visits between two different sites, in

contrast in thesis work there is only one-way visit by the offshore team to the onsite team.

B. The use of online collaborative tools such as videoconferencing, online document

repository (MS SharePoint, JIRA), chatting, email, telephone to solve communication

and coordination problem

We found that online tools are the necessary infrastructures that every bank in the Netherlands

that involved in the global project use in order to make the global project works well. This is

obligatory; to overcome distance (in particular over 50 meters) we need additional tool to

deliver our message to our counterparty in other end. Let examine what kind of tools are used

by these banks.

Bank I uses videoconferencing every day to enable standup meetings in their Scrum activities. To

deliver requirements specification, Bank I often use email and online repositories (MS

SharePoint, JIRA) while their counterpart in the offshore team can retrieve the document and

then later, confirm it via videoconferencing meetings, chatting and telephone. A similar

condition also happens on all other three banks. It is a common practice to use using online

collaborative tools to solve communication and coordination problem over distance in RE in the

global project.


difference(s) with our findings. Damian et al. [56] has stated that “a combination of lean and

rich media is needed for an effective process of requirements negotiations when stakeholders

are geographically dispersed”. This work is based on case study of six academic teams involved

in geographically distributed software projects with an emphasis on requirements engineering

activities. The difference between the paper and this thesis is in the scope of tools that has been

used in the research. The paper focuses on the use of video-conferencing as synchronous media

type and a tool called ‘Internet-Based Inspection System’ as asynchronous media type, whereas

we found more broader tools such as videoconferencing, chatting, telephone (synchronous

media) and email, online document repository (such as MS SharePoint, JIRA) as asynchronous

media have been used in the global project.

Sinha et al. [57] report to enable successful collaboration during requirements engineering in

distributed places, a set of architecture of tool must be constructed. The report is based on a

case study for a one-year period research in IBM, with practitioners on site in US and the

Netherlands and remote team members in India. The difference between the paper and this

thesis is the type of the tool. The authors in the paper developed a specific tool called EGRET to

support the requirements communication and management across the distributed team. In

addition, the authors study the infrastructure of the tool and its impact to the users over some

period. In contrast, we found in the organizations we interviewed that they use mixed media

tools to communicate over distance.

Steinmacher et al. [58] made a 3C model in distributed software development to show that set

of media is needed in order to support communication, coordination and cooperation (3C) in

dispersed of development sites. The 3C model defines collaboration as the union of

communication, coordination, and cooperation efforts. This paper is based on a systematic

46

literature review on awareness support within the GSD scenario. The difference between the

paper and this thesis is that the paper focus on modeling the tools over communication,

whereas we found more practical uses of the tools over GSD sites.

Menten et al. [59] shows that using collaborative media (a wiki system) and audio recordings

help requirements elicitation process in globally distributed software development settings. The

paper is based on literature review and it proposes a concept. The differences between the

paper and this thesis are: 1) the scope of the work, 2) it is also to the scope of tools that are

used in the global project. The scope investigation of the paper is focus only on requirements

elicitation; in contrast, we more focus on general RE practices in thesis. Furthermore, this paper

only focuses on a wiki system and audio recordings as the authors suggest it will help

requirements elicitation process in global projects. However, what we found is a more variety in

tools to collaborate between sites in RE activities in global settings. For example a variety of

tools: videoconferencing, online document repository, chatting, email and telephone are the

tools used in the global project.

Finally, Herbsleb [60] argue that project repository tools have an important role to “enrich

project memories” in global projects. This paper is based on literature review and expert

opinion. The difference between the paper and this thesis is the scope of the tool. The paper

only mention one tool (project repository), but we found various tools to use in global projects

such as videoconferencing, online document repository, chatting, email and telephone.

C. The use of a transparent process in RE helps to solve inadequate information and lack

of supervision in global projects

We found that the use of a transparent process in RE is effective to solve inadequate

information and lack of supervision in global projects. Bank R and Bank K argue that to make

things smooth in RE activities, a clear transparent process in RE processes must be developed

and taught to all stakeholders involved in the global project so that all parties gain a common

understanding despite of challenges in the global project. The transparent process in RE

processes means that there is a clear definition to someone involved in the global project

whether he/she is in the RE elicitation phase, RE analysis phase, RE validation phase to the final

requirements specification phase. In short, there is a need to standardize the process in RE so

that all persons involved have clear roles what to do and what to expect in the global project.

This is in many ways solve inadequate information and lack of supervision in the global project.


difference(s) with our finding. Ebert et al. [53] stated that “what is crucial in a global

development organization is that all development locations working in one product line use the

same processes, methodology, and terminology even when changes occur”. The paper

suggestion is coming from a case study on a company that summarizes experiences and share

best practices from projects of different types and sizes that involve several locations on

different continents and in many cultures. The difference between the paper and this thesis is

that the former suggests a general workflow in the organization, while in the thesis we suggest a

transparent process in the RE activities in a global project within an organization.

47

Bhat et al. [37] show that a holistic framework for RE best practices is needed to support RE

processes in global projects. In addition, shared process and shared goals between sites are

created to fill the gap knowledge between sites. In addition, the framework in this paper means

a structure to classifying RE practices that gives a quick assessment of available RE practices for

the practitioners in real-life work. This paper is based on the authors’ experiences in real-life

project and recommendations in literature. The difference between the paper and this thesis is

that this paper presents a complete framework of RE practices, while in thesis; we only focus on

the transparent process in RE as part of the (sub) framework. The paper suggest to create a

proper project structure clearly showing the value and dependency of each activity and artifact,

that in thesis interviews show this is what the respondents need in a global project.

Berenbach [61] report that clear role of organizational structure and processes help distributed

requirements engineering processes. This work is based on the authors experience in Siemens

organization, in particular on several projects that involve outsourcing to Siemens organizations

in India, China, and Eastern Europe. The difference between the paper and this thesis is that the

paper focuses on organization structure and roles in each personnel involved in RE of global

project, while in thesis our findings focus on transparent processes that define RE processes

executed in global projects.

Niazi et al. [39] created a global framework for requirements engineering in a global project to

improve processes in requirements engineering. Their global framework is made based on initial

findings at five GSD organizations. The global framework in the paper intends to provide a

standard of RE practices that can be used by practitioners in real-life. The framework is based on

best practices as standard use by industry. The difference between this paper and thesis work is

in the scope of the work. The paper is attempted to make a complete global framework on RE

practices, while in our thesis we focus only on small part of the framework that is the

transparency processes in RE.

Finally, Prikladnicki et al. [62] proposed a reference model in global software development to

help software engineers identify their role before starting the project. This paper is based on the

results found in a case study conducted in two software development units from multinational

organizations located in Brazil. The difference between the paper and this thesis is that the

paper focuses on a general model of global software development in an organization, while the

focus in this thesis is on a much smaller area regarding transparancy process over RE activities in

global projects.

2. Characteristics of GSE that have largest impact on RE activity

All of our respondents have admitted that distance is the characteristic of GSE that has the

largest impact on RE activity. Distance here means geographical distance, where location of the

office site and development site is separate by very long distance; so it is difficult to meet locally

and requires significant travel. In order to do RE activities, for example, to describe

requirements to the developer, respondents heavily depends on ICT technology, like onscreen

videoconference call, telephone, chatting, and email. Furthermore, distance make the

respondents have some difficulties in coordination and monitoring of how the software is being

developed.

48

The second characteristic of GSE that has the largest impact on RE activity is the cultural

differences. It is the fact that Dutch culture is in contrast with Indian culture, for example. As

refer to our theoretical research in chapter 2, Dutch people have different culture

characteristics compared to Indian people. Power distance in Dutch people is quite low

compared to India, while Indians are much more striving to collectivity rather than Dutch, which

is more individualistic. In addition, Indian people tend to avoid conflict compared to Dutch.

Therefore, as the consequences, there are differences in the way of communication and

interaction. Dutch people are more direct in communication (because of less power distance),

Indian people are more indirect (because of much power distance) and this (sometime) causes

misunderstandings and conflicts in communication. In addition, Indian people tend to do

anything what is written in RE specification without a complete understanding of the business

requirements behind it (because to avoid conflicts). As result, most software that has been

developed must be rebuilt again because it is not what business people expect.

Lastly, surprisingly, time zone differences are not a big matter for most of our respondents,

since they can manage by making appointment when everyone is available in both sides. More

importantly, both sites can manage the same working hours, which are eight hours per day,

which in return is much appreciated by both teams.

3. Tools to solve problems in RE in GSE project setting

Tools are playing an important role in GSE project organizations. Referring to our theoretical

research in chapter 2, we found the importance of online collaboration tools. The absence of

collocated way of work is replaced by the advance of screen information technology. Meetings,

workshops, discussion between business department and development sites is conducted by

video conference calls, either prepared by the internal organization or by a third party. While

usual communication is, also done by either asynchronous communication tools such as email or

synchronous communication tool such as chatting/messaging or telephone calls.

Apart from communication, another online collaboration tools can be used for managing work

and monitoring. Tools for example MS SharePoint is used for sharing RE documents

specification, and it is useful for both IT department in the banks and the offshore development

site to exchange documents in which is used to describe requirements for further development.

In addition, software like JIRA is used for managing and distributing work based on requirements

work division to which development team must develop. Hence, in this point, online

collaboration tools play an important role in GSE project organization.

4. Flow of RE process in GSE project setting

Regarding RE processes in GSE project setting, there is no particular difference in the way local

project is working, except in which type global outsource company to this bank is given to

develop the project (see table 33). Projects are started from business needs, where business

departments ask IT departments in the bank by sending initial requirements documents to

develop applications. Moreover, this is where RE processes are executed. IT department is

represented by business analyst in conducting RE elicitation and RE modeling with business

users. After it is done, it will be refined by RE analysis and negotiation. Finally, RE validation is

49

required by IT department to business department to finalize the RE specification. The whole RE

process is managed by own bank rules and procedures, which can be different in details but it

has the same principal general flow of RE processes.

For example, bank I is more flexible in validating final specifications that it can be done by email,

verbal communication and other non-formal validation. While bank K and R, are very strict in

their procedures that final specifications must be written and signed by the product owner in

corresponding business department counterparts. Bank S is in the middle type, it can be formal

or non-formal.

After requirements specification documents are final, they will be transferred and explained to

the offshore or nearshore development site(s). The summary of RE flows is described in the

following table.

Table 33 Summary of RE Flow in GSE Project Organization


Business -> IT Department -> Offshore Development

Business -> IT Department -> PMO department -> Nearshore Development

Business -> IT Department -> Offshore Development

Business -> IT Department -> Nearshore/Offshore Development

The differences of each bank are explained as follows. Bank I and Bank S have the same RE flow

in GSE projects. While bank R is conducting both offshore and nearshore development. Bank K

has slight differences between the IT department to nearshore development, it has a PMO

department who manage the project from start to finish. We refer offshore and onshore

definitions to chapter 2.

5. GSE organization model

We have riveting findings related GSE organization model. The general model of GSE

organization that we analyzed from the interviews is depicted in the following figure.

Office Site Development Site

RE Documents Artifacts

Communication Screen

Sharing Get

Transfering

Feedback

Figure 4 General Model of GSE Organization

We observe there are two kind of GSE model organization based on our interviews. They are:

1. Two completely separate team between bank’s office site and team’s offshore/nearshore

development team site. There is no additional cost to maintain an onsite coordinator. This

model is chosen by bank I and bank K.

50

2. In bank’s office site, there is a staff acts as onsite coordinator from team’s

offshore/nearshore development team a representative. This is to manage communication

and coordination between two sites. There is additional cost to maintain an onsite

coordinator. This model is chosen by bank S and Bank R.

The second model obviously has advantage to reduce the gap in distance arises in GSE projects.

The communication, coordination and cultural problems can be easier to address although the

problem remains. The only drawback in this model is the additional cost to maintain the

coordinator and onsite personnel. This finding is very interesting, and need to be explored

further in future research to investigate its implications.

6. Differences between RE practices done in locally and globally

In term of differences between RE practices done in locally and globally, our interviewees have

different opinions. Bank I is conducting of RE practices in the same manner as if it is in local. In

contrast, bank K and bank R have the same response that RE practices in global project are more

difficult and complex than RE practices in local project. This is being said because, in local

project, the communication can done face-to-face or collocated that RE practices in elicitation,

describing, analyzing, negotiation and validation are more easier, rather than having people

separated by distance. Bank S has both sides opinion. The similar thing between RE local

compare to global is the way of RE practices in local has the same practices in global. However,

the different of RE local compare to global is the presence of the distance which communication

between two sites is more difficult. One thing for sure, all banks adapt situation in global

projects in order to have everything is in order.

We do make comparison based on our interviews with personnel that doing RE practices in

locally (in chapter 5) and globally, as depicted in the following table.

Table 34 Comparison between RE Practices in Local and Global Organization

RE Practices Area RE Practices in Local Organization RE Practices in Global Organization

RE Elicitation Natural language, use case and other modeling language

Natural language, user stories, stand-up meetings trough screens and other modeling language

RE Analysis & Negotiation

Through discussions and escalate problems

Through discussions, conduct small benefit analysis and escalate problems

RE Documentation

Using own template by organization, using tools to distribute RE documents artifacts

Using own template by organization, but depends on situation (flexible), using tools to distribute RE documents artifacts

RE Validation Formal signing in RE specification document

Non-formal and formal signing RE document, sometimes approval by email is enough

RE Management Organization own procedure RE’s management

Organization own procedure RE’s management

Thus, based on RE local practices and RE global practices findings, there are not many

differences between RE practices in local and global project. The only difference in global

project is the presence of distance problem that cause communication, coordination and control

51

are much more difficult. However, the RE practices of both local and global project, in most of

the cases are remains the same. One thing for sure, global project is heavily depends on tools to

bridge over the distance problems.

7. The importance of RE in GSE project setting

Bank I said that RE is always important and spent 30% time in RE phase compare other phase in

software development process. Bank K said RE is important because there is no way to deliver a

project if people do not know what they want. Bank K spent 30% time in RE phase. Bank S said

that RE is very important because if there is some flaw in the requirements, entire project will fail

and if the users give the wrong requirements, ultimately development team will give wrong

software product in return. Bank S spent in average 25% in RE phase. Bank R said that RE is very

important because if there is really one small thing does not work, as it should than there is a lot

problem to roll back for every system. Further, without proper requirements we cannot do any

development. In addition, Bank R spent in average 60% in RE phase, because the respondents

are business analyst who is responsible for making RE specification with users.

8. Improvement RE process in GSE project setting

In term of improvement RE processes and practices in GSE project setting, we found interesting

findings. Bank I says that to improve RE process in GSE project setting as this statement

“working together on one place with the whole team, so now we talking about feature team, so

it is multidisciplinary team. So I mean I take out 'distance' so people can work together.” In

addition, Bank I wants people from offshore to be “sit next to them. Work collocated.” So, Bank

I would like to have the team from offshore to be available next to those to reduce

communication gap that is occurred because of distance in GSE project setting. Surprisingly, we

found that Bank S has practice what Bank I is required. Thus, in order to minimize

communication gap and increase coordination effectiveness, Bank I’s management arrange GSE

project management that require representative or coordinator on site from offshore developer

team. Thus, Bank I already done this for seven years and the result of project is satisfying. The

problems found in GSE project are reduced and most importantly, communication gap because

of distance is reduced because someone from the offshore teams helps to bridge any problems

that may occur during software development process including RE phase. However, Bank R has

other opinion regarding RE process in GSE project setting improvement. Bank R says about

improving internal organization structures to make things in RE process faster and to have

dedicated team in each project.

9. Other finding: motivation and goal in doing RE practices in GSE projects

In this section, we examine motivation and goal in the interviews compared to our theoretical

research in chapter 2. We found variety findings concerning motivation and goal in RE practices

in GSE projects. Bank I says that cost is the main goal in doing RE practice. Lower cost in

conducting RE practices in GSE is the main motivation of Bank I. Bank K says that the goal of RE

practices in GSE projects is to make sure the clear requirements process in the global setting.

Bank K stress out about transparency in PMO as the basis monitoring in GSE project. Bank S says

52

that the goal of RE practices in GSE projects is to explain and understand clearly from business

users to offshore development team. Thus, the motivation is to make transparency process in

RE so that both sites understand the whole RE processes although it separated by distance.

Furthermore, Bank R has the same motivation with Bank K and Bank S. Bank R says that the goal

of RE practices in GSE projects is to create as generic as possible in the requirements document

so that the project execution can have flexibility factors. In addition, to make sure the

requirements cover for all parties that they cover what it needed. Bank R is focusing on

transparency and flexibility process in RE activity and requirements specification completeness

by all party involved.

Let we examine these findings and compare what we found in this research and in the literature.

Referring to chapter 2, according to Carmel [26], the main motivation for organization to do a

GSE project are catalyst factors such cost reduction, access to global talent pool. Thus, in regards

of catalyst factors, our finding confirm and complementary what literature suggested.

Furthermore, definition of vision factors is a motivation in doing GSE lead by how an

organization envision in the future. One of these factors is definition of virtual teams, which its

characteristics include transparent process and knowledge authority [26]. Moreover, Bhat et al.

[37] proposed best practices GSE framework (see table 9), one of the suggestions is to have

shared process among sites in the GSE project. The authors explain that in people dimension,

team members should be trained to use the right processes, tools, and technologies. In addition,

in process dimension, the authors suggest variety methodology such as Quality Function

Deployment, a proper project structure, use CMM, maintain and share artifacts repository, and

share requirements specification templates [37]. As we can see here, our findings in regards of

transparency process complementary and support what literature said. In addition, one little

different apart from [37], the use of scrum methodology in our respondents as part of shared RE

processes among sites of GSE team. Our banks respondents as interviews suggested, besides its

pitfalls, said they have successfully adopt Scrum methodologies in their RE processes, which is

made RE processes more transparent.

53

7. Public Survey Results

7.1. Introduction We conducted a public survey on during a period of four weeks from the second week of May 2015

to the third week of June 2015. As we mentioned in chapter 4, we choose social media (Linkedln) as

our source for contacting respondents for the survey. In addition, we also used professional contacts

from the researchers to add more respondents. We received data from 121 respondents. This

chapter presents the analysis and observations of the results of the survey.

7.2. Public Survey Results

7.2.1. Information Background

In this section, we present our audience’s profile (the complete summary of our profile is shown in

table 35). Most of our respondent’s roles are middle manager or higher (40%), while others hold

various positions. An average year of experience of our respondents is 17 years experiences working

in software development, where the minimum is one-year experience and the maximum is fifty

years of experiences. Out of in total 121 respondents, 89% have experience in a GSE project.

Approximately 31% of them are working in the software domain, while 45.8% of them are working

in an organization that has more than 4000 employees. In particular, the respondents that come

from a banking background (11.8%) the majority of them are working in commercial banks (57.7%).

The complete information of public survey audience’s profiles can be found in appendix C.

Table 35 Public Survey Audience's Profile

Profile Information

Number of respondents 121 Role or position Middle manager or higher (40%) Experience Average 17 years Has experience in a GSE project 89% (108 respondents) Domain Business 31.1% in software field, 11.8% in banking, 7.6% in

telecommunication, the rest in other field Banking domain 57.7% in commercial bank Organization’s size 45.8% > 4000 employees Type of project 50 % Custom software development Project trigger 53% Customer requests Software methodology 33.3% Agile methodology Duration of the project 43.9% more than 24 months Project’s stakeholder 64.9% Customer Project’s users 73% Customer

We are moving on to the global project category. The majority types of the projects are custom

software development projects (50%), while customers request are the most reason to start the

project (53%). 33.3% uses Agile methodologies as their software methodology and 43.9% have a

54

project’ duration of more than 24 months. The majority stakeholders and project’ users are

customers, 64.9% (major stakeholder) and 73% respectively (major user).

There are interesting findings on motivation behind the global project (see table 36). As we recall to

theoretical research in chapter 2, there are four categories: catalyst, sustain, sizing, and vision

factors. Majority respondents are answering catalyst factors as the main motivation in their global

projects (83.17%). Catalyst factors are cost reduction and finding best people in global environment.

In addition, alongside catalyst factors, sustain factors are the main reason of doing globally project

(16.83%), such as development rigor, multiple teams in different places. Furthermore, there are the

sustain factors such as growing organization size and project size (7.92%). Finally, the vision factors

are mentioned by the least number of respondents (1.98%), such as: organization is having global

structure and change visions. Respondents had the possibility to give multiple answers in this

question regarding their motivations for executing their project globally (e.g. catalyst and size

factors, for example).

Table 36 Motivations in the global project

Motivation Factors Results

Catalyst 83.17% Sustain 16.83%

Size 7.92% Vision 1.98%

To investigate the differences between collocated RE and global RE (see table 37), we used

categories from chapter 2 concerning impacts in requirement understanding, which are cultural

differences (CD), loss of communication richness (LCR), loss of teamness (LT), time zone differences

(TZD), coordination breakdown (CB), geographically dispersed (GD), and in addition, knowledge

differences (KD). We also captured other differences. Respondents can answer multiple differences.

Out of 102 respondents who answer this question, 94 of them (92%) confirm there are differences

in conducting RE in global projects or local projects. The majority of the respondents state that LCR

is the main impact factor in doing RE in the global project (56.38%). CD is the next major factor

(35.11%), follow by CB with 18.09%, KD is 15.96%., and TZD is 13.83%. Interestingly, GD gets 6.38%

and LT is 3.19%. Lastly, almost 14.89% of them mention other impact factors in globally RE practices,

as shown in table 37.

Table 37 Differences of RE practices in the global project and local project

Impact Factors Results of the Survey Information

LCR 56.38% Loss of intensive communication CD 35.11% Cultural differences CB 18.09% Coordination breakdown KD 15.96% Knowledge differences in each site TZD 13.83% Time zone differences GD 6.38% Geographically dispersed, distance in general LT 3.19% Loss of ‘teamness’, team ‘feeling’

55

Others 14.89% S/W Methodology used, scarce resources, clear requirements, lower cost, organization platform, size of stakeholders, global contract

7.2.2. RE Problems and Solutions

On the top three RE problems in global projects, our respondents’ answers vary, as depicted in table

38. In most RE problems that happen in a global project (mark yellow in the table), 14.8%

respondents selected point “PS19. Loss of communication richness”. Then “PS1. Lack of customer

and user communication” (9.3%) and “PS2.Lack of developer communication” (7.4) are problems

selected by the respondents as most RE problems in global projects. However, 9.3% respondents

mentioned other problems as well.

Secondly, most RE problems that occur in a global project (mark green in the table), each of these

problems got 9.0% which are: “PS13.Requirements keep changing”,” “PS8.Complexity of

application”. Then, “PS12.Incomplete/Inconsistent requirements” got 8%. Finally, on third most RE

problems in the global project, we got results which are: ”PS8.Complexity of application” (9.3%),

“PS15.Ambiguous requirements” (7%), and “PS4. Inappropriate skills” (7%).

Table 38 Top three RE problems in a global project

List of RE problems in a global project Most Problem Second Most

Problem Third Most

Problem

PS1. Lack of customer and user communication 10 9.3% 6 6.0% 3 3.5%

PS2. Lack of developer communication 8 7.4% 5 5.0% 3 3.5%

PS3. Lack of training 2 1.9% 2 2.0% 0 0.0%

PS4. Inappropriate skills 4 3.7% 3 3.0% 6 7.0%

PS5. Lack of defined responsibility 3 2.8% 4 4.0% 4 4.7%

PS6. Unstable workforce (low staff retention) 3 2.8% 4 4.0% 4 4.7%

PS7. Poor time and resource allocations 1 0.9% 2 2.0% 0 0.0%

PS8. Complexity of application 2 1.9% 9 9.0% 8 9.3%

PS9. Undefined RE process 1 0.9% 1 1.0% 1 1.2%

PS10. Requirements provided (stated) by customers are not the actual requirements

5 4.6% 2 2.0% 1 1.2%

PS11. Poor user understanding 0 0.0% 3 3.0% 3 3.5%

PS12. Incomplete/Inconsistent requirements 8 7.4% 8 8.0% 4 4.7%

PS13. Requirements keep changing 4 3.7% 9 9.0% 5 5.8%

PS14. Inadequate requirements traceability 0 0.0% 2 2.0% 0 0.0%

56

PS15. Ambiguous requirements 1 0.9% 6 6.0% 6 7.0%

PS16. Misplaced requirements in a requirements document

0 0.0% 0 0.0% 0 0.0%

PS17. Cultural differences 3 2.8% 3 3.0% 4 4.7%

PS18. Geographic dispersion 2 1.9% 0 0.0% 2 2.3%

PS19. Loss of communication richness 16 14.8% 4 4.0% 3 3.5%

PS20. Coordination breakdown 2 1.9% 1 1.0% 1 1.2%

PS21. Loss of ‘teamness’ 4 3.7% 3 3.0% 2 2.3%

PS22. Timezone differences 2 1.9% 2 2.0% 1 1.2%

PS23. Developer's lack of business understanding 8 7.4% 5 5.0% 7 8.1%

PS24. Understanding people's competences in distance

0 0.0% 2 2.0% 1 1.2%

PS25. Translation business requirements into technical requirements

4 3.7% 1 1.0% 4 4.7%

PS26. Different perception of requirements between stakeholders and team

2 1.9% 3 3.0% 3 3.5%

PS27. Different/Various suppliers/developers team involved in the Project

0 0.0% 1 1.0% 0 0.0%

PS28. Requirements processes are not transparent 0 0.0% 1 1.0% 1 1.2%

PS29. Different software methodology used between internal and outsource partners

2 1.9% 0 0.0% 0 0.0%

PS30. A multitude of international stakeholders 1 0.9% 2 2.0% 1 1.2%

PS31. Other (please fill below) 10 9.3% 6 6.0% 8 9.3%

Number of respondents 108

100

86

We also asked what kind of solutions is proposed by the respondents for their top most RE problem

in a global project. In table 39, the most left column shows compilation of RE solutions that we

gathered from literature (see chapter 2). Uppermost row of the table are the RE problems that we

gained from the survey.

57

Table 39 Solutions of the most important problem in RE practice in a global project

As we can see in the table, visiting (face-to-face) whether in the kick off meeting or regular visits

between sites is chosen by the majority of the respondents as their solution to most of the problems

in RE (58.3%) in GSE settings. Surprisingly, the same solution is also chosen by the audience, in order

to solve the second and third most problems in RE in 50.5% and 39.5% respectively. It appears that

though, GSE is all about working on a distance, the best practices of the respondents is still to meet

in person.

As confirmation to our main findings in the interviews (see chapter 6), we gained responses as

shown in table 40. The use of 'a liaison' officer is to represent the offshore teams in the onsite team

effective to solve RE problems in a global project, 67.4% respondents confirm positively. Then, the

use of online collaborative tools such as videoconferencing, document repository, chatting, email,

telephone effective is to solve RE problems in a global project, 93.8% respondents confirm

positively. Furthermore, the use of a transparent process in RE effective is to solve RE problems in a

global project, 72.3% respondents also confirm positively. This mean, our findings in the interviews

are confirmed by this public survey.

RE Solutions 1 2 3 4 5 1 2 3 4 5 1 2 3 4 5

S1. Documents management 15.7% 24.5% 37.3% 18.6% 3.9% 21.5% 16.1% 29.0% 28.0% 5.4% 28.8% 25.0% 22.5% 18.8% 5.0%

S2. Competence management 17.0% 18.0% 29.0% 26.0% 10.0% 17.6% 20.9% 25.3% 24.2% 12.1% 16.5% 22.8% 22.8% 24.1% 13.9%

S3. Video/Audio conferencing 3.0% 11.9% 24.8% 34.7% 25.7% 8.6% 17.2% 23.7% 26.9% 23.7% 6.3% 20.0% 12.5% 38.8% 22.5%

S4. Email/Chat 1.0% 16.0% 34.0% 34.0% 15.0% 13.2% 18.7% 26.4% 29.7% 12.1% 16.0% 19.8% 25.9% 25.9% 12.3%

S5. Forums 22.9% 27.1% 30.2% 13.5% 6.3% 30.0% 26.7% 16.7% 18.9% 7.8% 30.8% 26.9% 19.2% 14.1% 9.0%

S6. Visualization of requirements 2.1% 18.6% 18.6% 39.2% 21.6% 13.0% 13.0% 26.1% 31.5% 16.3% 20.3% 12.7% 13.9% 27.8% 25.3%

S7. Telephone 10.1% 20.2% 34.3% 26.3% 9.1% 14.6% 19.1% 31.5% 24.7% 10.1% 21.3% 25.0% 25.0% 22.5% 6.3%

S8. Job rotation 24.5% 28.6% 18.4% 21.4% 7.1% 26.7% 30.0% 21.1% 12.2% 10.0% 41.0% 20.5% 19.2% 9.0% 10.3%

S9. Motivation and trust building 4.0% 14.1% 19.2% 31.3% 31.3% 13.8% 13.8% 18.1% 33.0% 21.3% 22.2% 16.0% 13.6% 27.2% 21.0%

S10. Visiting (Face to Face) / Kick off

meetings / Reguler visits

2.9% 5.8% 5.8% 27.2% 58.3% 5.4% 9.7% 10.8% 23.7% 50.5% 9.9% 4.9% 13.6% 32.1% 39.5%

S11. Terminologies 6.1% 10.2% 26.5% 39.8% 17.3% 11.0% 17.6% 23.1% 31.9% 16.5% 21.5% 13.9% 16.5% 29.1% 19.0%

S12. Standards 8.2% 19.6% 29.9% 33.0% 9.3% 14.4% 15.6% 30.0% 23.3% 16.7% 19.2% 19.2% 24.4% 20.5% 16.7%

S13. Rewards (prizes and salary

increments)

37.8% 25.5% 25.5% 7.1% 4.1% 44.9% 36.0% 6.7% 6.7% 5.6% 44.9% 29.5% 12.8% 7.7% 5.1%

S14. Trainings (culture, language

etc.)

4.0% 23.2% 31.3% 28.3% 13.1% 11.8% 28.0% 18.3% 24.7% 17.2% 15.0% 17.5% 27.5% 18.8% 21.3%

S15. Liaisons (onsite

representative/coordinator from

offshore development team)

5.2% 9.3% 19.6% 39.2% 26.8% 6.7% 13.3% 15.6% 41.1% 23.3% 13.9% 17.7% 16.5% 31.6% 20.3%

S16. Requirements traceability

matrix

22.4% 23.5% 22.4% 22.4% 9.2% 29.2% 18.0% 23.6% 19.1% 10.1% 33.3% 17.9% 23.1% 14.1% 11.5%

S17. Requirements change

management process

16.2% 17.2% 26.3% 26.3% 14.1% 21.1% 18.9% 25.6% 23.3% 11.1% 28.2% 19.2% 19.2% 20.5% 12.8%

S18. Proper Project Management

Office (PMO) to make RE processes

more transparent

31.3% 21.9% 25.0% 15.6% 6.3% 26.7% 30.0% 24.4% 13.3% 5.6% 30.8% 35.9% 16.7% 9.0% 7.7%

S19. Multidisciplinary requirements

team

9.2% 18.4% 24.5% 35.7% 12.2% 19.4% 11.8% 22.6% 30.1% 16.1% 17.3% 14.8% 25.9% 34.6% 7.4%

S20. Suppliers/Offshore/Outsource

team alignment

8.4% 18.9% 21.1% 31.6% 20.0% 16.7% 11.1% 25.6% 25.6% 21.1% 17.9% 20.5% 24.4% 17.9% 19.2%

S21. Test driven requirements

specification

14.3% 12.2% 27.6% 29.6% 16.3% 16.5% 20.9% 25.3% 25.3% 12.1% 21.5% 20.3% 25.3% 19.0% 13.9%

S22. Very detail requirements

specification

29.9% 25.8% 20.6% 17.5% 6.2% 31.9% 28.6% 18.7% 12.1% 8.8% 31.6% 26.6% 26.6% 8.9% 6.3%

S23. User stories for requirements

specification

5.3% 14.7% 23.2% 34.7% 22.1% 17.4% 13.0% 26.1% 27.2% 16.3% 17.9% 11.5% 29.5% 30.8% 10.3%

Others 26.3% 5.3% 28.9% 10.5% 28.9% 34.8% 17.4% 26.1% 0.0% 21.7% 40.0% 24.0% 16.0% 4.0% 16.0%

Loss of communication richness Requirements keep changing Complexity of application

58

Table 40 Interviews findings confirmation

Findings Results of the Survey

The use of liaison 67.4% is supporting

The use of online collaboration tool 93.8% is supporting

The use of process of transparency in RE 72.3% is supporting

In addition, we asked our audience to what effective solutions to RE problems they have found in

their global projects. Most of them clearly show that realization of face-to-face communication

during the project is important. Although distance is the main impact in RE practice in global project,

there are other ways to perform face-to-face communication. For example: visiting activities, kick-

off-meeting, regular visits, performing liaison officer or other form communication, in order to

construct a way to communication and coordination over distance and be able to complete the

global project successfully.

7.2.3. Closure

Our final open questions to the respondents in the public survey were to indicate what kind of

special activities or factors that make RE practices work well in a global project and that gives

improvement over the current situation. The answers vary. One respondent says transparency over

RE processes, and other says formal sign off by all stakeholders. Describing user stories and making

visualization of requirements also helps RE practices in global projects. To improve their current

situations, the respondents suggest the following actions: kick-off-meeting in the same location,

improve acceptance test, reduce number of roles, empower the teams, and providing a high quality

team’s coordination tool.

7.3. Analysis We show that the public survey support our findings in the interviews. We gained important insights

of RE practices in global projects. The main findings of our public survey are:

1. ‘Team visits’ is the most effective solution to solve RE challenges in a global project

We observe from the survey answers, distance is a challenge that unavoidable in doing global

project, in particular RE practices. The consequences of distance challenge affects

communication and coordination over RE activities. The respondents admitted that in their

global projects, these challenges are happening: the loss of communication ‘richness’ and the

loss of ‘teamness’. Therefore, awareness within the global team should be increased in a global

project because there are different things compared to collocated situation. Our audience

remarks awareness of communication and coordination by mentioning the solution of “team

visits”, which are to visits to each other team location. The goals of this activity are: 1) to

increase awareness; 2) to increase communication; 3) to increase coordination between team.

More importantly, people between sites should know each other and ultimately it leads to

59

creating trust between them. That is probably why “motivation and building trust” is the next

solution chosen by the respondents. This makes sense because on remote sites, each team

relies on trust of the other team without actually really is seeing them. In RE activities, in which

communication is a key factor for successful RE processes, building trust is the most important

thing for teams involved.

Referring to chapter 2, according Carmel [26], even with collaborative technologies such as

video conferencing, telephone, email, traveling teams to visit each other sites is “a vital

ingredient to global software team” success. Thus, our finding in this public survey complements

and supports Carmel’s. Furthermore, Bhat et al. [37] reported best practices to achieve the

strategic success factors in GSE. One of their best practices to build trust is “get team together

at the formation stage for a face-to-face kickoff session”. The authors suggest it is very

important to build trust in remote sites since the situation in GSE teams is lack of

communication richness, will then eventually cause lack of trust. One of the solutions is having

team visits for example in kick off meetings, in order to have face-to-face meetings with all

members involved. Again, our finding in this public survey complements and supports this

argument.

2. Face-to-face communication is important even in a global project

As addressed in the first point of the findings, team visits are the most effective solution

proposed by the audience of the survey. This leads to the fact that ‘face-to-face communication’

is important even in a globally distributed project. The important thing from ‘face-to-face

communication’ in the global project is make things easier in RE processes. For example to

gather and explain requirements, it is more effective that someone explains it directly rather

with written form or offline communication. Therefore, solution practices of “team visits” and

“liaison officer” are essential to realize “face-to-face communication”. Carmel and Bhat et al.

argues that personal face-to-face meetings are the main way to build trust in a global software

team [26, 37]. Therefore, to maintain trust in a GSE project, a face-to-face meeting plays the

important role in GSE project. Thus, our finding complements this argument made by Carmel

[26] and Bhat et al. [37]. Apparently, current technologies are not yet mature enough in

providing comparable awareness levels as real-life face-to-face meetings.

3. Basic RE problems still exist in the global project

Although RE problems in the global project are dominated by distance challenges, the classic RE

problems still exist. As shown in table 38, ”lack of customer and user communication”, “lack of

developer communication”, “developer’s lack of business understanding”, “requirements keep

changing”, “complexity application”, ”incomplete/inconsistent requirements”, are in fact classic

RE problems that also exist in the global projects. Therefore, solutions to overcome these

challenges may also come from are classic RE solutions, which are “terminologies”, “trainings”,

“test driven specification”, and “user stories for requirements specification”.

As shown in chapter 5 (see table 26), this is also supported by theoretical research in chapter 2,

these findings confirm the classic RE problems found in local organization also exist in the GSE

project. Comparing with list common RE problems made by Daniel et al. [17], our finding

confirms these common RE problems that also occur in GSE projects. Moreover, our finding also

matches with the findings in local RE research. For example, the number one top RE problems

60

found by Talbot et al. [21], which is “scope creep/changing requirements”, is matched with our

findings. Verner et al. [63] found incomplete requirements as the biggest RE problem according

to their survey, which is also similar with our survey. Another finding by Soleman et al. [18] has

stated that “lack of customer and user communication” as top RE problem according their

survey, which is again similar with our findings. Thus, this shows that basic/local RE problems

exist in global projects too.

4. Organizational factors are the driving forces for doing global projects

“Reduce costs” and “talent pool” are the catalyst factors in doing global project. The interesting

is byproduct of these factors. Most of audience admitted doing global project is unavoidable by

situation within organization itself. Nowadays, most of companies are not focus only on

domestic resources. Therefore, to increase sale and customer, they should grow and open

company sites in other countries. The increase of multinational companies and the necessity

increase size and need within organization are the growing factors motivation in doing a global

project.

Refer to chapter 2, according Carmel [26], organization’s motivations to do a GSE project are

catalyst factors, sustain factors, size factors, and vision factors. Our findings confirm these

motivations, and found that the catalyst factors are the main motivation in doing a GSE project.

5. Confirmation to our findings in the interviews result

From the surveys, we gain positive review from the respondents, although not all of them agree

with the solutions offered from findings in the interviews with our respondents with banks in

the Netherland (see chapter 6).

In the use of ‘liaison’, we receive positive feedbacks such as “communication may be easier,

especially when language and cultural differences are an issue”, “it helps nut it doesn't solve the

biggest problems”, “only if that person is a very good participant and is able to feed back the info

to the teams”, “it can help but in that case the liaison officer needs to understand the full

offshore team and all its members/skills”, and “a liaison is essential to maintain trust. If each

team trust there is someone there who will follow though, track down issues, and work with

people until there is solid understanding. The liaison is perfect for building that trust.” On the

contrary, the negative reviews are “it adds an element in the communication chain where

communication can break down”, ”hinders team feeling”, “too costly and too much overhead in

startup setting”, and “by definition the officer forms a bottle neck”. Although there are benefits

in the use of liaison, we should aware of the risks of it.

In the use of online collaboration tools, we gain most positive feedbacks from the audience.

They are “video conferencing is the next best thing. Chat is easy for quick questions and

communications”, “slack for team communication”, “video conferencing at decision level yes,

chatting at development level yes”, “videoconferencing yes if often used because body language

can be read and whole teams can be involved, chatting yes for quick questions between 2

members.”, and “online communication is essential.” On the flipside, the negative reviews on

online collaboration tools are “No. Some might work a bit better than others. But none

overcome the miscommunication” and “mail not so much, too much time difference”. Hence,

online collaboration tools are indeed the most crucial thing in RE practices in a global project.

61

In the use of transparent process, we gain positive responses. The feedbacks are “structure in

the RE process will help managing expectations, everyone knows what is coming or expected of

him or her without the need to communicate this all the time.”, “tell me when a non-transparent

process works. Meaning yes, it always helps. And it only works if you manage it f-2-f and stick to

it. “, “yes, if everyone also agrees and rally understands and the project is able to change them

when needed”, and “transparency is essential for any process of for any outstanding company. If

you want to build a x10 high performance company transparency needs to be the default in all

things”. Thus, the transparency process is the essential thing in RE practices in a global project.

62

8. Conclusions and Discussion

8.1. Conclusions In this thesis, we conduct a small research regarding RE practices in GSE project organization, in

particular banking industry in the Netherlands. In addition, we compare our interviews results in

banks in the Netherlands with the interviews and the mini survey results in a local organization (in

this case, a bank in Indonesia). In this section, we are going to conclude and answer our research

questions in section 1.3.

We did seven interviews from total four banks in the Netherlands that agree as our source of

research. In addition, we do public survey to confirm our findings in the interviews. The

respondent’s profile and years experiences are varied. Nevertheless, they are all qualified as our

source of research. As grounded theory, in chapter 2, we present the theoretical research that we

use as our references model. We list domain area of RE practices, RE problems and RE solutions in

GSE from literature survey, and design interview questions based on that.

Thus, our conclusion is depicted in following table.

Table 41 Research Questions and Answers

Research Questions Answers

Main Research Question (MQ)

What are the lessons learned from GSE RE practices?

1.The use of ‘liaison’ to represent offshore team to onsite team effective to solve cultural differences, lack of ‘teamness’ and ‘language problem’; 2. The use of online collaborative tools such as videoconferencing, online document repository (MS SharePoint, JIRA), chatting, email, telephone is able to solve communication and coordination problem; 3. The use of transparent process in RE process help to solve inadequate information and lack of supervision in the global project


What are the differences of RE practices in a local software development project compare to GSE project settings?

There are not much differences between RE practices in a local software development and GSE project setting, unless distance and cultural differences. The current state-of-the-art practices of RE in GSE organization follow standard practices in the likes of Sommerville’s RE practices, guidance in SWEBOK, and also by internal organization own guidance. In term of GSE, organizations depend heavily on ICT technology to communication, coordination, cooperation and monitoring.

Sub What are the challenges in RE RE challenges in GSE setting project, includes

63

Research Question 2 (RQ2)

activities in GSE project settings? lack of communication richness, requirements translation from business to technical issues, requirements that not clear, distance issues, cultural differences, language problems, miscommunication, different methodologies, process is not transparent.


What are the proposed solutions of such challenges in RE activities in GSE project settings?

Solutions for RE challenges are varied but in general the solutions are: intensive communication and coordination between parties, e.g. team visits and/or the use of liaisons, the use of collaboration tools (e.g. video/audio conference, telephone, email and other software tools), user involvement in RE process, transparency process, management support and most importantly team work skills in managing global project, includes PMO skill, communication skill, trust, and other soft skills.

8.2. Discussion We understand the topic thesis is a broad subject that needs to be exploring further. However,

there are some issues in interview results that worth to discuss.

First, issue related to the quality of RE practices in GSE organization. We understand that defining

requirements in software development is the trickiest part. A lot of RE problems start from this area

process. Requirements are not clear; the client cannot define business requirements very clear,

problems in translating requirements from business need into technical parts. Therefore, it needs

special skill to define good requirements. These skills can be learnt through workshops or further

education. Thus, quality of RE practices needs to get more intention by management of

banks/organization in order to increase overall quality software development.

Wohlin et al. [64] conducted experiment in regards RE quality. They provide 26 quality attributes to

define RE quality, some of them are: 1) Do the requirements achievable? 2) Are the requirements at

the right level of detail? 3) Are the requirements clear? The result of this experiment showed that

the level of RE quality highly depends on the process adopted; e.g. waterfall methodologies differ

with agile methodologies in term of RE processes execution. Moreover, the attributes are tested in

various condition and showed that stakeholder’s role in determining quality of RE is very important.

The similarity with this thesis, both are subjecting RE process. However, the differences are the

paper is more detail on experiment in quality of RE, whereas in this thesis, we mention quality of RE

as side effect of conducting RE practices in the GSE project. Kauppinen et al. [65] studied what

success factors affected implementing RE processes in the organization. According to them, the

success factors found in the literature are user involvement, culture change, continuous RE process

improvement, evolutionary RE process improvement, pilot projects, training and educations, and

simplicity of the RE process. Their findings in regards of success factors in RE include: 1) motivation,

64

commitment, and enthusiasm of personnel, 2) usefulness of RE process, 3) practicality of the RE

processes, 4) training, 5) support, 6) implementation of the strategy, and 7) improvement activities.

Furthermore, based on these findings, the authors conclude that the success factors in

implementing RE processes in the organization depend on three dimensions: human dimensions

(skill, knowledge, motivation etc.), infrastructure (training and support), and characteristic of RE

process (usefulness and practicality) [65]. These success factors therefore affect quality of RE

processes, which reflect of the outcome of the RE processes itself. Our findings in the thesis confirm

the conclusion on this paper. In addition, human factors indeed the main catalyst factor, which

affects most in RE practices, either in local or global project perspective. The similarity with this

thesis, both subject on RE processes in the organization, but our thesis focus on implementation RE

practices in GSE project, whereas this paper on local project.

Second, issue related to define what is global in RE process in GSE organization. We need to explore

when the project means global for the organization. Is different office sites in one city already

considered global? On the other hand, is it compulsory that office sites and development to be

separated by two continents so it will be consider global? It is worth to discuss, because it will going

to affect what strategy to be used in the organization on how to handle RE processes. Moreover,

this is important to organization about the guidance of getting to know what is global software

engineering and its implications [66]. Once an organization knows and learns what GSE is then the

requirements-engineering phase will run smooth in the organization. Thus, the organizations need

to increase awareness and knowledge regarding GSE discipline knowledge.

There is little literature that discusses the guidance in GSE project. Smite et al. [24] provide a good

assessment tool to determine whether a project fit in GSE term. The authors define a

comprehensive taxonomy of classification knowledge in GSE. Moreover, the taxonomy is divided

into five parameters, which are: 1) sourcing (the starting point), 2) location, 3) legal entity, and 4)

geographical distance [24]. With these parameters, we can determine what is global in RE process in

GSE organization. The similarity between this paper and thesis work is both works focus in GSE. The

different is that the paper focused on study in GSE taxonomy in general, whereas this thesis focuses

on RE practices in GSE project. Dorina C. Gumm [66] provided a taxonomy regarding GSE project.

According to her study, there are four dimensions of distributed software development, they are: 1)

physical distribution, organizational distribution, temporal distribution, and distribution among

stakeholder groups. Moreover, the author suggested that the perceived of distance to these

dimensions within the organization determine whether the project consider to be global or not [66].

However, the author did not clear specifically whether or not the project is global or not, but only

provide parameters of which then the organization itself decide whether the project is global or not.

The similarity between this thesis and the paper, both research are setting in GSE project. However,

this thesis focuses on RE practices in GSE project, whereas the paper focuses on general framework

of distributed software project.

Third, issue related to increase the knowledge about RE practices. This third issue is important,

because this is the basic knowledge of RE. What we learn from interview results, the audience seem

not to care or simply do not know the process of RE or the details of RE practices. It seems RE just a

65

process to create documents, and the audience and most organization think that the most

important in software engineering is the coding or development software itself. This is not wrong

either, but if RE is underestimated, then it will guarantee the failure of software itself. Thus, IT

department in an organization need more attention to increase knowledge in RE science, in

particular RE practices and RE processes/steps.

El Emam et al. [13], as one of the pioneer research in RE, mentioned this requirement to successfully

RE practices. The authors said, “The most desirable users have skills set that include good

knowledge of system development processes (especially the requirements engineering process and

modelling techniques) and their deliverables”. Moreover, user participation with knowledge in

regards RE practices create catalyst a successful software project [13]. The similarity between this

paper and thesis work is both works focus in RE practices. The different is that the paper focused on

study in local RE, whereas this thesis focuses on RE practices in GSE project. Another work by De la

Vara et al. [67] mentioned several challenges in toward customer-based RE practices which is

include lack of knowledge of RE practices. Thus, the authors suggest some training will overcome

such problem [67]. The similarity between this paper and thesis work is both works focus in RE

practices. The different is that the paper focused on study in local RE, whereas this thesis focuses on

RE practices in GSE project.

8.3. Reflection of Thesis Process There are things that need to be noted during working this thesis assignment, they are:

Time limitation

We acknowledge that to increase validity of this research, large number of audience is needed

in the research. However, there is a time limitation in this research. Therefore, those detail and

wider research are open to next thesis or research work.

Audience scarcity

We admitted that to find audience in public survey department, that fit and suitable in this

research is hard because of the unique nature of the topic of this research. First, the person

must know and experience in software development, in particular RE phase. Second, the person

must know and experience in global software engineering and involved in RE phase. Third, the

person must be in banking industry. The candidate audience must met these criteria, otherwise

it is not consider fit in this research.

8.4. Validity According to Wohlin et al. [68], there are four scheme to articulate validity on software engineering

research, they are:

1. Conclusion validity, which is concerned with the relationship between the treatment and the

outcome.

2. Internal validity, If a relationship is observed between the treatment and the outcome, we must

make sure that it is a causal relationship, and that it is not a result of a factor of which we have

66

no control or have not measured. In other words, that the treatment causes the outcome (the

effect).

3. Construct validity, which is concerned with the relation between theory and observation. If the

relationship between cause and effect is causal, we must ensure two things: (1) that the

treatment reflects the construct of the cause well and (2) that the outcome reflects the

construct of the effect well.

4. External validity, which is concerned with the generalization. If there is a causal relationship

between the construct of the cause, and the effect, can the result of the study be generalized

outside the scope of our study? Is there a relation between the treatment and the outcome?

In term of conclusion validity, we already show that our research questions have been answered

and explained in section 6.1. The research outcome show and confirm what grounding theory

(theory research, see chapter 2). Further, we show additional findings that can be used for next

candidate to research in future.

In term of internal validity, we make sure that our research data is has a causal relationship, which is

the impact of RE practices in global project settings. Our research is in control environment, where

place and respondents background has capability and experience in software engineering in general,

and requirements engineering in particular.

In term of construct validity, we show the relationship between theory and observation that has

cause and effect. The banks are practicing GSE project cause different treatment in RE practices,

which involved ICT technologies to communicate, and coordination. Although, the RE processes are

the same as local, but there are differences and it is covered by technology and procedure.

In term of external validity, we show that as a small sample for further studies in GSE literature that

confirms and strengthen theory and challenges that found in theory and literature. However, we

admitted that with only few respondents as our sources of data, more data is needed to be added

and explored in future research.

8.5. Recommendations of Future Work We recommend these items to future work:

Expand research into more banking that involved in GSE projects.

This is important because more respondents mean to increase external validity and getting

more data. Recalled from chapter 6 in regards interviews with banks in the Netherlands, we only

managed interview personnel of four banks out of possible 29 banks in the Netherlands

(http://www.expatax.nl/banksexpatax.php).

To do more survey to gain wider audience in regarding RE practices in GSE project.

This is important, again, because more respondents mean to increase external validity and

getting more data. Recalled from chapter 7 in regards conducting public survey, we manage

gathering 121 respondents. However, only 108 of them have experience in GSE project. We

expected to have more audience, but unfortunately, with limited time of thesis project (see

section 8.3) we only have the aforementioned number of respondents.

67

To explore more about constructing a general or reference model or theory regarding RE

practices in GSE project.

In thesis work, we cover important findings in regards RE practices in GSE project, so that we

gain insights or lesson learned of RE practices GSE project that local RE can benefit from it.

However, we do not cover an extensive model or theory about RE practices in GSE project in

general, so that this work can be used as reference in another project. The challenges to do this

whether we could gain more respondents and more data (see two points recommendation

above), also to offer a sophisticated model regarding RE practices in GSE project. However, to do

this requires more time, more resources, and more cost to get a comprehensive research work.

We expect this thesis work could be a stepping-stone for more similar studies in the future.

To do vertical research (deepening) in RE processes in global software engineering

We suggest to do research in more RE specific. These topics, as we gather from insights in the

interviews and/or also from the public survey feedbacks and improvements, which are:

o What is the effective RE elicitation method in GSE project?

o What is the effective RE validation process in GSE project?

o What is the contingency plan to RE processes in GSE project if such IT

telecommunication is not exists in such area in the world?

o What are the effective ways besides face-to-face meeting offered by team visits or

liaisons to build trust among teams in a GSE project? (e.g. team rotation)

o What are the risks of not having a transparent process in a GSE project?

o What aspects in software methodology affect the outcome of RE processes in a GSE

project?

o What factors affect RE practices quality in a GSE project?

o How to measure a successful RE practices in a GSE project?

o What is the importance of early bonding of the team(s) at the beginning of the GSE

project?

To do horizontal research (wider) in GSE besides requirements engineering

We hope that our research could inspire another research in GSE field. For example, doing

research to investigate development phase or testing phase in GSE project. Therefore, with

much richer various research in complete software engineering phases in GSE, contribute a

significant clear knowledge in GSE field.

68

Bibliography 1. Abran, A. and P. Bourque, SWEBOK: Guide to the software engineering Body of Knowledge.

2004: IEEE Computer Society. 2. Babcock, R., G. Harkin, and H. Lloyd, Industry Best Practices for the Software Development Life

Cycle. 2007, Montana Department of Transportation. 3. Sommerville, I. and P. Sawyer, Requirements engineering: a good practice guide. 1997: John

Wiley & Sons, Inc. 4. Solingen, R.v., IN4185 Globally Distributed Software Engineering. 2014. 5. Zowghi, D. Does global software development need a different requirements engineering

process. in Proceedings of International Workshop on Global Software Development. 2002. Citeseer.

6. Glinz, M. and R.J. Wieringa, Guest editors' introduction: Stakeholders in requirements engineering. Software, IEEE, 2007. 24(2): p. 18-20.

7. Cheng, B.H. and J.M. Atlee. Research directions in requirements engineering. in 2007 Future of Software Engineering. 2007. IEEE Computer Society.

8. Bourque, P. and R.E. Fairley, Guide to the Software Engineering Body of Knowledge (SWEBOK (R)): Version 3.0. 2014: IEEE Computer Society Press.

9. Systems and software engineering -- Life cycle processes --Requirements engineering. ISO/IEC/IEEE 29148:2011(E), 2011: p. 1-94.

10. Sawyer, P., I. Sommerville, and S. Viller, Requirements process improvement through the phased introduction of good practice. Software Process: Improvement and Practice, 1997. 3(1): p. 19-34.

11. Boehm, B., et al. Software requirements as negotiated win conditions. in Requirements Engineering, 1994., Proceedings of the First International Conference on. 1994. IEEE.

12. Potts, C., K. Takahashi, and A.I. Antón, Inquiry-based requirements analysis. IEEE software, 1994. 11(2): p. 21-32.

13. El Emam, K. and N.H. Madhavji. A field study of requirements engineering practices in information systems development. in Requirements Engineering, 1995., Proceedings of the Second IEEE International Symposium on. 1995.

14. Supha Khankaew, S.R., A Review of Practice and Problems in Requirements Engineering in Small and Medium Software Enterprises in Thailand. EmpiRE 2014, Karlskrona, Sweden, 2014.

15. Neill, C.J. and P.A. Laplante, Requirements engineering: the state of the practice. Software, IEEE, 2003. 20(6): p. 40-45.

16. Das, V.V. Involvement of Users in Software Requirement Engineering. in Information Technology, (ICIT 2007). 10th International Conference on. 2007.

17. Daniel Mendez Fernandez and S. Wagner, Naming the pain in requirements engineering: design of a global family of surveys and first results from Germany, in Proceedings of the 17th International Conference on Evaluation and Assessment in Software Engineering. 2013, ACM: Porto de Galinhas, Brazil. p. 183-194.

18. Solemon, B., S. Sahibuddin, and G. Abdul Azim Abd. Requirements engineering problems in 63 software companies in Malaysia. in Information Technology, 2008. ITSim 2008. International Symposium on. 2008.

19. Basharat, I., et al. Requirements engineering practices in small and medium software companies: An empirical study. in Science and Information Conference (SAI), 2013. 2013.

20. Quispe, A., et al. Requirements Engineering Practices in Very Small Software Enterprises: A Diagnostic Study. in Chilean Computer Science Society (SCCC), 2010 XXIX International Conference of the. 2010.

69

21. Talbot, A. and A. Connor. Requirements Engineering Current Practice and Capability in Small and Medium Software Development Enterprises in New Zealand. in Software Engineering Research, Management and Applications (SERA), 2011 9th International Conference on. 2011.

22. Uolevi Nikula, J.S., Heikki Kälviäinen, A State-of-the-Practice Survey on Requirements Engineering in Small- and Medium-Sized Enterprises. 2000.

23. Carmel, E., Global software teams. 1999, Upper Saddle River, NJ: Prentice Hall. 24. Šmite, D., et al., An empirically based terminology and taxonomy for global software

engineering. Empirical Software Engineering, 2014. 19(1): p. 105-153. 25. Carmel, E. and R. Agarwal, Tactical approaches for alleviating distance in global software

development. Software, IEEE, 2001. 18(2): p. 22-29. 26. Carmel, E., Global software teams: collaborating across borders and time zones. 1999: Prentice

Hall PTR. 269. 27. Damian, D. and D. Moitra, Guest Editors' Introduction: Global Software Development: How Far

Have We Come? Software, IEEE, 2006. 23(5): p. 17-19. 28. Hanisch, J. and B.J. Corbitt, Requirements Engineering During Global Software Development:

Some Impediments to the Requirements Engineering Process-A Case Study. 2004. 29. Conchúir, E.Ó., et al., Global software development: where are the benefits? Communications of

the ACM, 2009. 52(8): p. 127-131. 30. Damian, D. Requirements Engineering in Distributed Projects. in Global Software Engineering,

2006. ICGSE '06. International Conference on. 2006. 31. Khan, H., et al. Requirements Understanding in Global Software Engineering: Industrial Surveys.

in Proceedings of the International Conference on Computer and Software Modeling,(CSM’20111), Singapore. 2011.

32. Greek, H., Cultures and Organizations, Software of the mind. 1991, McGraw Hill Company Limited, England.

33. Brockmann, P.S. and T. Thaumüller. Cultural Aspects of Global Requirements Engineering. in 2009 Fourth IEEE International Conference on Global Software Engineering (ICGSE’09). 2009.

34. Alnuem, M.A., A. Ahmad, and H. Khan. Requirements Understanding: A Challenge in Global Software Development, Industrial Surveys in Kingdom of Saudi Arabia. in Computer Software and Applications Conference (COMPSAC), 2012 IEEE 36th Annual. 2012.

35. Laurent, P., et al. A Taxonomy and Visual Notation for Modeling Globally Distributed Requirements Engineering Projects. in Global Software Engineering (ICGSE), 2010 5th IEEE International Conference on. 2010.

36. Herbsleb, J.D. Global Software Engineering: The Future of Socio-technical Coordination. in Future of Software Engineering, 2007. FOSE '07. 2007.

37. Bhat, J.M., M. Gupta, and S.N. Murthy, Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing. Software, IEEE, 2006. 23(5): p. 38-44.

38. Damian, D., et al., Practice: Requirements Engineering in Global Teams. Global Software and IT: A Guide to Distributed Development, Projects, and Outsourcing, 2012: p. 257-267.

39. Niazi, M., et al. GlobReq: A framework for improving requirements engineering in global software development projects: Preliminary results. in Evaluation & Assessment in Software Engineering (EASE 2012), 16th International Conference on. 2012. IET.

40. Keele, S., Guidelines for performing systematic literature reviews in software engineering. 2007, Technical report, EBSE Technical Report EBSE-2007-01.

41. Schneider, S., R. Torkar, and T. Gorschek, Solutions in global software engineering: A systematic literature review. International Journal of Information Management, 2013. 33(1): p. 119-132.

42. Frederick J. Gravetter, L.-A.B.F., Research Methods for the Behavioral Sciences. 2012.

70

43. Haron, A., et al. Understanding the Requirement Engineering for organization: The challenges. in Computing Technology and Information Management (ICCM), 2012 8th International Conference on. 2012.

44. Anderson, S. and M. Felici, Requirements engineering questionnaire. vol, 2001. 1: p. 15. 45. Damian, D., Stakeholders in Global Requirements Engineering: Lessons Learned from Practice.

Software, IEEE, 2007. 24(2): p. 21-27. 46. Wilson, I. and R. Stern, Approaches to the Analysis of Survey Data. 2001, Statistical Guideline

Series supporting DFID Natural Resources Projects. Reading, United Kingdom: Statistical Services Centre, University of Reading. Available from http://www. reading. ac. uk/ssc (accessed 25 June 2004).

47. Coughlan, J., M. Lycett, and R.D. Macredie, Communication issues in requirements elicitation: a content analysis of stakeholder experiences. Information and Software Technology, 2003. 45(8): p. 525-537.

48. Saiedian, H. and R. Dale, Requirements engineering: making the connection between the software developer and customer. Information and Software Technology, 2000. 42(6): p. 419-428.

49. Al-Rawas, A. and S.M. Easterbrook, Communication problems in requirements engineering: a field study. 1996: National Aeronautics and Space Administration.

50. Bjarnason, E., K. Wnuk, and B. Regnell. Requirements are slipping through the gaps—A case study on causes & effects of communication gaps in large-scale software development. in Requirements Engineering Conference (RE), 2011 19th IEEE International. 2011. IEEE.

51. Coughlan, J. and R.D. Macredie, Effective communication in requirements elicitation: a comparison of methodologies. Requirements Engineering, 2002. 7(2): p. 47-60.

52. Krishna, S., S. Sahay, and G. Walsham, Managing cross-cultural issues in global software outsourcing. Communications of the ACM, 2004. 47(4): p. 62-66.

53. Ebert, C. and P. De Neve, Surviving global software development. Software, IEEE, 2001. 18(2): p. 62-69.

54. Damian, D.E. and D. Zowghi, RE challenges in multi-site software development organisations. Requirements engineering, 2003. 8(3): p. 149-160.

55. Holmstrom, H., et al. Global software development challenges: A case study on temporal, geographical and socio-cultural distance. in Global Software Engineering, 2006. ICGSE'06. International Conference on. 2006. IEEE.

56. Damian, D., F. Lanubile, and T. Mallardo, On the need for mixed media in distributed requirements negotiations. Software Engineering, IEEE Transactions on, 2008. 34(1): p. 116-132.

57. Sinha, V., B. Sengupta, and S. Chandra, Enabling collaboration in distributed requirements management. Software, IEEE, 2006. 23(5): p. 52-61.

58. Steinmacher, I., A.P. Chaves, and M.A. Gerosa, Awareness support in global software development: a systematic review based on the 3C collaboration model, in Collaboration and Technology. 2010, Springer. p. 185-201.

59. Menten, A., S. Scheibmayr, and L. Klimpke. Using audio and collaboration technologies for distributed requirements elicitation and documentation. in Managing Requirements Knowledge (MARK), 2010 Third International Workshop on. 2010.

60. Herbsleb, J.D. Global software engineering: The future of socio-technical coordination. in 2007 Future of Software Engineering. 2007. IEEE Computer Society.

61. Berenbach, B. Impact of organizational structure on distributed requirements engineering processes: lessons learned. in Proceedings of the 2006 international workshop on Global software development for the practitioner. 2006. ACM.

71

62. Prikladnicki, R., J.L.N. Audy, and R. Evaristo. A reference model for global software development: findings from a case study. in Global Software Engineering, 2006. ICGSE'06. International Conference on. 2006. IEEE.

63. Verner, J., et al., Requirements Practices: A Comparative Industrial Survey, in Advances in Information Systems Development, A. Nilsson, et al., Editors. 2006, Springer US. p. 719-730.

64. Wohlin, C., Engineering and managing software requirements. 2005: Springer Science & Business Media.

65. Kauppinen, M., et al., Implementing requirements engineering processes throughout organizations: success factors and challenges. Information and Software Technology, 2004. 46(14): p. 937-953.

66. Gumm, D.C., Distribution dimensions in software development projects: a taxonomy. Software, IEEE, 2006. 23(5): p. 45-51.

67. De La Vara, J.L., et al. Towards customer-based requirements engineering practices. in Empirical Requirements Engineering (EmpiRE), 2012 IEEE Second International Workshop on. 2012. IEEE.

68. Wohlin, C., et al., Experimentation in software engineering. 2012: Springer Science & Business Media.

72

A. List of Literature Survey Paper No Authors Title

Conference/ Journal/Book

Publisher Area of RE

Study Research

Type Research

Methodology Academia/

Industry Validation

1

Sajid Ibrahim Hashmi, Fuyuki Ishikawa, Ita Richardson

A communication process for global requirements engineering

ICSSP’13, May 18–19, 2013, San Francisco, CA, USA

ACM (2013)

Communication

Modeling Literature Survey

Both Complete Research

2

Daniela Damian, Filippo Lanubile, Teresa Mallardo

The role of asynchronous discussions in increasing the effectiveness of remote synchronous requirements negotiations

ICSE'06, May 20-28, 2006, Shanghai, China

ACM (2006)

Communication

Modeling Case Study Academia Complete Research

3 Brian Berenbach

Impact of organizational structure on distributed requirements engineering processes: lessons learned

GSD’06, May 23, 2006, Shanghai, China

ACM (2006)

Organization Structure

Modeling

Case Study and Literature Survey

Industry Complete Research

4 Eric Knauss, Daniela Damian

V:ISSUE:LIZER: exploring requirements clarification in online communication over time

ICSE 2013, San Francisco, CA, USA

IEEE (2013)

Communication

Tools Experiment Academia Complete Research

5

Vesna Mikulovic, Michael Heiss

"How do I know what I have to do?": the role of the inquiry culture in requirements communication for distributed software development projects

ICSE'06, May 20-28, 2006, Shanghai, China

ACM (2006)

Communication

Modeling Case Study Industry Complete Research

6 Matthias Heindl, Stefan Biffl

Risk management with enhanced tracing of requirements rationale in highly distributed projects

GSD’06, May 23, 2006, Shanghai, China

ACM (2006)

Risk Management

Modeling Survey Industry Complete Research

7

Mikko Korkala, Minna Pikkarainen and Kieran Conboy

A case study of customer communication in globally distributed software product development

Proceedings of the 11th International Conference on Product Focused Software

ACM(2010)

Communication

Modeling Case Study Both Complete Research

8

Paula Laurent, Patrick Mäder, Jane Cleland-Huang, and Adam Steele

A Taxonomy and Visual Notation for Modeling Globally Distributed Requirements Engineering Projects

2010 International Conference on Global Software Engineering

IEEE(2010)

Analysis Modeling Interviews and Case Study

Academia Complete Research

9 Mohammed Abdullah Alnuem

Requirements Understanding: A Challenge in GlobalSoftware Development, Industrial Surveys in Kingdom of Saudi Arabia

2012 IEEE 36th International Conference on Computer Software and Applications

IEEE(2012)

Analysis Modeling Survey Academia Complete Research

73

10

Achim Menten, Sven Scheibmayr, Lars Klimpke

Using audio and collaboration technologies for distributedrequirements elicitation and documentation

Managing Requirements Knowledge (MARK), 2010 Third International Workshop

IEEE(2010)

Elicitation Tools Interviews Academia Complete Research

11 Andreas Deuter

Slicing the V-Model -- Reduced Effort, Higher Flexibility

2013 IEEE 8th International Conference on Global Software Engineering

IEEE(2013)

Validation Modeling Experiment Academia Complete Research

12 Daniela E. Damian and Didar Zowghi

An insight into the interplay between culture, conflict and distance in globally distributed requirements negotiations

Proceedings of the 36th Hawaii International Conference on System Sciences (HICSS’03)

IEEE(2002)

Culture Modeling Case Study Academia Complete research

13

Kai Stapel, Eric Knauss, and Kurt Schneider

Using FLOW to Improve Communication of Requirements inGlobally Distributed Software Projects

2009 Collaboration and Intercultural Issues on Requirements (CIRCUS 2009)

IEEE(2009)

Communication

Modeling Experiment Academia Complete research

14

Maria Paasivaara, Ville T. Heikkil¨a and Casper Lassenius

Experiences in Scaling the Product Owner Role in Large-Scale Globally Distributed Scrum

2012 IEEE Seventh International Conference on Global Software Engineering

IEEE(2012)

Process Modeling Case Study Academia Complete research

15 Daniela E. Damian and Didar Zowghi

The impact of stakeholders' geographical distribution on managing requirements in a multi-site organization

Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02)

IEEE(2002)

Elicitation Modeling Case Study Academia Complete Research

16

Daniela Damian, Sabrina Marczak, and Irwin Kwan

Collaboration Patterns and the Impact of Distance on Awareness in Requirements-Centred Social Networks

15th IEEE International Requirements Engineering Conference

IEEE(2007)

Communication

Modeling Case Study Academia Complete Research

17

Patricia Shiroma Brockmann, Thomas Thaumüller

Cultural Aspects of Global Requirements Engineering: An Empirical Chinese-German Case Study

2009 Fourth IEEE International Conference on Global Software Engineering

IEEE(2009)

Culture Modeling Case Study Academia Complete Research

18

Nosheen Sabahat, Faiza Iqbal, Farooque Azam, Muhammad Younus Javed

An iterative approach for global requirements elicitation: A case study analysis

2010 International Conference on Electronics and Information Engineering (ICEIE 2010)

IEEE(2010)


74

19

Ivaldir H. de Farias Junior, Ryan R. de Azevedo, Hermano P. de Moura, Dennis S. Martins da Silva

Elicitation of Communication Inherent Risks in DistributedSoftware Development

2012 IEEE Seventh International Conference on Global Software Engineering Workshops

IEEE(2012)

Elicitation Modeling Literature Survey

Academia Complete Research

20

Michael Geisser and Tobias Hildenbrand and Franz Rothlauf

An Evaluation Method for Requirements Engineering Approaches in Distributed Software Development Projects

Software Engineering Advances, 2007. ICSEA 2007

IEEE(2007)

Evaluation Modeling Experiment Academia Complete Research

21

Juan Manuel Carrillo de Gea, Joaquıń Nicola´s, Jose´ Luis Fernańdez Alemań, Ambrosio Toval, A. Vizcaıńo, and Christof Ebert

Reusing Requirements in Global Software Engineering

Managing Requirements Knowledge (Book)

Springer-Verlag Berlin Heidelberg (2013)

Process Modeling Literature Survey

Both Complete Research

22

Hakim Bendjenna, Nacereddine Zarour, and Pierre-Jean Charrel

Enhancing Elicitation Technique Selection Process in a Cooperative Distributed Environment

REFSQ 2008


Elicitation Modeling Experiment Academia Complete Research

23

M. Ramzan, Asma Batool, Nasir Minhas, Zia Ul Qayyum, and M. Arfan Jaffar

Automated Requirements Elicitation for Global Software Development (GSD) Environment

ASEA/DRBC/EL 2011



24

Miriam Sayão, Aluízio Haendchen Filho, and Hércules Antonio do Prado

Requirements Engineering for Distributed Development Using Software Agents

ER Workshops 2008


Process Tools Experiment Academia Complete Research

25

H. Keith Edwards, Varadharajan Sridhar

Analysis of the Effectiveness of Global Virtual Teams in Software Engineering Projects

Proceedings of the 36th Hawaii International Conference on System Sciences - 2003

IEEE(2003)

Process Modeling Case Study Academia Complete Research

26

P. Laurent, A. Steele, J. Cleland-Huang and P. Mäeder

Evaluating the Effectiveness of a Collaborative Requirements Engineering Modeling Notation for Planning Globally Distributed Projects

Proceedings of The 2013 World Congress in Computer Science, Computer Engineering, and Applied Computing

- Process Modeling Case Study Academia Complete Research

75

27 Waqar Hussain, Tony Clear

Spreadsheets as Collaborative Technologies in Global Requirements Change Management

9th International Conference on Global Software Engineering, 2014

IEEE(2014)

Process Tools Case Study Academia Complete Research

28

Mahmood Niazi, a, b, c, Mohamed El-Attar b, Muhammad Usman d and Naveed Ikram

GlobReq: A framework for improving requirementsengineering in global software development projects: Preliminary results

Proceedings of the EASE 2012

IET (2012)

Analysis Modeling Case Study Academia Research Proposal

29 Christian Lescher

Global Requirements Engineering: Decision Support for Globally Distributed Projects


IEEE(2009)

Decision Making

Modeling Experiment Academia Research Proposal

30 Sajid Ibrahim Hashmi

Global Requirements Engineering on the Cloud: PhD Research Proposal

2013 IEEE 8th International Conference on Global Software Engineering

IEEE(2013)

Process Modeling Interviews and Case Study

Academia Research Proposal

31

Steffen Lohmann, Philipp Heim, Kim Lauenroth

Web-based Stakeholder Participation in DistributedRequirements Elicitation

16th IEEE International Requirements Engineering Conference

IEEE(2008)

Elicitation Tools Experiment Academia Research Proposal

32

Neetu Kumari.S, Dr.Anitha S. Pillai

A survey on global requirements elicitation issues and proposed research framework

Software Engineering and Service Science (ICSESS), 2013 4th IEEE International Conference

IEEE(2013)



33

Catherine Lowry Campbell and Bartel van de Walle

Asynchronous requirements engineering: enhancing distributed software development

Information Technology: Research and Education, 2003. Proceedings. ITRE2003. International Conference

IEEE(2003)

Communication



34

Miguel Romero1, Aurora Vizcaíno2, Mario Piattini2

Teaching Requirements Elicitation within the Context ofGlobal Software Development

2009 Mexican International Conference on Computer Science

IEEE(2009)



35

Masatoshi Shimakage and Atsuo Hazeyama

A Requirement Elicitation Method in Collaborative Software Development Community

PROFES 2004


Elicitation Modeling Experiment Academia Research Proposal

76

36

Huma Hayat Khan , Mohd. Naz’ri bin Mahrin , Suriayati bt Chuprat

Situational factors affecting Requirement Engineering process in Global Software Development

Conference on Open Systems (ICOS), December 2 - 4, 2013, Sarawak, Malaysia

IEEE(2013)

Analysis Modeling Literature Survey

Academia SLR

37

Barkha Javed, Sumaira Sultan Minhas

Process Support for Requirements Engineering Activities inGlobal Software Development: A Literature Based Evaluation

Computational Intelligence and Software Engineering (CiSE), 2010

IEEE(2010)


Academia SLR

38

Alejandro L´opez, Joaqu´ın Nicol´as, Ambrosio Toval

Risks and Safeguards for the Requirements EngineeringProcess in Global Software Development


IEEE(2009)

Risk Management


Academia SLR

39

Farzana Yousuf, ZahidZaman, Naveed Ikram

Requirements validation techniques in GSD: A survey

Multitopic Conference, 2008. INMIC 2008. IEEE International

IEEE(2008)

Validation Modeling Literature Survey

Academia SLR

40

Huma Hayat Khan , Mohd. Naz’ri bin Mahrin , Suriayati bt Chuprat

Situational requirement engineering: A systematic literature review protocol

2013 IEEE Conference on Open Systems (ICOS), December 2 - 4, 2013, Sarawak, Malaysia

IEEE(2013)

Analysis Modeling Literature Survey

Academia SLR

41 Klaus Schmid

Challenges and Solutions in Global Requirements Engineering – A Literature Survey

SWQD 2014

Springer International Publishing Switzerland (2014)


Academia SLR

42

Betty H.C. Cheng, Joanne M. Atlee

Research Directions in Requirements Engineering

FOSE '07: 2007 Future of Software Engineering

IEEE Computer Society (2007)

Future direction of RE and GSE

Summary Literature Survey

Academia Summary

43 James D. Herbsleb

Global Software Engineering: The Future of Socio-technical Coordination

FOSE '07: 2007 Future of Software Engineering

IEEE Computer Society (2007)

Future direction of GSE and RE

Summary Literature Survey

Academia Summary

44 Yvonne Hsieh

Culture and Shared Understanding in DistributedRequirements Engineering

IEEE International Conference on Global Software Engineering (ICGSE'06)

IEEE(2006)

Culture Modeling Literature Survey

Academia Summary

45

Jyoti M. Bhat, Mayank Gupta, and Santhosh N. Murthy

Overcoming Requirements Engineering Challenges: Lessons from Offshore Outsourcing

Software, IEEE, Volume: 23 , Issue: 5

IEEE(2006)

Process Modeling Case Study Industry Summary

77

46 Daniela Damian

Stakeholders in Global Requirements Engineering: Lessons Learned from Practice

Software, IEEE Volume: 24 , Issue: 2

IEEE(2007)

Process Expert Opinion

Literature Survey

Academia Summary

47

Didar Zowghi Does Global Software

Development Need a

Different Requirements

Engineering Process?

In Proceedings

of International

Workshop on

Global

Software

Development

(Vol. 2002)

- Process Summary Literature

Survey

Academia Summary

B. Summary Pilot Test Interview (RE Practices in Local

Organization)

No List of questions Type of

question Respondent 1

(60 m) Respondent 2

(32 m) Respondent 3

(38 m) Respondent 4

(75 m) Respondent 5

(61 m) Analysis

1 What is your name and position in the organization?

Backgound Information

R – Manager I - Senior System Analyst

F – Senior System Analyst

Y – Head of Application Development Team

R – System Analyst/manager

All interviewees come from the same background and similar position, with different hierarchy. The highest is the head of application team, and the lowest is manager.

2 What is your role in the application development?


A bit of mixed up – as a Project Manager, Business Analyst and also System Analyst, even also as a Programmer

As a Business Analyst and Project Manager

To make sure the user deliver user requirement as clear as possible

To manage division and all resources to develop multi-sector applications, in particular data warehousing and business intelligence which requested by users

There are several roles, they are: involved in user requirements documentation supervising with users, making design documentation, monitoring of coding, involved in unit testing, lastly involved in making testing scenario until finished

My aim for this question is to get know the role of interviewee in the development team, respondent 1 and 2 seems to answer it right, but respondent 3,4,5 answer it by explaining his task/duty.

3 How long do you work on software development field?


8-9 years 10 years 10 years 8.5 years 4 years 9 months

All interviewees has over 4 years experience, with the maximum 10 years experience. This means all interviewees have sufficient knowledge to

78

answer the questions in the interview.

4

Have you ever involved in Global software development?


No, I never involved in global software development





All interviewees has no experience in GSE/GSD project, means that this is a local organization.

5

What is the last project do you ever involved until it finished? How long it finished? How many man involved in a team in the project?


Electronic Banking BI, the duration of the project is 6 months, with two full time personnel (including me)

BI E-Procurement, the duration project is 8 months, we have 3 members from internal organization and 7 from outsource company

FIN enhancement, the duration is 11 months, the total man involved were 12 man

Enterprise Data Warehouse, in duration of 4 years project with 20 people involved in the team

BI website project, it has 1.5 years duration, with team members of 10-12 people

The projects are varied from two team members to 20 persons team, and the duration project in 6 months until 4 years project

6

Who are your users and stakeholders of the project?


Minister of finance

Internal department and external vendor

Banks and external parties/respondents

Our users are other departments in the organization, the board director, also external parties for example banking

The user is internal Communication Department, but the application can be accessed by internet users.

3 respondents said the users and stakeholders are the internal departments, whereas 2 said external parties

7

What software development life-cycle method do you follow?


We always use RUP (Rational Unified Process), the bottom-up model

We used waterfall method

We use waterfall method

We use waterfall method combine with rapid prototyping

We use waterfall

Most respondents (4/5) use waterfall method while only one said RUP method

8

What do you do on requirement phase in software development project?

RE General

First, there should be a problem statement; Second, we do requirement registration and the third, business requirement definition which answer the problem statement.

We gather detailed requirements and point out solution plan

To make sure the user requirement document as clear as possible so that we can deliver the right technical solution

First, we meet with the stakeholders of the project, second, we listen the stakeholder’s need, third, we read previous references including policies and reports, four, we clarify the need, five, we develop model represent the requirement, six, we communicate the model to the stakeholders, eight we record and do the requirements documentation

We assisted and supervise users during making user requirements specification

In this questions, all respondents have similar answers, that are the engagement with users and has the same RE goal that is to produce a clear requirements specification

79

9

Do you carry out a feasibility study before starting a new project?

RE Practice

Sometimes we make a selection based on priorities of the requirement where mandatory, optional ones. The feasibility study done before the project started before information system management forum. The forum goal is to align with organization principal strategic direction.

User delivered early user requirements description, and then we review existing system (if exist) and we discuss development scope with the user including further requirements gathering and elicitation

Yes, we carry out a feasibility study at user’s need elicitation

Before we did EDW project, we conducted a feasibility study with consultant. Now we generally have assessment of newly project proposal before the project started.

No, I don’t do a feasibility study

4 respondents answer that they carry out feasibility study while one said did not do a feasibility study.

10

Do you use business concerns to drive requirements elicitation?

RE Practice Yes

Yes, we elicit requirements based on business concerns

Yes, team from organization take part in requirements elicitation

Yes, business process as our guidance in requirements elicitation. The problems are how complete process documentation, how detail is it, how accurate it is reflected the actual process. Therefore, we need direct observation in order to understand the operational of process business.

-

4 respondents answer that they use business concerns to drive requirements elicitation.

11

Which techniques do you use the most for elicitation requirement? For example: prototypes, use case, scenarios.

RE Practice For most cases, we use use case.

We use prototype and use case

We use prototype and use case

We use prototype and use case.

We do not use a specific method. We only find the gaps between the existing system and the future system that is going to be develop

Use case is the most technique used by the respondents (4), while prototype is the second (3)

12

Do you prototype requirements that are poorly understood?

RE Practice Never

Yes, in particular the requirements that poorly understood and is not clear.

Yes

Yes. In EDW project we need to educate users. With prototype, we facilitate the user’s education. Thus, users will know the actual need.

No

3 respondents said they has employ prototype to describe more detail of poorly understood of requirements

80

13

Do you use checklists for requirements analysis?

RE Practice Yes, but not a formal checklist.

Yes sometimes

Yes, but not entirely necessary needed

Yes, based on SDLC standard in our organization called P3SA. The checklist consists of background, problem statement, goal of the project, functional requirements and non-functional requirements.

Yes, we use checklist that contains a general guideline to construct a user requirements specification

5 respondents have said they use checklists for requirement analysis

14 Do you prioritize requirements?

RE Practice Yes Yes Yes

Yes, but in reality all users have force to make all requirements are in high priorities. But, because of time constraint, we make requirements prioritization.

Yes, we prioritize requirements based on real business needs not on user own personal deed.

5 respondents have said they prioritize requirements

15

How do you negotiate requirements with the users if conflict happens in requirements analysis?

RE Practice

We give alternative solutions to solve a problem and the pros and cons with also it costs and benefits. The costs affect the project duration.

We use discussion with users.

We use discussion with users and record them in Minutes of Meeting (MoM)

Users are ‘the king’. What we do is we facilitate a meeting between users if there are different needs or conflicts.

First we make the same perception on problem statement, then we see if the problem domain exist in users perspective or it is in the developer’s perspective. The matters on how we look the conflicts and to the problems.

Majority respondents said the discussion method is used for negotiation purpose, while respondent 5 use a viewpoint method.

16

What tools do you use to find conflicts and overlaps in the requirements? For example with the requirement matrix.

RE Practice

No, we don’t have a specific tool. Because our project mostly based on ‘IT follow business’ term unless we buy a package software, then it would be ‘business follow IT’.

We use presentation about solution plan to the users

No specific tool, but we discuss with users if there are conflicts and we use requirements checklist if things get complicated and overlaps with other requirements

We use a workshop. Usually all stakeholders are there and therefore redeem the conflicts.

No there is no specific tools. But we use traditional ways like negotiation, meeting or escalate problems into higher level management

There is no specific tool for accommodate conflict and overlaps, while one said workshop is the best method to redeem conclict because all stakeholders are present and discuss the conflicts.

17

Do you have software requirements standard (SRS) templates / documents for describing requirements?

RE Practice

Yes, we have a standard template in organization called P3SA.



Yes, we have a standard template in organization.

Yes, we have a standard template in organization.

All respondents said they have a standard SRS template based on own organization format.

81

18

Do you have guidelines how to write requirements?

RE Practice Yes, we have Yes, the guidelines refers to P3SA

Yes, the guidelines refers to P3SA

Yes, the guidelines refers best practice framework, in this case, we use Rational Unified Process framework.

Yes, but the guidelines only on high level terms

All respondents said they have a guidelines to write requirements document.

19

What approach are you using/did you use in analysis and modelling the software requirements?

RE Practice

We use narration approach because it easier to understand by users

We use checklist and mock up so that users understand look and feel of the proposed solution

We use standard input-process-output methodology, no particular modelling is used

We use a use-case for application which involved a lot interaction/transaction, and we use ERD for application in category of data management in the like of EDW and Business Intelligence

We don’t have specific method in analysis and modelling the software requirements. Mostly we only use our own judgement.

The respondents answer varied in this questions. This give us insight that there are no standard approach in analysis and modelling requirements.

20

Do you check that requirements document meets your standards?

RE Practice Yes

Yes, usually we focus checking on the filled requirements on the template

Yes

Yes, it is part of quality assurance (QA) of the requirements

Yes, as our early reference, although it is very high level

All respondents said they check requirements according organization's standard.

21

Do you define validation checklists to focus the validation process? Do you organize formal requirements inspections?

RE Practice

Yes, the requirement is validated by a forum called FMSI

Yes, we have SRS validation forum called FTTI that validate technical requirements and FMSI that validate management and policy requirements

Yes, usually we validate them at system design forum, which the output is final design documentation

Yes, we once have a formal validation. But now as developer, the validation is not formal.

Yes, we have formal document validation, but no specific forum to discuss requirements validation.

All respondents said they have validation process in requirements activities.

22

Do you conduct UAT based on the user requirements?

RE Practice Yes Yes Yes Yes

Yes, UAT made based on user requirements specification

All respondents said they conduct UAT based on user requirements. This gives us insight that they all aware of traceability requirement practice.

82

23

Do you have defined policies for requirements management?

RE Practice

No particular policy, but we only realign the requirements through business strategic forum

Yes, P3SA and P2SA. We use P3SA for new development and P2SA for change requirements on existing software. Beside that we have insource, outsource, join development also buy a package software or build custom software policy.

Yes, we have a policy that all software development must be approve in technical forum and finally agree by management in management forum

Yes, we have a standard procedure for requirement management for example templates, document standard, document guidance, models used in the RE.

I don’t know exactly, but as far as I know the department gathered all users from other department in early phase of software development, and then discusses various need of information system. In this forum, all requirements proposal is assessed by some kind of calculation. If they meet certain criteria, then it will be new project, otherwise it will suspended or even rejected.

3 respondents said they have policy for requirement management.

24

Do you check every development items with requirements items?

RE Practice Yes

No, not every items of development is checked with requirements items

Yes, with checklist

Yes Yes, we must

Majority respondents (4/5) said they check requirement items with development items. This also gives us insight that they all aware of traceability requirement practice.

25 Do you define traceability policies?

RE Practice No Yes, we use traceability matrices

No

No specific traceability policies. We do programming based on design document, and design document is made based on user requirements and all requirements check by users in UAT.

No specific traceability policies. We do make comparison between the document design and application whether they match or not.

Surprisingly, although they have practice the traceability practice but no formal tracebility policy is defined

26

Do you use a database to manage requirements?

RE Practice No Yes, we use BPM software

No

No, we use only word processing and software for modelling

No, we don’t use a database or a software tool.

Majority respondents(4/5) said the they do not have a particular database to record past requirements. But one respondents said he try BPM software to store past requirements.

83

27

Do you define change management policies?

RE Practice

Yes, every change must follow a clear business need

Yes, It is governed in P2SA

Yes, with change’s requirement form

Yes, but with strict condition. If there are requirements changes the procedure is very strict because the cost and timing of the project.

Yes, in formal, user must submit a formal letter contains change requirements plan and it reasons. And then we discuss the possible project with consequences like duration, cost and man power involved.

All respondents said they have change management policies.

28 How do you identify volatile requirements?

RE Practice

We identify through the business process that usually changes

We identify through the use parameter in the requirements, so we utilize requirements change by variable changes. Furthermore we use master data management, flexibility on user management, also formula/calculation parameterization

We identify through a signed change’s requirement form

Actually there is agile methodology which fit with volatile requirements in particular data warehousing and business intelligence project. But unfortunately our organization is yet adapted agile methodology. The reason behind this is because mostly the projects are outsource and under contract so it will implicate moral hazard to the project if we use agile methodology. However, if we insource this is different case, we can use agile methodology.

It is hard to identify volatile requirements. Normally what we do is to make a deadline for user to submit final user requirement specification. This document is used as guideline to make design document. If there is change in this phase, it is only allowing minor changes that not affect project plan.

This question give insight on how respondent identify volatile requirements. Respondent 1 said investigate business process to identify volatile requirements. Respondent 2 said he using parameters, Respondent 3 through standart change form, Respondent 4 concern with SDLC methodology and finally Respondent 5 has no specific method.

29 Do you reuse requirements over different projects?

RE Practice

Yes, we do this to obtain gaps in the requirements

Yes, for example we apply reuse requirements on user management requirements

Yes, for example we apply reuse requirements on validation rules over previous project

In concept we do, but it is not formally supported by framework, methodology and tools. For example, for data requirements it has more chance it will repeat in the future, so we can use the previous data model.

Yes, as additional references. For example we use asset software development as our first reference if there is the same requirement in the future.

All respondents said they reuse requirements if any.

84

30

List top three of problems and their solutions of RE activities in in your organization.

RE Problems and Solutions

First, users cannot explain clearly the problems in the requirements, Second, users doesn’t know what their need, Third, users cannot detail their requirements. Analyze the problems, giving alternatives, if these are not working well, we will use prototypes.

First, requirements that are not clear, Second, requirements that are not fixed, Third, requirements that are highly volatile. We use a mixed solutions of brainstorming, interview, mock up(prototype), DFD/flowchart and if necessary BPM (Business Process Management) method

First problem is user does not know their precise need, the solution is we make intensive meetings with users to gather more detail requirements, Second problem is user does not know how to translate business need into information system language, the solution is we make prototype or mock up over system that we want to build in order to confirm system description Third problem is the requirements are highly volatile; the solution is to limit development scope in order to gain clear understanding of the system goal and motivation

Problem number one: users are not always understood and firm with their requirements. The solution is we use prototyping in this case. Problem number two: key users dependence, there is a limitation to key business person on certain business area, which make difficult to track requirements while in UAT. The solution is we involve many key persons as much as person, in order to eliminate on certain number of people dependence. Problem number three: it is involved with our system/business analyst capability. The solution is we do rotation/mutation on certain staffs. The other solution is we make ‘a pair programs’ with other analyst who more capable and experience, which can be a mentor by other analyst.

First, the requirements did not trigger from business need, but mostly based on user intention with no business need, the solution we reject the latter type project in proposal forum meeting. Second, sometimes users don’t have a clear business process. Therefore their requirements are vague, need to be clarified first. The solution we need a firm guideline about business case or documentation or an expert in the field so that it confirm a clear business process. Third, in our IT skill we don’t have enough technical capability in requirement engineering. The person that involved in RE should be understanding business very well so that it avoids misunderstanding with users. The solution is we should have a training or certification on requirement engineering field.

This question give insight on how respondents respond with problems in RE activities. All main problem in RE is that users did not have a clear understanding to define their requirements, therefore user requirements deepening or requirements process iteration is very important to produce a high quality SRS document as the bassis of software development.

85

31

What do you do if there is a communication/coordination problem with the users?

RE Problems and Solutions

If there is no decision upon problems in the requirements, we usually called the management to carry out solution

We refine requirements along with customers and lots of discussion

We make a particular discussion forum, if the problems persist we escalate them to management

First, we identify problems statement, second we do clarification and third we do correction in particular if mistakes or problems are from our side. Four, if the problems persist we escalate to senior management to find solution.

Users should know what the requirements based on real business needs; otherwise the proposal requirement is rejected.

Although the answers are varied, but if they have a communication deadlock, they asked higher management to solve communication problems.

32

How long (in total percentage) do RE activities take in the development phase?

Closure Approximately 20%

40% More or less about 30%

20-25% Usually 20%

Based on the respondents answers, they have spend more or less spend 30% in RE activities among other phases in software development

33

What tool do you use to gather requirements? (for example MS Word/Excel/a particular software)

Closure word dan visio

We use MS Word for now, but we plan on using BPM software

We use MS Word

We use MS Word, Excel, Powerpoint also Visio

We use MS Word and Excel

MS Word is clearly the tool used for gathering requirements

34

How important do you think RE is in your development project? (On scale 1 to 5 most important)

Closure

5, because the clear requirements will determine its duration and quality

5, because the efficient and effectivity process and the compliance with best practices on RE (cause a quality development project)

5, in my opinion lot of software failures happens because the inconsistency, incomplete, and incorrect of requirements specification

5, It is very important because a mistake in this phase could affect into next phases in software development, even though is not all requirements should be clear in the beginning. In this case, we can employ agile methodology, although our organization is not adopting it yet. Iterative requirements are possible, started with requirements defined by grand design architecture in the organization, where small requirements changes are not affect the whole software development could be accommodate in certain times.

5, because failure in defining the requirements it have the ‘domino’ impact to later phases in software development project.

All respondents said RE is very important (5). This question is aim to get respondent motivation in conducting RE. Most of them agree that the clear requirements produce a better quality of software development. Although it is not the only factor of software development success, but it clearly has significant contribution to a successful software development.

86

General remarks:

1. Average duration of interview is 53 minutes, where the shortest is 32 minutes to the longest is 75 minutes, out of 34 questions

2. From total of 20 questions of RE Practices, the respondents have already done of 16 RE practices (the green ones) or is about 80%. This is a high RE practice result for a local organization

3. Overall, the result of the pilot test is successful, although for real interview, some type of questions (yes/no) should be change into more how to/why/what type of questions in order to gain more insights from the interviewee

Thus, from these interviews, we gain useful insights of RE practice in a local organization.

C. Public Survey Audience’s Profile