A Study of Emotions in Requirements Engineering Ricardo Colomo-Palacios1,* , Adrián Hernández-López1, Ángel García-Crespo1, and Pedro Soto-Acosta2 1
Universidad Carlos III de Madrid Av. Universidad 30, Leganés, 28911, Madrid, Spain {ricardo.colomo,adrian.hernandez,angel.garcia}@uc3m.es 2 University of Murcia Campus de Espinardo, 30100, Murcia, Spain
[email protected]
Abstract. Requirements engineering (RE) is a crucial activity in software development projects. This phase in the software development cycle is knowledge intensive, and thus, human capital intensive. From the human point of view, emotions play an important role in behavior and can even act as behavioral motivators. Thus, if we consider that RE represents a set of knowledge-intensive tasks, which include acceptance and negotiation activities, then the emotional factor represents a key element in these issues. However, the emotional factor in RE has not received the attention it deserves. This paper aims to integrate the stakeholder’s emotions into the requirement process, proposing to catalogue them like any other factor in the process such as clarity or stability. Results show that high arousal and low pleasure levels are predictors of high versioning requirements. Keywords: Software Engineering, Requirements, Software psychology, Emotions.
1 Introduction The human dimension is a key element in software engineering (SE), sometimes having greater importance than the technical dimension. Its importance is due to the fact that SE is essentially based on intellectual and social activities [1]. The roles of humans involved in SE fall into four categories; the individual, the team, management and the stakeholder/interested party, including customer and client. There are always interrelations and overlaps among these four categories. According to DeMarco and Lister [2], the “final outcome of any [SE project] effort is more a function of who does the work than of how the work is done” (p. 93), and is defined by the equation effort = people x time . Although the importance of human factors has been widely recognized as key for SE, researchers should place greater focus on the humans involved in SE than what has been done to date [3]. Software requirements express the needs and constraints placed on a software product that contributes to the solution of some real-world problem. The term Requirements Engineering (RE) is widely used in the field to denote the systematic handling of
1
requirements. In order to establish a sound requirements definition, we must begin to pay attention to the human dimensions, consciously addressing the psychology and sociology of its use, i.e. improving information requirements determination from a cognitive perspective [4], cognitive bias in SE [5], and cognitive fit in requirements modeling [6]. The importance of human factors in RE is reflected in the fact that regardless of the methods and tools employed, the success of requirements analysis depends on how well users and analysts communicate and collaborate [7]. Furthermore, the participation of the customer in defining the requirements is vital [8]. Finally, it can be said that requirements engineering is a multidisciplinary human-centered process, although we can benefit from some tools and techniques in addition to human expertise [9]. Even if requirements evolution is managed correctly, most software errors are introduced during this phase and emerge at a later stage [10]. According to the review carried out by Walia and Carver[11], many main errors that can occur in other phases are related to the requirements phase. Hence the errors in the requirements are costly and dangerous. Because of the intrinsic importance of requirements, along with strong human influence in the production and development of these requirements, the aim of this paper is twofold. Firstly, the importance of knowing the stakeholders’ views on requirements from an emotional standpoint is highlighted. Secondly, through a human emotions specification technique, the method to include this feature in requirements is presented. The ultimate goal is to build an instrument that, through analysis of the emotions present in the requirements, predicts requirements evolution over time and incorporates standards for better governance of the project.
2 The Importance of Emotions and RE Human behavior is influenced not only by rational-economic factors; it is influenced, among other factors, by emotions [12]. Returning to the review conducted by Walia and Carver [11], human errors in the requirements phase were identified and classified into the following categories: communication, participation, domain knowledge, specific application knowledge, process execution, and other cognition errors. In this paper we will focus on the “other cognition” errors, specifically in emotions. Determining a unique definition of the term “emotion” represents a complicated task. In a study at the beginning of the 1980s, Kleinginna & Kleinginna [13] found 92 definitions and classified them into 11 categories. Leaving aside the discussion concerning the concreteness and universality of emotion concept, Izard [14] claimed that emotion is composed of three aspects: a) the experience or conscious feeling of emotion, b) the processes that occur in the brain and nervous system, and c) the observable extensible patterns of emotion. As a result of this asseveration, Russell, Weiss and Mendelsohn [15] proposed a measure of affect which had a profound impact on social psychology. They termed the measure the Affect Grid, a scale designed as a quick means of assessing affect along pleasure-displeasure and arousal-sleepiness dimensions on a 1-9 scale. According to the studies of these authors, the Affect Grid is potentially suitable for any study that requires judgments about affect of either a descriptive or a subjective kind. The interaction between requirements and emotions is not totally unexplored. Ramos and Berry [16] have discussed and emphasized the importance of emotions in
2
RE. The reasons for their analysis are, firstly, the transformation that involves the use of a new system to users [17], and secondly, the difficulty in defining the requirements in ways that are beneficial for developers and users, i.e. establishing a win-win relationship . The result of their studies confirms the importance and validity of the emotional factor in RE, as well as any other classic factor, such as performance, cost, user interface, etc. The approach proposed in this paper focuses on the evolution of requirements and the parallel evolution of the emotions through the various stages. From the evolutionary viewpoint within a software development project, requirements evolve from their creation in the elicitation phase. Thus, an overall picture of emotions and requirements should provide the starting point for the creation, development and specification of requirements by taking into account the emotional factor. This paper aims at creating and testing a solution for the prediction of the life cycle of requirements. The ultimate goal is to use emotional qualification of requirements as a key for a more complete requirements management and greater suitability of soft issues in requirements specification.
3 The Experiment 3.1 Research Design Based on the idea that our processing of emotions tends to be biased, and that these biases affect our perception, judgment, and behavior [18], this paper proposes using the Affect Grid psychological tool created by Russell et al. [15] to characterize requirements throughout the development process. Thus, based on requirements, stakeholders express the emotion that requirements raise for them. It requirements measurement are intended to be discrete, but their changes over time serialize intake data enabling the creation of patterns. For each requirement, it is proposed that all stakeholders involved in it perform an emotional assessment about this requirement using the Affect Grid. In addition, it is proposed that this assessment be repeated with each requirement version upgrade. Thus, through the requirements repository, the emotional traceability can be established taking into account the emotional assessment made by stakeholders. The emotional evaluation is conducted through the Affect Grid, which is a singleitem scale of pleasure and arousal. Thus, the participants answers the question “What’s your emotion regarding this requirement definition?” and places one checkmark somewhere in the grid. Subsequently, these data are encoded together with requirements to ensure the pursued emotional traceability. The proposed evaluation method has been implemented in two projects. The first project, known as Project A, is developed in the context of a software development organization using its own means. The project consists of performing an adaptive maintenance of a legacy information system. To this end, a total of 28 user requirements were identified and documented that subsequently served as the basis for a software development project which lasted 7 months. There were a total of 97 different versions of requirements. Meanwhile, project B was focused on the development of a touristic information system. In this context, a software development organization was hired to undertake the
3
system development. The project team specified a total of 37 user requirements. The development project lasted 6 months, after which the developed system was implemented. There were a total of 115 different requirements versions. All scores were codified using a 1-9 Likert Scale, with 1 meaning low arousal-pleasure, and 9 meaning high arousal-pleasure. Each score represents the pleasure (y axes) and arousal (x axes). Based on the requirements identified in projects A & B, both users and developers implement the operations described, namely rating requirements using the Affect Grid in all its versions. The experiment’s aim is to verify whether the emotional assessment responds to any pattern. Therefore, some hypotheses are set. In the first place, from the evolution of scores along the versions, two hypotheses are defined: H1: Higher requirement versions’ scores have higher Pleasure scores. H2: Higher requirement versions’ scores have lower Arousal scores. These hypotheses are based on the premise that requirements finally have to fit users’ needs on the one hand, and have to be carried out by developers on the other hand. In addition, initial contacts with requirements produce stress in developers and users. In order to specialize these hypotheses, hypotheses regarding final requirements are set: H3: Pleasure scores for final requirements are higher than for non-final requirements. H4: Arousal scores for final requirements are lower than for non-final requirements. Final requirements are supposed to fit the user’s needs and are accepted by all stakeholders; therefore these hypotheses specialize H1 and H2. 3.2 Sample Description The sample was composed of 11 individuals: five of them belonging to project A (3 developers and 2 users), and 6 to project B (3 developers and an equal number of users). In relation to demographic characteristics, the group of participants consisted of 4 women (36%) and 7 men (64%), with an average age of 32.7. The projects sample choice was made according to the available projects, and the participants are those directly involved in the requirements process. 3.3 Results and Discussion As a result of participants’ activities, a total of 1,175 emotional ratings were collected. Table 1 shows average and standard deviation of Pleasure and Arousal dimensions in different scenarios. The data analysis of final requirements scores shows that there is a marked trend of Pleasure and Arousal scores in the case of final version requirements. On the one hand, Pleasure dimension remains constant while on the other hand, Arousal decreases with time. Further analysis is needed to shed light on the differences of these results with those obtained for all versions scores, which points to an increase of pleasure along versions and a decrease of arousal. A set of T-test has been carried out between version x and x+n. From these tests, it can be concluded that there are not significant changes when n is low (1 or 2), but it is significant with higher n (
