Enriching Requirements Analysis with the Personas Technique

Abstract

A thorough understanding of the users that interact with the system is necessary to develop usable systems. The Personas technique developed by the human-computer interaction (HCI) discipline gathers data about users, gains an understanding of their characteristics, defines fictitious personas based on this understanding and focuses on these personas throughout the software development process. The aim of our research is to build Personas into systems development following software engineering (SE) guidelines. The benefits to be gained are an understanding of the user which is not traditionally taken into 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 of systematization common in SE. We have called the modified technique PersonaSE. Second, we incorporated the proposed technique into the software requirements analysis process.

Keywords

• eol>Personas technique
• usability
• human-computer interaction
• requirements analysis
• software process

1. INTRODUCTION

In recent decades, the HCI community has developed a variety of techniques for improving software systems usability, but these techniques are not very widespread in SE [ 17 ]. On the other hand, software developers only receive basic usability training [ 12 ] and do not usually have the knowledge they need to build usable software.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Two separate processes for building usable systems —one from SE to develop the system and another from HCI to improve usability— are not easily manageable. Software development and usability design cannot be controlled and synchronized separately. Additionally, the likely overlap of activities across the two processes would reduce efficiency and increase costs. Milewski [ 15 ] claims that there are still problems with SE-HCI interactions that require more research. One of the major remaining obstacles to cooperation between HCI and SE is that there is little knowledge and communication about the practices and techniques of HCI in SE and vice versa.

In this research, we propose modifying the HCI technique to assure that it is completely incorporated and assimilated in the SE development process. This step will benefit both disciplines, as it will promote an understanding between the SE and HCI activities and techniques. We have chosen the Personas technique [ 8 ] used in the HCI user analysis activity. This technique is useful for gathering, analysing and synthesizing the information related to 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 surveys of real end users. The quantitative and qualitative data that are gathered, analysed and synthesized about the users are used as background for designing the personas [ 10 ].

We have selected the Personas technique, as, even though it has not been around for long (the first HCI literature citation dates 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 of the current impact of personas is that the Microsoft MSN Personas gateway (http://advertising.msn.com/home/ MSNPersonas.asp) uses this technique in its marketing strategy to attract advertisers, showing concern about who its users are. However, the Personas technique does not include a detailed definition of the basic process elements—activity and product—, 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 make the modifications required to conform to the levels of systematization and method characteristic of SE. We have called this modification of the Personas technique PersonaSE. These modifications adapt Personas for incorporation and use in the SE development process analysis activity. Finally, we enrich the software process analysis activity by establishing the relationships between the proposed PersonaSE technique activities and the traditional SE requirements analysis activities to enable the software engineer to put Personas into routine use.

This paper has been structured as follows. Section 2 describes the Personas technique. Section 3 presents the analysis of the weaknesses of the latest version of Cooper and colleagues’ Personas [ 8 ], as well as suggested modifications. Section 4 presents the proposed PersonaSE technique. In section 5, we detail the enrichment of the SE requirements analysis process, discussing the relationships between the PersonaSE and routine SE requirements analysis activities. Finally, section 6 discusses the conclusions.

2. PERSONAS TECHNIQUE

The Personas technique provides an understanding of the system user in terms of his or her characteristics, needs and goals to be able to design and implement a usable system. This method is attributed to A. Cooper [ 6 ], who later upgraded the method in [ 7 ] and [ 8 ]. Several methods for successfully creating personas have been proposed on this basis [ 10 ][ 11 ][ 18 ]. To assure that the design focus is on user considerations, this method does not take into account real users participating in the design process; it creates fictitious users, called personas. These personas specify the target user. The development efforts are focused on these personas. Personas main potential benefit is that it serves the explicit development objective [ 2 ].

The Personas technique is based on a survey of users that can be used to tightly couple the key characteristics and goals of the personas to the user data [ 10 ][ 11 ][ 7 ]. When he was working for Cooper Interactive, Goodwin [ 10 ] suggested that personas should mainly be based on qualitative data, gathered through interviews and observations. Cooper and Reimann [ 7 ] share Goodwin’s view and detail the social research methods they recommend. These methods focus on user goals and take into account user domains. The data gathered from the observations and interviews are mapped to behavioural variables. The mapping does not need to be overly precise. The important thing is for the mapping of different interview subjects to be correct. A number of interview subjects grouped within a set of behavioural variables forms a behavioural model. A behavioural model is the basis of a persona. If detailed data are added to the behavioural model, it becomes a persona. Once personas have been created, they need to be documented and shared with team members. The communication of personas has been recognized as a key factor for software project success [ 16 ][ 1 ]. In a failed application of the Personas technique, reported by Blomquist and Arvola [ 3 ], lack of communication was identified as the main ground for the failure. To prevent this failure, Cooper and Reimann [ 7 ] mention two basic deliverables for each created persona: a list of its key characteristics and a third-person narrative of the persona. Cooper and Reimann stress the importance of the persona having a name and a photograph to make it more life like. The narrative should be one to two pages long and should not cover all the observed details, as ideally the team members will have participated in the interview phase, and people outside the team do not need to know the interview details [ 7 ]. When the personas have been documented and the materials are finished, a meeting should be arranged with the team of developers to present the personas [ 16 ].

3. PERSONAS TECHNIQUE

MODIFICATIONS

To be able to build personas into routine software development, the technique needs to conform to the guidelines on systematization and definition of certain elements of the SE software process. More to the point, the technique needs to be defined by its activities and the outputs associated with each activity to be fit into SE. To add these elements to Personas, first we analysed the criticisms of the latest version of Cooper and colleagues’ technique [ 8 ], proposing improvements that have an impact on such weaknesses. Second, we systematized the decomposition of Personas into activities and defined an output for each activity.

To make all these modifications we selected the latest version of the Personas technique [ 8 ], because i) Cooper authored the original proposal, ii) versions by other authors were based on this proposal, and iii) it has been successfully used in different software development projects (see [ 11 ][ 4 ][ 18 ][ 9 ]).

Table 1 is an assessment of Cooper and colleagues’ Personas [ 8 ] with respect to two criteria, Procedure Definition and Product Formalization and their associated attributes. The attributes of the Procedure Definition criterion are: a) What does the procedure do? and b) How does the procedure work? Criterion a) evaluates how well the technique defines what a step should do (the possible values are Implicit, Semi-Explicit and Explicit). Criterion b) evaluates how well the technique defines what techniques and procedures should be used to perform a step (the possible values are Undefined, Semi-Defined and Defined). The Product Formalization criterion also has two attributes: a) Product Content (the possible values are Undefined, Semi-Defined and Defined); and b) Product Structure (the possible values are Informal, Semi-Formal and Formal).

Table 1 is a summary of the values of the characteristics assigned to each step of the Personas technique [ 8 ] for each analysed criterion. As Table 1 shows, What does the procedure do? is the only attribute that takes the explicit value for almost all the steps of the Personas procedure, i.e. the procedure is declarative and indicates what to do in most steps. Looking at the How does the procedure work? attribute, we find that over 70% of the steps of the Personas technique take the value of either undefined or semidefined. Therefore, this procedural attribute is not completely defined in most of the Personas steps. The Product Content attribute takes the value of undefined and semi-defined in over 70% of the Personas technique steps, reflecting, like the last attribute, weaknesses in this respect. Product Structure is the worst rated attribute, as almost 60% of the Personas technique steps are given the poorest rating, informal, for this attribute, and none of the steps have a formally defined product structure. This is evidence that the Product Formalization criterion needs more modification. Also, changes need to be made to how each Personas step is carried out in order to reach the levels of systematization demanded by SE. weaknesses specified in Table 1. This new proposal, called PersonaSE, is described in the next section. For example, Cooper and colleagues [ 8 ] assume in Step 1 Identify Behavioural Variables- that the users have already been interviewed and the gathered data have been organized. This is an implicit step, which should be listed as the first explicit step of the technique. To improve this aspect, we propose adding an initial activity in the personas construction process, called State Hypotheses. This new activity aims to state initial personas hypotheses and gather the data required from potential future users and then identify the behavioural variables in a later activity using the creativity-building techniques proposed in this paper (see Table 2). Additionally, we define two new documents that consist, respectively, of a justified List of Personas Hypotheses for activity 1 and a List of Behavioural Variables for activity 2 (see Table 2). In Step 5 - Check for Completeness and Redundancy-, Cooper and colleagues [ 8 ] do not specify any product associated with this step, and it is rated as N/A (see Table 1), that is, not applicable. In our version of the personas technique we suggest that participatory meetings be held to evaluate the models obtained and that they be recorded in a Validation Document (see Table 2).

The other steps of Cooper and colleagues’ Personas technique [ 8 ] have been analysed similarly. This analysis is available at http://arantxa.ii.uam.es/~sacuna/PersonaSE/modificacion and is, for reasons of space, not detailed in this paper.

The aim behind the Personas technique is to adapt the system to the future system users. However, none of the steps in this technique includes usability mechanisms (e.g. provides undos, alerts, wizards, feedbacks, etc.) connected to the defined personas. In our paper, we have identified the usability mechanisms (undo, cancel, etc.), imported from [ 14 ], that the different types of personas will need according to their characteristics and what they expect of the software system. Following on from this line, the aim of which is to consider usability in the early stages of the software development process, we have set out to incorporate additional activities into the Personas technique that are helpful for this purpose. These new activities are: a) Relate behaviour patterns to usability mechanisms; b) Build use cases; and c) Build mock-ups. Both use cases and mock-ups should include the usability mechanisms selected for each created persona. For each of the identified limitations, we have proposed a modification that can be easily incorporated into the Personas technique. These modifications implement a new version based on Cooper and colleagues’ Personas technique [ 8 ] that covers the Informal Informal Informal

N/A Semi-formal Informal

4. PERSONASE TECHNIQUE

The PersonaSE technique that we propose consists of a set of interrelated activities that lead to the creation of personas and ease the incorporation of the usability mechanisms from the SE requirements analysis activities, thereby helping to improve the usability of the software system that is to be developed.

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 transcribed interviews, from which the information required to carry out the other activities is gathered. In activity 2 -Identify Behavioural Variables-, the full List of Behavioural Variables is identified from the Interview Synthesis.

Activity 3 -Map Interview Subjects to Behavioural Variables outputs the Ranges of Behavioural Variables and Mapping of Interview Subjects. These products are the input for activity 4 Identify Significant Behaviour Patterns, where the Significant Behaviour Patterns are identified and the Group Percentage Table is generated. This is the source of the personas. The Personas Foundation Document is put together during activity 5 Synthesize Characteristics and Relevant Goals-. This document contains the full definition of a persona. Activity 6 -Check for Redundancy and Completeness- is carried out to locate information gaps that need to be filled. Additional interviews may be required for this purpose. They may discover behaviours outside the behavioural spectrum, which would have an impact on other activities. The Validation Document is the input for activity 7 - Expand the Description of Attributes and Behaviours-. This activity outputs a narrative for each of the created personas, that is, a one-page document describing the persona and a typical day in the life of that persona.

In activity 8 -Relate Behaviour Patterns to Usability Mechanismsthe behavioural patterns or created personas are related to different usability mechanisms, and these relationships are justified in a Pattern-Usability Mechanism Relationship Document. All the information gathered from the above activities is used in activity 9 -Designate Persona Types- in order to associate the persona type with each persona. In activity 10 -Build Use Cases- use cases are built taking into account the relationships between the patterns and usability mechanisms. Finally, in activity 11 -Build Mock-Ups-, mock-ups (also containing the usability mechanisms for each persona) are built, and the Mock-Up Evaluation Document is generated. The PersonaSE technique has been used to design a Web-based Flight Booking System. This application, available at http://arantxa.ii.uam.es/~sacuna/PersonaSE/aplicacion, gives a better understanding of how the PersonaSE technique works. This system searches flights based on the selection, by defined personas, of dates, destination and origin, as well as the number of adult passengers.

5. INTEGRATION OF THE PERSONASE

TECHNIQUE INTO THE SOFTWARE

REQUIREMENTS ANALYSIS PROCESS

As PersonaSE helps to synthesize all the data available about the prospective system users and also to determine what it is that the product should do to satisfy the personas’ needs and profile, the best place in the development place to incorporate this new technique is the software requirements analysis process. To be able to integrate PersonaSE into the software requirements analysis process activities, each PersonaSE technique activity has to be assigned to the activities making up the requirements analysis process. This way, the requirements analysis activities will be modified because, apart from the routine tasks, requirements analysts will also have to perform new tasks taken from the PersonaSE technique. To define the SE requirements analysis process activities, we considered SWEBOK (SoftWare Engineering BOdy of Knowledge) [ 13 ]: Requirements Elicitation, Requirements Analysis, Requirements Specification and Requirements Validation. The right-hand side of Figure 1 shows these four activities according to [ 13 ]. Each of these SE activity types is linked to one or more PersonaSE technique activities (left-hand side of Figure 1). The directed lines in Figure 1 show links between the PersonaSE technique and the four analysis activities.

The PersonaSE technique offers the Requirements Elicitation activity additional information sources and resources for eliciting knowledge to what are traditionally used in the SE requirements elicitation activity. The PersonaSE technique activities linked to the requirements elicitation activity and their justification follow: - Identify possible personas: state hypotheses for the personas to be created to determine who the possible interview subjects will be. This is a preliminary step designed to find out things about the user. - Hold ethnographic interviews: these ethnographic interviews are designed and held taking into account the stated personas 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. - Synthesize the interview responses: interview synthesis is based on analysis, for which reason the analysis and synthesis of interviews are linked to the requirements elicitation analysis task. - List behavioural variables: by synthesizing the interviews we get the list of behavioural variables that are to somehow characterize the possible users, thereby helping to find out things about the user. - Identify the ranges of behavioural variables: these ranges are identified by observing how the subjects are grouped around the behavioural variables. These groups characterize possible system users, thereby providing greater knowledge of the user. - Relate behaviour patterns to usability mechanisms: this relationship provides information about what the possible users need to interact with the system. - Select representative personas to elicit requirements: possible users are selected to participate in the routine requirements elicitation process, thereby helping to improve the knowledge there is about the user. - Implement mock-ups: building mock-ups provides information by explicitly stating what the user requires of the system STATHEIHPYOPTOESTIHSESES Identify Possible Personas

Hold Interviews IDENTIFY VARIABLES List Behavioural Variables

Synthesize Interviews MAP SUBJECTS TO VARIABLES

Identify Ranges

Map Subjects IDENTIFY PATTERNS

SYNTHESIZE CHARACTERISTICS

AND GOALS CHECK FOR REDUNDANCY

AND COMPLETENESS EXPAND THE DESCRIPTION

OF ATTRIBUTES AND

BEHAVIOURS

RELATE BEHAVIOUR PATTERNS TO USABILITY

MECHANISMS DESIGNATE PERSONAS

Select Representatives Enrich with Secondary Personas

BUILD USE CASES BUILD MOCK-UPS Implement Mock-Ups Evaluate Mock-Ups REQUIREMENTS ELICITATION REQUIREMENTS

ANALYSIS REQHUIPIORTEEMSEISNTS SPECIFICATION REVQAHULIPIIDORTAEEMTSIEIOSNNTS depending on his or her profile. Discussing the mock-up with potential users will supply even more information.

The PersonaSE activities offer the Requirements Analysis activity useful conceptual tools that supplement and/or extend instruments usually used in the requirements analysis activity. They can analyse information and knowledge about the user, model the user and help to model the system. In the following, we justify the linkage between the PersonaSE technique activities and the requirements analysis activities. - Map interview subjects: by representing how multiple subjects are grouped around the behavioural variables, we are modelling the user. This has to do with the conceptual modelling that is carried out in the requirements analysis activity. - Identify significant behaviour patterns: personas (archetypal users) are the result of identifying particular groups of subjects in more than one range. This is, in the last analysis, equivalent to user modelling. - Synthesize characteristics and relevant goals: this brief description of characteristics and relevant goals, which reflects the personality of the created personas, is also helpful for modelling the user. - Expand the description of attributes and behaviours: the development of narratives provides a brief introduction to the persona in terms of job or life style and conveys the persona’s attitudes, needs and problems to other team members. This is a user model in the shape of a narrative. - Enrich the system with secondary personas: system modelling is extended by determining what functionalities the secondary personas would add to the system. - Build use cases: the use cases enriched with the behaviour pattern-dependent usability mechanisms are a system model. This activity can therefore be linked to the system modelling traditionally performed in requirements analysis.

The PersonaSE activity Enrich system activity with secondary personas inputs information for writing requirements to the Requirements Specification activity, which generally has to do with drafting a document specifying the requirements that the system should comply with and is concerned particularly with the structure, quality and verifiability of that document: - Enrich the system with secondary personas: by determining what functionalities (not explained by the primary persona) the secondary persona expects to find in the system, this activity inputs requirements for the Software Requirements Specification document.

The PersonaSE technique activities related to Requirements Validation are: - Check for redundancy and completeness: mappings are checked, as are the characteristics of the personas and their goals in order to find out whether there are any important gaps that need to be filled in. This way, the developed models and products are validated in both textual and graphical format. - Evaluate mock-ups: a document is drafted to record the results of the user evaluation of the mock-ups, thereby validating the set of mock-ups.

6. CONCLUSION

This work contributes towards building HCI knowledge into routine SE practice. To do this, we modified the HCI Personas technique to comply with the levels of systematization common in SE, and we enriched the requirements analysis process by incorporating the PersonaSE activities into the four routine requirements activities: requirements elicitation, requirements analysis, requirements specification and requirements validation. After adding PersonaSE to the four activities, the activities that gained most were requirements elicitation and requirements analysis, as PersonaSE introduces important innovations into these activities: i) elicit the characteristics of real users to create fictitious personas based on the understanding of these users, and ii) model these personas.

The integration of personas and requirements analysis can better identify what the software product should do and how it should behave, as it shapes a common language to help to build an understanding of the personas who are to interact with the system and match the system development to the characteristics of these personas. The next step is to determine the timeline for integrating the PersonaSE technique activities into SE’s software requirements analysis process.

References

[1] T. Adlin , H. Jamesen , J. Pruitt. ( 2002 ). Personas: Exploring the Real Benefits of Imaginary People . Available: http://www.chiplace.org/ techniques/show-article. jsp?id=1.

[2] H. Beyer , K. Holzblatt. ( 1998 ). Contextual Design: Defining Customer-Centered Systems . Morgan Kaufmann Publishers, San Francisco.

[3] A. Blomquist , M. Arvola. ( 2002 ). Personas in Action: Ethnography in an Interaction Design Team . Second Nordic Conference on Human-Computer Interaction. Proceedings of NordiCHI , pp. 197 - 200 .

[4] S. Calde , K. Goodwin , R. Reimann. ( 2002 ). SHS Orcas . The First Integrated Information System for Long-Term Healthcare Facility Management . American Institute of Graphic Arts, New York. Available: http://www.aiga.org/ resources/content/7/6/2/documents/FORUM\_calde\_ case\_0 32102 .pdf.

[5] A. Cooper. ( 1999 ). The Inmates are Running the Asylum . Sams, Indianapolis.

[6] A. Cooper. ( 2003 ). The Origin of Personas . Available: http://www.cooper.com/insights/journal\_of\_design/articles/ the\_origin\_of\_personas\_1.html.

[7] A. Cooper , R. Reimann. ( 2003 ). About Face 2.0: The Essentials of Interaction Design . Wiley, Indianapolis.

[8] A. Cooper , R. Reimann , D. Cronin. ( 2007 ). About Face 3.0: The Essentials of Interaction Design . Wiley, Indianapolis.

[9] J. Dong , K. Kelkar , K. Braun. ( 2007 ). Getting the Most Out of Personas for Product Usability Enhancements . Second International Conference on Usability and Internationalization. Proceeding of the UI-HCII , pp. 291 - 296 .

[10] K. Goodwin. ( 2002 ). Getting from Research to Personas: Harnessing the Power of Data . Available: http://www.cooper. com/content/insights/newsletters/2002\_11/getting\_from\_re search\_to\_personas.asp.

[11] J. Grudin , J. Pruitt. ( 2002 ). Personas, Participatory Design and Product Development: An Infrastructure for Engagement . Participatory Design Conference. Proceedings of the PDC, Computer Professionals for Social Responsibility , pp. 144 - 161 .

[12] A. Holzinger. ( 2005 ). Usability Engineering Methods for Software Developers . Communications of the ACM 48 ( 1 ): pp. 71 - 74 .

[13] IEEE Computer Society Professional Practices Committee. ( 2004 ). Guide to the Software Engineering Body of Knowledge (SWEBOK- 2004 Version) . IEEE Computer Society , Los Alamitos, CA.

[14] N. Juristo , A. Moreno , M. Sánchez. ( 2007 ). Guidelines for Eliciting Usability Functionalities . IEEE Transactions on Software Engineering 33 : pp. 744 - 758 .

[15] A. Milewski. ( 2004 ). Software Engineers and HCI Practitioners Learning to Work Together: A Preliminary Look at Expectations . Proceedings of the 17th Conference on Software Engineering Education and Training CSEET´04 IEEE , pp. 45 - 49 .

[16] J. Pruitt , J. Grudin. ( 2003 ). Personas: Practice and Theory . Available: http://www.research.microsoft.com/research/coet/ Grudin/Personas/Grudin-Pruitt.pdf.

[17] A. Seffah , E. Metzker. ( 2004 ). The Obstacles and Myths of Usability and Software Engineering . Communications of the ACM 47 ( 12 ): pp. 71 - 76 .

[18] K. Vasara. ( 2003 ). Introducing Personas in a Software Project . Master's thesis , Helsinki University of Technology, Helsinki.