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

preferences.

1 INTRODUCTION

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

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

technique.

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 BACKGROUND

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

techniques.

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

requirements.

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,

2012).

Figure 2: Empathy Map Template (Osterwalder e Pigneur,

2013).

3 PATHY TECHNIQUE

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

follows.

 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

concerns.

 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.

4 EMPIRICAL STUDY

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

publication.

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

requirements.

Figure 5 presents an example of a persona

(persona P1 for SA) following the PATHY 2.0

template.

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 RESULTS

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

application.

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

P1.

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

P2.

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

P3.

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

P4.

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

P5.

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

P6.

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

application:

“(...) 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

precise.

“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

solved:

“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

requirements:

“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

6 CONCLUSIONS

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

identification.

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,

2006).

ACKNOWLEDGEMENTS

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

01/2016).

REFERENCES

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

Kaufmann.

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

publications.

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