Identifying Possible Requirements using Personas
A Qualitative Study
Bruna Ferreira
, Gleison Santos
and Tayana Conte
IComp, UFAM, Federal University of Amazonas, Manaus, AM, Brazil
UNIRIO, Federal University of Rio de Janeiro State, Rio de Janeiro, RJ, Brazil
Keywords: Personas, Requirements Elicitation, Empathy Map.
Abstract: Involving end users in requirements elicitation helps to generate applications with a positive usage
experience. However, in the current context of software development, having users involved in the
requirements elicitation is difficult due to factors such as: lack of paying customers; users’ unavailability for
validations; and budget and time restrictions for applying traditional techniques, such as interviews and
questionnaires. Therefore, using alternative techniques to understand and gather users’ needs is indicated.
Persona is a technique that was created to help understanding users, their characteristics and what they
expect from an application. The technique allows describing users’ profile and understanding their
characteristics, attitudes and behaviors. However, the description of a persona may have many irrelevant
information not generating requirements for the development of the application. Therefore, we proposed the
PATHY technique to support the creation of personas and to generate more focused descriptions regarding
specific requirements identification for a particular application. This paper presents a study using the
PATHY technique (version 2.0). This empirical study aims to evaluate the quality of the possible software
requirements the technique helps identifying, while gathering the participants’ feedback on using the
PATHY technique. The results show that PATHY supports creating personas’ descriptions that lead to the
identification of requirements to help in application design according to target users’ characteristics and
The software development industry has become
extremely competitive, since there are many
products from the same domain that strive to satisfy
users (Bhowmik et al., 2014). To stand out from
competitors, it is important to understand the
applications’ target audience to meet their needs and
provide a good usage experience. However, an
obstacle frequently encountered by teams when
developing an application is the absence of paying
customers or users directly involved in the design of
the application (Anvari and Tran, 2014). Therefore,
the access to users is limited (Thalen and Voort,
2014), which can generate issues when collecting
requirements using traditional techniques such as
interviews and questionnaires (Marsden and Haag,
2016). Furthermore, budget and time for the
application development may be limited for using
elicitation techniques with end users (Viana and
Robert, 2016). These facts can make it hard to define
users’ specific characteristics and needs about the
requirements for the application design.
Considering the context described above, it is
necessary to employ others techniques to help
software engineers understand the users’ needs and
characteristics, while generating possible application
requirements even when users are unavailable for
usual validations during the development. The
Personas technique is a way to support the
immersion in the users’ characteristics during the
requirements engineering process (Schneidewind et
al., 2012). This technique provides the development
team with an understanding of the users’
characteristics, needs and goals to allow software
engineers to design and implement applications to
meet the users' needs (Väänänen-Vainio-Mattila et
al., 2008).
Although the Personas technique provides
support in understanding target users, it has some
aspects to be improved. For instance, the description
of the personas is more focused on the users’
attitudes (beliefs, personality, motivations, and
Ferreira, B., Santos, G. and Conte, T.
Identifying Possible Requirements using Personas - A Qualitative Study.
DOI: 10.5220/0006311600640075
In Proceedings of the 19th International Conference on Enterprise Information Systems (ICEIS 2017) - Volume 2, pages 64-75
ISBN: 978-989-758-248-6
Copyright © 2017 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
personal desires) (Guo et al., 2011) in order to help
the development team create empathy. On the other
hand, the behaviors of the persona that support the
application design (searched information, accessed
tools, perfomed tasks) are superficially described
(Guo et al., 2011). Therefore, the Persona technique
helps software engineers to become familiar with the
persona as a person. However, it does not detail
what should be designed to meet the needs of this
persona. Adsitionally, a lot of the information
generated in the description of the personas can be
irrelevant (not useful for identifying possible
requirements) for designing an application, causing
lack of focus on the application domain.
Empathy Map (EM) is a method that can be
employed to create personas (Osterwalder and
Pigneur, 2013). It helps designing business models
according to customers’ perspective (Osterwalder
and Pigneur, 2013). However, the EM is not focused
on software development.
We proposed the PATHY technique (Personas
empATHY) to support the software engineer in
understanding users’ needs, even when there are not
available users, and to identify possible application
requirements. PATHY is based in EM, because it
integrates guide questions to describe users’ profile
through personas. However, as opposed to EM,
PATHY has guide questions to reflect about user in
software context. Therefore, PATHY aims to drive
the creation of personas whose descriptions are more
focused on the application domain. In addition,
PATHY aims to support finding possible
requirements for the application without losing focus
on the user.
We performed an empirical study to evaluate the
quality of possible requirements generated by the
personas’ description and to collect the participants’
feedback about using PATHY. During the study, we
used the technique to create personas. We evaluated
the created personas and the participants’ feedback.
The analysis of the personas showed that the
technique helps identifying possible requirements
for the application, such as functionalities and user
interface details. Also, the participants’ feedback
suggests some features regarding the usefulness,
difficulties and possible improvements in the
This paper is organized as follows. Section 2
presents some concepts about Personas and Empathy
Map. Section 3 presents the PATHY technique.
Section 4 describes the study, followed by the results
in Section 5. Finally, Section 6 discusses our
conclusions and future works.
2.1 Persona
A Persona is a hypothetical archetype of a real user
(Grudin and Pruitt, 2002), which describes a user’s
goals, skills, and interests (Cooper, 1999). The
Personas technique mainly consists of the collection
of users’ data, so software engineers can understand
users’ characteristics and, based on this, they can
define specific descriptions of these users and focus
on these personas during the software development
process (Castro et al., 2011). In order to describe
Personas, some of their characteristics should be
detailed, such as the name, image, occupation,
family, age, sex, ethnicity, education, socioeconomic
status, life story, goals, and tasks (Pruitt and Adlin,
2010). Figure 1 presents a persona description
example. We created this persona for an application
to monitor epileptic people.
Figure 1: An example of the description of a persona.
Some examples of possible requirements extracted
from Figure 1 with a described persona are
presented below. From the information: “He needs
to know where his daughter is if she has an epilepsy
crisis” one possible requirement is that the
application must have a functionality to locate the
epileptic person. From “He wants to be notified
quickly in case his daughter has a crisis”, a possible
requirement is: the application must recognize when
the person has on an epilepsy crisis and send a
notification for her family or friends.
Some benefits of using personas are: to engage
teams on thinking about users and their needs during
the whole design process; to help teams on decision
making about efficient design, with no inadequate
generalization; and communicating knowledge about
Identifying Possible Requirements using Personas - A Qualitative Study
users to all stakeholders (Mashapa et al., 2013).
Some techniques to describe personas have been
proposed to involve users in the software
development process and generate possible
requirements for an application. Acuña et al. (2012)
proposed Personas for SE, based on Cooper's
version. New steps to adapt personas to the software
development process had been included in this
technique. Use cases are built in one of the stages,
based on both the generated personas and the
obtained knowledge about users by the process of
creating the personas. Idoughi et al. (2012) proposed
a technique where elements of the persona
description help designing the application`s interface
while the identifyed functionalities are extracted.
Aoyama (2007) proposed the Hanako method to
integrate scenarios and personas. The method is
goal-driven and helps extracting requirements from
a users’ group. Table 1 presents the described
characteristics using the presented personas
Table 1: Characteristics of some Personas techniques.
In Table 1, we can see the characteristics that these
techniques consider to create personas. Most of the
presented characteristics are related to characteristics
of personas’ attitudes (Identification, Psychological
details, needs/expectations, special
needs/accessibility, relation/interation with other
persons, usage context, and enviroment), i.e., they
describe personal life and psychological details.
These characteristics are important to empathize in
the users but they do not identify possible
requirements of the application. Furthermore, the
techniques presented some characteristics (goals,
experiences/skills, used applications/ services) that
can help to indentify possible requirements.
However, they are generically described. Therefore,
they can present information that is not part of the
application domain and does not generate possible
It is important that both attitudes and behaviours’
characteristics are described in the personas to
empathize and identify possible requirements that
are useful for the development of the application
(Guo et al., 2011). Therefore, we identify some
limitations in the techniques listed in Table 1: (i)
they focus more on empathy than on the
identification of possible requirements; (ii) the
characteristics that help to identify behaviors do not
focus specifically in the application domain because
these characteristics are generically described.
Consequently, it is necessary to propose specific
techniques to guide the description of personas
focusing in identify possible requirements related to
the domain of the application that will be developed.
Motivated by this need, we proposed the PATHY
technique. PATHY aims to support the identification
of possible requirements for an application. The
PATHY technique is based on the Empathy Map
that is described in the next Subsection.
2.2 Empathy Map
Empathy Map (EM) (Gray et al., 2010) is a method
to support business models design according to
customers’ perspectives. It goes beyond
demographic characteristics gathered from users’
interviews and questionnaires, and provides a better
understanding of customer’s environment,
behaviour, aspirations and concerns (Osterwalder
and Pigneur, 2013). Although it is a business plan
method, the Empathy Map can be adapted to other
goals, such as the creation of personas.
The goal of the EM is to create an empathy level
for a specific person (Gray et al., 2010). The EM
template is presented in Figure 2. Empathy Map is
composed by 6 fields (Bratsberg, 2012): (a) See –
what user sees in his/her environment; (b) Say and
Do – what user says and how he/she behaves in
public; (c) Think and Feel – what goes through the
user’s mind; (d) Hear – how the environment
influences the user; (e) Pain –frustrations, pitfalls
and risks experienced by the user, and (f) Gain –
ICEIS 2017 - 19th International Conference on Enterprise Information Systems
what the user really wants and what can be done to
achieve his/her goals.
EM helps to design for the users’ needs, making
the persona creator immersed in the users’
experience, which would be difficult to achieve if (s)
he were to read a report. The filling of the EM is
done in a collaborative way. After understanding the
user, stakeholders can know how small design
changes can have major impact on users (Bratsberg,
Figure 2: Empathy Map Template (Osterwalder e Pigneur,
PATHY is a technique for creating personas and
supporting the identification of possible
requirements for an application about to be
designed. It keeps focus on the users without leaving
the application domain. To achieve this goal, the
technique provides guide questions to drive the
software engineer on empathizing with users and
then reflecting on their behaviors and attitudes.
Therefore, the technique helps identifying new
possible requirements or improves existent
requirements, according to the users’ needs.
The technique is based on the Empathy Map.
However, Empathy Map is not focused on software
development, being used for business model design,
bringing many features that are not useful to
generate possible requirements for the design of an
application. Therefore, PATHY aims to adapt
Empathy Map for using it in the context of the
design of an application. As a result, the elaborated
personas using PATHY can generate more relevant
information to find possible requirements.
The technique’s first version (Ferreira et al.,
2015) had guiding questions providing irrelevant
information to identify possible requirements for an
application. We performed an analysis of the
generated personas with PATHY 1.0, presented in
(Ferreira et al., 2015). From this analisys, we
evolved the technique and generated PATHY 2.0.
Figure 3 presents the template from the PATHY 2.0.
The template of the PATHY is composed by the
Figure 3: Template of the PATHY 2.0.
Identifying Possible Requirements using Personas - A Qualitative Study
following fields: (1) Who; (2) Context; (3)
Technology Experience; (4) Problems; (5) Needs,
and (6) Existing Solutions. Furthermore, the
template also presents guiding questions to compose
each field. PATHY 2.0 fields are described as
Who: Description of who is the persona who
will use the application. This field brings guiding
questions related to the persona’s characteristics
itself, for example: personality, frustrations and
Context: Characteristics of the persona’s
routine. Additionally, aspects about the
environment the persona lives in and people it
has contact with are described in this field.
Technology Experiences: Experiences that the
persona had with others technologies or
applications. Furthermore, applications’
characteristics that the persona likes and does not
like can be described.
Problems: Problems faced by the persona which
can be solved by the application about to be
designed are described in this field. This field’s
goal is to increase the understanding about the
users’ issues.
Needs: It describes what is necessary to be done
in order to solve the problems described in the
previous field (Problems).
Existing Solutions: It describes existing
solutions related to the ideas and interfaces to be
improved or included in the application about to
be designed for solving the identified problems.
The PATHY technique proposed in this paper
addresses users’ (persona) problems description
which other techniques (as shown in Table 1) do not
address. The identification of problems helps to
analyze which aspects the application must solve.
PATHY also has the existing solution field to help
comparing with other applications of the same
domain, bringing possible requirements for the
application to be designed. The presented
techniques do not include fields with characteristics
about similar applications.
We performed an empirical study to evaluate the
quality of possible requirements generated in the
personas and to collect the participants’ feedback on
using PATHY version 2.0. The steps for this study
were: Scenarios Elaboration, Training on the
PATHY technique, Creation of personas and Filling
the Feedback Questionnaire. These steps are
presented in Figure 4 and are described as follows.
We perform this study with eight Information
Systems graduate students. The students were
attending a class on Software Process in the Federal
University of the State of Rio de Janeiro. They also
signed a confidentiality term to maintain the
anonymity of their data. By signing this term, they
agreed to provide collected data for analysis and
As a previous assignment, the participants had
defined a software development process for a
fictional company. As part of this process, they
elaborated scenarios describing an application that
would be developed. The scenarios were also used in
this study to create the personas. Prior to the
personas creation, the participants had already
identified some requirements for the application.
They were about to develop the application and had
already started the requirements elicitation process.
Figure 4: Steps to perform study.
Table 2 presents the description of the scenarios.
They development the three scenarios in groups: two
students created Scenario A (SA); two other students
created Scenario B (SB) and four students created
Scenario C (SC). At all, six personas were created,
as shown in Table 2.
ICEIS 2017 - 19th International Conference on Enterprise Information Systems
Table 2: Description of application scenarios selected by
the participants and related personas.
Before the creation of tge personas, all participants
had a 40 minutes training with a PATHY use
example. After the training, the participants had
created personas using the PATHY 2.0 technique.
After creating the personas, the participants had
answered a questionnaire containing
open questions about the usage of the technique.
Table presents these questions. After the
participants had created the personas, we analyzed
their descriptions to verify all the generated possible
Figure 5 presents an example of a persona
(persona P1 for SA) following the PATHY 2.0
Table 3: Feedback questionnaire.
The extracted information of the created personas
presents behavioral aspects, i.e, characteristics that
directly contribute to development the application to
be designed.
The identified characteristics as parts of the
personas’ descriptions can generate possible
requirements for an application. These parts,
extracted from the descriptions, represent situations
or personas’ characteristics to help thinking about
possible requirements for an application.
Figure 5: Example of Persona (P1) for Scenario A (SA) created using PATHY 2.0 template.
Identifying Possible Requirements using Personas - A Qualitative Study
We performed the analisys as follows: we extracted
some parts of the personas’ descriptions and then we
identified possible requirements of the application.
In Table 2, we present the analysis of the elaborated
personas for the listed applications.
5.1 Personas Analysis
Besides identifying possible requirements, two
researchers classified them using the following
categories (Buisine et al., 2016): (1) Users’ Needs:
users’ expressed ideas with no reference to any
application or how to fulfill these needs, for
example: “He is afraid of failing”; (2) Product
Functions: users’ desires about product features but
with no reference to concrete solutions, for example:
“For an app to catch my attention all my friends
have to use it too”; (3) Technical Solutions: direct
reference to technologies or components, for
example: “The mobile app for managing contacts
could be used to manage customers”. In addition to
those three categories, we included a new one: (4)
Experience: Characteristics to allow identifying if
the user has experience about other applications /
technologies. In this category, there are no direct
references about applications/technologies, for
example: “he uses cell phones”. We calculated the
Cohen’s Kappa to measure the degree of agreement
between the two researchers (Fleiss, 1981). Kappa is
a measure of interobserver agreement and measures
the degree of agreement beyond what would be
expected by chance alone (Landis and Koch, 1977).
We obtained 0,614 as a result for Kappa. According
to the interpretation of Kappa suggested by Landis
and Koch (1977), the obtained result indicates the
level of significative agreement among the
researchers. Figure 6 shows the amount of possible
requirements types generated from each persona.
The information presented in Figure 6 is described
as follows.
Figure 6: Amount of possible requirements for each
The participants created personas P1 and P2 for SA
(Educational Quiz application). Persona P1
generated 20 possible application requirements.
From these 20 possible requirements, six described
users’ needs, five described experiences, five
described product functions and four described
Technical Solutions. Table 4 presents some
examples of possible requirements for P1.
Table 4: Examples of Possible Requirements generated in
From P2, we identified 16 possible requirements,
where eight described users’ needs, five described
experiences, two described product functions and
one described a Technical Solution. Table 5 presents
some examples of these possible requirements.
ICEIS 2017 - 19th International Conference on Enterprise Information Systems
Table 5: Examples of Possible Requirements generated in
For SB (scenario of the application for generating
management reports from text files), the participants
created one persona - P3. From this persona, they
generated 17 possible requirements, where seven
described users’ needs, five described experiences,
five described product functions and five described
Technical Solutions. Table 6 presents some
examples of the generated possible requirements.
Table 6: Examples of Possible Requirements generated in
For SC (Scenario of an application for Purchasing
process automation), the participants elaborated
three personas: P4, P5 and P6. The amount of
possible requirements generated for P4 was 32.
From those 32 possible requirements, ten described
users’ needs, five described experiences, nine
described product functions and eight described
Technical Solutions. Table 7 presents some possible
requirements generated for this application.
Table 7: Examples of Possible Requirements generated in
From persona P5, we identified seven possible
requirements; two described users’ needs, two
described experiences, two described product
functions and one described Technical Solutions.
Table 8 lists some identified possible requirements.
Table 8: Examples of Possible Requirements generated in
From persona P6, we identified 21 possible
requirements. From those, four described users’
Identifying Possible Requirements using Personas - A Qualitative Study
needs, nine described experiences, six described
product functions and two described Technical
Solutions. Some of these possible requirements are
described in Table 9.
Table 9: Examples of Possible Requirements generated in
When analyzing the generated personas, we
observed which possible requirements types were
described in the personas. The most described type
of possible requirement in personas was users’ needs
(37 possible requirements in total), i.e., most
personas provide ideas about what the user needs,
but they do not present many references to solutions.
The second type of most described possible
requirement was Experiences (31 possible
requirements), allowing to identify if the user is a
newcomer or experienced. The third most described
possible requirement was about Product Functions
(29 possible requirements), i.e., personas provide
information about which features are desired in the
product, but no concrete solutions are presented.
Finally, the least identified possible requirement was
about Technical Solution (16 possible requirements),
i.e., these descriptions are not focused on identifying
the solution to be used but they present some
references that lead to solutions. In the following
paragraphs, we summarize which types of possible
requirements are generated from each PATHY field.
Therefore, we can have a goal overview of the
technique fields.
“How” and “Context”: Participants described
preliminary information about the problem to be
solved in these fields. They started to empathize
with the users. They described concerns and
frustrations able to motivate the development of the
application. For example, in SA – P1, in the ‘Who’
field, the “Hard paying attention to class” part can
be a motivation for creating the educational Quiz to
help attracting students’ attention. While in SC – P4,
in the ‘Who’ field, the “I get frustrated when realize
I lost money due to a lack of sales control” extract
can motivate improving sales control with the
application to be developed.
“Technology Experience”: Experiences lived by
the persona (user) and the user interface types that
the persona uses, were described in this field,
making it possible to have an idea about how the
interface design should be done for this persona.
Nevertheless, we also found out information about
mentioned application features that were not
detailed. For example: in SC – P4, one can read that
“he does not like apps with messy navigation…”. In
such extract it is not clear what does it mean to have
a messy navigation.” Therefore, some adjustments
to guide the questions are still needed, to provide
information that is more detailed, and help the
application design.
“Problems” and “Needs”: Problems that lead to
identifying possible functional requirements for the
application were described in these fields. For
example: in SA – P1, one can read that “Lack of
competitiveness to arouse the interest of being a
better student”, which gives an idea that the quiz
should generate competitiveness. In some cases,
features were also described. For example:
“Automatically sent and generated receipts.”
“Existing Solutions”: Similar applications to be
used as basis for the application being designed are
described in this field. For example: in SA – P1, one
can read that “the ‘Perguntados’ Game offers a
similar quiz.” Examples about how to solve
mentioned problems were also presented. For
example: in SC – P4, one can read that the “App
communicates with the local database, which has a
stock copy to control products sale. This is then
updated to the server.” The techniques presented in
Table do not have this information in their
description. Therefore, using those techniques, it is
not possible to compare the application that is being
designed with other existing applications.
5.2 Qualitative Analysis
To evaluate the participants’ perception about
PATHY, we performed a qualitative analysis of the
answers provided in the questionnaires. Qualitative
methods provide a better understanding of issues
ICEIS 2017 - 19th International Conference on Enterprise Information Systems
that require more specific and detailed analysis;
allowing human behavior and thinking to be
considered when understanding the object of study
(Seaman, 2008). The qualitative analysis performed
in this work is based on Grounded Theory (GT)
procedures; mainly coding, i.e., the process of
assigning meaning to data (Strauss e Corbin, 1998).
While analyzing the questionaries data, we
created codes associated to text fragments (open
coding). Another researcher reviewed the codes
related to the citations of each transcript of the
questionnaire. This researcher verified the codes and
categories to audit the coding process in order to
mitigate an eventual bias caused by having a single
researcher in the coding process.
After the open coding, we started the axial
coding phase by creating relationship codes. We
identified three main categories: (a) difficulties; (b)
lack of users in the creation of personas and (c)
usefulness. The categories are described as follows.
The difficulties found during PATHY usage
were the following:
Some participants considered that the technique
generates doubts regarding if they should describe
the personas’ feelings or the characteristics for an
“(...) sometimes I kept thinking during the
questions about the characteristics of the personas if
I should report the feeling regarding the application
or my personal feeling.”– P4
Another encountered difficulty was regarding the
reporting of what the persona disliked (see quotation
from participant 1 - P1) and that the lack of
knowledge about similar applications turns it harder
to fill (see quotation from participant 3 - P3):
“I only had difficulty in the items which discuss
what the persona does not like because I had to
hypothetically remember.” – P1
“Lack of knowledge about similar applications
and about more popular ones turn filling the tables
even harder.” – P3
These difficulties are regarding the guiding
questions that support the creator of the persona in
describing the characteristics of other applications.
On the other hand, some participants mentioned that
thinking about similar applications helps them
identify requirements:
“(...) the vision of similar solutions helps to see
how requirements can be improved, which simplifies
the usage of the technique.” – P2
“In this technique we developed information
regarding the application and we addressed positive
and negative points of similar applications, making
it possible to compare them.”P3
“Searching for similar solutions help us to find
issues in other applications and how to make our
application become unique.” – P2
Another identified category was the user absence
in the process of creating personas. The participants
mentioned that if the elicitation was performed with
real users, it would generate information that is more
“I think that if the elicitation was directly
conducted with end users, it would generate more
precise data about what they want from our
product.” – P1
“Imagining a persona and creating his/her
preferences may not reflect most users’ reality. It
would be more interesting to have a direct elicitation
with users.” – P3
Regarding not having the user during the
creation of personas, the participants mentioned:
“The most striking negative aspect is to make
sure that the created persona will intentionally use
the application” – P2
“Even if the information is creatively inserted, it
may not be compatible and may be against real
information.” – P3
One participant was not sure if PATHY could
help with user/customer interaction:
“A negative aspect (...) is to be sure (...) whether
the customer interaction would be facilitated
because of having the imagined user (persona).”
Despite the participants discussing the lack of
users during the creation of personas, they
mentioned some features that turn PATHY useful.
The identified aspects regarding the usefulness of
PATHY are described as follows:
PATHY can help to identify aspects in order to
improve the user experience with the application:
“The view of similar solutions helped verifying
how requirements could be (…). For example: using
simple colors, such as blue and white, reflect the
Facebook interface (…), then a user can feel more
comfortable using the application, as it is similar to
something popular.” – P2
Identifying Possible Requirements using Personas - A Qualitative Study
“(...) It is easy to identify requirements (…),
since besides identifying others aspects about the
users’ behavior (technological expertise level,
references of other applications they like or unlike,
others). – P4
The PATHY technique helps the developer to
empathize with the users: “(…) it allows an
immersion in the user’s thoughts and in his life. – P2
The participants also mention that PATHY was
useful to help understanding the problem to be
“When trying to deal with the problem from a
user's perspective, you can better see how your
product solves a problem and have an idea about the
environment in which your product will be
embedded (for example, this allows me to think
about integrations with other applications). This is
very positive.” – P5
They also considered PATHY useful to elicit
“The requirements of the application were easily
identified as the personas’ needs were arrising”
Some participants mentioned requirements they
identified using PATHY:
“(...) add chat feature for users”– P6
“The social interaction is an important aspect to
be considered because it can define the interest of
end users (students) in our application.” – P1
“(...) the technique helped me think about
possible integrations with other applications” – P6
This paper presents a study to verify how PATHY
2.0 describes personas and to collect the
participants’ feedback about the technique. PATHY
uses guiding questions to help describing personas to
focus in finding characteristics for the application.
From this study results, we identified that the
PATHY technique generates relevant characteristics
for the development of an application, for example:
functional requirements, characteristics of other
application which users are familiar with, and
motivations for them to use the application.
Furthermore, participants considered the technique
useful in order to learn about the user for whom the
application will be designed. Also, they indicated
that the technique was helpful for the requirements
Despite its advantages, the PATHY technique
stills needs some improvements. The guiding
questions should be modified so software engineers
can be able to describe characteristics that are more
detailed about the applications that the persona likes
or does not like and similar applications.
Furthermore, one of the criticisms for the PATHY
technique is the lack of users during the
development of personas. However, the PATHY
technique can also be used when there are users to
performer searches. When there are not available
users, software engineers should perform internet
searches or searches in app stores in order to
understand users by using the guiding questions
from the technique. In this study, we did not used
information about real users because we perform the
study in the class.
As future work, we will improve the guiding
questions to generate possible requirements that are
more detailed. Therefore, we will perform a study in
an industry context with an improved version of the
PATHY technique and compare the technique with
other traditional requirements elicitation method
such as the GORE approach (Anwer and Ikram,
We thank all the students who participated in the
empirical study. We acknowledge the financial
support granted by CNPq, FAPEAM through
process number 062.00578/2014; CAPES through
process number 175956/2013, FAPERJ (projects E-
26/203.446/2015–BBP, E-26/210.643/2016, E-
211.174/2016) and UNIRIO (grant PQ-UNIRIO
Acuña, S. T., Castro, J. C., Juristo, N., 2012. A HCI
technique for improving requirements elicitation. In:
Journal of Information and Software Technology v.
54, n. 12 (2012), p.1357-1375.
Anvari, F., Tran, H. M. T., 2014. Holistic Personas and
Reflective Concepts for Software Engineers. In:
Proceedings of the 8th European Conference on IS
Management and Evaluation: ECIME 2014. Academic
Conferences Limited, p. 20-27.
Anwer, S., Ikram, N., 2006. Goal Oriented Requirement
Engineering: A Critical Study of Techniques. In:
Software Engineering Conference. APSEC 2006. 13th
Asia Pacific. IEEE, 2006, p. 121-130.
ICEIS 2017 - 19th International Conference on Enterprise Information Systems
Aoyama, M., 2007. Persona-scenario-goal methodology
for user-centered requirements engineering. In: 15th
IEEE International Requirements Engineering
Conference (RE 2007). IEEE, p. 185-194.
Bratsberg, H. M., 2012. Empathy Maps of the FourSight
Preferences. Creative Studies Graduate Student
Master’s Project. Buffalo State College. Paper 176.
Bhowmik, T., Niu, N., Mahmoud, A., Savolainen, J.,
2014. Automated support for combinational creativity
in requirements engineering. In: Requirements
Engineering Conference (RE), 2014 IEEE 22nd
International. IEEE, p. 243-252.
Buisine, S., Guegan, J., Barré, J., Segonds, F., Aoussat, A.,
2016. Using avatars to tailor ideation process to
innovation strategy. In: Cognition, Technology &
Work, v.18, n. 13, p. 583-594.
Castro, J. W., Acuña, S. T., Juristo, N., 2008. Enriching
requirements analysis with the personas technique, In:
Proceedings of the International Workshop on:
Interplay between Usability Evaluation and Software
Development (I-USED 2008), p. 13-18.
Cooper, A., 1999. The inmates are running the asylum:
Why high-tech products drive us crazy and how to
restore the sanity, in Sams Publishers.
Ferreira, B. M., Barbosa, S. Conte, T.U., 2015. Eliciting
Requirements using Personas and Empathy Map to
Enhance the User Experience. In: 29th Brazilian
Symposium on Software Engineering, 2015, Belo
Horizonte, p.80 – 89.
Fleiss, J. L., 1981. Statistical Methods for Rates and
Proportions, Second ed., John Wiley & Sons, New York.
Gray, D., 2010. Brown, S., Macanufo, J. Gamestorming –
A playbook for innov ators, rulebreakers and
changemakers. Sebastopol, CA: O’Reilly Media.
Grudin, J. e Pruitt, J., 2002. Personas, participatory design
and product development: An infrastructure for
engagement. In: Participation and Design Conference.
p. 144-152.
Guo, F. Y., Shamdasani, S., Randall, B., 2011. Creating
effective personas for product design: insights from a
case study. In: International Conference in
Internationalization, Design and Global Development.
Springer Berlin Heidelberg, p. 37-46.
Idoughi, D., Seffah, A., Kolski C., 2012. Adding user
experience into the interactive service design loop: a
persona-based approach. In: Journal of Behaviour &
Information Technology. v. 31, n. 3(2012), p. 287- 303.
Landis, J. R., Koch, G. G., 1977. The measurement of
observer agreement for categorical data. Biometrics
1977; 33, pp. 159-174.
Marsden, N., Haag, M., 2016. Stereotypes and Politics:
Reflections on Personas. In: Proceedings of the 2016
CHI Conference on Human Factors in Computing
Systems. ACM, 2016. p. 4017-4031.
Mashapa, J., Chelule, E., Van Greunen, D. e Veldsman.
A., 2013. Managing User Experience–Managing
Change In: Human-Computer Interaction, INTERACT
2013. Springer, p. 660-677.
Osterwalder, A., Pigneur, Y., 2013. Business Model
Generation. Alta Books Editora.
Pruitt, J., Adlin T., 2010. The persona lifecycle: keeping
people in mind throughout product design. Morgan
Schneidewind, L., Horold, S., Mayas, C., Kromker, H.,
Falke, S., Pucklitsch, T., 2012. How personas support
requirements engineering. In: Usability and
Accessibility Focused Requirements Engineering
(UsARE), p. 1–5.
Seaman, C., 2008. Qualitative Methods. Shull et al. (eds.)
Guide to Advanced Empirical Software Engineering,
Springer, p. 35- 62.
Strauss, A., Corbin, J., 1998. Basics of Qualitative
Research: Techniques and Procedures for Developing
Grounded Theory. Thousand Oaks, CA, SAGE
Thalen, J.P.,Voort, M.C. van der., 2014. Virtual personas:
A case study on truck cabin design. In: Third
International Conference, DUXU 2014, Held as Part
of HCI International 2014, p. 357 - 368.
Väänänen-Vainio-Mattila, K., Roto, V., Hassenzahl, M.,
2008. Towards practical user experience evaluation
methods. E. L. C. Law, N. Bevan, G. Christou, M.
Springett & M. Lárusdóttir (eds.) Meaningful
Measures: Valid Useful User Experience
Measurement (VUUM), p. 19-22.
Viana, G., Robert, J. M., 2016. The Practitioners’ Points
of View on the Creation and Use of Personas for User
Interface Design. In: International Conference on
Human-Computer Interaction. Springer International
Publishing, p. 233-244.
Identifying Possible Requirements using Personas - A Qualitative Study