Remote and Collaborative Software Development Projects: A

Requirements Elicitation Exploratory Study

Alexandre Grotta

1,2 a

and Edmir Parada Vasques Prado

IS Post-graduation Program (PPgSI), University of São Paulo (USP), São Paulo, Brazil

IS Graduation Program, Federal Institute of São Paulo (IFSP), São Paulo, Brazil

Keywords: Virtual Projects, Software Development, Requirements Elicitation.

Abstract: Remote and collaborative software development (RCSD) projects are gaining more relevance in the actual

information technology (IT) industry. RCSD projects may carry many benefits, such as economic, velocity,

and flexibility impacts to an IS project. Anyhow, RCSD might be complex, due to the team’s geographic

distribution, the issues of remote interactions, and other issues that might impact RCSD projects. One of the

first aspects to be affected in RCSD is the software requirements given they are often at the project beginning.

In this context, this research aims to analyse the factors that impact functional and non-functional

requirements in RCSD projects. For this objective, we choose a case study with 59 participants that formed

11 teams of software development. As result, we find that, in this research context, three factors of those six

had a positive association with the quality of RE. They are skills in software development, techniques of

software development, and tools (adequate selection and usage). These finds are in line with the literature

based on the triad People-Process-Tools. Our finds aim to contribute to the project management and software

engineering theoretical bases relevant parts, mainly RE success factors, team management, and projects.

1 INTRODUCTION

The Software development process is no longer

solitary or single-person-centered. Instead, it has been

recognized as a collaborative process, where artifacts

are shared constantly. This new paradigm has been

named the remote and collaborative software

development (RCSD) process. In RCSD, cooperation

allows teams to better understand the information

system (IS) and its requirements, such as functional

and usability requirements. (Gallardo-López et al.

2016). However, new challenges impact distributed

IS projects when this collaboration gains large scale,

such as internationally distributed projects (Yadav,

2016).

RCSD projects are relevant because of many

benefits, such as economic, velocity, and flexibility

gains, although distribute projects might be complex.

These benefits were most notably seen during the

2019-2021 pandemic period when the workforce had

to quickly switch to a remote work environment

(Stechert 2021). Many IS teams move forward to

https://orcid.org/0000-0003-2549-138X

https://orcid.org/0000-0002-3505-6122

adopt the Agile development approach, even if they

have not been adopted before. The hybrid approach

also gained more momentum, given many project

teams could work remotely, with no major quality

impacts compared to the other alternatives then

(Marek, Wińska & Dąbrowski 2021). On the other

hand, Agile teams were thought to share physical

environments. But when these projects are distributed

among different places or regions, part of the teams’

bounds are damaged (Stechert, 2021).

The remote environment challenges start to affect

the project from its beginning. Requirements

elicitation (RE) is one of the first aspects to be

affected by a remote environment. Even before

starting the software development phase as many

project members might believe (Babar, Bunker, &

Gill, 2018). RE might be defined as the discovery,

gathering, and dissemination of user needs (Alexa e

Avasilcai, 2018). Thus, one of the major flaws in

software projects is related to incorrect and

incomplete RE (Mishra, Mishra & Yazici, 2008). In

this context, this research aims to analyse the factors

Grotta, A. and Prado, E.

Remote and Collaborative Software Development Projects: A Requirements Elicitation Exploratory Study.

DOI: 10.5220/0011812400003467

In Proceedings of the 25th International Conference on Enterprise Information Systems (ICEIS 2023) - Volume 2, pages 117-125

ISBN: 978-989-758-648-4; ISSN: 2184-4992

 2023 by SCITEPRESS – Science and Technology Publications, Lda. Under CC license (CC BY-NC-ND 4.0)

117

that influence RCSD within virtual project teams.

This main objective was narrowed down into two

specific objectives: i) to identify factors that influence

RE in virtual DCS projects with an agile approach,

and ii) to analyse the influence these factors apply to

the requirements quality. To perform this analysis, we

investigated virtual teams which applied the Agile

approach and the RCSD and that carried out RE

activities.

2 THEORETICAL BASES

In this section, we detail two relevant concepts for

this research. First, we define and classify the RE. We

then detail RCSD.

2.1 Requirements Elicitation (RE)

In traditional (waterfall) software development

projects, RE must be performed at the initial stage of

software development, and all requirements must be

gathered and correctly documented. However, in a

constantly evolving environment like the actual one,

requirements also change frequently, including

during the development phase. Traditional

methodologies might be difficult to be applied in a

constantly changing environment. Thus, agile

methodologies can improve the software

development process by being more flexible to

accommodate software requirements changes and

this is one of the main reasons agile methodologies

are chosen for remote and RCSD environments

(Batool et al., 2013; Curcio et al., 2018).

The RE is often described as the initial phase of

the software life cycle and it is considered the most

critical and complex phase of a software project

(Pandey, Suman, & Ramani, 2010; Fernandes et al.,

2012; Buitron, Flores-Rios, & Pino, 2018). RE

success is considered a prerequisite for software

success, given RE delineates both the system’s needs

and its limitations, via communication with

stakeholders (Curcio et al., 2018).

A common categorizing approach is to split

requirements as functional requirements or non-

functional requirements (Pandey, Suman e Ramani,

2010), as follows:

Functional Requirements (FR). They express

the users’ needs and the activities the software must

perform, except those considered by the limitations.

(Buitron, Flores-Rios, & Pino, 2018).

Non-Functional Requirements (NR). The NFs

limit software behavior through software-specific

attributes, such as software security mechanisms,

software distribution type, and software usage

licenses (Younas et al., 2017). NFs are important

parts such as technology selection, hardware

allocation, and software development standards

(Younas et al., 2017; Buitron, Flores-Rios, and Pinto,

2018)).

2.2 Collaborative Software

Development (RCSD)

To detail the RCSD, we narrowed it down into three

dimensions (Sardjono, Retnowardhani, & Budianto,

2021): people, processes, and technologies.

People. People is a dimension that may embrace

many factors of human beings. For this research, we

choose the factors ‘motivation’ and ‘learning

capability’, for reasons detailed as follows.

Motivation is a critical factor for the success of a

project given unmotivated people tend not to be

engaged in project activities. On the other hand,

project team members might be motivated mainly by

two different motivation dimensions (Sardjono,

Retnowardhani, & Budianto, 2021) expect internal

rewards, such as developing his/her capabilities, and

feel internally a sense of being able to. Extrinsically

motivated team members might be interested in

external rewards, such as financial rewards, the need

for relations, or family and friends needs (Melo et al.,

2011). Therefore, some behavioral attitudes may

express positive team member motivation, such as

delivering on time (punctuality) and delivering

frequently (Grotta & Prado, 2021). Motivation is a

critical factor for the success of a project given that

team motivation reflects on customer benefits (Melo

et al., 2011).

Team members’ learning capability is another

relevant factor. Given the constant changes in the

environment and technology, both self-directed and

collaborative learning as necessary skills for software

development project members (Intayoad, 2014).

Process. We choose two of the available factors

for the software development process –

communication and RE techniques – for the

following reasons. First, communication directs the

collaborative interaction patterns in global software

development teams. Both the communication mode

and task type influence communication patterns

(Serce et al., 2011). Thus, communication influences

directly or indirectly the outcome of a project, which

can be positive or negative outcomes. It includes

conflict communication (Marshall and Gamble,

2015). The communication type to deal with

interpersonal conflicts is highly related to RE

outcomes (Liu et al., 2011).

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

118

The second factor is RE techniques. More

specifically, this factor directly influences RE. Thus,

different RE techniques might or might be

appropriate in certain RE contexts (Alflen, Prado &

Grotta, 2021).

Technology. This dimension relates to the IT

resources of virtual DCS projects. There is a

framework to analyse RCSD teams. It allows a

unified view of how the stakeholders’

communications occur by the means of the

technology and how technology is used. The

technologies scaffold the teams’ communication

given communication, as presented, is a critical factor

in this type of project (L'Erario et al., 2020). The

communication success/ effectiveness of

geographically distributed teams is also related to the

ability of team members to use and collaborate with

the technology (Serce et al., 2011).

3 RESEARCH METHODOLOGY

This research aims to explore the factors that

influence the quality of requirements in virtual DCS

projects with an agile approach. Therefore, this is an

exploratory study that may offer more information

about the study object and scaffold the formulation of

hypotheses for future research (Creswell & Creswell,

2021).

We adopted the case study as defined by

(Eisenhardt, 1989), given the case study allows the

researcher to respond flexibly to new findings when

collecting primary data. In this research, for

confidentiality reasons, the organization and the

participants were anonymized. However, all other

relevant information is presented.

3.1 Research Propositions

The research propositions are grouped according to

the three dimensions detailed in the Theoretical Basis

Section. In summary, we choose three dimensions,

according to Figure 1 as follows, that resulted in six

research propositions:

Dimension 1 – People dimension represents the

characteristics of RCSD teams:

P1: Teams with higher motivation produce RE

with better quality in DCS projects.

P2: Teams with better software development

skills produce RE with better quality in DCS

projects.

Dimension 2 – Process dimension represents the

characteristics of RE processes:

P3: Teams with a better level of communication

in software development processes produce RE

with better quality in DCS projects.

P4: Teams that do the most proper use of ER

techniques produce RE with better quality in

DCS projects.

Dimension 3 – Resources dimension represents the

technological resources used by team members:

P5: Teams with better IT infrastructure

resources produce RE with better quality in DCS

projects.

P6: Teams with better use of collaboration tools

produce RE with better quality in DCS projects.

These propositions aim to establish the relationships

between the research variables. The variables were

divided into two categories, as detailed in the next

Subsections: independent variables (3.2) and

dependent variables (3.3).

3.2 Independent Variables

This research model is based on (Creswell &

Creswell, 2021). It has six independent variables.

Three variables were evaluated at the individual level:

Motivation (V1), Skills (V2), and Communication

(v3). The other three variables were evaluated at the

group level: the usage of RE techniques (V4), IT

Infrastructure (V5), and Project Tools (V6).

● Motivation (V1). This variable refers to the

team's motivation specifically in the RE process. The

motivation level of each team member was defined

based on two criteria – attendance, punctuality, and

self-assessment, which were done via a questionnaire.

The composition of these three indicators defined a

rational variable ranging from zero to 10. Team

motivation was calculated from the arithmetic mean

of team members' motivations.

● Skill (V2). This variable represents the skill of

each team member in the software development

activity. This ability was measured by academic

grades obtained in disciplines related to software

development. This variable is of the rational type

ranging from zero to 10. The team's ability was

calculated as the arithmetic mean of the team

members' abilities.

● Communication (V3). This variable measures

the quality of communication between the team

members and the customer in the RE process. The

communication level of each team member was

defined based on their participation and interactions

with the group. It was assessed by an individual

questionnaire. The composition of these two

indicators defined a rational type of variable ranging

from zero to 10.

Remote and Collaborative Software Development Projects: A Requirements Elicitation Exploratory Study

119

Figure 1: Research Propositions.

The team communication level was calculated as

the arithmetic mean of the team members'

communication levels. The other three independent

variables were evaluated at the team level only. They

are detailed as follows:

● RE Techniques (V4). It represents the proper

usage of RE techniques. A five-point Likert-type

ordinal scale was defined: 1 - very low; 2 - low; 3 -

medium; 4 - high; 5 - very high. The top three most

cited RE techniques were: interviewing,

brainstorming, and prototyping.

● Infrastructure (V5). It represents the low-level

infrastructure that is represented by both hardware

and internet connection capabilities. It was assessed

by the same Likert scale as presented in V4.

● Tools (V6). This variable represents the

appropriate usage of collaboration tools (software) by

the team. There was an ordinal three levels scale as

follows: no collaboration tools; inappropriate

collaboration tools; or proper collaboration tools.

3.3 Dependent Variables

As seen in Figure 1, the research proposition has two

dependent variables as follows:

● FR Quality (V7). It refers to the functional

requirements quality. It was measured by a prototype

presentation, versus the client's requirements. To

measure this variable, a three-level ordinal scale was

defined as follows: level 0, low RE quality (33% of

the FR, or less) was fully achieved; level 1, medium

RE quality (more than 36% and less than 66% of the

FR) were elicited with completeness and consistency;

and level 2, high-quality RE (more than 66% of the

FR) were elicited correctly.

● NR Quality (V8). It refers to the non-functional

requirements quality and we utilized the same scale

as we did in V7 but for NR.

3.4 Case Study Protocol

This Subsection details the case study protocol into

eight steps, and its intermediary steps, from i) data

collection policies to vii) data analysis procedures, as

follows:

i) Data Collection Policies. The data collection

policies were limited by the research objectives,

propositions, and evidence sources, including those

that support the threats to validity and conclusions.

ii) Data Source. This research collected three

sources of evidence: observation carried out in

meetings to follow up on the RE work of a DCS

project; a questionnaire applied to team members; and

a prototype of the software delivered by the teams.

Data were collected from four different sources, to

allow verification of evidence employing

triangulation, according to (Yin, 2010):

iii) Participants. The case study was conducted

in the first semester of 2022, with students of an IS

undergraduate course. A total of 61 students

participated in this study thought an entire semester.

Beyond the course knowledge, many of the students

also had work experience (previous or in progress).

iv) Data Sources. Data were collected based on

the survey variables. Data were collected in the first

half of 2022. One data source could be related to one

or more research variables, as shown in Table 1.

Table 1: Data sources by variables.

ID Variable Type* Data Source

V1 Motivation I Quiz

V2 Skills I Grades

V3 Communication I Interactions

V4 Techniques I Interactions

V5 Infrastructure I Interactions

V6 Tools I Interactions

V7 FR quality D Prototype

V8 NF quality D Prototype

* Variables: (I) - Independent or (D) - Dependent

v) Participants’ Objective. To observe the

phenomenon of RE, the students were grouped into

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

120

teams. Each group had the main objective as follows:

to elicit the system requirements and then to produce

and present a working prototype.

vi) Influence of the Researcher. All projects

were developed using RCSD. Beyond the

observation, the researcher also played the role of

product owner, which is the person in charge of

defining product requirements for the development

team.

vii) Data Analysis Procedures. The most

relevant interactions were recorded and then

transcribed into text. These results allowed the

analysis of the group members' discourse via a

semantic content analysis (Bardin, 2011).

Questionnaire data and grades were analyzed using

descriptive statistics. Finally, the researcher – in the

role of Product Owner – analyzed all prototypes and

compared the results obtained by the teams regarding

RE deliveries compared to their original definition.

4 RESULTS

In this Section, we first contextualize the case study.

We then present the results outline. Finally, presents

the evaluation of research propositions with data

grouped by teams’ results, as seen in Table 2:

4.1 Context of the Case Study

This case study was conducted in the first semester of

2022. The IS undergraduate program has a minimum

duration of four years. It is in the São Paulo state,

Brazil. The select course of that program was from

the 7

semester, thus those students were considered

Seniors. The course was mainly offered during the

night period. Therefore, many students were working

during the day, such as internships or full job

contracts.

In this research, we tried to keep as much as

possible the same conditions for all participants for

the same context, as follows: (i) the requirements

were presented to the teams in the same manner; (ii)

the researcher conducted the same activities for all

teams; (iii) the duration of the activities was the same

for all teams, divided into four interactions; (iv) the

evaluation was the same for all teams.

A total of 59 students formed eleven teams for the

software development project, according to Table 2.

Each team worked on one single academic only. This

case study was focused on observing the students and

their projects. The semester project was first divided

into two phases: first, perform the requirements

elicitation; second, produce and present a project, and

Table 2: Motivation, Skills, and Communication.

Team

Members M H C Members M H C Members M H C

E1 8,3 5,1 5,3 M01 9,0 6,0 6,2 M03 8,0 6,0 4,8 M05 7,4 6,0 3,4

M02 8,0 5,0 4,8 M04 8,8 3,5 6,2 M06 8,5 4,0 6,2

E2 6,9 4,4 6,0 M07 7,4 4,5 7,6 M09 6,9 4,0 6,2 M11 6,9 3,0 6,2

M08 6,9 5,5 6,2 M10 5,6 4,3 2,0 M12 7,4 5,0 7,6

E3 8,3 7,2 5,9 M13 9,0 9,0 7,6 M15 8,8 7,5 7,6 M17 6,9 7,5 2,0

M14 8,0 4,5 4,8 M16 9,0 7,5 7,6

E4 7,1 8,3 6,4 M18 7,4 8,5 7,6 M20 6,6 10,0 4,8 M22 6,9 6,0 6,2

M19 7,4 8,0 7,6 M21 6,9 9,5 6,2 M23 7,4 8,0 6,2

E5 8,7 6,1 8,2 M24 9,0 6,5 9,0 M26 8,5 5,5 7,6 M28 8,5 6,5 7,6

M25 9,0 6,0 9,0 M27 8,5 6,0 7,6

E6 4,0 9,4 6,8 M29 4,0 9,0 6,2 M31 4,1 9,5 7,6 M33 3,6 9,5 4,8

M30 4,1 9,5 7,6 M32 4,1 9,5 7,6

E7 2,3 5,3 5,7 M34 2,3 4,5 6,2 M36 2,0 7,0 2,0 M38 2,5 4,0 7,6

M35 2,3 5,0 4,8 M37 2,3 5,5 6,2 M39 2,5 5,5 7,6

E8 3,9 8,3 6,9 M40 4,1 8,0 9,0 M42 4,0 9,0 7,6 M44 3,3 9,0 2,0

M41 4,1 8,5 9,0 M43 4,1 9,5 9,0 M45 3,5 6,0 4,8

E9 2,4 5,2 7,6 M46 2,5 5,5 7,6 M47 2,5 4,0 9,0 M48 2,3 6,0 6,2

E10 8,7 6,6 6,8 M49 9,0 8,0 7,6 M51 9,0 7,0 7,6 M53 8,5 5,5 6,2

M50 8,0 4,1 4,8 M52 9,0 8,5 7,6

E11 2,3 6,7 5,3 M54 2,3 7,5 4,8 M56 2,2 3,5 3,4 M58 2,5 7,0 7,6

M55 2,3 7,5 6,2 M57 2,3 6,5 4,8 M59 2,3 8,0 4,8

Legend: (1) Team average; (2) Motivation; (3) Skill; (4) Communication

Remote and Collaborative Software Development Projects: A Requirements Elicitation Exploratory Study

121

review requirements whenever necessary. In the first

interaction with the class, the teams were formed, and

the main activities and deliverables were planned. All

team members were very engaged. Although before

the end of the semester, two students dropped their

course enrollment, thus they are not listed in Table 2.

4.2 Results Outline

As seen in Table 2, the variable motivation was the

one that had both the lowest average and the highest

difference among the teams. The mean of the teams

was 5.7 with a standard deviation of 2.7. According

to Mukaka (2012), the preliminary data analysis

showed three variables were positively aligned with

the RE: skills, techniques, and tools. This is because

the teams that stood out in the RE were also superior

in these three variables. Furthermore, these three

variables indicated a correlation with the FR and NR,

because as their level grows, the quality level of FR

and NR also grows. We then verified the correlation

between independent and dependent variables via

Spearman's correlation as shown in Table 3.

Table 3: Variables Spearman Correlation.

Dimensions P

Variables

Independents Dependents

FR* NF*

People

P1 Motivation 0,545 0,145

P2 Skills 0,945 0,6

Process

P3 Communication 0,4 0,173

P4 Techniques 0,8 0,455

Tools

P5 Infrastructure 0,6 0,291

P6 Tools 0,836 0,409

* Bold=Strong or Very Strong Correlation;

Italic = moderate Correlation

Positive associations between independent and

dependent variables were those with strong or very

strong correlations, as shown in Table 3. According

to Mukaka (2012), values between 0 and 0.3 represent

negligible correlations, between 0.31 and 0.5 weak,

between 0.51 and 0.7 moderate, between 0.71 and 0.9

strong, and 0.9 or greater represent very strong. We

highlight the four independent variables that had in

Table 3 strong and/or moderate correlation with the

dependent variable, as follows:

● Skills had the strongest positive association

with FR (very strong) and the NF (moderate)

requirements. This indicates that the teams’ skills

were the most relevant independent variable to be

considered for the elicitation of requirements.

● Tools; Techniques: A strong level of

correlation was found for both tools and techniques

independent variables. This indicates that, beyond the

skills, Teams also need to select and have access to

the appropriate tools, while they also had to utilize the

most appropriate techniques, towards achieving FR

needs.

● Infrastructures: Finally, this independent

variable was the only one to have a moderate

correlation with FR. Thus, in this research context,

the availability of good infrastructure, if not all, at

least in parts affects the quality of the final FR.

4.3 Research Propositions Evaluation

Finally, table 4 summarizes the tests of research

propositions by grouping the data by teams. The top

performers’ teams were E3, E6, E7, and E8, which

represent 30.8% of the teams. They elicited

requirements with a good level of completeness and

consistency. These teams scored an average of 8.8 on

the ER. The top performers were superior to the other

teams concerning three variables: skills, techniques,

and tools.

The average performers teams E1, E2, E4, E5 and

E10. These teams scored an average of 5.0 on the ER.

Finally, teams E9 and E11 had an unsatisfactory

performance, given they scored less than 2.5 for FR

and zero for the NR requirements. This indicates that

the motivation was very different among the teams.

On the other hand, the variable communication and

skills had a higher average when compared to the

motivation. They also had fewer standard deviations.

5 DISCUSSIONS

In this Section, we first perform an analysis of the

propositions, followed by a description of the

research limitations.

5.1 Analysis of the Propositions

To research validity, we choose to state as a

confirmed proposition only those that have a strong

or very strong Spearman Correlation, as described in

Table 2. Thus, we could confirm propositions P2

(Skills), P4 (Techniques), and P5 (Tools) regarding

FR. On the other hand, we could not confirm any

proposition regarding NR. Most importantly, each

confirmed proposition belongs to one specific

dimension, from where we can state all three

dimensions influence FR, as described in the

theoretical bases of this research. The result confirms

the validity of the people-process-technology

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

122

Table 4: Evaluation of Research Propositions by Teams.

Teams Motivation Skills Communication Techni

ues Infrastructure Tools F

Qualit

E3 8,3 7,2 5,9 5 4 1 2 2

Superior

E8 3,9 8,3 6,9 5 5 2 2 2

E6 4 9,4 6,8 5 4 2 2 1

E7 2,3 5,3 5,7 4 4 1 1 2

4,6 7,6 6,3 9,5 8,5 7,5 8,8 8,8

E1 8,3 5,1 5,3 5 5 1 1 1

Average

E2 6,9 4,4 6 4 5 2 1 1

E4 7,1 8,3 6,4 5 4 1 1 1

E5 8,7 6,1 8,2 5 5 1 1 1

E10 8,7 6,6 6,8 4 4 1 1 1

7,9 6,1 6,5 9,2 9,2 6 5 5

E11 2,3 6,7 5,3 5 2 1 1 0

Unsatisfactory

E9 2,4 5,2 7,6 2 4 1 0 0

2,4 6 6,5 7 6 5 2,5 0

structure, often applied in IS system development, as

presented in the theoretical basis of this research.

People. This dimension is composed of two

propositions: P1 and P2. Although the first one,

motivation, was not verified, the second one, skills,

was verified (with a very strong correlation). This

result is in line with Intayoad (2014), which states

‘skills’ is an important attribute for professional

success. In the context of this research, professional

skills were highly relevant for RE success.

Process. This dimension is composed of two

propositions: P3 and P4. Although the first dimension

(communication) was not verified, the second one

(techniques) was verified. Proposition P4 associates

the adequate use of RE techniques with the

improvement of the quality of the RE and it was

verified as described in Table 1.

Resource Dimension. This dimension is

composed of two propositions: P5 and P6. Similarly,

from the other two dimensions, only one was

considered valid. This means that hardware

technological resources were not associated with

better RE quality. On the other hand, proposition P6

(tools) had a strong correlation with FR elicitation.

This result is in line with the work by Serçe et al.

(2011), who argue that the success and effectiveness

of geographically distributed teams are more

sensitive to the ability of team members to use these

tools and technology to collaborate. In other words,

our findings suggest that the ability to use

collaboration tools improves the quality of RE in

virtual DCS projects.

5.2 Research Limitations

The research limitations were assessed according to

(Yin, 2010). We identified and safeguarded against

three limitations at least, as follows.

Data Collection Process: we considered the

research bias in the observations or interpretation of

team members’ data; for this limitation, the

researcher was an expert in its area, which decreased

that bias.

Generalization of Results: we highlight that it is

not possible to generalize our results, given this is a

single-shot case study. Anyhow, case studies support

other future research, in this case, the knowledge of

the factors that influence the quality of RE.

Data Analysis: Data were collected through

interactions conducted by the researcher. But at least

one other researcher supported the interpretation of

the participants’ results to avoid any biased from the

observation process. Lastly, to avoid participants’

negative selves-influence, inter or intra-group, all

results were assessed against plagiarism, and

participants were stimulated to do fair play.

6 CONCLUSIONS

The objective of this research was to analyse the

interaction of IS teams working remotely in

collaborative software development (RCSD)

projects. For this objective, we conducted a case

study with 59 participants divided into 11 teams. In

conclusion:

Research Objectives. Recovering that the main

objective of this research was to analyse the factors

that influence RCSD within virtual project teams. The

first specific objective was to identify factors that

influence RE in virtual DCS projects with an agile

approach. We identified six factors that were

categorized into three dimensions. The specific

objective was to analyse the influence these factors

apply to the requirements quality. In this research

context, three of six factors had a positive association

with the quality of RE: skills [in software

Remote and Collaborative Software Development Projects: A Requirements Elicitation Exploratory Study

123

development], techniques [of software development],

and tools [adequate selection and usage of].

Practical and Theoretical Contribution. This

research contributes to the RCSD practices in remote,

virtual, and/or distant working environments. We

present RE success factors in this research context.

Particularly, the team’s most relevant aspect was

‘skills. By using the most appropriate process, the

teams that were able to select and use the most

appropriate were also able to successfully elucidate

and implement software requirements. The research

aims to contribute to the project management and

software engineering theoretical bases. For future

research, we plan to investigate the gap in hybrid

environments.

REFERENCES

Alflen, N. C., Prado, E. P., & Grotta, A. (2020). A Model for

Evaluating Requirements Elicitation

Techniques in

Software Development Projects. In ICEIS (2) (pp. 242-

249).

Alexa, L., & Avasilcai, S. (2018). The requirement

elicitation process of designing a collaborative

environment - the cre@tive.biz case. MATEC Web of

Conferences. doi: 10.1051/matecconf/201818404010

Babar, A., Bunker, D., & Gill, A. (2018). Investigating the

relationship between business analysts’ competency

and requirements elicitation: A thematic-analysis

approach. Communications of the Association for

Information Systems, 42(1), 334–362.

Bardin, L. (2011). Content Analysis. Sao Paulo: Edicoes 70.

Batool, A., Motla, Y., Hamid, B., Asghar, S., Riaz, M.,

Mukhtar, M., & Ahmed, M. (2013). Comparative study

of traditional requirement engineering and agile

requirement engineering. In: 15th International

Conference on Advanced Communications Technology

(ICACT), pp. 1006–1014.

Buitron, S. L., Flores-Rios, B. L., & Pino, F. J. (2018).

Elicitación de requisitos no funcionales basada en la

gestión de conocimiento de los stakeholders. Revista

Chilena de Ingeniería, 26(1), 142–156. doi:

10.4067/S0718-33052018000100142

Creswell, J. W., & J. D. Creswell (2021). Projeto de

pesquisa: métodos qualitativo, quantitativo e misto, 5ª.

ed. Porto Alegre: Penso.

Curcio, K. D. C.; Navarro, T.; Malucelli, A.; Reinehr, S.

(2018). Requirements engineering: a systematic

mapping study in agile software development. v. 139,

01 2018. ISSN 0164-1212.

Eisenhardt, K. M. (1989) Building theories from case study

research. Academy of Management Review. 14(4),

532-550.

Gallardo-López, L. et al. (2016). Collaborative working:

Understanding mobile applications requirements. In:

International Conference on Computational Science

and Computational Intelligence. doi. 10.1109/CSCI.

2015.86

Grotta, A., & Prado, E. P. V. (2021). DevOpsBL: DevOps-

based learning on Information Systems Higher

Education. In 27th Annual Americas Conference on

Information Systems, AMCIS 2021.

Intayoad, W. (2014). PBL framework for enhancing

software development skills: An empirical study for

information technology students. Wireless Personal

Communications, 76(3), 419-433.

Knauss, E., Yussuf, A., Blincoe, K., Damian, D., & Knauss,

A. (2018). Continuous clarification and emergent

requirements flows in open-commercial software

ecosystems. Requirements Engineering, 23(1), 97-117.

doi: 10.1007/s00766-016-0259-1

L’Erario, A., Gonçalves, J. A., Fabri, J. A., Pagotto, T., &

Cunha Palácios, R. H. (2020). CFDSD: a

Communication Framework for Distributed Software

Development. Journal of the Brazilian Computer

Society, 26(1),7.

Liu, J. Y. C., Chen, H. G., Chen, C. C., & Sheu, T. S.

(2011). Relationships among interpersonal conflict,

requirements uncertainty, and software project

performance. International Journal of Project

Management, 29(5) 547-556. doi. 10.1016/j.ijpro

man.2010.04.007

Marshall, A., & Gamble, R. (2015). Gauging influence in

software development teams. In: 2015 IEEE Frontiers

in Education Conference (FIE), El Paso, TX, USA, pp.

1–8.

Marek, K., Wińska, E., & Dąbrowski, W. (2021). The State

of Agile Software Development Teams During the

Covid-19 Pandemic. Lecture Notes in Business

Information Processing, 408, pp. 24-39.

Melo, C., Cruzes, D. S., Kon, F., & Conradi, R. (2011).

Agile team perceptions of productivity factors. In:

IEEE Computer Society, USA, pp. 57–66. ISBN

9780769543703.

Mishra, D., Mishra, A., & Yazici, A. (2008). Successful

requirement elicitation by combining requirement

engineering techniques. In: First International

Conference on the Applications of Digital Information

and Web Technologies (ICADIWT), 2008. pp. 258–263.

Mukaka, M. M. (2012). Statistics corner: A guide to

appropriate use of correlation coefficient in medical

research. Malawi Medical Journal, 24(3), 69-71.

Pandey, D., Suman, U., & Ramani, A. (2010). An effective

requirement engineering process model for software

development and requirements management.

International Conference on Advances in Recent

Technologies in Communication and Computing, p. 287-

291, doi: 10.1109/ARTCom.2010.24

Sardjono, W., Retnowardhani, A., & Budianto, W. (2021).

Development Model of Evaluation of Knowledge

Management Systems Implementation in Government

Organization”. International Conference on Information

Management and Technology (ICIMTech), p. 369-374.

Serçe, F. C. et al (2011). Online collaboration:

Collaborative behaviour patterns and factors affecting

ICEIS 2023 - 25th International Conference on Enterprise Information Systems

124

globally distributed team performance. Computers in

Human Behaviour, 27(1), 490-503.

Stechert, C. (2021). Digital and distributed project

management in mechanical engineering studies - a case

study. Procedia CIRP, 100, pp. 500-505.

Yadav, V. (2016). A Flexible Management Approach for

Globally Distributed Software Projects. Global Journal

of Flexible Systems Management, 17(1), 29-40.

Yin, R. K. (2010). Qualitative Research from Start to

Finish. Guilford Publications, New York, USA.

Younas, M., Jawawi, D., Ghani, I., & Kazmi, R. (2017).

Non-functional requirements elicitation guideline for

agile methods. Journal of Telecommunication,

Electronic and Computer Engineering, 9(1), 137-142.

Remote and Collaborative Software Development Projects: A Requirements Elicitation Exploratory Study

125