Towards a Data-Driven Requirements Elicitation Tool

through the Lens of Design Thinking

Jos

e Cezar de Souza Filho, Walter Takashi Nakamura, L

ıgia M

arcia Teixeira,

ogenis Pereira da Silva, Bruno Freitas Gadelha and Tayana Uch

oa Conte

Institute of Computing (IComp), Federal University of Amazonas, UFAM, Manaus, Brazil

Keywords:

Data-Driven Requirements Engineering, Design Thinking, User Reviews.

Abstract:

Data-Driven Requirements Engineering (DDRE) proposes that software requirements development goes be-

yond the application of traditional elicitation techniques (e.g., interviews and questionnaires) by considering

other sources of data, such as user reviews available on app stores, social networks, and forums. While many

studies are looking for requirements mining and automatic classiﬁcation through machine learning, informa-

tion retrieval, and natural language processing algorithms, few studies investigate how to support software

practitioners who will use this knowledge in practice, for instance, through tools to support the process. In

this context, Design Thinking (DT) emerged as a promising approach to design user-centered solutions to this

problem. Thus, in this paper, we conducted an exploratory study to investigate how DT beneﬁts the develop-

ment of a data-driven requirements elicitation tool. To do so, we applied the Double Diamond process, having

in mind Brown’s DT Cycles, supported by a set of DT techniques. Our results indicate that DT techniques can

be integrated into the development process, allowing a better understanding of the problem and supporting the

development of user-centered solutions. We provide the beneﬁts and drawbacks of adopting DT as a toolbox

in the context of DDRE tools.

1 INTRODUCTION

Advances in mobile technology led to a data increase

on the real use of software. Nowadays, online stores,

such as Google Play and Apple’s App Store, allow

users to report their experiences when using the ap-

plications by posting reviews in the platform. From

developers’ perspective, these reviews are a valuable

source of information that can support the identiﬁca-

tion of missing features, bugs, improvement sugges-

tions, and experience reports (Guzman and Maalej,

2014), as well as a set of requirements that can drive

future releases (Carre

no and Winbladh, 2013).

Traditionally, Requirements Engineering (RE) in-

volves the use of techniques such as interviews, ques-

tionnaires, focus groups, and workshops. However,

RE has been changing the approaches to consider

other sources, such as reviews from social networks,

forums, and user reviews (Maalej et al., 2015), lead-

ing to a paradigm shift known as Data-Driven Re-

quirements Engineering (DDRE).

Some researchers have been working on the topic,

for example, investigating algorithmic solutions on

how to automate requirements mining and classiﬁ-

cation by applying different machine learning, infor-

mation retrieval, and natural language processing al-

gorithms (Maalej et al., 2015; Lu and Liang, 2017).

However, few efforts have been made to understand

how to support software practitioners who will use

this knowledge in practice, for instance, through

tools. Therefore, we need to move forward in investi-

gating practitioners’ needs and eliciting requirements

to develop tools that support the DDRE process. To

support the development of such tools, we can use

Design Thinking (DT), a discipline that uses empa-

thy, collaboration, and experimentalism to understand

users’ needs and design solutions to a certain prob-

lem, focusing on achieving innovation (Brown, 2008).

This paper presents an exploratory study to inves-

tigate how DT can beneﬁt the development of a data-

driven requirements elicitation tool. To do so, we ap-

plied the Double Diamond process (Design Council,

2015), having in mind Brown’s DT Cycles (Brown,

2008), supported by a set of DT techniques. With

this work, we provide the beneﬁts and drawbacks of

adopting DT as a toolbox in the context of DDRE

tools, which can be useful for practitioners in select-

ing DT techniques to develop future software tools.

de Souza Filho, J., Nakamura, W., Teixeira, L., da Silva, R., Gadelha, B. and Conte, T.

Towards a Data-Driven Requirements Elicitation Tool through the Lens of Design Thinking.

DOI: 10.5220/0010443402830290

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

ISBN: 978-989-758-509-8

283

2 DESIGN THINKING

Design Thinking is a discipline that adopts methods

and designers’ sensibility to develop people’s needs-

oriented products, combining what is technologically

feasible and business strategy to generate customer

value and market opportunity (Brown, 2008), and has

been investigated by recent works on RE. For in-

stance, Canedo et al. (2020) observed that DT con-

tributes to the improvement of requirements elici-

tation process and that it allows, through prototyp-

ing, the identiﬁcation of errors in requirements under-

standing prior to implementation. Also, Hehn et al.

(2019) presented approaches for tailoring and inte-

grating DT and RE.

There are several DT processes in the literature.

One of the most known is Brown’s Design Thinking

Cycles (Brown, 2008), composed of three phases: in-

spiration puts designers in touch with circumstances

(e.g., a problem, an opportunity, or both) that moti-

vate the search for solutions; ideation is the phase of

generating, developing, and testing ideas that can re-

sult in solutions; and implementation is the process of

putting a viable idea on the market.

Another process is named Double Diamond (De-

sign Council, 2015), represented by two diamonds.

The ﬁrst diamond explores a circumstance in a

broader or deeper way (divergent thinking) and has

two steps: discover involves collecting information

and insights from people affected by the circumstance

to gain an initial problem understanding; and de-

ﬁne uses the insights obtained in the previous step

to achieve a deep problem understanding, identifying

the needs and opportunities to be solved. The sec-

ond diamond focuses on taking actions to problem-

solving (convergent thinking) and has two other steps:

develop, in which designers use the data collected and

work collaboratively to build different solutions for

the problem; and deliver, the time to validate the pro-

posed solutions, discarding those that did not work

and improving the most appropriate ones, i.e., it is the

moment to converge the solution to be delivered.

3 METHODOLOGY

In this paper, we investigate how DT beneﬁts the de-

velopment of a data-driven requirements elicitation

tool to support the automation of the requirements

elicitation process following the DDRE paradigm.

The tool, called Mining Reviews, mines user reviews

from a mobile application available in app stores, an-

alyzes them and summarizes the results by presenting

the most frequent terms mentioned by users and their

respective reviews, which requirements engineers can

use to proceed with requirements’ development and

management. The tool can contribute to improving

existing applications and creating new ones that seek

to solve the problems and gaps in competing applica-

tions according to users’ feedback.

To better understand stakeholders’ needs to de-

velop this tool, we applied the Double Diamond pro-

cess, having in mind Brown’s DT Cycles (Section 2),

supported by a set of DT techniques (Figure 1). From

that process, we obtained ﬁndings on the beneﬁts and

drawbacks of DT techniques applied, guided by two

questions: (i) how did each DT technique contribute

to the tool development? and, (ii) if and how did each

DT technique cause the need to modify/improve the

artifacts generated by the other techniques?

Figure 1: DT process and selected techniques inspired

by Design Council (2015).

3.1 DT Techniques Selection

To support techniques selection, we consulted the De-

sign Thinking Assistant for Requirements Elicitation

(DTA4RE) tool

(Souza et al., 2020). This tool pro-

vides an repository about 27 DT techniques catego-

rized by their application in the different phases of

the DT process, presenting, for each technique, when

to use it, its pros and cons, and other information. We

analyzed the techniques suggested for each DT pro-

cess phase and selected the most appropriate ones ac-

cording to the applicability to the problem under in-

vestigation. In the next subsections, we detail each

technique selected.

3.2 Data Gathering Techniques

Stakeholder Map. The ﬁrst step to develop a prod-

uct is to identify the key stakeholders that affect or

are affected by the project development. This infor-

mation may not be clear during initial-stage projects,

thus we needed a technique to support us in this pro-

cess. The Stakeholder Map is a technique that pro-

https://sites.google.com/site/dta4reassistant/

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

284

vides a visual representation of the groups that are in-

volved in a project, making it possible to analyze and

map their relationships (Stickdorn et al., 2011). We

used a model that helps prioritizing the stakeholders

according to their inﬂuence and interest in the project

based on Mendelow (1981). Inﬂuence indicates the

power degree that a stakeholder has to hinder or ad-

vance the project. Interest indicates how interested

the stakeholder is in what is being developed.

Interviews. There are different types of interviews,

such as unstructured, structured, and semi-structured.

We conducted semi-structured interviews through a

set of predeﬁned questions, in which the interviewer

has the ﬂexibility to guide the conversation accord-

ing to the participant’s answers to obtain information

of interest (Fontana and Frey, 1994). It can be con-

ducted through online meetings, being suitable to the

context of the worldwide COVID-19 pandemic sce-

nario. Before starting the interviews, the participants

signed an online consent form, stating that the partic-

ipants’ data would be treated anonymously, and we

would not publish any sensitive information.

We carried out the interviews through Google

Meet platform

with three participants from the group

identiﬁed in the Stakeholder Map as having high in-

terest in the project: a project manager, a software

tester, and a software developer. They work on indus-

try projects developing mobile applications and ana-

lyze user reviews to identify potential improvements

for those applications. We asked questions (available

in our technical report

) related to their main activi-

ties, the need for analyzing user reviews, and the main

challenges involved in this process. We also asked

their perceptions and expectations towards a tool that

could support their work.

3.3 Data Synthesis Techniques

Concept Map. It is a diagram that depicts suggested

relationships between concepts by representing ideas

and information as boxes that are connected with la-

beled arrows, often in a downward-branching hierar-

chical structure (Novak and Ca

nas, 2006). We chose

this method because it allows having a broad view of

the project and of the relationship between each idea

and information. First, we had a meeting at Google

Meet platform to discuss what would be the best way

to represent the ideas. Then, to build the concept map,

we used a web application called Lucidchart

, which

allowed us to work collaboratively.

http://meet.google.com

https://doi.org/10.6084/m9.ﬁgshare.14044151.v3

http://www.lucidchart.com

Personas. Are a hypothetical representation of users

that provides an understanding of their characteristics,

needs, and goals, which can be used to guide the de-

velopment process (Castro et al., 2008). We used this

technique to have a better understanding of our target

group of stakeholders.

Personas were created based on the Personas Em-

pathy Map (PATHY) technique (Ferreira et al., 2018),

which provides a template with guiding questions that

help describe and create the persona, based, for in-

stance, on his/her experience with technology, needs,

and problems. As we only needed to know more

about who the persona is, we selected only the items

in the ‘who’ ﬁeld. We ﬁlled the template to create two

personas: one male and one female. To avoid creat-

ing empathy with a persona with the same gender as

its creator, a male researcher was responsible to create

the female persona and vice versa.

Empathy Map. This method allows externalizing the

knowledge about users and supporting the decision-

making process. More than just demographic char-

acteristics, it allows understanding customer’s envi-

ronment, behavior, aspiration, and concerns (Ferreira

et al., 2015; Gray et al., 2010) to gain empathy with

a speciﬁc person (Osterwalder and Pigneur, 2010).

With this method, we aimed to decipher the stake-

holders’ minds by putting ourselves in their shoes and

to go beyond the creation of simple personas by giv-

ing them life through their pains and needs. we used

the template presented by Osterwalder and Pigneur

(2010), which is composed of 6 quadrants that address

what they do, see, hear, think and feel, as well as their

pains and gains.

3.4 Develop Technique

Bodystorming. It is a type of brainstorming that in-

volves active staging with simple prototypes (Haning-

ton and Martin, 2012), i.e., the researchers put them-

selves in the stakeholders’ shoes, staging situations

similar to what happens in their daily lives. We em-

ployed it to understand better how the use of our tool

could help our stakeholders. To perform customer ex-

perimentation with our tool, we followed two steps:

Script Creation and Bodystorming Video.

In Script Creation, we deﬁned two scenarios, one

for each stakeholder represented by the personas we

created in the Data Synthesis phase. In these sce-

narios, the stakeholders would need to look among

several reviews to identify relevant features to be im-

proved, created, or removed. After creating and dis-

cussing the scripts, we followed to the Bodystorm-

ing Video step to simulate the meetings of stakeholder

1 with his bosses and stakeholder 2 with her friends

Towards a Data-Driven Requirements Elicitation Tool through the Lens of Design Thinking

285

through a video call.

At a given moment in the scenarios, we realized

that the stakeholders would need to interact with our

tool and provide feedback. To create a visual repre-

sentation of the tool, we applied Prototyping (Sec-

tion 3.5). Following the iterative nature of the DT

process, we performed the Script Creation before Pro-

totyping to understand the interaction scenarios better

and gain insights. Thus, we performed the Script Cre-

ation and Bodystorming Video until the scenes where

the stakeholders interact with the tool. Then, we de-

veloped the prototypes and went back to the bodys-

torming process to ﬁnish the scripts and recordings.

3.5 Deliver Technique

Prototyping. It allows validating the ideas produced

and can occur continuously and parallel to the previ-

ous phases. In this technique, a tangible artifact is cre-

ated to develop and test the ideas with project teams,

clients, and end-users (Hanington and Martin, 2012).

In this step, we, as a team, discussed how the interface

would look like and how we would show the results

to the stakeholders. To do so, we designed a high-

ﬁdelity prototype developed in HTML and CSS3.

4 RESULTS

In this section, we present the results and artifacts cre-

ated with the techniques in each DT phase.

4.1 1st Diamond: Divergent Thinking

Stakeholder Map. Initially, we had a limited view of

the stakeholders. Some team members did not recog-

nize software practitioners as end-users of the tool,

but only the end-users of mobile applications from

which the reviews will be extracted. This technique

allowed us, as a team, to identify that we have a spe-

ciﬁc case of end-users since they will use the tool as

part of the development of new software products, go-

ing beyond the daily use of common software. It also

allowed us to identify stakeholders that we did not

think of until then (e.g., application investors).

Through a visual representation, we could analyze

the relationship between inﬂuence and interest of the

people involved in the project. As a result, we identi-

ﬁed four different stakeholder groups (Figure 2).

1. Application Investors: a group of people who will

provide ﬁnancial support to the project. As in-

vestors, they have their feet on the ground and are

cautious to spend their money. Usually, they seek

Figure 2: Stakeholder map.

to invest in business opportunities instead of fo-

cusing on the details of the application. In this

sense, they are the stakeholders with low interest

and inﬂuence in the project, as our tool will not

beneﬁt them directly.

2. Requirements Engineers and Developers: the

stakeholders that will use our tool and will be di-

rectly beneﬁted by the project. For this reason,

they have high interest and high inﬂuence in the

project, being necessary to always keep them in-

formed through active communication to evaluate

whether the tool is meeting their needs.

3. End-users: typically, mobile application end-

users are the main target of requirements engi-

neers and developers, which makes them very in-

ﬂuential in the project. By contrast, our tool will

not beneﬁt them directly, as it is being designed

for software practitioners. Instead, they will ben-

eﬁt from the improvements brought by developers

and requirements engineers for the mobile appli-

cation through the use of our tool. Thus, they have

high inﬂuence but low interest in our project.

4. Application Owner/Company, Project Leaders,

and Managers: as their teams will use our tool

to improve the company’s products, their interest

in the project is high. However, they have low in-

ﬂuence, as they will not use our tool directly.

Based on the results, we decided to focus on the two

groups with more interest in our project: i) develop-

ers and requirements engineers; and ii) project leaders

and managers.

Interviews. The results indicated that the three par-

ticipants have analyzed user reviews to improve the

company’s software. The software tester, for instance,

stated “currently, in our project group, it is necessary

at a certain time to look at user reviews about our ap-

plication to see the problems they reported and what

we can improve”. This indicates that the companies

are aware of the importance of user reviews for soft-

ware development and evolution.

Regarding the main challenges, two interviewees

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

286

pointed out the lack of constructive information in the

reviews, which hinders the identiﬁcation of what as-

pects of the software to improve or ﬁx. The software

tester, for instance, stated “users sometimes do not

make a constructive criticism, they do not tell you

what should be improved in the application explic-

itly”. Two interviewees also pointed out the time re-

quired to read and analyze the reviews, which makes a

manual analysis unfeasible. The project manager, for

instance, stated “[the problem is the] waste of time

reading lines and lines of feedback to transform them

into a few lines of technical terms”.

Finally, when asked about the helpfulness of an

automated analysis of user reviews and their expec-

tations about a tool designed for this task, all three

stakeholders were unanimous in saying that it would

contribute a lot to their work, especially to speed up

the development process. The software tester, for in-

stance, stated “this would be very interesting. In addi-

tion to showing constructive comments, ﬁltering what

we need would be very cool, [i.e., extracting] both

negative feedbacks, by which we could improve our

application, as well as positive feedbacks. This will

greatly automate our work”.

In summary, the results from the interviews re-

vealed that the problem under study is real and rel-

evant. We found that the automation of mining user

reviews could help them identifying the main issues

and speeding up the development process. It high-

lights the need for approaches that automate the anal-

ysis and provide relevant information for the develop-

ment team to improve the company’s software. Thus,

we proceeded to the next step to obtain more informa-

tion and expand our understanding of the problem.

Concept Map. The concept map helped us to or-

ganize, analyze, and understand the concepts of the

project. The visual representation (Figure 3) made it

easier to have a broad view of the project and iden-

tify the relationship between each concept. However,

this technique was not so useful to gain insights to

improve the project.

Figure 3: Concept map.

Personas. The creation of the personas allowed us

to identify what is the proﬁle of the users we will

be dealing with, since some team members were ini-

tially unaware of this information. In this way, the

technique helped the team to recognize the different

needs, experiences, and the stakeholders’ behaviors.

We created two distinct personas for the group with

high priority identiﬁed in the Stakeholder Map, fo-

cusing on the need to use our tool (Figure 4).

Empathy Map. This technique helped us to create

empathy with the stakeholders and think about their

needs, feelings, and desires. We built two empathy

maps based on existing knowledge and data from the

personas created. Figure 5 presents the empathy map

for persona 2.

4.2 2nd Diamond: Convergent Thinking

Bodystorming. This technique enable us to represent

situations in which we put more attention on under-

standing the problem than on identifying a solution.

The application of bodystorming made it easier to un-

derstand and empathize with users by acting in dif-

ferent roles in the interaction within a short period of

time. Moreover, it allowed immediate feedback for

the ideas generated and provided a more precise un-

derstanding of the contextual factors of the project.

The scenarios created in the Script Creation step of

bodystorming for the stakeholders represented by per-

sonas 1 and 2 are available in our technical report.

Prototyping. Finally, we developed a high-ﬁdelity

prototype of our tool with basic functionalities. It al-

lowed us to have a more accurate view of what we

will be delivering to the stakeholders. From the in-

terviews, we realized the need to summarize the in-

formation to be presented by the tool, since the par-

ticipants considered unfeasible the time necessary to

read and analyze the reviews manually. Therefore, we

needed to think about the information visualization

and the necessary functionalities to prototype the so-

lution. During the prototype development, we noticed

that the use of word clouds would be more intuitive to

the stakeholders, as it conveys the importance of each

term among the others according to their sizes on the

screen, instead of presenting an ordered list with the

most frequent terms as originally thought.

On the main screen, we decided to show a video

to encourage tool usage and a menu where the stake-

holder can select the app in which the reviews will be

analyzed. Figure 6 presents the developed prototype

representing the basic ﬂow of the tool considering, for

instance, a food delivery application. After the user

of our tool chooses the desired application, the tool

mines its user reviews. The data are then analyzed to

identify the most frequent terms in the reviews, pre-

sented to the user through a word cloud (Figure 6a).

When navigating through it, he/she can click on one

of the terms to visualize its related reviews (e.g., the

Towards a Data-Driven Requirements Elicitation Tool through the Lens of Design Thinking

287

Figure 4: Left) persona 1 for a requirements engineer; Right) persona 2 for a businesswoman/developer.

Figure 5: Empathy map for persona 2.

term “service” in Figure 6b) and understand the feed-

back from the application users better. Finally, the

user can download the extracted data and start the

mining and analysis for another application.

5 DISCUSSION

The DT techniques provided valuable contributions to

the project development. We detail the main ﬁndings

and lessons learned from each DT phase, as well as

implications for practitioners.

5.1 1st Diamond: Divergent Thinking

The Stakeholder Map allowed us to have a more

comprehensive view of different stakeholder proﬁles.

Through the inﬂuence/interest graph, we could iden-

tify who would directly or indirectly beneﬁt from the

Mining Reviews tool, as well as which of them should

be prioritized in the development process. Initially,

we had mobile application end-users as stakeholders.

By applying this technique, we still considered them

as stakeholders but realized that they are not directly

beneﬁted by our tool, thus having low interest on it.

We identiﬁed that our main end-users are practitioners

who work directly with application development (e.g.,

software developers and requirements engineers), as

well as other stakeholders (e.g., project leaders, man-

agers, and application investors). By identifying the

most inﬂuential and interested group of stakeholders,

we could focus our efforts on this speciﬁc group and

plan the next steps accordingly.

Interviews played an important role to understand

how the tool would ﬁt into the market. We identiﬁed

that users’ opinion is essential for the stakeholders

to identify potential issues and improvement oppor-

tunities to increase users’ satisfaction. However, they

spend a lot of resources and people to streamline the

process of adapting their products to their customers’

needs and desires, as there is a huge amount of re-

views to analyze, most of them not informative. This

ﬁnding is in accordance with Chen et al. (2014), who

identiﬁed that only 35.1% of the reviews contained

information that can directly support developers im-

proving their software applications. In this sense, the

results revealed that the problem under study is real

and there is a need to summarize useful information.

Thus, the tool proposed can beneﬁt the stakeholders

with a more comprehensive view of the application’s

main issues, which can help them extract and identify

the requirements that should be prioritized.

The Concept Map helped representing our

knowledge about the problem in a structured way.

The visual representation allowed a better understand-

ing of the concepts involved in the project and the re-

lationships between them. However, this technique

was not so useful to get new insights. It is proba-

bly due to the limited amount of data available in this

initial stage of the project, which hinders the identiﬁ-

cation of missing concepts and new relationships that

would not be seen before drawing the map.

The Persona technique was essential for all team

members to share a broad and common view on the

different needs, expectations, and stakeholders’ be-

haviors, as this information was not clear to some

members. By giving them personalities and concerns,

it was possible to understand how our tool would help

them, and what improvements we could make to min-

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

288

Figure 6: Prototype - a) word cloud as a result of the analysis for a food delivery application; b) viewing related reviews when

selecting a word cloud term.

imize their concerns.

Finally, the Empathy Map allowed us to go deep

into the stakeholders’ mind. By analyzing their feel-

ings and behavior, we could understand what our

client would think and feel about our tool.

Take Away Message: use the Stakeholder Map to

identify stakeholders that had not yet been assumed,

especially when the information is scarce. Apply

Interview to conﬁrm the relevance of the problem

and to know their needs and challenges better. Use

Personas to share the same view with your team

about who are the users of your application. Apply

the Empathy Map to deepen empathy with stake-

holders, seeking to understand what they can per-

ceive in your application. These techniques are use-

ful for the initial project steps. The Concept Map

is more useful to larger projects, since it may not

provide new insights to identify new relationships

or entities in project with limited amount of data.

5.2 2nd Diamond: Convergent Thinking

The Bodystorming technique provided an innovative

way to put ourselves in the stakeholders’ shoes by in-

terpreting them and identifying how they can use the

tool proposed, which would not be possible through

the use of the traditional brainstorming technique.

During its application, the idea of using a Web ap-

plication emerged, as it would be the fastest and most

intuitive way for the stakeholders to read and analyze

user reviews. Despite its usefulness, we realized that

it requires mastering previous techniques. For exam-

ple, to generate a scenario and a script to simulate

what may be a problem and its solution, it is neces-

sary to have a good understanding of the stakehold-

ers, which may only be obtained by employing the

techniques presented previously.

Through Prototyping, we could identify new so-

lutions to previously seen problems, in addition to

new features that we could add to our ﬁnal product.

Before building the prototype, for example, we did

not know the best way to present the results to the

stakeholders. At ﬁrst, we thought of providing an

ordered list with the most frequent terms. However,

we realized that this approach lacks usability, as the

user has to scroll down the screen to see more terms.

Moreover, a simple list does not convey the relevance

of each term. After discussing, we reached a consen-

sus that a word cloud would be much more appealing,

informative, and usable to the user, as all terms are

presented in the same space with a variety of colors

and different sizes according to their frequency, high-

lighting the relevance of each term.

Take Away Message: use Bodystorming to deepen

your understanding of stakeholders by putting your-

self in their shoes and acting accordingly. Apply

Prototyping to rethink strategies to present summa-

rized information to users.

6 FINAL CONSIDERATIONS

In this paper, we investigated how Design Thinking

beneﬁts the development of a data-driven require-

ments elicitation tool, named Mining Reviews, based

on the extraction of user reviews. To do so, we carried

out an exploratory study by employing the Double

Diamond process (Design Council, 2015) supported

by a set of DT techniques that allowed us to deepen

our understanding of the problem and trace a path to-

wards a solution that meets the stakeholders’ needs.

In summary, through DT, we could understand how to

help with tooling support people who will use DDRE

knowledge in practice.

This study contributes to: (i) understanding the

beneﬁts and drawbacks of adopting DT as a toolbox

for developing tools to support data-driven require-

ments engineering; and, (ii) understanding the useful-

ness of user review analysis for requirements develop-

ment and the needs and challenges faced in this con-

text by software practitioners, which are being con-

sidered in the development of Mining Reviews tool.

Towards a Data-Driven Requirements Elicitation Tool through the Lens of Design Thinking

289

Currently, we are developing the Mining Reviews

tool based on the solutions identiﬁed in this study, in

addition to verifying the suitability of the algorithms

indicated in the DDRE state-of-the-art. As future per-

spectives, we intend to analyze the beneﬁts of other

DT techniques, such as those that observe stakehold-

ers in their work environment (e.g., Behavioral Arche-

ology and Behavioral Map). We also intend to carry

out empirical studies to evaluate the tool’s usefulness

with practitioners in the industry, as well as in the con-

text of requirements engineering education.

ACKNOWLEDGEMENTS

This research, carried out within the scope of the

Samsung-UFAM Project for Education and Research

(SUPER), according to Article 48 of Decree no

6.008/2006(SUFRAMA), was funded by Samsung

Electronics of Amazonia Ltda., under the terms

of Federal Law no 8.387/1991, through agreement

001/2020, signed with Federal University of Ama-

zonas and FAEPI, Brazil. Also supported by CAPES

- Financing Code 001, CNPq process 311494/2017-0,

and FAPEAM process 062.00150/2020. We thank the

USES research group for the support and practitioners

for their voluntary participation in the interviews.

REFERENCES

Brown, T. (2008). Design thinking. Harvard Business Re-

view, 86(6):84.

Canedo, E. D., Pergentino, A. C. S., Calazans, A. T. S.,

Almeida, F. V., Costa, P. H. T., and Lima, F. (2020).

Design thinking use in agile software projects: Soft-

ware developers’ perception. In ICEIS 2020, Proceed-

ings of the 22nd International Conference on Enter-

prise Information Systems - Volume 2, pages 217–224.

SCITEPRESS.

Carre

no, L. V. G. and Winbladh, K. (2013). Analysis of

user comments: an approach for software require-

ments evolution. In ICSE ’13, 2013 35th International

Conference on Software Engineering, pages 582–591.

IEEE.

Castro, J. W., Acu

na, S. T., and Juristo, N. (2008). En-

riching requirements analysis with the personas tech-

nique. In I-USED 2008, Proceedings of the First

Workshop on the Interplay between Usability Eval-

uation and Software Development. CEUR Workshop

Proceedings.

Chen, N., Lin, J., Hoi, S. C., Xiao, X., and Zhang, B.

(2014). Ar-miner: mining informative reviews for de-

velopers from mobile app marketplace. In ICSE 2014,

Proceedings of the 36th International Conference on

Software Engineering, pages 767–778. ACM.

Design Council (2015). What is the framework for

innovation? design council’s evolved double

diamond. https://www.designcouncil.org.uk/news-

opinion/what-framework-innovation-design-councils-

evolved-double-diamond. Acessed: 22 Nov, 2020.

Ferreira, B., Silva, W., Barbosa, S. D., and Conte, T.

(2018). Technique for representing requirements us-

ing personas: a controlled experiment. IET Software,

12(3):280–290.

Ferreira, B., Silva, W., Oliveira, E., and Conte, T. (2015).

Designing personas with empathy map. In SEKE

2015, 27th International Conference on Software En-

gineering & Knowledge Engineering, pages 501–505.

KSI Research Inc.

Fontana, A. and Frey, J. (1994). Interviewing: The art of

science. In Denzin, N. and Lincoln, Y., editors, The

Handbook of Qualitative Research, pages 361–376.

Sage Publications.

Gray, D., Brown, S., and Macanufo, J. (2010). Gamestorm-

ing: A playbook for innovators, rulebreakers, and

changemakers. “O’Reilly Media, Inc.”.

Guzman, E. and Maalej, W. (2014). How do users like this

feature? a ﬁne grained sentiment analysis of app re-

views. In RE’14, 2014 IEEE 22nd international re-

quirements engineering conference, pages 153–162.

IEEE.

Hanington, B. and Martin, B. (2012). Universal methods of

design: 100 ways to research complex problems, de-

velop innovative ideas, and design effective solutions.

Rockport Publishers.

Hehn, J., Mendez, D., Uebernickel, F., Brenner, W., and

Broy, M. (2019). On integrating design thinking for

human-centered requirements engineering. IEEE Soft-

ware, 37(2):25–31.

Lu, M. and Liang, P. (2017). Automatic classiﬁcation

of non-functional requirements from augmented app

user reviews. In EASE’17, Proceedings of the 21st In-

ternational Conference on Evaluation and Assessment

in Software Engineering, page 344–353. ACM.

Maalej, W., Nayebi, M., Johann, T., and Ruhe, G. (2015).

Toward data-driven requirements engineering. IEEE

Software, 33(1):48–54.

Mendelow, A. L. (1981). Environmental scanning – the im-

pact of the stakeholder concept. In ICIS 1981, Pro-

ceedings From the Second International Conference

on Information Systems, pages 407–418. Association

for Information Systems.

Novak, J. D. and Ca

nas, A. J. (2006). The theory un-

derlying concept maps and how to construct and use

them. http://cmap.ihmc.us/docs/theory-of-concept-

maps.php. Acessed: 22 Nov, 2020.

Osterwalder, A. and Pigneur, Y. (2010). Business model

generation: a handbook for visionaries, game chang-

ers, and challengers. John Wiley & Sons.

Souza, A., Ferreira, B., Valentim, N., Correa, L., Marczak,

S., and Conte, T. (2020). Supporting the teaching of

design thinking techniques for requirements elicita-

tion through a recommendation tool. IET Software,

14(6):693–701.

Stickdorn, M., Schneider, J., Andrews, K., and Lawrence,

A. (2011). This is service design thinking: Basics,

tools, cases. Wiley.

ICEIS 2021 - 23rd International Conference on Enterprise Information Systems

290