Using Combined Techniques for Requirements Elicitation:

A Brazilian Case Study

Naiara C. Alflen

, Ligia C. M. C. Santos

, Edmir P. V. Prado

and Alexandre Grotta

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

Keywords: Requirements Elicitation, Information Systems, Team Participation.

Abstract: Within the requirements engineering domain, requirements elicitation (RE) is one of the most difficult phases.

Towards a successful and high-quality software development process, RE often suffers from information

challenges such as ambiguity, incompleteness, and inconsistent data. Within this context, this research aims

to analyze the contribution of RE combined techniques of both i) the elicitation of functional requirements

(FR), and ii) non-functional requirements (NFR) at an Information Systems Higher Education (IS) course.

Via a systematic literature review (RSL), 61 articles crawled from the Scopus database that meets the RE

search criteria were fully reviewed and finally generated the list of RE. The top three REs (Interview,

Prototyping, and Brainstorming) were then used to support the IS course case study with 56 students. Results

showed that combined FR and NFR techniques improved the RE completeness and consistency when

compared to every single technique isolatedly.

1 INTRODUCTION

Within the software development domain,

requirements engineering is the most complex phase

(Pandey et al., 2010; Fernandes et al., 2012; Buitron,

et al., 2018). Within requirements engineering, the

requirements elicitation (RE) step is dedicated to the

discovery, extraction, and disclosure of users' needs

(Alexa & Avasilcai, 2018). Thus, RE is

understanding the users’ needs.

Nevertheless, RE is a difficult task. It deals with

information ambiguity, incomplete, and inconsistent

data, given requirements are ofter not well-known

before-hand (Vijayan et al., 2016). RE is thus much

more than writing requirements only: it is discovering

and understanding real problems of real-users

(Araújo, Anjos, & Silva, 2015). Thus, problems and

misunderstands needs are ofter one of the main

factors why the projects fail (Gonzales & Leroy,

2011). A common reason for that is because users

have difficulty expressing their requirements

(Nuseibeh & Easterbrook, 2000). These difficulties

usually lead to large faults in software projects such

https://orcid.org/0000-0001-9666-1417

https://orcid.org/0000-0001-5947-4065

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

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

as incomplete and incorrect requirements (Mishra et

al. 2008).

Traditional requirements engineering is often

insufficient for requirements elicitation. They were

not planned for constantly evolving nowadays

environments thus leading to failures in software

development (Knauss et al. 2018). On the other hand,

agile methodologies are suitable for changes in both

requirements and RE process during software

development. Moreover, the agile combination of

several RE techniques can improve the quality of

functional requirements (FR) and non-functional

requirements (NFR) elicitation (Asghar et al., 2017).

Thus, the objective of this research is to analyze

the eliciting process of FR via a combination of both

RE techniques and NFR, by comparing the combined

use of RE techniques when compared to the usage of

every single technique isolated. In addition to the

Section, this research is composed of the following

Section 2, Base Concepts and Research Framework;

Section 3, Research Method; Section 4, Case Study;

Section 5, Results; Section 6, Discussions; and

Section 7, Conclusions.

Alﬂen, N., Santos, L., Prado, E. and Grotta, A.

Using Combined Techniques for Requirements Elicitation: A Brazilian Case Study.

DOI: 10.5220/0010432702410248

In Proceedings of the 23rd International Conference on Enterprise Information Systems (ICEIS 2021) - Volume 2, pages 241-248

ISBN: 978-989-758-509-8

241

2 BASE CONCEPTS AND

RESEARCH FRAMEWORK

2.1 Functional Requirements

FRs describe what software should do, or what it is

expected to do (Dardenne et al., 1993; Alvertis et al.,

2016). In this case, FRs express the users’ needs. RFs

should describe in detail the software functions, with

inputs, outputs, and exceptions. FRs are the activities

that the software must perform without worrying

about real-world physical aspects (Buitron et al.,

2018).

Thus, the RF description must be clear and precise

towards the users’ understanding capacities. FRs

must be easy to understand so that developers can

implement properly implement them. FRs must be

complete and consistent. Completeness is all the

requested services (Boehm, 2000). RFs cannot leave

any doubts or contradiction.

2.2 Non-functional Requirements

NFRs define software operating requirements

(Alvertis et al., 2016). It is an important technology

definition: hardware and software standards (Younas

et al., 2017). The NFRs specify the properties of the

software (Pandey et al., 2010) and software behavior

and its attributes (Buitron et al., 2018), such as

software security mechanisms, distribution, and

licenses (Younas et al., 2017). NFRs describe the

quality of the software thus they can lead to a fail or

success rate to any project (Asghar et al., 2017).

Therefore, quality criteria should be considered an

inseparable part of NFR eliciting process (Younas et

al., 2017).

2.3 Requirements Elicitation

Techniques

The identification of RE techniques was performed

through a systematic literature review (SLR). The

SLR is a method to identify and analyze works

available in the scientific databases and answer

research questions. Kitchenham and Charters (2007)

mention that SLR uses a rigorous, reliable, and

auditable method. We use the protocol proposed by

these authors to perform the SLR. This protocol

establishes strategies for bibliographic research and

the identification and evaluation of articles. The

protocol was carried out in two stages: planning and

selection of articles; and presentation of the SLR

results.

2.3.1 SLR Planning and Selection

The SLR planning consists of two items: definition of

objective and definition of the research protocol. The

objective of this SLR is to identify RE techniques,

and the definition of the protocol was carried out in

three steps presented below:

(1) SLR Question. RE is a topic addressed in

different fields of knowledge and in this research, the

field of software development was specified. Thus,

the question defined for this SLR was: What are the

RE techniques used in software development

projects?

(2) SLR Identification. We use the Scopus

database (https://www.scopus.com), as this database

index works from the ACM Digital Library and

IEEEXplore libraries. The search term used was:

TITLE-ABS-KEY ((“Requirements elicitation” OR

“requirements gathering”) AND (Techniques OR

methods OR procedures OR tools OR artifacts or

specification) AND (software OR system OR

systems)).

(3) SLR Selection Criteria. We adopt

inclusion, exclusion, and quality criteria for the

selection of articles. The works were included in the

research framework when they met the inclusion

criteria but were eliminated from the research

framework when satisfying one of the exclusion

criteria.

2.3.2 SLR Results

The application of the search term in the Scopus

database resulted in 1972 articles. We apply the

inclusion, exclusion, and quality criteria to these

articles, resulting in 61 articles. In most of the works,

we found more than one RE technique. However,

different nomenclatures have been found for similar

techniques, such as the terms “questionary” and

“survey”. We grouped the similar techniques and

forty RE techniques remained. However, five of these

techniques were most frequently cited: interview,

questionnaire, prototyping, use case, and

brainstorming.

We made a comparison between these five

techniques most cited in RSL and the techniques most

frequently used in the business context. The works of

Kassab, Neill, and Laplante (2014) and Todoran et al.

(2013) were used to assess the business context.

Kassab et al. (2014) surveyed companies in 23

countries, and Todoran et al. (2013) conducted an

exploratory study to understand RE in the context of

cloud computing.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

242

We identified three techniques present in both

works and present amongst the five most cited in

RSL:

(1) Interview. The technique most mentioned in

the articles was the interview. It was cited in 45 of the

61 selected articles. Interviews are essential to gather

information for new projects through questions and

answers, in which the information collected is more

in-depth, but involves a limited number of

respondents (Saad & Dawson, 2018). Interviews can

be structured, semi-structured, or unstructured. In

structured interviews, all interviewees are asked

about the same questions, while in unstructured

interviews, the interviewer does not need to follow a

list of questions (Pitula & Radhakrishnan, 2011). In

semi-structured interviews, both situations are

addressed. Semi-structured or unstructured

interviews have the benefit of looking for new and

unexpected ideas (Smith, Strauss & Maher, 2010).

For Gill, Zaidi, and Kiani (2014) the success of this

technique depends on the interviewer's ability to

conduct the interview and collect the requirements.

(2) Prototyping. It is an incomplete version of

the software, which can be either disposable or

evolutionary (Younas et al., 2017). The disposable

prototype is used only to understand the user's

requirements and perception, while the evolutionary

provides a basis for the user's final version. This

technique facilitates user engagement and the early

identification of problems that may affect the

usability of the software (Ramakrishnan et al., 2014).

However, according to Gill et al. (2014), a

disadvantage of this technique is the expenditure of

time and resources.

(3) Brainstorming. It is a way to tune the user's

mind concerning the requirements (Younas et al.,

2017). It is performed in two phases: In the first, ideas

are collected and in the second, discussions about the

collected ideas are carried out (Younas et al., 2017).

This technique is used for the massive collection of

data for further refinement of ideas (Al-Qudah,

Cristea, & Lei, 2013). However, Sadiq et al. (2009)

claim that this technique is not suitable for eliciting

security requirements, that is, it does not provide a

consistent set of security requirements. The user

experience must also be considered for the correct use

of this technique, as users with more experience can

better express their needs. In this case, techniques

such as brainstorming are effective (Mishra et al.,

2018). Another interesting feature of this technique is

the stimulus to creativity. Caleb-Solly et al. (2014)

used brainstorming sessions to stimulate and provoke

ideas amongst the participants and achieved more

creative and unexpected ideas.

2.4 RE Techniques Practice

This section presents some works related to the

combination of RE techniques. Saad and Dawson

(2018) highlighted that the use of only one technique

for RE can result in an inadequate specification,

which affects the quality of the requirements. They

argue that there is a need to combine techniques for

the RE process to be efficient and successful. The

SLR found three studies that addressed the

combination of RE techniques (Fernandes et al.,

2012; Lim & Finkelstein, 2012; Gill et al., 2014).

Fernandes et al. (2012) combined the Six

Thinking Hats technique with the Brainstorming

technique. Six Thinking Hats is a creative thinking

technique, in which each hat is assigned a color: blue,

green, red, yellow, black, and white. The technique

proposes that each person in the group thinks actively

and differently. They concluded that this approach

could improve user engagement in RE.

Lim and Finkelstein (2012) developed a method

(StakeRare) to identify and prioritize software

requirements with a collaborative approach. This

method is developed in four stages: identification and

prioritization of stakeholders based on their influence

on the project; interviews based on the identified

profile, to specify the initial requirements of the

software, carried out using the focus group technique;

RE of each stakeholder based on a collaborative

approach; and prioritizing stakeholder requirements.

Another method found in the literature was

described by Gill et al. (2014). They proposed the

Contributory Appreciative Inquiry method for RE,

composed of six phases: use of the artificial

intelligence technique to highlight future requirements;

a compilation of a high-level requirements' list;

categorization of requirements into contributory

points; mapped requirements are analyzed with

stakeholders through brainstorming sessions; and

finally, the requirements are listed and specified.

2.5 Research Framework

The research framework consists of two research

propositions and a description of the variables that

make up the propositions. The propositions consider

only the three RE techniques most cited in the

literature and most used in the business context:

interview, prototyping, and brainstorming.

2.5.1 Research Propositions

The research framework is outlined in Figure 1. It

consists of two research proposals, which suggest that

Using Combined Techniques for Requirements Elicitation: A Brazilian Case Study

243

the combined use of RE techniques improves the

quality of RF and NFR.

Figure 1: Research framework.

Type C The teams that belong to this group use

only the interview as a RE technique

Type T The teams that belong to this group

combine the use of interview and

brainstorming techniques for RE

It should be noted that the prototyping technique

was used by all teams, as the quality of the RF and

NFR was assessed by the prototype.

The research framework presents two

propositions to be verified in this research:

P1. Teams that use more than one RE technique

produce a better-quality functional

requirements (FR) specification.

P2. Teams using more than one RE technique

produce a better-quality non-functional

requirements (NFR) specification.

These propositions are based on variables that are

described below.

2.5.2 Research Variables

The research framework has three types of variables:

independent, dependent, and control. It is possible to

manipulate the data of the independent variables and

they influence the dependent variables. The

dependent variables are the results of the influence of

the independent variables. Finally, the control

variables are considered variables that influence the

results of the dependent variables and can be used to

explain the results (Creswell, 2007).

Independent Variable. It is the variable whose

manipulation allows the study of the impact on the

quality of the elicited requirements.

(1) Combined use of techniques. Refers to the

number of techniques used in RE: level 0 refers to the

use of only one RE technique; and level 1 refers to the

combined use of more than one RE technique.

Dependent Variables. These are two variables that

represent the quality level of RF and RNF. In this

research, quality refers to two attributes:

completeness and consistency of requirements.

(1) Quality of RF. It represents the correct

elicitation, in terms of completeness and consistency

of the RF. This variable has three levels: level 0 refers

to a low-quality RE; level 1 refers to a medium quality

REç and level 2 refers to high-quality RE.

(2) Quality of RNF. It represents the quality of

RNF in terms of completeness and consistency of RF

and has the same levels as the previous variable.

Control Variables. The research model consists of

two control variables that are associated with the

involvement of teams in the RE process.

(1) Motivation. It refers to the team's motivation

in the entire ER process evaluated by two criteria:

assiduity and punctuality of the team in interactions.

This indicator has three levels: level 0, which

represents a team with a lack of attendance and lack

of punctuality; level 1, which represents a team with

a lack of attendance or lack of punctuality; and level

2, which represents a team with assiduity and

punctuality. Assiduity and punctuality were used as

criteria for measuring motivation, as according to

Grotta (2019), they can be used to assess the

motivation of a team.

(2) Communication. It refers to communication

in the RE process between team members and between

the team and the client. This indicator has three levels:

level 0, which represents a lack of communication

between team members and between the team and the

client; level 1, which represents a lack of

communication between team members or between the

team and the client; and level 2, which represents

adequate communication between team members and

between the team and the client.

3 RESEARCH METHOD

The research proposed in this work is an exploratory

study. According to Creswell (2007), an exploratory

research aims to offer information about the object of

study and guide the formulation of hypotheses for

future research. This research explores the influence

of using more than one RE technique on the quality

of FR and NFR. It should be noted that this study is

qualitative and cross-sectional research, as the data

were collected only once.

This section describes the research steps and the

methodological procedures for collecting and

analyzing data.

3.1 Research Phases and Strategy

The research consists of five phases. The first phase

comprises the literature review, in which the basic

Only one RE

technique is

used

(interview)

Combined use

of RE

techniques

(interview and

brainstorming)

Control group

(type C)

increases

FR quality

Test group

(type T)

increases

NFR quality

P1 and P2 are research propositions

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

244

research concepts were described. In the second

phase, we developed the research framework

composed of the research proposals and variables,

based on the literature review. Then, in the third

phase, we define the methodological procedures,

which are presented in this section. In the fourth

phase, we collected the data that is presented in

sections 4 and 5. In the fifth and last phase, we carry

out the results’ analysis and the research conclusions.

We adopted the case study as a research strategy

because according to Eisenhardt (1989) the case study

allows the researcher to flexibly analyze the findings

of data collection.

3.2 Case Study Protocol

The research protocol describes the selection of

research participants and the requirements that must

be specified by the teams. Finally, we describe the

interaction plan between researchers and participants

for data collection.

3.2.1 Selection of Research Participants

We performed the case study in the second half of

2019, with undergraduate students of an Information

Systems course at the University of São Paulo. We

selected a morning class from the third semester of

the course. The choice of a morning class made it

possible to have students with greater availability to

perform the research activities because few students

of this morning class had professional activities or

internships.

The selected class had 56 students, enough for the

composition of several teams for the software

development project needed to analyze RE

techniques.

3.2.2 Requirements Specified by the Teams

According to the protocol, teams must elicit

requirements for an employee’s evaluating system of

a private company. The results must be presented

using a prototype. The requirements to be elicited

include:

(1) Functional Requirements. Twelve RFs

were defined for employees’ evaluation, which was

categorized into three groups: performance, behavior,

and social and personal skills.

(2) Non-functional Requirements. Five

NFRs related to design and user interface were

defined: responsive design; intuitive interface with an

attractive appearance; concepts and text familiar to

the user; data must have consistency and follow a

standard; and warning messages about users’ actions.

In the end, the teams must deliver a prototype with

the requirements. In this way, the prototyping

technique is used by all teams.

3.2.3 Interaction Plan with Teams

We have defined four interactions for evaluating team

activities and outcomes.

(1) First Interaction. We present the project

proposal to the teams. In this stage, we defined the

teams, the activities, and the interaction schedule with

a duration of four months.

(2) Second Interaction. In this interaction, all

teams must use the interview technique for RE. The

FR and NFR are reported to the groups and the criteria

for the elaboration of the prototype. It is expected

with this interaction that the teams understand the

software requirements to start the prototype

development. Teams were also asked to create user

stories based on this interaction, which should be

delivered in the third interaction.

(3) Third Interaction. In this interaction, the

teams use interview and brainstorming techniques.

The goals are to verify the work developed by the

teams since the second interaction, analyze the

requirements specification elaborated by the teams,

and clarify teams' doubts. During this interaction, we

evaluate the motivation and communication of the

team in carrying out the activities.

(4) Fourth Interaction. This is the last

interaction. The teams deliver the final version of the

prototype. We re-evaluated the team's motivation and

communication in carrying out the activities. Finally,

team members must answer an anonymous

questionnaire about the project.

4 CASE STUDY

This section describes the case study characteristics.

First, we describe the teams’ characteristics, and then

we describe the control we did on the case study

external variables, which we sought to keep constant

so as not to influence the research outcomes.

4.1 Teams’ Characteristics

We formed ten teams with the 56 students. Six teams

with six students and four teams with five students.

We surveyed each student's school performance. This

made it possible to form teams with similar school

performance. This activity was carried out in the first

interaction with the teams. The results are shown in

Table 1.

Using Combined Techniques for Requirements Elicitation: A Brazilian Case Study

245

Table 1: Teams’ characteristics.

Teams Members School perfor- Type of

number mance (0 to 10) team

E01 6 6.1 Test

E02 6 6.4 Test

E03 5 6.0 Test

E04 5 6.4 Test

E05 6 6.2 Control

E06 6 6.7 Control

E07 5 6.7 Control

E08 5 6.0 Control

E09 6 6.0 Test

E10 6 6.8 Control

4.2 Case Study External Variables

We tried to keep constant the variables that are not part

of the research framework to allow that only the use of

techniques influences the RE process. Amongst the

variables that were kept constant, the following stand

out: (1) the activities in all teams were coordinated by

the same researcher; (2) performance assessment of all

teams was also carried out by the same researcher; (3)

we describe the requirements to all teams in a similar

way; (4) the time to do the activities was the same for

all teams, that is, four months to develop the project

and four interactions with the researcher; (5) GitHub

(https://pages.github.com) was used by all teams to

develop the project, which is a free platform on which

several users can work on the same project; and (6) the

number of students per team was almost the same since

teams were formed with six or five students.

The teams’ school performance was similar: the

control group had an average of 6.5 and the

experimental group 6.2. Thus, the teams’ school

performance remained very close, not being a

variable of influence on the results of the study.

5 RESULTS

Table 2: Requirements’ quality level.

Group Number of Team FR NFR

techniques (P1*) (P2)

Control 1 E08 0 0

Control 1 E10 1 0

Control group performance (%) 25,0 0,0

Test 2 E01 2 2

Test 2 E02 1 1

Test 2 E03 1 0

Test 2 E04 2 1

Test 2 E09 1 0

Test group performance (%) 70,0 40,0

* 0: low-quality; 1: medium quality; 2: high-quality

Table 2 shows the quality levels of the requirements

obtained by the teams. In proposition P1 we analyzed

the influence of the use of ER techniques on the

quality of RF, and in proposition P2 we analyzed the

influence on the quality of RNF.

The E05, E06, and E07 teams did not deliver the

prototype, so we disregarded the results of these

teams. The teams in the experimental group used to

interview and brainstorming techniques, and the

teams in the control group used only the interview.

We calculate the performance of the groups by

dividing the sum of the quality levels achieved by the

teams, by the maximum quality level possible. For

example, the performance of the control groups

concerning the FR was 25.0%, that is, (0 + 1)/(2 + 2).

We expected that the FR and NFR of the

experimental group would be of higher quality than

the control group. The results confirmed both

propositions. In the P1 proposition, higher quality for

the FR was expected, and the teams in the

experimental group performed 45.0% higher than the

control group. Similarly, in proposition P2, the higher

quality was expected for the RNF, and the teams in

the experimental group performed 40.0% higher than

the control group.

6 DISCUSSIONS

We performed the analysis using the research control

variables: motivation and communication. The

analysis was based on data collected from interactions

between the researcher and the teams, and the

anonymous questionnaires submitted to students.

Table 3 shows the results for propositions P1 and P2

and of the control variables.

Table 3: Research propositions.

Group Team P1* P2 Moti- Commu-

(FR) (NFR) vation nication

Control E08 0 0 2 0

Control E10 1 0 2 2

Performance (%) 25,0 0,0 100,0 50,0

Test E01 2 2 2 2

Test E02 1 1 2 0

Test E03 1 0 1 1

Test E04 2 1 2 2

Test E09 1 0 2 0

Performance (%) 70,0 40,0 90,0 50,0

Difference (%) 45,0 40,0 -10,0 0,0

* Research propositions

0: low-quality; 1: medium quality; 2: high-quality

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

246

Propositions P1 and P2 were confirmed by the

research. The use of more than one RE technique has

increased the quality of FR and NFR in terms of

completeness and consistency. In the case of FR, the

experimental teams - used more than one technique -

had a performance of 70.0%, being 45.0% superior to

that of the control teams - used only one technique.

Likewise, the experimental teams performed 40.0%

higher than the control teams concerning NFR. The

results were very close for both RF and RNF. It can

be inferred that the improvement achieved in the

quality of the requirements did not depend on the type

of requirement. The results corroborate the claims of

Saad and Dawson (2018) that the use of only one RE

technique can result in an inadequate specification

that affects the quality of the requirements.

The control variables had no significant difference

between the control and test groups. This shows that

they did not influence the result and reinforces the

evidence that quality improvement in RF and RNF

occurred due to the use of more than one RE

technique. The first control variable - motivation -

was assessed by students' attendance and frequency

in interactions. The experimental group was 10.0%

lower than the test group. It can be inferred that

improvement in RF and RNF quality was not

associated with the team’s motivation.

The second control variable - communication -

was evaluated by two aspects: communication

between team members and between the team and the

client. The performance of the team's communication

was the same for the experimental group and the

control group. There was no difference between the

groups, and it can be inferred that the improvement in

the quality of RF and RNF was not associated with

team communication.

7 CONCLUSIONS

The goal of this research was to analyze the influence

of the combined use of RE techniques in the quality

of FR and NFR. To achieve this goal, we carried out

qualitative and exploratory research based on a case

study involving 56 undergraduate students during the

second semester of 2019. It should be noted that the

research has limitations, of which the following stand

out: (1) researcher’s bias in analyzing and interpreting

the collected data; (2) the educational environment, in

which the case study was applied, has differences

from the business environment, where software

projects are developed under different goals,

strategies, and human conflicts; and (3) the method

used does not allow the generalization of results to

other contexts.

The results confirm that the combined use of RE

techniques improved the completeness and

consistency of the RF and RNF. It was also possible

to observe two control variables: motivation and

communication. These variables had no positive

association with the result.

The use of more than one technique for RE to

improve the quality of requirements. This result has a

similarity with the research methods

recommendations, in which the use of alternative

methods or data from different sources increases the

rigor of the method (Yin, 2014). Therefore, we

suggest for future research the analysis of RE

techniques that have complementarity in terms of

source or method of data collection.

REFERENCES

Al-Qudah, D., Cristea, A., & Lei, S. (2013). An exploratory

study to design an adaptive hypermedia system for

online advertisement. The 9th International Conference

on Web Information Systems and Technologies, 368–

374. doi: 10.13140/2.1.3107.9368

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

elicitation process of designing a collaborative

environment – the cre@tive.biz case. MATEC Web

Conf, 1-4. doi: 10.1051/matecconf/201818404010.

Alvertis, I., Papaspyros, D., Koussouris, S., Mouzakitis, S.,

& Askounis, D. (2016). Using crowdsourced and

anonymized personas in the requirements elicitation

and software development phases of software

engineering. 2016 11th International Conference on

Availability, Reliability and Security (ARES), 851–856.

IEEE. doi: 10.1109/ARES.2016.71.

Araújo, R., Anjos, E., & Silva, D. (2015). Trends in the use

of design thinking for embedded systems. In: 15th

International Conference on Computational Science

and Its Applications. 10.1109/ICCSA.2015.25.

Asghar, A., Tabassum, A., Bhatti, S., & Jadi, A. (2017).

Impact and challenges of requirements elicitation

prioritization in quality to agile process: Scrum as a

case scenario. 2017 International Conference on

Communication Technologies (ComTech), 50–55.

IEEE. doi: 10.1109/COMTECH.2017.8065749.

Boehm, B. (2000). Requirements that handle ikiwisi, cots,

and rapid change. Computer, 33(7), 99-102.

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. Ingeniare:

Revista Chilena de Ingeniería, 26(1), 142–156. Scielo.

doi: 10.4067/S0718-33052018000100142.

Caleb-Solly, P., Dogramadzi, S., Ellender, D., Fear, T., &

Van Den Heuvel, H. (2014). A mixed-method approach

to evoke creative and holistic thinking about robots in a

Using Combined Techniques for Requirements Elicitation: A Brazilian Case Study

247

home environment. ACM/IEEE International

Conference on Human-Robot Interaction, 374–381.

ACM Press. doi: 10.1145/2559636.2559681.

Creswell, J. (2007). Projeto de pesquisa: métodos

qualitativo, quantitativo e misto. Artmed.

Dardenne, A., van Lamsweerde, A., & Fickas, S. (1993).

Goal-directed requirements acquisition. Science of

Computer Programming, 20(1-2), 3-50.

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

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

550.

Fernandes, J., Duarte, D., Ribeiro, C., Farinha, C., Pereira,

J., & Da Silva, M. (2012). Ithink: A game-based

approach towards improving collaboration and

participation in requirement elicitation. Procedia

Computer Science, 15(1), 66–77, Genoa. Elsevier B.V.

doi: 10.1016/j.procs.2012.10.059.

Gill, K., Zaidi, A., & Kiani, M. (2014). Eliciting futuristic

end-user requirements through contributory

appreciative inquiry. 2014 National Software

Engineering Conference, Rawalpindi, 49–54. IEEE.

doi: 10.1109/NSEC.2014.6998240.

Gonzales, C. K. & Leroy, G. (2011). Eliciting user

requirements using appreciative inquiry. Empirical

Software Engineering, 16(6), 733–772. doi:

10.1007/s10664-011-9156-x.

Grotta, A. (2018). Aprendizagem baseada em projeto ágil

para educação em programação de computadores no

ensino superior brasileiro. Dissertação - Escola de

Artes, Ciências e Humanidades, USP, São Paulo.

Kassab, M., Neill, C., & Laplante, P. (2014). State of

practice in requirements enginee- ring: contemporary

data. Innovations in Systems and Software Engineering,

10(4), 235-241. doi: 10.1007/s11334-014-0232-4.

Kitchenham, B. & Charters, S. (2007). Guidelines for

performing systematic literature reviews in software

engineering. Technical Report EBSE 2007-001, Keele

University and Durham University Joint Report.

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

A. (2018). Continuous cla- rification and emergent

requirements flows in open-commercial software

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

Springer London. doi: 10.1007/s00766-016-0259-1.

Lim, S., & Finkelstein, A. (2012). Stakerare: Using social

networks and collaborative filtering for large-scale

requirements elicitation. IEEE Transactions on

Software Engineering, 38(3):707–735. doi:

10.1109/TSE.2011.36.

Mishra, D., Aydin, S., Mishra, A., & Ostrovska, S. (2018).

Knowledge management in requirement elicitation:

Situational methods view. Computer Standards &

Interfaces, 56(1), 49-61. Elsevier B.V. doi:

10.1016/j.csi.2017.09.004

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

requirement elicitation by combining requirement

engineering techniques. In 2008 First International

Conference on the Applications of Digital Information

and Web Technologies (ICADIWT),

258–263. IEEE.

doi: 10.1109/ICADIWT.2008.4664355

Nuseibeh, B. & Easterbrook, S. (2000). Requirements

engineering: A roadmap. In Proceedings of the

Conference on The Future of Software Engineering,

35–46. ACM. doi: 10.1145/336512.336523.

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

requirement engineering process model for software

development and requirements management. 2010

International Conference on Advances in Recent

Technologies in Communication and Computing, 287 –

291. doi: 10.1109/ARTCom.2010.24

Pitula, K. & Radhakrishnan, T. (2011). On eliciting

requirements from end-users in the ICT4D domain.

Requirements Engineering, 16(1), 323–351. Springer.

doi: 10.1007/s00766-011-0127-y.

Ramakrishnan, L., Poon, S., Hendrix, V., Gunter, D.,

Pastorello, G., & Agarwal, D. (2014). Experiences with

user-centered design for the tigers workflow API. IEEE

10Th International Conference On E-Science, 290-297.

doi: 10.1109/eScience.2014.56.

Saad, A., & Dawson, C. (2018). Requirement elicitation

techniques for an improved case-based lesson planning

system. Journal of Systems and Information

Technology, 20(1), 19-32. doi: 10.1108/JSIT-12-2016-

0080.

Sadiq, M., Ghafir, S., & Shahid, M. (2009). An approach

for eliciting software requirements and its prioritization

using analytic hierarchy process. In 2009 International

Conference on Advances in Recent Technologies in

Communication and Computing, 790–795. IEEE. doi:

10.1109/ARTCom.2009.58.

Smith, C., Strauss, J., & Maher, P. (2010). Data structure

visualization: The design and implementation of an

animation tool. Proceedings of the 48th Annual

Southeast Regional Conference, 1-6. ACM. doi:

10.1145/1900008.1900105.

Todoran, I., Seyff, N., & Glinz, M. (2013). How cloud

providers elicit consumer requirements: An exploratory

study of nineteen companies. In: Rio de Janeiro: IEEE

Computer Society, 105-114. doi:

10.1109/RE.2013.6636710.

Vijayan, J., Raju, G., & Joseph, M. (2016). Collaborative

requirements elicitation using elicitation tool for small

projects. In 2016 International Conference on Signal

Processing, Communication, Power and Embedded

System (SCOPES), 340–344. doi:

10.1145/10.1109/SCOPES.2016.7955848.

Yin, R. K. (2014). Case Study Research Design and

Methods, 5

ed. Thousand Oaks, CA: Sage.

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

Non-functional requirements elicitation guideline for

agile methods. Journal of Telecommunication,

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

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

248