Models for Integrating UX into Software Engineering ... - CiteSeerX

Download PDF
3 downloads 0 Views 206KB Size Report
Comment
Sep 15, 2014 - functionalities and qualities of a product, User eXperience (UX), is becoming ... Validation of the models in interviews with 12 practitioners and ...
Models for Integrating UX into Software Engineering Practice: an Industrial Validation Pariya Kashfi, Robert Feldt, Agneta Nilsson, Richard Berntsson Svensson

arXiv:1409.4194v1 [cs.SE] 15 Sep 2014

Division of Software Engineering Department of Computer Science and Engineering Chalmers University of Technology and Gothenburg University SE- 412 96 Gothenburg, Sweden Email: [email protected]

Abstract—The user’s overall experience and perception of functionalities and qualities of a product, User eXperience (UX), is becoming increasingly important for success of software products. Yet, many software companies face challenges with their UX practices, hence fail to achieve a good UX in their products. Part of these challenges are rooted in inadequate knowledge and awareness about UX but also in that UX models are commonly not well integrated with existing software engineering (SE) models and concepts. Therefore, we present two SE-specific models of UX for practitioners: (i) a layered model that shows the relation between functional, quality, and UX requirements, and (ii) a general, UX-aware software process overview model that shows the additional concepts and activities that can help achieve a good UX. Validation of the models in interviews with 12 practitioners and researchers generally found the models useful for practice; for instance to raise knowledge and awareness about UX, improve communications regarding UX and facilitating making UX-aware decisions in the development process. In total, we identified six different areas of use for the models. Index Terms—User eXperience, quality requirements, nontask-related, hehonic, non-instrumental.

I. I NTRODUCTION User eXperience (UX) is a user’s overall experience and perception of functionalities and qualities of a product [1], [2]. Good UX is crucial to maintain or gain market shares [3], [4], contributes to higher work motivation and performance, and can affect the well-being of the end users [5], [6]. Recently, researchers in the field of Software Engineering (SE) have shown an increasing interest and more attention to UX; in particular with emphasis on requirements related to users’ emotions (e.g. fun), motivations (e.g. desire to help others), and values (e.g. caring for environment); and how such requirements can help to shape a good UX, and consequently contribute to success of software [7], [8], [9], [10]. Studies show that practices face a number of challenges concerning UX [11]. Among other reasons, these challenges are rooted in practitioners’ low knowledge and awareness about UX. Moreover, there is still limited theory and practice regarding how SE practitioners in general, and Requirements Engineering (RE) practitioners in particular should address UX. In our view, the current UX models are often abstract and complex (e.g. [12], [13]), and suffer from a language gap since they are developed using terminologies less known to SE

practitioners. In particular, it is not clear from these models how UX relates to common concepts such as Functional Requirements (FR), and Quality Requirements (QR) (aka. nonfunctional requirements) of software. Since, SE practitioners and SE standards such as ISO25010 [14] often use this existing terminology, mapping UX models and concepts to such terminology can facilitate a better understanding of UX among practitioners. This can enable overcoming the challenges with UX in practices that are rooted in practitioners’ lack of knowledge and understanding of UX [11]. To this aimd, we have developed two models of UX that present the relation between UX, functional and quality requirements, and the additional concepts required in software development processes in order to cover UX. The models have been developed based on our earlier empirical work on identifying barriers to UX and QRs in SE processes [15], [11]. This paper reports on the models and our static validation of them in academia as well as industry. The structure of this paper is as follows: Section two summarizes the concept of UX, while the third section presents related work in SE. Section four then describes our research methodology while the fifth section presents the UX model. The paper is concluded with a discussion and suggestion for future research. II. U SER E X PERIENCE Although, there is still no standardized definition of UX, the existing definitions share the same essence. Among other things, the definitions emphasize the subjectivity of UX (i.e. its relation to how a user perceives the product), and the fact that usability is a part of UX. For instance, Hassenzahl and Tractinsky [16] define UX as “a consequence of a user’s internal state (predispositions, expectations, needs, motivation, mood, etc.), the characteristics of the designed system (e.g. complexity, purpose, usability, functionality, etc.) and the context (or the environment) within which the interaction occurs (e.g. organizational/social setting, meaningfulness of the activity, voluntariness of use, etc.).” In general, UX literature emphasizes that assuring efficiency and effectiveness, i.e usability, does not guarantee the overall end user satisfaction or pleasure [16]. Hartson and Playa [1] consider usability, usefulness, and emotional impact as three components of UX.

Usability and usefulness in their definitions relate to the users’ tasks, and goals of work or play, while emotional impact relates to users’ feelings (e.g novelty, pride of ownership). UX includes two aspects: task-related (aka. instrumental or pragmatic), and non-task related (aka. non-instrumental, or hedonic) [2], [13], [12]. The task-related aspect consists of elements that relate to what users want to ’do’ (i.e. users’ behavioral goals) (e.g. ’I want to login using id/password’) [2]. The non-task-related aspect consists of elements that relate to what users want to ’be’ (i.e. users’ psychological needs) (e.g. ’I want to feel secure’) [2]. These element have complex relations [12]; e.g. if security of the software is low (a taskrelated element), users will loose their ’sense of trust’ (a non-task-related element). The non-task-related aspect relates to individuals’ psychological well-being, and is inherently subjective [2]. III. U SER E X PERIENCE AND SE Over the years, SE research has had a shift of focus from emphasizing only software functionalities; and has embraced the importance of various software quality attributes in success of software [17], [14], [6]. Researchers highlight that ignoring QRs can lead to developing software that is too costly, difficult to use, or results in the end users dissatisfaction [18]. Therefore, a group of studies in the filed of SE focus on modeling and providing a better understanding of how the end users perceive various aspects of software, and how that affects their satisfaction and software acceptance. One example is Quality in Use (QiU) model that according to ISO25010 [14] is “the degree to which a product or system can be used by specific users to meet their needs to achieve specific goals with effectiveness, efficiency, freedom from risk and satisfaction in specific contexts of use.” QiU mainly covers the task-related aspect of UX, and does not include much non-task-related quality attributes [19]. Nevertheless, we find such efforts important in taking the first step and lifting researchers’ and practitioners’ awareness regarding the role of user and user’s perception in accepting or rejecting software in general; which traditionally has not been the focus of SE. SE literature also includes publications that study taskrelated and non-task-related quality attributes and their effects on UX. As an example, Doerr et al. [20] discuss the relation between a number of task-related quality attributes and QiU, and propose a systematic guideline on how to appraise and measure users’ satisfaction in early phases of software development. Similarly, Kerkow [21] and Nass [6] focus on systematic support to find a balance between task-related and non-task-related QRs of software in order to reach a good UX. Nass et al. [6] argue for finding the right balance between task-related and non-task-related aspects of software. Thew and Sutcliffe [22] present a method to support understanding and dealing with emotions, values, and motivations; what they refer to as ’soft requirements’. They also suggest a taxonomy of values, a part of which includes emotions. HCI literature often uses terms such as ’emotional goals’ or ’emotional design’ to refer to the aspects of software that

go beyond traditional usability (i.e. the non-task-related) [23]. On the other hand, researchers in the field of SE use the term emotional requirements to refer to user’s goals and needs that go beyond functionalities, and traditional quality requirements such as usability [24], [7]. For instance, Ramasubramaniam et al. [25] categorize requirements to FRs, QRs, and emotional requirements. Bentley et. al. [26] use the term ’affective requirements’ [26]. Moreover, Callele et el. [24] introduced the concept of experience requirements as “descriptions of user, player, and customer experiences that must be met (functional experiences) or are satisfaction goals (non-functional experiences), for products or services.” To the best of our knowledge, none of the current studies focuses on introducing all aspects and components of UX to practitioners. SE literature often presents a simplistic view of UX, for instance by focusing only on the task-related aspect of UX (e.g. [14]), or by decreasing it to emotions and ignoring its other elements such as usefulness (e.g. [26]). In particular, none of the studies aim to bridge the language gap in current UX models. Moreover, these studies propose methods or tools to be added to different phases of software development (e.g. requirements [21]) with an assumption that there is a general agreement in the organizations regarding what UX is, and what it consists of. This is while in our view, before such theoretical contributions, there is a need to improve practitioners’ knowledge and awareness about UX. In our study, we focus on mapping UX-related concepts into SE common terminology in an effort to bridge the existing language gap and create a common understanding of UX among practitioners with different backgrounds. In our view, this should be the first step to integrate UX into SE practices. IV. R ESEARCH A PPROACH Our UX models were developed in close collaboration with industry, and following the technology transfer model by Gorschek et. al. [27], including the following steps: Problem issue in industry: The main motivation behind creating new integrated UX/SE models was our analysis of challenges with UX practices, and the fact that the majority of these challenges are rooted in practitioners’ lack of knowledge and awareness about UX, and in particular its non-task-related aspect. From our interviews it was clear that UX designers and software developers had differing views of what UX is and how it fits together with development practices [11]. Study state of the art and problem formulation: The models were developed based on ample literature study on UX, and challenges with UX in software development practices. The models are inspired by a number of existing UX frameworks including Hartson and Pyla’s [1], Hassenzahl’s [2], Mahlke’s [12] and Zimmermann’s [13], Jordans’ hierarchy of consumer’s needs [28], and aims to integrate these results with the main literature on software quality; such as ISO25010 [14], ISO9241-210 [29], and Chung’s framework [17]. Candidate solution: In a series of workshops the authors developed and refined two models of UX with focus on

requirements and process. The models merge UX concepts with common concepts of SE in integrated models. Validation of the model Validation in academia was performed through interviews with four researchers. Two of the researchers have a SE background and the other two a HCI background with focus on UX. For static validation in industry, we performed interviews with eight practitioners with different backgrounds, from four different companies. We selected these interviewees based on their backgrounds and roles in the companies. Four of these practitioners represent technical roles (e.g. developers, and management with technical background), and four represent design roles (e.g. interaction designers, and management with design background). This served to validate the models from two different perspectives: SE and UX. In the remainder of this paper, all of the interview data is provided with a corresponding perspective. The interviews were performed individually, face-to-face, and lasted between 30 to 60 minutes. We chose semi-structured interviews [30] to collect more of the interviewees’ viewpoints. Moreover, we found it important that the interviewees can openly express their understanding of the model, and how such a model can be used in their research and practice. Validity Threats Threats to validity are outlined and discussed based on the classification by Runeson and H¨ost [30]: (i) One threat is related to the selection process of subjects for interviews (construct validity). Selection bias is always present when subjects are not fully randomly sampled. A possible bias may be that only subjects that have a positive attitude towards UX are selected. However, the subjects were selected based on their role and experience. In addition, the presence of a researcher may influence the behavior and response of the subjects. This threat was alleviated by the guarantee of confidentiality of the data. (ii) Since this study is of empirical nature, incorrect data (internal validity) is another validity threat. In case of the interviews, taking records in form of audio and a few cases written extensive notes mitigated this threat. (iii) The ability to generalize the results beyond the actual study (external validity) is another threat. Since the interviews are just a sample they should be interpreted with some caution. Still we sampled a number of different organizations in different industrial domains to decrease the effect of this threat. V. I NTEGRATED M ODELS OF U SER E X PERIENCE Our first model relates UX to various types of requirements, the second one situates UX-related concepts in a SE context. A. An UX-aware Model of Requirements Our proposed model for software requirements (Fig. 1) shows the relation of FRs and QRs to UX, and includes them as three categories of requirements. Functional requirements describe which functions/features the software should have. Quality requirements describe how and to what degree(s) the software will provide its functions, and can be1 described, 1 at

least in theory

defined and measured objectively 2 . Both FRs and QRs can be evaluated objectively without reference to a specific user. In contrast, UX Requirements (UXR) describe or relate to the end user’s satisfaction or pleasure of using the software; they have a subjective element by definition and depend on the perception of a user. They cover aspects such as usability, usefulness, emotions, aesthetics, motivations, and values. e.g. ’the system shall be learnable’ (usability), ’the system shall make the work of the end user easier’ (usefulness), ’the end user shall feel in control’ (emotions), ’the system shall have a minimalistic design’ (aesthetics), ’the system shall facilitate getting quick access to trendy news’ (motivations), ’the system shall advocate recycling’ (values). In this model, we emphasize that requirements can be categorized into layers where higher layers depend on requirements below. For example, a QR that describes which performance the software must have needs to be stated in relation to some (or sets of) specific functions or features on which the performance is to be measured. Thus, it assumes some functional requirements have already been (or at least could have been) established. Similarly, a users perception of the software can be constrained by UX requirements but implies some FRs or QRs that the perception is based on. This does not however mean that one should first consider or implement the lower levels of requirements, just that there is some logical order to them. The level of abstraction typically increases as we move upwards in the model. For instance ’shall evoke a sense of trust’ is a more abstract concept compared to ’shall be secure’ (QR) or ’shall have a log-in function’ (FR). Moreover, qualitative data plays a more important role in requirements work or testing as we move upwards in the model because the subjectivity and the role of humans, i.e. the end users, increases. For instance, a user at a certain time and context might perceive the software to be ’fun’, while another user (or even the same user at another time or context of use) might perceive the software as ’not fun’. Therefore, in the top layer, taking the end user’s perception into account for testing purposes is inevitable, which often will require user involvement in the process. Often, there is a need for a visual representation of the software (e.g. sketch, prototype, a running system) for testing; since the end users cannot contribute in the testing process if they are not presented with a tangible product to interact with. This is in contrast to QRs and FRs which can often be tested independently of the end users (e.g. a developer can test whether according to the specifications a certain performance requirement is satisfied or not, or a certain functionality is implemented or not.) In addition, different layers ask for different focus (in particular, in RE and testing): individual features, emergent properties and end user’s perception. At the FR layer, the focus is on specifying, realizing, and testing individual functions. At the QR layer, the focus is on specifying, realizing and testing 2 More precisely, via these definitions we divide the traditional QRs into two categories of (a) objective, and (b) subjective QRs. The latter, in our model is called UX requirements.

quality attributes of software that will often require putting a number of functions together (i.e. emergent properties). For instance, measuring the performance of software is dependent on performance of many functions individually and how they combine to provide a certain feature. At the QR layer, the focus is on specifying, realizing and testing UX, that is dependent on larger collection of FRs and QRs that contributes to UX as a temporal phenomenon [13]. In summary, our proposed model of requirements clarifies that there is a difference between QRs that can be measured and validated objectively, without a human user, and those that cannot. The key idea is that the latter should be singled out among the QRs and, since they always involve user subjectivity, we propose they should be called UX requirements. We note that in practice both QRs and FRs often can also involve subjectivity since specifying them to a degree that they are fully objectively measurable is often not cost-effective. B. An UX-aware Process Model The UX-aware requirements model presented above implies that a number of additional concepts and activities need to be considered in SE practice. Companies currently differ in how well aware they are of UX requirements and how they then handle them during development. In our work with UX and SE practitioners, we found a need for models that more clearly extends existing practices to better handle UX. We propose a number of such, general activities that a software company need to take into account in order to develop software with better UX. They are shown as extensions to a generic, iterative process model (Fig. 2). Below we discuss these extensions. 1) UX Vision: a set of high-level UX requirements e.g. ’software shall be motivating’, ’the end user should feel in control’, ’the end user should feel secure’. In our model, we argue for an UX-aware business vision (or product vision), i.e. a business vision that includes UX vision. In such a vision, enough attention should be paid to ’user satisfaction’, ’user pleasure’, and non-task-related needs of users. 2) Intended UX: a set of testable UX requirements meant to be achieved through a set of identified functional and quality requirements. An intended UX describes how to achieve a UX vision, at the requirements level. Our model proposes that an intended UX should be identified as part of the analysis and requirements steps of a development process. The intended UX refined the high-level UX vision and connects it to other types of requirements. For instance, the high-level emotional requirement ’software should be fun’ can be part of a vision and is then refined to ’80% of target users should indicate that software is fun.’ and connected to a FR such as ’the user shall receive a badge after checking into 5 different sessions’. If there is no ’intended UX’ then the UX achieved in the development process is called ’accidental UX’3 . 3) Perceived UX: a user’s subjective, time, and context dependent perception of the UX design of the product (either accidental or intended) as achieved through implemented 3 In reality, the UX will typically be partly intended and partly accidental but naming the end points helps clarify the concepts

functional and quality requirements; that ideally should lead to the user’s satisfaction and pleasure. The definition emphasizes that regardless of having an ’intended UX’ or ’accidental UX’, the user will perceive her possession, interaction and experience with the software in a context dependent and subjective manner. Although ’perceived UX’ is always fundamentally subjective and thus not totally controllable and design-able, the role of the UX-aware extensions in the model aims to align it as much as possible with the ’intended UX’ in order to fulfill the high-level UX vision to evoke satisfaction and pleasure for a majority of the end users. VI. D ISCUSSION AND VALIDATION To facilitate the integration of UX into SE practices, we developed two models of UX. Below we discuss our models and the results of their validation. A. Comparison to Other Models For several reasons, the current UX models and frameworks are not applicable by practitioners, in particular practitioners with more technical backgrounds (e.g. SE). First, such models are created mainly by researchers and practitioners which are not software engineers or developers. Therefore, the terminology used in those models have typically not been in line with the terminologies used in current SE research and practices. Consequently, SE practitioners and researchers have difficulties to understand and apply such models [11]. Second, these models often present high-level concepts such as ’system properties’ [12], ’qualities’ [13], [12], ’attributes’ [2], ’utility’ [12], ’product character’ [13], [2], and ’product features’ [2] but do not present how such concepts are translated to more detailed concepts used in SE research and practice, e.g. FRs and QRs. Third, these models only present the perspective of users and designer, while lacking an important perspective, i.e. developer’s perspective, that at the end leads to realization of UX in software products. Accordingly, the following goals guided the development of our models: be as simple and as clear as possible, use common SE terminology when possible, clearly present the relation between FRs, QRs and UX, be an extension and not a substitution for existing software process models, and require minimal changes in current software development processes. B. Why the concept of UX vision? Software products play an important role in supporting businesses [31]. Therefore, looking into business goals and eliciting business requirements is recommended in RE literature as one of the first activities in software development processes [31]. Lauesen [32] defines business goals as “highlevel reasons for getting the new product”, and emphasizes that although the term ’business’ is used, these goals cover non-business cases as well e.g. in non-profit organizations. While in SE the common practice is to support businesses by staying on budget, reducing life cycle time and achieving product performance goals [31], researchers in the field of HCI argue for a good UX as an important means to support

Types of requirements

Dependencies

Main focus in the process

The end user software UX requirements

f1

Quality requirements

f1

f2

f3

....

End user's perception

f3

....

Emergent properties

f3

....

Individual features

software f2

Functional requirements

f1

Fig. 1. Typical concepts covered in current practices market trends branding policies business goals competitors end users' task-related goals technological constraint

functional requirements task-related quality requirements

An UX-aware model of requirements The generic iterative process

Business vision

Requirements

requirement prioritization

Testing functionalities Testing task-related qualities

f2

UX vision

Intended UX

Realization

Testing

Perceived UX

Concepts needed to support UX

end users' non-task-related goals users' values, motivations, preferences

non-task-related quality requirements

UX-aware prioritization

Testing non-task-related qualities focus on the end user's perception the end user involvement prototype or a version of software

Fig. 2. The UX-aware, generic software development process model. The left column includes typical concepts/practices in the current SE processes. The right column shows the additional concepts/practices that should be taken into consideration to make the process more UX-aware. The model is generic, and does not include any direction arrows, or chronological order. Regardless of the type of process (e.g. agile or waterfall), the concepts related to UX are still relevant. Awareness is the main aim of the model, and the model does not force any specific way of working to achieve UX in software.

businesses [3], [4], [33], [34], [5], [6], [33]. Therefore, emphasizing only business requirements, technology and market trends, and giving little attention to end user satisfaction and pleasure makes products vulnerable to competition [33]. Here, ’user’s goal’ does not refer to tasks a user must accomplish (the traditional focus of RE), but rather more personal goals that are related to user’s values, emotions, and motivations; as captured by our definition of UX requirements.

features that competitors offer). Good UX is about creating a system that prevents frustration and evokes satisfaction and pleasure [2], [33]. By removing features that have little/no value to users their satisfaction can increase. By making UX vision part of the overall system and business vision we can highlight the importance of UX concerns.

Moreover, non-task-related concepts have traditionally received less attention compared to other aspects such as technology, market-trends and business requirements in the SE field. For instance, in main SE references (e.g. SWEBOk [35], Chung’s framework [17], ISO25010 [14]) non-task-related aspects of UX, such as desirability and aesthetics, are far less discussed and included in the models compared to task-related QRs, such as performance.

Refining UX requirements and identifying their connection to other requirements helps make practitioners aware of UX requirements and think about what will help achieve them. This step is needed in order for high-level UX requirements, from the vision, to be made concrete. First, specifying such requirements reduces the risk of missing important fucntionalities and qualities that contribute to delivering a good UX [24]. With no specification, we must rely on practitioners to infer such functionalities and qualities [24] which is challenging in particular since practitioners are less familiar with the nontask-related aspects of UX [11]. Second, if these requirements are specified, prioritization of funcitonalities and qualities can be done based on their effects on UX [33], [24]. Moreover,

Moreover, while market-driven RE emphasizes on eliciting creative, and innovative requirements in order to create a competitive edge for the software [36], it often does not take UX into consideration. In particular, a good UX is not necessarily achieved by including more features (e.g. all

C. Why the concept of Intended UX?

UX requirements can be prioritized themselves based on how they contribute to the overall end user satisfaction and pleasure as outlined by a vision [33], [24]. Third, specifying UX requirements helps in providing a better validation plan [24] that should include UX validation as well. Finally, having specified UX (i.e. described as intended UX) facilitates providing a rational for design decisions and therefore makes collaboration among designers and developers easier [33]. D. Why the concept of Perceived UX? To emphasize that an UX-aware testing is fundamentally different from traditional software testing, we highlight the concept of ’perceived UX’. One difference is the need to focus on the end user’s perception which often means that end users must be involved in testing activities. Moreover, although UX is realized through implementation of FRs and QRs, it cannot be tested only by testing these FRs and QRs in isolation. Even if we achieve our intended UX, a specific user’s perceived UX might not be what we intended; it is fundamentally subjective. In practice, this means that qualitative data gathering and analysis needs to be part of any validation, in addition to objective and quantitative methods more often used for FRs and QRs. Moreover, we emphasize on the concept of ’accidental UX’. Not being aware of UX may have similar effects on the product as not dealing with QRs, i.e. may lead to more expensive software products and increased time-to-market [37]. Furthermore, according to Berntsson Svensson et al. [15], dealing with QRs in a reactive rather than proactive way makes it difficult for product management to plan and rely on QRs to achieve competitive advantages. Similar effects are likely to be seen when the UX is accidental rather than intended. E. Validation The models were validated through interviews with eight software practitioners and four researchers. All of the interviewees were positive regarding clarity and understandability of the models. This is evidenced by one of the interviewees saying “My first impression of the model is that it is clear, easy to read, and easy to understand what UX is and what extra ’things’ are needed to make more UX aware decisions.” (SE perspective) The interviewees highlighted that the models put together various UX-related concepts and create an understandable picture of UX: “It’s a good thing to get all the pieces together” (UX) The participants had some suggestions regarding the terms and shapes used in the models, that was taken into account when revising the models to the version we have presented above. In the following, we discuss the main use and benefits of the models from the interviewees’ 1) Raising awareness about UX: The participants agreed perspective (Table I). that the models help in raising knowledge and awareness not only in the organizations, but also among customers. In their view, such models will facilitate informing stakeholders about the importance of UX, and considering UX in practices. One practitioners stated: “We have struggled to explain and show the importance of UX, and that the decisions that for

example, product managers make will actually affect the UX. Perhaps a model like this can help us in explaining the importance of being aware of UX, and that the decisions about which functional requirement and non-functional requirement to include is important for the overall UX.” (UX) In addition, the interviewees emphasized that introducing the concept of ’accidental UX’ is a good way to inform industries about UX. It can be used as a ’selling point’ for UX in industries, and even convincing practitioners to aim for an improved UX practice. One of the practitioner stressed: “This is what I told a big client of ours: it doesn’t really matter if you disregard it or not, it will happen anyway. Users’ will have some experience, so it’s better that we start and try to make it deliberate.” (UX) 2) Raising awareness about various requirements: The interviewees indicated how the UX-aware requirements model would raise awareness about the role of all types of requirements in achieving a good UX. Pointing to the two bottom layers of the model, one of the interviewees stated: “You can define something that looks really cool [. . . ] but to consistently deliver a good UX, we need to go the whole way down.” (UX) Moreover, the interviewees generally agreed that to achieve a good UX, satisfying FRs and QRs are important but not enough. Regarding the importance of user values and goals beside functionality and technology, one of the interviewees stated:“If you look at Silicon Valley start-ups [. . . ] 8 in 10 fail, not because it is bad technology but because there is no need for it. You need to spend time figuring out what do people actually want.”(UX). In particular regarding QRs, designers discussed how there is still disagreements on the importance of viewing QRs from not only the system perspective but also the end users’ perspective: “We have quite an argue with people because the perceived performance is more important than the actual performance, usually.” (UX) 3) Raising awareness about UX-aware Testing: The concept of testing, and its relation to the models was repeatedly brought up in the interviews. For instance, a researcher in the area of software testing stated how such a model gives a good overview of ’who’ can validate ’what’. In his view, the model clearly shows that validation of the top level in the model of the requirements, i.e. UX, cannot happen without taking the end user’s perception into account, and this is something that testers should be aware of. One of the interviewees pointed to the requirements model and stated: “what I see more use for is the right side, [. . . ] it hints on how to evaluate these things, what approaches you should be using to evaluate these things.” (UX researcher) The importance of user involvement (both in RE and testing) was another concept that in the interviewees’ view was explicitly covered by the two models. The models also facilitated discussions around challenges related to testing. For instance, the interviewees discussed how for various reasons (e.g. pointing out the UX problems in the software but not the reasons behind them) the more explored quantitative testing methods used by SE are insufficient for UX testing.

Area of use from interviewees’ perspective

Sample quotation

understanding UX

“you can recognize a lot of this, regardless of if you’re from a design background, test background, developer background, you can sort of get this picture.” (UX) “I think it could be used as a enlightening [. . . ] to raise the awareness of the need for also the QR and UX requirements, cause I think we push them away today.” (SE). ”it could make companies aware that they need another kind of testing, it’s not enough with the normal testings they have in their test departments that is just functional or quality testing.”(UX) “I see the model as very pedagogical, which should make it easy to explain and discuss [UX] with others.” (UX) “I think it’s helpful, because it is not everybody in the organization that is aware of what UX engineers are actually working with; so I think we are still not fully aware of all the things that we need to do in getting a good UX.” (SE) “Something explicit like this could lift up the discussion about UX and improve the discussion of which features to include in the coming products to be able to improve our UX goals.” (SE) TABLE I

understanding various requirements understanding UX-aware testing communication regarding UX identifying strong/weak points of current practices regarding UX UX-aware decision making

T HE MAIN USE OF THE MODELS ACCORDING TO THE INTERVIEWEES

4) Facilitating communication regarding UX: The interviewees highlighted how the models can improve communication among stakeholders. In their view, this is facilitated through proposing a common terminology and model of UX. Regarding the importance of such a common terminology and model, one of the interviewees stated: “a common terminology among the staff will improve the communication, particularly between us and the managers.” (UX)

a change of focus in current SE practices, and spreading knowledge that UX requirements are naturally different from other requirements and therefore should be treated differently. 6) Supporting UX-aware decision making: The interviewees highlighted that such models will help improving decision making in their practices, e.g. they argued that having an ’UX vision’ will guide making UX-aware decisions in feature prioritization.

5) Identifying strong/weak points of current practices regarding UX: An interesting observation in the interviews was the fact that presenting the models to practitioners opened up a series of discussions regarding challenges, and points of improvements in relation to various steps (the process model) or regarding various types of requirements (the requirements model). This suggests that the models inspire communication in the organizations in relation to the painpoints, and improving the practices concerning UX (and even QRs). Such discussions around the models help in identifying where things go wrong. Therefore, although our initial aim was to provide the models for SE practitioners, we realized that the models are useful for other practitioners as well (e.g. designers). As an example, being inspired by the UX-aware model of requirements, one of the practitioners stated: “many times the design gets a little bit too elaborate for what is actually practical to implement. [. . . UX designers] have to take into account what kind of technical world they exist in.” (SE) As another example, we observed that some SE practitioners believe that their current practices already cover what UX suggests, and that UX requirements can be treated the same as more explored types of requirements. This is evidenced by one of the interviewees saying: “The practical application of discussions, elicitation, specifying UX goals and UX requirements, all of this is something we already do for any other goals and requirements.” (SE). This is while UX practitioners believe in reality these approaches suffer from not having UX as their main focus: “’they go through emotions and have it in their check lists, but it is not at the center of their effort [. . . ]. That’s perfectly fine when you do the functional level, but there are tons of other complexities that you need to consider.” (UX) This shows the importance of raising awareness among SE practitioners regarding that UX requires

F. Proposed improvements In the following, we discuss the interviewees’ concerns and suggestions to improve the models that were presented to them. The models presented in this paper have already been updated based on the interviewees’ feedback. 1) The need for examples: The participants emphasized on providing examples to make sure the audience of the models get a good understanding of the ’fluffy’ concepts such a motivation, values and emotions; because otherwise, there is a risk that the models will be added to the collection of existing abstract models that is not used much in practice. Regarding this one of the interviewees stated: “I always have problems with these sorts of definitions. Because it’s always lots of highlevel words. I’m hoping that you’d sort of clarify it for your people.” (UX researcher) 2) A common misconception: The participants argued that use of a ’layered’ view of requirements should not cause a mis-conception in the audience regarding how UX can be achieved. The mis-conception would be to think that one should implement FRs, and QRs before starting to think about UX: “I just want to make sure that when people work with UX they know that this is something that you should consider from the start and not at the end.”(UX researcher). 3) Extending the models: There were disagreements among the participants about whether such models should remain high level, or provide specific steps to follow, or tools to apply, etc. As an example one of the interviewees highlighted: “When models are simple, then they can help us, practitioners, to become more aware of UX without ’forcing’ us to make major changes in the way we are working.” (UX). On the other hand, another interviewee stressed: “it would have been good if there were some practical steps. [. . . ] some practical guidance of how to apply it.” (UX).

4) Breaking down UX Requirements: Another issue that was brought up by UX researchers and practitioners was that such a model does not offer much advice on ’how to break down the UX requirements into FRs and QRs (e.g. what FRs and QRs should be included in order to achieve a ’fun’ software), which is still an open problem even in the field of UX. We note this as important for future work. G. Conclusions and Future Research We have presented two models that integrate UX concepts more clearly with existing SE terminology and practice. The models were statically validated in interviews with both SE and UX researchers and practitioners. Future research should introduce the models on a wider scale in software development companies, provide even more detailed advice and examples on how to break down UX requirements and connect them to other requirement types, and provide concrete guidelines for specific practices. R EFERENCES [1] R. Hartson and P. Pyla, The UX Book: Process and Guidelines for Ensuring a Quality User Experience. Morgan Kaufmann, 2012. [2] M. Hassenzahl, “The Thing and I: Understanding The Relationship Between User and Product,” in Funology from usability to enjoyment, M. A. Blythe, A. F. Monk, K. Overbeeke, and P. C. Wright, Eds. Kluwer Academic, 2003, ch. 3, pp. 31–42. [3] E. Law, A. Vermeeren, M. Hassenzahl, and M. B. Eds, “Towards a UX Manifesto COST294-MAUSE affiliated workshop,” Structure, no. September 2007. [4] K. Petrovic and M. Siegmann, “Make space for the customer: The shift towards customer centricity,” Des. User Exp. Usability. Theory, . . . , pp. 485–490, 2011. [5] N. Millard and L. Hole, “In the Moodie: Using ’affective widgets’ to help contact centre advisors fight stress,” in Affect Emot. HumanComputer Interact., P. Christian and R. Beale, Eds. Springer-Verlag Berlin, Heidelberg, 2008, pp. 186 – 193. [6] C. Nass, S. Adam, J. Doerr, and M. Trapp, “Balancing User and Business Goals in Software Development to Generate Positive User Experience,” in Human-Computer Interact. SCI 396, ser. Studies in Computational Intelligence, M. Zacarias and J. V. Oliveira, Eds., vol. 396. Berlin, Heidelberg: Springer Berlin Heidelberg, 2012, pp. 29–53. [7] N. Maiden, “Requirements and Aesthetics,” IEEE Softw., vol. 28, no. 3, pp. 20–21, May 2011. [8] I. Ramos and D. M. Berry, “Is emotion relevant to requirements engineering?” Requir. Eng., vol. 10, no. 3, pp. 238–242, Oct. 2005. [9] S. Koch and R. Proynova, “Approximating user values to preserve privacya proposal,” in 1 st Int. Work. Values Des. Build. Bridg. between RE , HCI Ethics Table Contents, C. Detweiler, A. Pommeranz, J. van den Hoven, and H. Nissenbaum, Eds., Lisbon, Portugal, 2011, pp. 32–40. [10] D. Bolchini and J. Mylopoulos, “From Task-Oriented to Goal-Oriented Web Requirements Analysis,” in Proc. Fourth Int. Conf. Web Inf. Syst. Eng., ser. WISE ’03. Washington, DC, USA: IEEE Computer Society, 2003, pp. 166—-175. [11] P. Kashfi, A. Nilsson, and R. Feldt, “Challenges with Integrating User Experience into Software Development Practices,” 2014. [12] S. Mahlke, “User Experience of Interaction with Technical Systems: Theories, methods, empirical results and their application to the design and evaluation of interactive systems,” PhD disseration, Berlin Technical university, 2007. [13] P. Zimmermann, “Beyond UsabilityMeasuring Aspects of User Experience,” PhD disseration, SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZURICH, Jan. 2008. [14] ISO25010, “Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models,” Geneva, Swiss, 2011. [Online]. Available: http://www.iso.org/iso/catalogue detail.htm?csnumber=35733

[15] R. Berntsson Svensson, T. Gorschek, B. Regnell, R. Torkar, A. Shahrokni, and R. Feldt, “Quality Requirements in Industrial Practice- An Extended Interview Study at Eleven Companies,” IEEE Trans. Softw. Eng., vol. 38, no. 4, pp. 923–935, Jul. 2012. [16] M. Hassenzahl and N. Tractinsky, “User experience - a research agenda,” Behav. Inf. Technol., vol. 25, no. 2, pp. 91–97, Mar. 2006. [17] E. Y. Lawrence Chung, Brian A. Nixon, On non-functional requirements in software engineering. Kluwer Academic, 2000. [18] H.-w. Jung and S.-g. Kim, “Measuring Software Product Quality: A Survey of ISO/IEC 9126,” IEEE Softw., vol. 21, no. 05, pp. 88–92, Sep. 2004. [19] P. Kashfi, A. Nilsson, and R. Feldt, “Supporting Practitioners in Prioritizing User Experience Requirements.” in 19th Int. Work. Conf. Requir. Eng. Found. Softw. Qual. (REFSQ 2013), Requir. Prioritization Cust. Oriented Softw. Dev., 2013. [20] J. Doerr, S. Hartkopf, D. Kerkow, D. Landmann, and P. Amthor, “Built-in User Satisfaction - Feature Appraisal and Prioritization with AMUSE,” 15th IEEE Int. Requir. Eng. Conf. (RE 2007), pp. 101–110, Oct. 2007. [21] D. Kerkow and C. Graf, “KREA-FUN : Systematic Creativity for Enjoyable Software Applications,” in FUN 2007 Proc. Work. Des. Princ. Softw. That Engag. Its Users Facing Emot. Responsible Exp. Des., 2007. [22] S. Thew and A. Sutcliffe, “Elicitation of Values, Motivations and Emotions: The VBRE Method,” in 1st Int. Work. Values Des. Build. Bridg. between RE, HCI Ethics, C. Detweiler, A. Pommeranz, J. van den Hoven, and H. Nissenbaum, Eds., Lisbon, Portugal, 2011, pp. 71–78. [23] D. A. Norman, Emotional design: Why we love (or hate) everyday things. Basic Books, 2004. [24] D. Callele, E. Neufeld, and K. Schneider, “An Introduction to Experience Requirements,” in 2010 18th IEEE Int. Requir. Eng. Conf. Ieee, Sep. 2010, pp. 395–396. [25] K. Ramasubramaniam and R. Venkatachar, “Goal-Aligned Requirements Generation,” in Adv. Concept. Model. Found. Appl., ser. Lecture Notes in Computer Science, J.-L. Hainaut, E. A. Rundensteiner, M. Kirchberg, M. Bertolotto, M. Brochhausen, Y.-P. P. Chen, S. S.-S. Cherfi, M. Doerr, H. Han, S. Hartmann, J. Parsons, G. Poels, C. Rolland, J. Trujillo, E. Yu, and E. Zim´anyie, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2007, vol. 4802, pp. 245–254. [26] T. Bentley, L. Johnston, and K. von Baggo, “Putting Some Emotion into Requirements Engineering,” in Proc. 7th Aust. Work. Requir. Eng., 2002, pp. 227–241. [27] T. Gorschek, C. Wohlin, P. Carre, and S. Larsson, “A Model for Technology Transfer in Practice,” Software, IEEE, pp. 88–95, 2006. [28] P. Jordan, Designing Pleasurable Products: An introduction to the new human factors. CRC Press, 2002. [29] E. Ics, “Ergonomics of human-system interaction Part 210: Humancentred design for interactive systems (ISO 9241-210:2010),” Tech. Rep., 2011. [30] P. Runeson and M. H¨ost, “Guidelines for conducting and reporting case study research in software engineering,” Empir. Softw. Eng., vol. 14, no. 2, pp. 131–164, Dec. 2008. [31] A. Aurum and C. Wohlin, Engineering and managing software requirements. Springer, 2005. [32] S. Lauesen, Software Requirments- Styles and Techniques. AddisonWesley, 2002. [33] A. Cooper, R. Reimann, and D. Cronin, About face 3: the essentials of interaction design. Indianapolis, IN, USA: Wiley-India, 2007. [34] N. Millard, L. Hole, and S. Crowle, “SMILING THROUGH: MOTIVATION AT THE USER INTERFACE,” in 8th Int. Conf. Human-Computer Interact., L. Erlbaum, Ed. Associates Inc. Hillsdale, 1999. [35] P. Bourque and R. Fairley, eds, Eds., Guide to the Software Engineering Body of Knowledge. IEEE Computer Society, 2014. [36] B. Regnell and S. Brinkkemper, “Market-Driven Requirements Engineering for Software Products,” in Eng. Manag. Softw. Requir., A. Aurum and C. Wohlin, Eds. Springer Berlin / Heidelberg, 2005, ch. 13. [37] B. Regnell, R. Svensson, and T. Olsson, “Supporting roadmapping of quality requirements,” Software, IEEE, 2008.