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.