=Paper=
{{Paper
|id=Vol-407/paper-5
|storemode=property
|title=Enriching Requirements Analysis with the Personas Technique
|pdfUrl=https://ceur-ws.org/Vol-407/paper5.pdf
|volume=Vol-407
|dblpUrl=https://dblp.org/rec/conf/iused/CastroAJ08
}}
==Enriching Requirements Analysis with the Personas Technique==
https://ceur-ws.org/Vol-407/paper5.pdf
Enriching Requirements Analysis with the Personas
Technique
John W. Castro Silvia T. Acuña Natalia Juristo
Departamento de Ingeniería Departamento de Ingeniería Facultad de Informática
Informática Informática Universidad Politécnica de Madrid
Universidad Autónoma de Madrid Universidad Autónoma de Madrid Campus de Montegancedo s/n
Calle Tomás y Valiente 11 Calle Tomás y Valiente 11 28660, Boadilla del Monte
28049 Madrid, Spain 28049 Madrid, Spain Madrid, Spain
john.castro@estudiante.uam.es silvia.acunna@uam.es natalia@fi.upm.es
ABSTRACT Two separate processes for building usable systems —one from
A thorough understanding of the users that interact with the SE to develop the system and another from HCI to improve
system is necessary to develop usable systems. The Personas usability— are not easily manageable. Software development and
technique developed by the human-computer interaction (HCI) usability design cannot be controlled and synchronized separately.
discipline gathers data about users, gains an understanding of Additionally, the likely overlap of activities across the two
their characteristics, defines fictitious personas based on this processes would reduce efficiency and increase costs. Milewski
understanding and focuses on these personas throughout the [15] claims that there are still problems with SE-HCI interactions
software development process. The aim of our research is to build that require more research. One of the major remaining obstacles
Personas into systems development following software to cooperation between HCI and SE is that there is little
engineering (SE) guidelines. The benefits to be gained are an knowledge and communication about the practices and techniques
understanding of the user which is not traditionally taken into of HCI in SE and vice versa.
account in SE. To do this, we had to undertake two types of tasks.
First, we modified the Personas technique to conform to the levels In this research, we propose modifying the HCI technique to
of systematization common in SE. We have called the modified assure that it is completely incorporated and assimilated in the SE
technique PersonaSE. Second, we incorporated the proposed development process. This step will benefit both disciplines, as it
technique into the software requirements analysis process. will promote an understanding between the SE and HCI activities
and techniques. We have chosen the Personas technique [8] used
Keywords in the HCI user analysis activity. This technique is useful for
Personas technique, usability, human-computer interaction, gathering, analysing and synthesizing the information related to
requirements analysis, software process. the users interacting with the software system. Personas helps to
focus software analysis and design on the features and goals of
the product’s end user [7]. Personas are detailed descriptions of
fictitious users, stressing their characteristics and goals based on
1. INTRODUCTION surveys of real end users. The quantitative and qualitative data
In recent decades, the HCI community has developed a variety of that are gathered, analysed and synthesized about the users are
techniques for improving software systems usability, but these used as background for designing the personas [10].
techniques are not very widespread in SE [17]. On the other hand,
software developers only receive basic usability training [12] and We have selected the Personas technique, as, even though it has
do not usually have the knowledge they need to build usable not been around for long (the first HCI literature citation dates
software. from 1999 [5]), it is a technique used routinely. Additionally,
encouraging results have been reported on the use of the Personas
technique in quite a few developments [2][11][4][7]. Its use is
especially widespread in Web development, although it can be
used to design any type of interactive software [5]. One indication
Permission to make digital or hard copies of all or part of this work for of the current impact of personas is that the Microsoft MSN
personal or classroom use is granted without fee provided that copies are Personas gateway (http://advertising.msn.com/home/
not made or distributed for profit or commercial advantage and that MSNPersonas.asp) uses this technique in its marketing strategy to
copies bear this notice and the full citation on the first page. To copy attract advertisers, showing concern about who its users are.
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee. However, the Personas technique does not include a detailed
definition of the basic process elements—activity and product—,
I-USED’08, September 24, 2008, Pisa, Italy which would enable its introduction into the SE development
process to enrich the requirements analysis activity.
The goal of our work is to analyse the Personas technique and and a photograph to make it more life like. The narrative should
make the modifications required to conform to the levels of be one to two pages long and should not cover all the observed
systematization and method characteristic of SE. We have called details, as ideally the team members will have participated in the
this modification of the Personas technique PersonaSE. These interview phase, and people outside the team do not need to know
modifications adapt Personas for incorporation and use in the SE the interview details [7]. When the personas have been
development process analysis activity. Finally, we enrich the documented and the materials are finished, a meeting should be
software process analysis activity by establishing the relationships arranged with the team of developers to present the personas [16].
between the proposed PersonaSE technique activities and the
traditional SE requirements analysis activities to enable the 3. PERSONAS TECHNIQUE
software engineer to put Personas into routine use. MODIFICATIONS
This paper has been structured as follows. Section 2 describes the To be able to build personas into routine software development,
Personas technique. Section 3 presents the analysis of the the technique needs to conform to the guidelines on
weaknesses of the latest version of Cooper and colleagues’ systematization and definition of certain elements of the SE
Personas [8], as well as suggested modifications. Section 4 software process. More to the point, the technique needs to be
presents the proposed PersonaSE technique. In section 5, we defined by its activities and the outputs associated with each
detail the enrichment of the SE requirements analysis process, activity to be fit into SE. To add these elements to Personas, first
discussing the relationships between the PersonaSE and routine we analysed the criticisms of the latest version of Cooper and
SE requirements analysis activities. Finally, section 6 discusses colleagues’ technique [8], proposing improvements that have an
the conclusions. impact on such weaknesses. Second, we systematized the
decomposition of Personas into activities and defined an output
for each activity.
2. PERSONAS TECHNIQUE
The Personas technique provides an understanding of the system To make all these modifications we selected the latest version of
user in terms of his or her characteristics, needs and goals to be the Personas technique [8], because i) Cooper authored the
able to design and implement a usable system. This method is original proposal, ii) versions by other authors were based on this
attributed to A. Cooper [6], who later upgraded the method in [7] proposal, and iii) it has been successfully used in different
and [8]. Several methods for successfully creating personas have software development projects (see [11][4][18][9]).
been proposed on this basis [10][11][18]. To assure that the
Table 1 is an assessment of Cooper and colleagues’ Personas [8]
design focus is on user considerations, this method does not take
with respect to two criteria, Procedure Definition and Product
into account real users participating in the design process; it
Formalization and their associated attributes. The attributes of the
creates fictitious users, called personas. These personas specify
Procedure Definition criterion are: a) What does the procedure
the target user. The development efforts are focused on these
do? and b) How does the procedure work? Criterion a) evaluates
personas. Personas main potential benefit is that it serves the
how well the technique defines what a step should do (the
explicit development objective [2].
possible values are Implicit, Semi-Explicit and Explicit). Criterion
The Personas technique is based on a survey of users that can be b) evaluates how well the technique defines what techniques and
used to tightly couple the key characteristics and goals of the procedures should be used to perform a step (the possible values
personas to the user data [10][11][7]. When he was working for are Undefined, Semi-Defined and Defined). The Product
Cooper Interactive, Goodwin [10] suggested that personas should Formalization criterion also has two attributes: a) Product
mainly be based on qualitative data, gathered through interviews Content (the possible values are Undefined, Semi-Defined and
and observations. Cooper and Reimann [7] share Goodwin’s view Defined); and b) Product Structure (the possible values are
and detail the social research methods they recommend. These Informal, Semi-Formal and Formal).
methods focus on user goals and take into account user domains.
Table 1 is a summary of the values of the characteristics assigned
The data gathered from the observations and interviews are to each step of the Personas technique [8] for each analysed
mapped to behavioural variables. The mapping does not need to criterion. As Table 1 shows, What does the procedure do? is the
be overly precise. The important thing is for the mapping of only attribute that takes the explicit value for almost all the steps
different interview subjects to be correct. A number of interview of the Personas procedure, i.e. the procedure is declarative and
subjects grouped within a set of behavioural variables forms a indicates what to do in most steps. Looking at the How does the
behavioural model. A behavioural model is the basis of a persona. procedure work? attribute, we find that over 70% of the steps of
If detailed data are added to the behavioural model, it becomes a the Personas technique take the value of either undefined or semi-
persona. Once personas have been created, they need to be defined. Therefore, this procedural attribute is not completely
documented and shared with team members. The communication defined in most of the Personas steps. The Product Content
of personas has been recognized as a key factor for software attribute takes the value of undefined and semi-defined in over
project success [16][1]. In a failed application of the Personas 70% of the Personas technique steps, reflecting, like the last
technique, reported by Blomquist and Arvola [3], lack of attribute, weaknesses in this respect. Product Structure is the
communication was identified as the main ground for the failure. worst rated attribute, as almost 60% of the Personas technique
To prevent this failure, Cooper and Reimann [7] mention two steps are given the poorest rating, informal, for this attribute, and
basic deliverables for each created persona: a list of its key none of the steps have a formally defined product structure. This
characteristics and a third-person narrative of the persona. Cooper is evidence that the Product Formalization criterion needs more
and Reimann stress the importance of the persona having a name modification. Also, changes need to be made to how each
Personas step is carried out in order to reach the levels of weaknesses specified in Table 1. This new proposal, called
systematization demanded by SE. PersonaSE, is described in the next section.
Table 1. Summary of the Assessment of the Personas Technique
CRITERION PROCEDURE DEFINITION PRODUCT FORMALIZATION
4. PERSONASE TECHNIQUE
The PersonaSE technique that we propose consists of a set of
STEPS OF THE CHARACTERISTIC Product Product
PERSONAS TECHNIQUE [8]
What? How?
Content Structure interrelated activities that lead to the creation of personas and ease
Step 1: Identify Behavioural
Semi-explicit Semi-defined Semi-defined Semi-formal
the incorporation of the usability mechanisms from the SE
Variables
requirements analysis activities, thereby helping to improve the
Step 2: Map interview subjects to
Explicit Undefined Semi-defined Informal
behavioural variables usability of the software system that is to be developed.
Step 3: Identify significant behaviour
Semi-explicit Semi-defined Undefined Informal
patterns Table 2 presents all the activities making up the PersonaSE
Step 4: Synthesize characteristics and
relevant goals
Explicit Semi-defined Semi-defined Informal technique. For each activity we outline objectives, techniques and
Step 5: Check for redundancy and
Explicit Semi-defined N/A N/A associated products. The new activities proposed are shown on a
completeness
Step 6: Expand the description of
grey background.
Explicit Defined Defined Semi-formal
attributes and behaviours
Paso 7: Designate persona types Explicit Defined Semi-defined Informal In activity 1 -State hypotheses- we formulate the list of initial
hypotheses for the personas that are to be created, and develop
and interview the future system users. This produces the
For example, Cooper and colleagues [8] assume in Step 1 -
transcribed interviews, from which the information required to
Identify Behavioural Variables- that the users have already been
carry out the other activities is gathered. In activity 2 -Identify
interviewed and the gathered data have been organized. This is an
Behavioural Variables-, the full List of Behavioural Variables is
implicit step, which should be listed as the first explicit step of the
identified from the Interview Synthesis.
technique. To improve this aspect, we propose adding an initial
activity in the personas construction process, called State Activity 3 -Map Interview Subjects to Behavioural Variables
Hypotheses. This new activity aims to state initial personas outputs the Ranges of Behavioural Variables and Mapping of
hypotheses and gather the data required from potential future Interview Subjects. These products are the input for activity 4 -
users and then identify the behavioural variables in a later activity Identify Significant Behaviour Patterns, where the Significant
using the creativity-building techniques proposed in this paper Behaviour Patterns are identified and the Group Percentage Table
(see Table 2). Additionally, we define two new documents that is generated. This is the source of the personas. The Personas
consist, respectively, of a justified List of Personas Hypotheses Foundation Document is put together during activity 5 -
for activity 1 and a List of Behavioural Variables for activity 2 Synthesize Characteristics and Relevant Goals-. This document
(see Table 2). In Step 5 - Check for Completeness and contains the full definition of a persona. Activity 6 -Check for
Redundancy-, Cooper and colleagues [8] do not specify any Redundancy and Completeness- is carried out to locate
product associated with this step, and it is rated as N/A (see Table information gaps that need to be filled. Additional interviews may
1), that is, not applicable. In our version of the personas technique be required for this purpose. They may discover behaviours
we suggest that participatory meetings be held to evaluate the outside the behavioural spectrum, which would have an impact on
models obtained and that they be recorded in a Validation other activities. The Validation Document is the input for activity
Document (see Table 2). 7 - Expand the Description of Attributes and Behaviours-. This
activity outputs a narrative for each of the created personas, that
The other steps of Cooper and colleagues’ Personas technique [8]
is, a one-page document describing the persona and a typical day
have been analysed similarly. This analysis is available at
in the life of that persona.
http://arantxa.ii.uam.es/~sacuna/PersonaSE/modificacion and is,
for reasons of space, not detailed in this paper. In activity 8 -Relate Behaviour Patterns to Usability Mechanisms-
the behavioural patterns or created personas are related to
The aim behind the Personas technique is to adapt the system to
different usability mechanisms, and these relationships are
the future system users. However, none of the steps in this
justified in a Pattern-Usability Mechanism Relationship
technique includes usability mechanisms (e.g. provides undos,
Document. All the information gathered from the above activities
alerts, wizards, feedbacks, etc.) connected to the defined personas.
is used in activity 9 -Designate Persona Types- in order to
In our paper, we have identified the usability mechanisms (undo,
associate the persona type with each persona. In activity 10 -Build
cancel, etc.), imported from [14], that the different types of
Use Cases- use cases are built taking into account the
personas will need according to their characteristics and what they
relationships between the patterns and usability mechanisms.
expect of the software system. Following on from this line, the
Finally, in activity 11 -Build Mock-Ups-, mock-ups (also
aim of which is to consider usability in the early stages of the
containing the usability mechanisms for each persona) are built,
software development process, we have set out to incorporate
and the Mock-Up Evaluation Document is generated.
additional activities into the Personas technique that are helpful
for this purpose. These new activities are: a) Relate behaviour The PersonaSE technique has been used to design a Web-based
patterns to usability mechanisms; b) Build use cases; and c) Build Flight Booking System. This application, available at
mock-ups. Both use cases and mock-ups should include the http://arantxa.ii.uam.es/~sacuna/PersonaSE/aplicacion, gives a
usability mechanisms selected for each created persona. better understanding of how the PersonaSE technique works. This
system searches flights based on the selection, by defined
For each of the identified limitations, we have proposed a
personas, of dates, destination and origin, as well as the number
modification that can be easily incorporated into the Personas
of adult passengers.
technique. These modifications implement a new version based
on Cooper and colleagues’ Personas technique [8] that covers the
Table 2. Description of the PersonaSE Technique Activities
ACTIVITIES OBJECTIVES TECHNIQUES PRODUCTS
State preliminary hypotheses about the Based on the information gathered from the customer, the • List of
possible personas to be created. nature of the application domain and the organizational Hypotheses
documentation gathered at the previous meeting with the for Personas
Activity 1.1: Identify
customer, developers state hypotheses for personas. The
possible personas
technique we recommend for this purpose is brainstorming,
ACTIVITY 1: STATE
followed by a voting round at the end of the session to
HYPOTHESES
determine the most creative and feasible hypotheses.
Based on these hypotheses, investigate The interviews for each hypothesis are conducted based on • Transcribed
Activity 1.2: Hold
possible system users to find out their business domain knowledge and through the proposed Interviews
ethnographic
motivations and behaviours, gathering ethnographic interviews template.
interviews
behavioural data.
Synthesize the responses to all the Analyse the results of the survey conducted in activity 1. To do • Interview
Activity 2.1:
interviews. this, process all the responses to the transcribed interview Synthesis
ACTIVITY 2: Synthesize the
questions using Atlas.ti software (http://www.atlasti.com/) to
IDENTIFY Interview Responses
output the behavioural variables.
BEHAVIOURAL
VARIABLES Activity 2.2: List List all behavioural variables. Check Behavioural variables are selected by participative meetings. • List of
Behavioural identified hypotheses for validity. Then, compare these variables with the personas hypotheses to Behavioural
Variables validate these hypotheses. Variables
Activity 3.1: Identify For each behavioural variable identify At a participatory meeting, analyse the interview synthesis to • Ranges of
the Ranges of its range of possible values. identify the ranges of each behavioural variable. Behavioural
ACTIVITY 3: MAP Behavioural Variables
INTERVIEW Variables
SUBJECTS TO Represent exactly how the multiple Interview subjects are mapped according to the perception of • Mapping of
BEHAVIOURAL subjects are grouped with respect to the subjects’ observations and the interview responses. To do
Activity 3.2: Map Interview
VARIABLES
Interview Subjects each of the significant behavioural this, place each of the respondents in different ranges for each Subjects
variables. of the identified behavioural variables.
Identify particular groups of interview Examine the mappings of interview subjects from activity 3 • Significant
ACTIVITY 4: subjects occurring in more than one and build a table showing the percentage of interview subjects Behaviour
IDENTIFY range or variable. that share each of the behavioural variable range values. The Patterns
SIGNIFICANT
BEHAVIOUR
groups with the highest percentages are the significant • Group
PATTERNS
behaviour patterns. These are the source of the personas, which Percentage
are given a name and a photograph. Table
ACTIVITY 5: Synthesize characteristics and relevant Synthesize the data for each person identified in activity 4, • Personas
SYNTHESIZE goals. Describe the personas’ briefly specifying points about the behavioural characteristics Foundation
CHARACTERISTICS personalities. identified in the synthesis of the interviews (activity 2). Document
AND RELEVANT
GOALS
ACTIVITY 6: CHECK Check persona mappings, Check that the important identified aspects are fully defined in • Validation
FOR REDUNDANCY characteristics and goals. the personas created and models built through participatory Document
AND inspection meetings.
COMPLETENESS
ACTIVITY 7: Convey the attitudes, personality, Analyse the data collected and the personas foundation • Narrative
EXPAND THE needs and problems of the personas to document (activity 5) and synthesize the personal profile and a
DESCRIPTION OF other team members. typical day in the life of each persona. For each created
ATTRIBUTES AND persona, write a third-person narrative.
BEHAVIOURS
ACTIVITY 8: RELATE Relate each behaviour pattern to Based on information about the values of the behavioural • Pattern –
BEHAVIOUR usability mechanisms. variables for each identified persona and the interview Usability
PATTERNS TO responses, analyse the relationships between the behaviour Mechanism
USABILITY patterns and usability mechanisms imported from [14]. Relationship
MECHANISMS Document
Prioritize the created personas to Based on the description of each of the personas types and all • Persona
determine which should be the primary the analyses conducted throughout the personas creation Type
Activity 9.1: Select
design objective, that is, find just one process, determine the person types (primary, secondary). Each Association
Representative
primary persona whose needs and of the created personas is associated with a personas type.
Personas to Elicit
ACTIVITY 9: objectives can be completely and
Requirements
DESIGNATE positively satisfied by a single
PERSONA TYPES interface.
Determine what secondary persona Analyse the secondary persona foundation document and (Software
Activity 9.2: Enrich
needs are likely to enrich the system. narrative and search for functionalities not stated by the Requirements
the System with
primary persona that are useful for the system. Specification is
Secondary Personas
enriched)
Materialize the usability mechanisms First build the usual set of use cases, not including the usability • Use Cases
listed in activity 8 in the use cases. mechanisms, and then add these mechanisms taking into (with
ACTIVITY 10: BUILD
account the relationship between the behaviour patterns and the usability
USE CASES
above mechanisms, and the information specified in the mechanisms)
Personas Foundation Document.
Build mock-ups that include the Based on the use cases developed in the last activity and the • Mock-ups
Activity 11.1:
usability mechanisms. analysis of the relationship between the created personas and
Implement Mock-ups
ACTIVITY 11: BUILD usability mechanisms, build mock-ups.
MOCK-UPS Validate mock-ups. At participatory meetings, validate mock-ups. • Mock-up
Activity 11.2:
Evaluation
Evaluate Mock-ups
Document
5. INTEGRATION OF THE PERSONASE depending on his or her profile. Discussing the mock-up with
potential users will supply even more information.
TECHNIQUE INTO THE SOFTWARE
The PersonaSE activities offer the Requirements Analysis
REQUIREMENTS ANALYSIS PROCESS activity useful conceptual tools that supplement and/or extend
As PersonaSE helps to synthesize all the data available about the instruments usually used in the requirements analysis activity.
prospective system users and also to determine what it is that the They can analyse information and knowledge about the user,
product should do to satisfy the personas’ needs and profile, the model the user and help to model the system. In the following, we
best place in the development place to incorporate this new justify the linkage between the PersonaSE technique activities and
technique is the software requirements analysis process. To be the requirements analysis activities.
able to integrate PersonaSE into the software requirements STATE HYPOTHESES
HIPOTESIS
analysis process activities, each PersonaSE technique activity has Identify Possible Personas
to be assigned to the activities making up the requirements Hold Interviews
analysis process. This way, the requirements analysis activities
IDENTIFY VARIABLES REQUIREMENTS
will be modified because, apart from the routine tasks, List Behavioural Variables ELICITATION
requirements analysts will also have to perform new tasks taken Synthesize Interviews
from the PersonaSE technique. To define the SE requirements
analysis process activities, we considered SWEBOK (SoftWare MAP SUBJECTS TO VARIABLES
Identify Ranges
Engineering BOdy of Knowledge) [13]: Requirements Elicitation,
Map Subjects
Requirements Analysis, Requirements Specification and
Requirements Validation. The right-hand side of Figure 1 shows IDENTIFY PATTERNS
these four activities according to [13]. Each of these SE activity
SYNTHESIZE
types is linked to one or more PersonaSE technique activities CHARACTERISTICS
AND GOALS
(left-hand side of Figure 1). The directed lines in Figure 1 show
links between the PersonaSE technique and the four analysis CHECK FOR REDUNDANCY
AND COMPLETENESS
REQUIREMENTS
ANALYSIS
activities.
EXPAND THE DESCRIPTION
The PersonaSE technique offers the Requirements Elicitation OF ATTRIBUTES AND
BEHAVIOURS
activity additional information sources and resources for eliciting
RELATE BEHAVIOUR
knowledge to what are traditionally used in the SE requirements PATTERNS TO USABILITY
MECHANISMS
elicitation activity. The PersonaSE technique activities linked to
the requirements elicitation activity and their justification follow: DESIGNATE PERSONAS
Select Representatives
- Identify possible personas: state hypotheses for the personas to
Enrich with Secondary Personas HIPOTESIS
REQUIREMENTS
be created to determine who the possible interview subjects will SPECIFICATION
be. This is a preliminary step designed to find out things about the BUILD USE CASES
user.
BUILD MOCK-UPS
- Hold ethnographic interviews: these ethnographic interviews are Implement Mock-Ups
REQUIREMENTS
designed and held taking into account the stated personas HIPOTESIS
VALIDATION
Evaluate Mock-Ups
hypotheses. Interviewing is a means of eliciting information. Like
the other information acquisition sessions that are held to elicit
requirements, these interviews also have to be transcribed. Fig. 1. Relationships between the PersonaSE activities and SE
- Synthesize the interview responses: interview synthesis is based requirements analysis activities
on analysis, for which reason the analysis and synthesis of - Map interview subjects: by representing how multiple subjects
interviews are linked to the requirements elicitation analysis task. are grouped around the behavioural variables, we are modelling
- List behavioural variables: by synthesizing the interviews we the user. This has to do with the conceptual modelling that is
get the list of behavioural variables that are to somehow carried out in the requirements analysis activity.
characterize the possible users, thereby helping to find out things - Identify significant behaviour patterns: personas (archetypal
about the user. users) are the result of identifying particular groups of subjects in
- Identify the ranges of behavioural variables: these ranges are more than one range. This is, in the last analysis, equivalent to
identified by observing how the subjects are grouped around the user modelling.
behavioural variables. These groups characterize possible system - Synthesize characteristics and relevant goals: this brief
users, thereby providing greater knowledge of the user. description of characteristics and relevant goals, which reflects
- Relate behaviour patterns to usability mechanisms: this the personality of the created personas, is also helpful for
relationship provides information about what the possible users modelling the user.
need to interact with the system. - Expand the description of attributes and behaviours: the
- Select representative personas to elicit requirements: possible development of narratives provides a brief introduction to the
users are selected to participate in the routine requirements persona in terms of job or life style and conveys the persona’s
elicitation process, thereby helping to improve the knowledge attitudes, needs and problems to other team members. This is a
there is about the user. user model in the shape of a narrative.
- Implement mock-ups: building mock-ups provides information - Enrich the system with secondary personas: system modelling is
by explicitly stating what the user requires of the system extended by determining what functionalities the secondary
personas would add to the system.
- Build use cases: the use cases enriched with the behaviour [3] A. Blomquist, M. Arvola. (2002). Personas in Action:
pattern-dependent usability mechanisms are a system model. This Ethnography in an Interaction Design Team. Second Nordic
activity can therefore be linked to the system modelling Conference on Human-Computer Interaction. Proceedings of
traditionally performed in requirements analysis. NordiCHI, pp.197-200.
The PersonaSE activity Enrich system activity with secondary [4] S. Calde, K. Goodwin, R. Reimann. (2002). SHS Orcas. The
personas inputs information for writing requirements to the First Integrated Information System for Long-Term
Requirements Specification activity, which generally has to do Healthcare Facility Management. American Institute of
with drafting a document specifying the requirements that the Graphic Arts, New York. Available: http://www.aiga.org/
system should comply with and is concerned particularly with the resources/content/7/6/2/documents/FORUM\_calde\_case\_0
structure, quality and verifiability of that document: 32102.pdf.
[5] A. Cooper. (1999). The Inmates are Running the Asylum.
- Enrich the system with secondary personas: by determining Sams, Indianapolis.
what functionalities (not explained by the primary persona) the [6] A. Cooper. (2003). The Origin of Personas. Available:
secondary persona expects to find in the system, this activity http://www.cooper.com/insights/journal\_of\_design/articles/
inputs requirements for the Software Requirements Specification the\_origin\_of\_personas\_1.html.
document. [7] A. Cooper, R. Reimann. (2003). About Face 2.0: The
The PersonaSE technique activities related to Requirements Essentials of Interaction Design. Wiley, Indianapolis.
Validation are: [8] A. Cooper, R. Reimann, D. Cronin. (2007). About Face 3.0:
The Essentials of Interaction Design. Wiley, Indianapolis.
- Check for redundancy and completeness: mappings are checked,
[9] J. Dong, K. Kelkar, K. Braun. (2007). Getting the Most Out
as are the characteristics of the personas and their goals in order
of Personas for Product Usability Enhancements. Second
to find out whether there are any important gaps that need to be
International Conference on Usability and
filled in. This way, the developed models and products are
Internationalization. Proceeding of the UI-HCII, pp.291-296.
validated in both textual and graphical format.
[10] K. Goodwin. (2002). Getting from Research to Personas:
- Evaluate mock-ups: a document is drafted to record the results Harnessing the Power of Data. Available:
of the user evaluation of the mock-ups, thereby validating the set
http://www.cooper.
of mock-ups.
com/content/insights/newsletters/2002\_11/getting\_from\_re
search\_to\_personas.asp.
6. CONCLUSION [11] J. Grudin, J. Pruitt. (2002). Personas, Participatory Design
This work contributes towards building HCI knowledge into and Product Development: An Infrastructure for
routine SE practice. To do this, we modified the HCI Personas Engagement. Participatory Design Conference. Proceedings
technique to comply with the levels of systematization common in of the PDC, Computer Professionals for Social
SE, and we enriched the requirements analysis process by Responsibility, pp.144-161.
incorporating the PersonaSE activities into the four routine [12] A. Holzinger. (2005). Usability Engineering Methods for
requirements activities: requirements elicitation, requirements Software Developers. Communications of the ACM 48(1):
analysis, requirements specification and requirements validation. pp.71-74.
After adding PersonaSE to the four activities, the activities that [13] IEEE Computer Society Professional Practices Committee.
gained most were requirements elicitation and requirements (2004). Guide to the Software Engineering Body of
analysis, as PersonaSE introduces important innovations into Knowledge (SWEBOK- 2004 Version). IEEE Computer
these activities: i) elicit the characteristics of real users to create Society, Los Alamitos, CA.
fictitious personas based on the understanding of these users, and [14] N. Juristo, A. Moreno, M. Sánchez. (2007). Guidelines for
ii) model these personas. Eliciting Usability Functionalities. IEEE Transactions on
Software Engineering 33: pp.744-758.
The integration of personas and requirements analysis can better [15] A. Milewski. (2004). Software Engineers and HCI
identify what the software product should do and how it should Practitioners Learning to Work Together: A Preliminary
behave, as it shapes a common language to help to build an Look at Expectations. Proceedings of the 17th Conference on
understanding of the personas who are to interact with the system Software Engineering Education and Training CSEET´04
and match the system development to the characteristics of these IEEE, pp. 45-49.
personas. The next step is to determine the timeline for integrating [16] J. Pruitt, J. Grudin. (2003). Personas: Practice and Theory.
the PersonaSE technique activities into SE’s software Available: http://www.research.microsoft.com/research/coet/
requirements analysis process. Grudin/Personas/Grudin-Pruitt.pdf.
[17] A. Seffah, E. Metzker. (2004). The Obstacles and Myths of
7. REFERENCES Usability and Software Engineering. Communications of the
[1] T. Adlin, H. Jamesen, J. Pruitt. (2002). Personas: Exploring ACM 47(12): pp.71-76.
the Real Benefits of Imaginary People. Available: [18] K. Vasara. (2003). Introducing Personas in a Software
http://www.chiplace.org/ techniques/show-article.jsp?id=1. Project. Master's thesis, Helsinki University of Technology,
[2] H. Beyer, K. Holzblatt. (1998). Contextual Design: Defining Helsinki.
Customer-Centered Systems. Morgan Kaufmann Publishers,
San Francisco.