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.
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
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.
Alflen, 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
2021 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
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.,
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
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
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
(2) SLR Identification. We use the Scopus
database (, 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
(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
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
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
We identified three techniques present in both
works and present amongst the five most cited in
(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
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.
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
Combined use
of RE
(interview and
Control group
(type C)
FR quality
Test group
(type T)
NFR quality
P1 and P2 are research propositions
ICEIS 2021 - 23rd International Conference on Enterprise Information Systems
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
The selected class had 56 students, enough for the
composition of several teams for the software
development project needed to analyze RE
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
(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.
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
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
( 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.
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.
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
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.
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.
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 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
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-
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:
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:
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:
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-
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:
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:
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:
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:
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