Keywords

1 Introduction

The development process of software, products and services can be structured differently, e.g. in a linear way, following a waterfall model [1], or in an iterative way, following a spiral model [2]. Nowadays, an increasing use of agile, iterative or incremental software development processes can be observed [3], which result from different workflows and changing attitudes towards development. Within these kinds of development processes, some decisions don’t have to be made at the beginning and can be adjusted along the development. These adjustments often result from technical issues and challenges, or from incorporate phases of coordination with clients. While technical or organizational adjustments are realized, it is essential to validate them with user requirements. Therefore, knowledge about users is a prerequisite to keep up with these changes. However, this valuable knowledge about users is often neglected after the requirements specification [6].

Providing access to this original knowledge about users along the development process can support an agile, incremental, or iterative development. In this regard, personas [4], which are commonly used in user-centered design and human-computer interaction activities, are not only a suitable method for the adequate documentation of users’ attributes, but also a tool for empathizing with users’ aims and needs [5]. Personas can be used by the development team for requirements engineering activities throughout the entire development process and in addition to user-centered design activities.

The integration of personas, as a kind of user description, in the requirements engineering activities, improves two aspects of the development: (1) considering multi-faceted user needs in the early phases of development, when functional key decisions are taken, (2) continuous integration, verification and revision of user requirements to evaluate developed prototypes and intermediate products.

In the following, the opportunities and challenges of the integration of personas in the different activities of the requirements engineering process are described, based on the practice of five research and development projects using personas. The described approach is based on the work of Schneidewind et al. [6] and extends this work in regard to the entire development process, using the persona method as a tool for keeping requirements vivid along the development process.

2 Requirements Engineering Activities

Requirements engineering provides “a structured set of activities, which are followed to derive, validate and maintain a system requirements document” [7]. These requirements engineering activities are often described as a linear process, which results in a validated final requirements document, used as a basis for system planning and implementation [8]. Within the further development process, additional managing activities have to be undertaken, in order to react on changing needs of stakeholders or changing environmental or organizational conditions [7].

These requirements management activities are closely related to the requirements engineering activities. In addition, agile development processes also demand a more dynamic dealing with requirements. Especially in the context of software development, prototyping, testing, and evaluation of the system might implicate changes of the requirements documents, which have to be replicable and revisable [9]. The approach of Nuseibah and Easterbrook [10] not only considers the developing activities of requirement documentation but also these evolving activities to adapt changes. In order to emphasize the incremental character of these activities, this approach is transferred to the spiral model of Kotonya and Sommerville [7], as shown in Fig. 1. As a consequence, the following activities [10] have to be undertaken iteratively.

Fig. 1.
figure 1

Spiral model of the requirements engineering activities (based on the approaches of Kotonya and Sommerville [7] and Nuseibah and Easterbrook [10])

Full size image

2.1 Eliciting Requirements

The elicitation activities provide methods and techniques to capture information about goals, domain knowledge, stakeholders and actors, as well as the operational environment of the system [8]. The core eliciting activities are part of the first iteration of the requirements engineering process. As a result, an informal statement of requirements is developed as a basis for further activities. Changes of requirements imply a reinterpretation or recollection of the information material in further iterations.

2.2 Modelling and Analyzing Requirements

Modelling activities result in abstract descriptions respectively diagrams, based on specific modelling languages, and present the core activities of the requirements engineering process [10]. In addition, the analyzing activities include the detection and resolving of conflicts between requirements and the determination of the bounds of the system [8]. Both, modelling and analyzing, are essential activities in all iterations and result in a common understanding of the requirements.

2.3 Communicating Requirements

The aim of the communication activities is the description of the requirements in an explicit and comprehensible language or notation [10]. Next to the specification of the requirements, the kind of the documentation in a logic or natural, formal or informal language is also essential for the further usage of the resulting draft of the requirements document. Along with the documentation of the concrete system requirements, the description of the context of use, including users, tasks, and usage environment [11], should be communicated.

2.4 Agreeing Requirements

The agreeing activities are often called validation, with the aim to check the requirements document for consistency and completeness [7], for instance via requirements reviews. Moreover, the agreement with all stakeholders and the consideration of their goals and conflicts [10] is an essential basis for the beginning of the following iterations.

2.5 Evolving Requirements

The evolving activities include methods and tools for the management of changes. A very important precondition for this requirements management is the traceability to check the impact of changes to further requirements [12]. These activities have to accompany all the other activities of eliciting, analyzing, communicating, and agreeing continuously, in order to recognize potential risks of changes during the whole process.

3 Challenges of User Requirements

According to IEEE, requirements are “a documented representation of a condition or capability” that either “must be met or possessed by a system or system component” or is “needed by a user to solve a problem or achieve an objective” [13]. In contrast to system requirements, which are derived from organizational, domain and platform restrictions [14], user requirements are based on the user needs [15]. In development processes, user requirements are often neglected or reduced to design aspects of the user interface [16, 17]. However, user requirements include information about users, tasks, and the environment [11], which concern not only usability aspects but also key decisions of system design and functionality.

As a consequence, user requirements can provide a basis for the system development and the evaluation process. This approach requires a holistic integration of user needs into the requirements engineering process. But the characteristics of user needs involve some challenges for the requirements engineering process. The challenges have been identified within five research and development projects. The projects differ in their duration, team size, goals, and their area of application, as shown in Table 1.

Table 1. Overview of research and development projects
Full size table

Elicitation Challenge: User Needs Are Independent from the Planned Solution.

The expectations of users often depend on their previous experiences with systems [18]. As a consequence, users are not able to imagine innovative system solutions or interactions, which differ from their current workflows. In order to provide flexible, open, and unbiased user requirements, it is important to identify the core goals and tasks of the users in detail, independently from current or future solutions. Otherwise, there is the risk of anticipating planned solutions, without considering the real user needs.

Analyzing Challenge: User Needs Are Rather Imprecise and Vague and Partly Even Contradictory and Illogical.

User needs often concern a complex task or goal of a user [18], which might be reached by different means and ways. Especially, systems, which are developed for several user groups, have to meet different user needs. But these needs respectively wishes might be inconsistent or illogical, not only in regard to different user groups, but also in regard to a single user. It is the responsibility of the usability and requirements engineers to solve these conflicts according to the best solution for the user, in order to reach the core goals and solve the tasks.

Communication Challenge: User Needs Leave Scope for Interpretation Along the Development Process.

The development and design process of a product integrates different stakeholders and developers with different opinions. Cooper et al. point out, that the user can be used to justify different personal opinions within a discussion, without having the user needs in mind, but the own idea of the product [5]. Therefore, a common understanding of the user based on real user data is needed, which can be understood by all involved stakeholders.

These mentioned challenges lead to the result, that there is a high potential to improve the user descriptions for requirements engineering activities. Current user descriptions are modeled in a very structured way, which is not sufficiently vivid and flexible. For instance, user roles focus on the tasks, but neglect the users’ motivation and actions as well as the context of use [11]. These approaches give a short overview, but do not enable the developer to feel empathy with the user, in order to also consider user needs into new upcoming development decisions. When key decisions are only taken from the developers’ point of view or even the developers interpret their own needs as user needs, the project risks failing to meet the real user needs.

4 Describing Users with Personas

Software, requirements and usability engineering have a set of different methods to describe users in regard to the needed detail level and purpose of the description. Personas provide a method to communicate typical behavior, motivation and goals of users in order to personify a group of users [4]. Personas are archetypes, which are derived from the dispositions and behavior of real people, but describe fictitious and clearly distinguishable characters. Compared to other methods for user descriptions, the strengths of personas [5] are:

  • User-oriented determination of product characteristics based on goals and tasks,

  • Universal communication tool for different stakeholders within the development process, especially to discuss challenges and solutions, based on a common understanding of the users,

  • Ad hoc evaluation tool, to reflect decisions and changes from a users’ point of view.

In general, the activities of the process for creating personas vary slightly between different authors [5, 19]. But all creating processes focus on the described strengths of personas and are based on qualitative and quantitative data, derived from analysis and statistics. Therefore, the approaches follow the same basic steps [20] starting with an identification of variables and values, followed by an identification of patterns, and the description of the persona, e.g. as shown in Fig. 2, and its validation. The following overview presents the core activities of each step of the persona creation:

Fig. 2.
figure 2

Example of a persona

Full size image
  1. 1.

    Identifying variables and values includes the operationalization of the activities, attitudes, aptitudes, motivations and skills [5] of the potential users, in respect to the product. The values represent specific manifestations of a variable, which differ from user to user and are revealed by qualitative and quantitative user research methods, for instance in interviews and observations, statistical reviews.

  2. 2.

    Identifying patterns maps the processed user data to a value of each variable. As a next step, the most frequent combinations of values are analyzed and classified into typical behavioral disposition. These patterns build the basis for the creation of the “skeleton” of the persona.

  3. 3.

    Describing personas enriches the patterns with demographic variables. Next to a name, age, and hobbies, some attributes of the character, a personal story, and a picture are added to the persona, in order to encourage more empathy with the user.

  4. 4.

    Validating personas includes the verification of the final typical dispositions of the personas as well as the agreement process with the stakeholders of the system and their political, organizational and legal restrictions.

The integration of personas into the requirements engineering process concerns two fields of work. Firstly, the creation process of the persona itself has to be integrated into the requirements engineering process. This integration of working activities is mainly related to the first iteration of the requirements engineering process, as shown in Sect. 5. Secondly, the usage of the personas, as a result of the persona creation process, provides advantages for several requirements engineering activities in further iteration, which are described in Sect. 6.

5 Integrating the Persona Creation Process

Current approaches to integrate user descriptions into the requirements engineering process are largely limited to the eliciting and analysis activities [21, 22]. Some approaches also suggest the integration of several user-centered design activities, such as user studies and usability testing, into the requirements engineering process [23, 24]. The usage of personas as user descriptions were suggested by Castro et al. [25], who developed an advanced persona technique and integrated the identified detailed creation activities within the whole requirements process. In this way, the developed persona is an additional result at the end of the requirements engineering process.

In contrast, we recommend to create the persona in the first iteration of the requirements engineering process, in order to provide the results of the persona creation as an added value to the majority of the requirements engineering activities in further iterations.

The development of personas is a creation process, which consists of different activities, as described in Sect. 3. These activities of persona creation are comparable to the requirements engineering activities, and transferable to the requirements engineering process, as shown in Fig. 3. Within the first elicitation phase, information about the context of use is collected, which build an important basis for both, the development of personas and further requirements. By these means, the variables and values defining the characteristics of the personas are identified, next to the first informal statement of requirements. As a next step, the elicited information is structured and analyzed for the identification of behavioral patterns of personas. The typical language to communicate personas is the textual form in combination with a picture (cf. Fig. 2), which should be added to the draft of the requirements document. Finally, these descriptions are validated and can be agreed with the stakeholders in combination with other requirements documents.

Fig. 3.
figure 3

Integration of personas into the requirements engineering process

Full size image

6 Opportunities of the Integration of Personas into the Requirements Engineering Activities

The integration of the created personas provides benefits for the different requirements engineering activities. Each benefit is supported by an example from a research and standardization project on passenger information in public transport, which provides a context of use with different actors, tasks and systems in a mobile environment. Therefore, the examples focus on a complex field of applications, which is similar to other fields of applications where the mentioned challenges typically arise.

6.1 Eliciting Requirements

Benefit: Personas Support the Identification of Actors and Scenarios.

Often, the development process focuses not only on one type of user in a specified scenario, but also on several actors within the context of use. Personas support the identification of these actors, based on their characteristics, and describe them from a holistic point of view. Therefore, scenarios can be derived more easily and different aspects of the usage and accompanying contexts can be addressed.

Example.

Within the mentioned field of application of passenger information, actors include passengers and personnel of transport companies, which e.g. can be divided into operators, dispatchers and service staff. The term “passengers” represents a heterogonous group of users, e.g. tourists and commuters, which can be described with personas [20]. Scenarios can cover typical situations, e.g. the daily route to work, or special situations, e.g. disturbances, including the different perspectives of the personas [26].

Benefit: Personas Support the Specification and Prioritization of Use Cases.

Use cases [27] can be derived from personas and scenarios to cover the different aspects in a more abstract way. Within the same process, personas can be used to prioritize use cases. The description of a persona supports an individual analysis of use cases and thereby overcomes the abstract actor oriented approach, where a prioritization can be hardly connected to the different users. Compared to the definition of use cases by Cockburn [27], which includes the context of use, stakeholders and their interests, as well as preconditions and end conditions, personas and scenarios already provide these information and extend them by adding motivations, goals and other personal characteristics.

Example.

The decision, whether a function to support sightseeing information or a function to support alternative routing in disturbances situations, should be favored within a passenger information system, can hardly be derived from use cases alone. It requires information about the context of use, especially the users and connected scenarios. This information can lead to the result, that alternative routing information will be used by different personas, while sightseeing is used solely by the tourist persona. Therefore, the alternative function will most likely receive a higher priority.

6.2 Modelling and Analyzing Requirements

Benefit: Personas Support the Prioritization of Requirements.

Requirements are usually not all equal in their priority. Priorities can be given in regard to clients’ wishes, technical feasibility or user needs. The comprehensive knowledge, combined within the persona descriptions, facilitates the comparison of the requirements of different users for the development team. In addition, personas serve as a neutral and agreed basis for discussion.

Example.

Within passenger information systems, different time related information can be found. Therefore, the list of requirements will include a number of requirements focusing on this time related information. A decision, as to whether the remaining minutes to departure or the time of departure should be used, or if real-time information is needed, can be made based on the needs of the personas.

Benefit: Personas Support the Deeper Understanding of Requirements.

In order to manage development challenges and requirements changes, the development team should have a deeper understanding of the requirements. In contrast to separated requirements lists, personas can provide additional information to get a holistic view of the requirements. Therefore, an adequate traceability of requirements and personas is an important prerequisite.

Example.

The development of the passenger information system included a set of requirements, which focuses on information and different presentation functions. Personas support developers implementing these functions by providing a context for the requirement. In a passenger information system not only the mere information, but also the combination with other information provides useful support for the passenger.

6.3 Communicating Requirements

Benefit: Personas Support the Comprehensible Communication of Requirements to Stakeholders.

As described in the previous benefits, the memorable and comprehensible descriptions of personas in natural language and pictures can play an important role for the eliciting and analyzing activities. The same advantages support the identification with users, their needs and goals for the different stakeholders. An integration of the personas into the requirements document therefore improves the understanding of the whole requirements document.

Example.

The developed personas for users of a passenger information were presented in a booklet [26]. The persona booklet was easy to handle and permanently available to all developers and stakeholders. In addition, further types of information, such as presentations, positioned figurative representations, or integrations into the daily routines also support the communication and the memorization of personas for the developers.

6.4 Agreeing Requirements

Benefit: Personas Support the Validation of Requirements.

The usage of personas during validation activities ensures the consideration of the user perspective during requirements reviews or testing. Thereby, personas can not only indicate an incompleteness of requirements, but also help to solve conflicts between the stakeholders.

Example.

In order to validate the requirements for a passenger information system, typical user requests to the system were derived from each persona. Subsequently, the requirements were checked to ensure a response to these requests, according to the specific user needs and expectations. In later iterations, these user requests could also be used for system and component tests, in order to ensure the correct responses to the requests.

6.5 Evolving Requirements

Benefit: Personas Support the Tracing of Requirements.

Along the development process, requirements are changed due to different reasons, e.g. technical issues or results of usability evaluations. Personas can not only support the decision and evaluation process of these changes by integrating the users’ perspective, but also keep track of related requirements and influences resulting from these changes. In addition, persons can be used to measure the compliance to requirements from another perspective. In regard to the final product, the persona perspective provides more reliable results, as the perspective is already based on the final users.

Example.

Even when a function is rated with high priority, situations along the development process can arise, where the requirements related to this function are questioned, due to different reasons. For instance, the departure timer within a mobile passenger application was questioned within the development process. The assessment of neglecting this function using the personas revealed that this function can be considered as an added value for several personas, but the departure timer does not represent a key function to solve a task. As a result, the requirements of the departure timer were removed.

7 Conclusion

Today, requirements engineering lacks a well-established process to combine personas as a type of user descriptions and requirements engineering activities. However, personas are already used to overcome different challenges along the development and requirements engineering process [28–31]. Therefore, personas can be considered as a powerful method to provide vivid descriptions and requirements along the development and requirements engineering process. In addition, the persona method bridges the gap between requirements engineering, user-centered software development and human-computer-interaction.

Based on the experiences of development and research projects of different scale and content, the described approach shows solutions to integrate the persona creation process and the persona artefacts in the requirements engineering activities. The benefits of the usage of personas and their exemplary application are described for well-established methods of requirements engineering. However, the validation of these findings still requires a systematical analysis of the requirements engineering activities in further development projects.

Personas provide a user-oriented overall context, which includes tasks, values, and motivations, for single requirements. The integration of personas into development projects ensures the consideration of the user needs in all requirements engineering activities and supports the solution of conflicts between requirements, as described by Miller and Williams [28]. By these means, personas support the requirements engineering process, serve as a stable reference for agile and iterative development processes and increase the usability of the final products.