Mohammadhossein Sherkat
Tim Miller
Antonette Mendoza- School of Computing and Information Systems, University of Melbourne, Parkville, VIC, Australia
In designing most software applications, much effort is placed upon the functional goals, making a software system useful. However, the failure to consider emotional goals, which make a software system pleasurable to use, can result in disappointment and system rejection even if utilitarian goals are well implemented. Although several studies have emphasised the importance of people’s emotional goals in developing software, there is little advice on how to address these goals in the software system development process. This paper bridges the gap between emotional goals elicitation and the software system design process by proposing a novel technique entitled the Emotional Goal Systematic Analysis Technique (EG-SAT) to systematically analyse people’s emotional goals in cooperation with functional and quality goals. EG-SAT allows in-depth analysis of emotional goals to build a software system and provides a visual notation for representing the analysis, facilitating communication and documentation. EG-SAT provides traceability of emotional goals in system design by connecting the emotional goals to functional and quality goals. To demonstrate the method in use, a two-part evaluation is conducted. First, EG-SAT is used to analyse the emotional goals of potential users of a mobile learning application that provides information about low carbon living for tradespeople and professionals in the building industry in Australia. The results of using EG-SAT in this case study are compared with a professionally developed baseline. Second, we ran a semi-controlled experiment in which 12 participants were asked to apply EG-SAT and another technique to our case study. The outcomes show that EG-SAT helped participants analyse emotional goals and gain valuable insights about the functional and non-functional goals for addressing people’s emotional goals. The key novelty of the EG-SAT is in proposing an easy to learn and easy to use technique that helps system analysts gain insights on how to address people’s emotional goals. Furthermore, the EG-SAT enables system analysts to convert emotional goals to traditional functional and non-functional goals that existing software engineering methodologies can analyse without demanding excessive effort.
1 Introduction
“Interaction with technology is now as much about what people feel as it is about what people do.” McCarthy and Wright (2007), p. 9.
It is widely argued that in designing most software applications, much effort is placed upon the utilitarian goals (functional and quality goals), which make a software system useful. However, overlooking key drivers of engagement such as people’s emotions and values, which cause a software system to be pleasurable to use, can result disappointment and system rejection depending upon the nature of the software system and emotional goals even if utilitarian goals are well-implemented Thew and Sutcliffe (2017); Miller et al. (2015); Proynova et al. (2011). It is due to this fact that from the human perspective, what they would or would not like to feel (emotional goal) in some applications are just as much or more important than what a system is supposed to accomplish Callele et al. (2006); Bahsoon et al. (2005). As a result, in the adoption and appropriation of software, stakeholders are demanding software that is more than just functional. They do not perceive a set of individual features in isolation but instead evaluate the entire experience, including their perception of the system at an emotional level Petermann (2013). Consequently, if a software system is unable to attract users, appeal to their emotional needs, a likely consequence is that people will not adopt it, it fails and often leads to users frustration Van Harmelen (2001); Platt (2007); Dix et al. (2003); Shneiderman et al. (2016).
It is important to take into account people’s goals that will create a desire to engage with the system (as opposed to the fear of not completing a particular work task). These goals may be related to social values or emotions that people wish to feel Sutcliffe and Thew (2010); Miller et al. (2012). From this perspective, considering people’s emotional goals is important as a transition in software design practice from useful, usable, and satisfying design to effective, efficient, and gratifying design. In such situations, the main design challenges are not just technical but also are driven by social and cultural needs to engage people at an emotional level Clancy (1995); Whittaker (1999); Tichy and Bascom (2008); Gonzales and Leroy (2011). Accordingly, overall software quality is reduced when people’s emotional goals are not incorporated into the software design process Dieste et al. (2008); Gonzales and Leroy (2011); Colomo-Palacios et al. (2010).
Emotional goals have typically been neglected in software engineering as people assume using a software system is a rational decision-making process. However, studies show that emotional goals are essential elements of considerations for interacting with anything that is designed to perform a function Tzvetanova et al. (2007). As a result, in designing and implementing a successful software system, software engineers must decide on the most effective combination of software features to address what people want and desire.
Miller et al. (2015) show that emotional goals are not the same as what is often termed quality goals because emotional goals are about people’s reaction to a system rather than a property of the system itself. Emotional goals such as the desire to feel ‘Part of a community’ or feel ‘a sense of worth’ are formed from an individual’s reflective emotional assessment of a system.
Addressing emotional goals in design is complicated for several reasons. First, emotional goals are the subjective part of people’s consciousness rather than the property of a software system. Second, people may be aware of their utilitarian goals, but they often are unaware of their behavioural goals. Third, people’s emotional goals are unstructured and often have a high level of ambiguity Callele et al. (2006); Mendoza et al. (2013). These characteristics cause several complexities in software design: 1) the subjectivity of emotional goals make them difficult to be elicited; 2) even if people’s emotional goals are elicited, there is no universal method of representing them in a way that is useful for software engineering; and 3) incorporating emotional goals into design is particularly challenging as it is difficult to understand how individual features support specific emotions.
The need to have adequate support for emotional goals is profound in social applications, such as platforms for enhancing social interaction, social networking and public health software systems. In these software systems, potential users are varied, often unknown, with different personalities, cultures, goals, characteristics, needs and desires. We define these types of software systems as People-Oriented Software (POS) systems. POS systems can be differentiated from other systems as: 1) people are often not obliged to use a software system, 2) people do not generally have well-defined roles and responsibilities and, 3) people have different cultural and social backgrounds and may conflicting as the same event can have wildly different emotional impacts on different people. These characteristics place greater importance on ensuring the motivation to engage is advocated for throughout the design process.
Reviewing the general advice for incorporating soft goals such as emotional goals into system design by the existing techniques like emotionally intelligent software agents Bates et al. (1994), Human-Computer Interaction (HCI) Preece et al. (2015); Marcus (2015), socio-technical design Thew and Sutcliffe (2017), User experience (UX) design Papakostas et al. (2021), and iterative development or after-development fixing up Robertson (2001); Goguen and Linde (1993) have a potential to give system analysts and designers some useful ideas regarding the system capabilities for addressing the users’ soft goals. Existing studies propose goals Dardenne et al. (1993); Anton (1996), personas Sim and Brouse (2015) and scenario techniques Holbrook (1990) to measure stakeholders’ emotional perceptions of requirements around emotional-related qualities. However, existing methods are not ideal as people’s emotional goals need to be understood before designing a software system. It may cost more if not integrated into the design process. Then, there is a lack of a systematic approach to integrate emotions fully within requirements engineering and map these goals to design and implementation of systems through the software engineering life cycle Miller et al. (2015); Sherkat et al. (2018).
In our previous work Sherkat et al. (2018), we defined the Emotional Attachment Framework—a series of techniques for capturing people’s emotional goals from data. In this paper, we argue that efforts may not be led to action without a proper method for analyzing people’s emotional goals to software specifications. For this reason, a technique for analyzing emotional goals and converting them to traditional functional and non-functional goals that existing software engineering methodologies can analyze is necessary for system prototyping, verification, validation, and final implementation. In this process, a key question for considering people’s emotional goals in system design activities is: How can system analysts systematically realize the design capabilities required to address users emotional goals?
To address this question, this paper proposes a method by combining the theories and techniques of software engineering, requirements engineering and decision making and incorporating emotional goals from the beginning of the software development life-cycle. The outcome of this study is a technique entitled Emotional Goal Systematic Analysis Technique (EG-SAT), which provides an approach to facilitate the process of finding software system capabilities to address emotional goals in software design.
The EG-SAT is a systematic technique that, instead of focusing on visualizing people’s emotional goals, can help provide system analysts with insights into how to address people’s emotional goals. This technique facilitates addressing emotional goals in the software design process by converting emotional goals into functional and non-functional goals that existing software engineering methodologies can analyze.
The EG-SAT aims to provide the right level of constraints to guide the process without overly constraining creativity. Instead of focusing just on visualizing people’s emotional goals, the proposed method in this chapter preserves the traceability of emotional goals through to the design features that support them. The proposed method is flexible to adopt any changes in terms of identifying new emotional goals during the system development process.
We evaluate our method in two parts. First, using an industry case study—a mobile learning application for the building industry sector. We recruited 16 participants and asked them to reflect their needs when using a mobile application for learning purposes. We analyzed and modelled the emotional goals of the key stakeholders using the Emotional Attachment Framework Sherkat et al. (2018). From the resulting models, we used EG-SAT to design and build a digital prototype. Via a subjective assessment of the digital prototype by 22 domain experts and end-users, compared with an alternative digital prototype also developed for the project, indicates that EG-SAT helped us find appropriate functional and non-functional goals for addressing people’s emotional goals.
Second, we recruited 12 participants with software engineering backgrounds and asked them to complete a series of tasks and answer questions about EG-SAT and any proposed alternative analysis techniques. We measured the time and accuracy of their responses and then asked a set of qualitative questions around their preferences between the techniques. We then asked domain experts to analyze the participants’ results and evaluate their output. The results show that the EG-SAT is more time-efficient, easier to use, easier to learn and can lead to more complete, correct and consistent results than the participant’s chosen techniques.
The following section discusses some main concepts, the complexity of people’s emotional goals and prior efforts in considering people’s emotional goals in design. In Section 3, we present our method for analyzing people’s emotional goals, and this proposed method will be evaluated in Sections 4. The last two sections of this paper are dedicated to discussion and conclusion.
2 Literature Review and Related Work
Even though the importance of people’s emotional goals have been emphasised in designing software systems and previous research has highlighted the growing need to consider emotional goals Bentley et al. (2002); Miller et al. (2015); Lopez-Lorca et al. (2014a); Miller et al. (2012); Lopez-Lorca et al. (2014b); Browne and Ramesh (2002), there is a huge gap between saying these are important and providing systematic techniques for incorporating them into the design.
Over the past 3 decades, several software engineering methodologies have been developed to assist system analysts in capturing goals and derive system functionality that supports them with various levels of abstraction and rigour Chung et al. (2012); Song et al. (2010); Cysneiros et al. (2001). Despite the maturity of existing software development approaches, it is widely argued that a major focus of these approaches is on functional and non-functional requirements and overlooking key drivers of that engagement; i.e. people’s values and emotions Bentley et al. (2002); Draper (1999); Gogueny (1994); Hassenzahl et al. (2001); Krumbholz et al. (2000); Miller et al. (2015); Proynova et al. (2011). As a result, designing a system’s specification for addressing people’s emotional goals remains a challenge.
This section briefly reviews the efforts in considering emotional goals in software system design and development. At the end of this section, we introduce the Function Analysis System Technique, from which we borrow several concepts.
2.1 Emotional Goals in Product Design
From the historical perspective, people’s emotions has been a part of design implicitly long before discussing its necessity explicitly Demir (2008). Research into capturing emotional goals in design dates back to the 1970s. In academia, people’s emotions as part of the design process emerged in the 1990s by the first conference on ‘Design and Emotion’ at the Delft University of Technology. Most of the research in this area focuses more generally on product design Chapman (2015). Participatory Design Sanders (2002), Empathic Design Fulton Suri (2003), Affective Interaction Beale and Creed (2009), universal Design Preiser and Ostroff (2001), Semantic Differential Methods, Conjoint Analysis, Semantic Description of Environments, Quality Function Deployment, Pleasure-Arousal-Dominance (PAD), Self Assessment Manikin (SAM), Product Emotion Measurement Instrument (PrEmo) and Kansei Engineering are a sample of these efforts Smith (2008); Norman (2013). Most of these methods may not provide a systematic approach for considering emotional goals in software systems development because: 1) they mainly can be applied to tangible components of a product, 2) they only consider the emotions at the moment of the first contact, 3) they are time and resources consuming methods, and 5) analysts should have something like images of finished products and represent them to the users.
Further to above mentioned conceptual frameworks and techniques for eliciting emotional goals in product design, some tools have been offered to interpret the emotional goals and communicate them. Gaver et al. (1999) proposed the Cultural Probes technique for capturing and analyzing people’s value, social and cultural requirements. Using the self reporting approach, this technique tries to utilize people’s values, social and cultural requirements that are significant for them in design. Djajadiningrat et al. (2000) for understanding how particular products should function, look and feel from the users’ point of view, proposed the Interaction Relabelling technique. By analyzing the users’ requirements in terms of form and function, this technique constructs the product’s specification. Sleeswijk Visser et al. (2007) for considering empathy, inspiration and engagement in product design and converting these three qualities to design specifications proposed a tool entitled ‘Context Mapping Tool Suit’. The context mapping suit is a visual tool to encourage creativity among the team. The output of this technique is a visual-verbal summary that helps system analysts to understand users in the creative process. Desmet and Hekkert (2002) in ‘Product and Emotion Navigator’ designed a database that design teams can use during the design process. The database includes the product images, the respected emotions creates by them for users and the reasons behind each emotion from the user’s point of view. McDonagh et al. (2002) proposed an ‘Image Board’ as a non-verbal technique for communicating a particular mood, function and cultural needs that users believe they need to be incorporated within a product design. Image boards are created with any images or materials collected by both system analysts or target users participation.
Although many of these methods have been applied to convert several types of emotional goals into design products, they 1) are descriptive techniques that usually recommend general advice without a repetitive and concrete process model, 2) have been designed for hard products, and their main concern is product appearance and, 3) are not formal enough to be used directly as an input of software engineering techniques. As a result, the proposed techniques in the product design domain may not provide a systematic process and method for software development purposes.
2.2 Emotional Goals in Software Engineering Domain
From the historical perspective, people’s emotions have been a part of design implicitly long before discussing its necessity explicitly Demir (2008). Many of these methods have been applied to convert several types of emotional goals into design products, but they 1) are descriptive techniques that usually recommend general advice without a repetitive and concrete process model, 2) have been designed for hard products, and their main concern is product appearance and, 3) are not formal enough to be used directly as an input of software engineering techniques. As a result, the proposed techniques in the product design domain may not provide a systematic process and method for software development purposes.
Although emotional goals are not such a well-studied topic in software engineering, some studies deal with this type of requirement.
In the following, we will review these approaches to see whether these methods or approaches can be used for addressing the emotional goals in software system design or not.
A number of previous studies have merely limited themselves to discuss the importance of considering soft goals - like emotional goals - and they have not gone beyond this preliminary stage. For instance, Sutcliffe (2009); Sutcliffe and Thew (2010) argued the role of people’s feelings and users’ value as ‘soft issues’ that can have different effects on requirements in the system development process. As another example, Levy (2020) investigated the importance of including emotional requirements in designing well-being applications for creating users engagement, fostering change and promoting well-being. The results of Levy’s study shows lack of having emotional requirements in developing well-being applications will not create user engagement over time Levy (2020).
Some past studies only outlined methods for understanding and recognizing such soft goals and did not mention how they can be used in designing a software system. As an example, Beyer and Holtzblatt (1999) suggested ‘Contextual Design’ as a user-centred approach for considering people’s norms in software design. This technique is similar to ethnography which users daily work is observed to understand and capture their insights for building the system. Although this technique can be used to discover people’s emotional goals, it does not particularly suggest a way to consider these requirements in design.
Friedman et al. (2013) in ‘Value Sensitive Design’ (VSD) proposed a technique for capturing the users’ moral values, which related to human welfare and justice, such as accountability and freedom from bias, and including them into the design. However, as Le Dantec et al. (2009) argued, VSD only includes a known set of values and does not have a technique for eliciting the other users’ values. Friedman in VSD also does not propose a tool for design a specific function for addressing a specific value in the design process.
By reviewing the literature, we can conclude that most of the previous studies have only focused on representing the soft goals. Eric (2009) by proposing the i* modelling notation tried to model soft goals Samavi et al. (2009). In Eric (2009); Samavi et al. (2009) studies besides classic non-functional requirements such as ‘reliable’ or ‘secure’, some emotional requirements are also included soft goals, such as ‘trustworthy’, ‘flexible’, ‘minimal intrusion’ or ‘normal lifestyle’. However, i* 1) does not provide enough explanation of how the soft goals analysis should be carried out in detail, 2) it does not advise how the soft goals should be identified and used in the design process and, 3) it also does not separate quality goals from emotional goals which we argue is important.
Miller et al. (2015) argue that emotional desires should be treated as first-class citizens in software engineering methodology. They proposed a notation of modelling emotional goals in agent-oriented modelling entitled ‘People-Oriented Software Engineering’ (POSE) to capture stakeholders’ desired feelings. They have compared the POSE with i* and reported that participants found POSE more efficient in terms of the average time for modelling emotional requirements as well as eliciting the correct emotional requirements. However, they do not propose a method to take these emotional goals to a design solution.
The next category of previous studies has been devoted to approaches that evaluate the effects of software systems on users’ emotions. For instance, Bianchi-Berthouze and Lisetti (2002) for considering the users’ emotions proposed ‘Model Of User Emotions’ (MOUE). In this model, by recognizing the users’ emotions from their facial expressions by processing movement, the system interprets and reacts according to the users’ emotions. By using a motion sensor, MOUE attempts to recognize and manage emotional expressions and creates a basis for translating emotional content to computational systems. As we discussed in Section 1, recognizing the users’ emotions after designing a software application is not our aim as we believe people’s emotional goals need to be understood before designing a software system and be considered as a part of system design.
This section has reviewed the current advice to consider emotional goals in the product and software system design process. Whilst the importance of consider such requirements has been widely emphasized, the past studies, to the best of our knowledge, provide general approaches for using the emotional goals in software system design process so that there is an opportunity to be more specific in software engineering.
As we saw in this section, the general advice for incorporating soft goals into system design by the existing techniques have some limitations in the software engineering domain. First, they are predominately representation techniques, and most of them only work at the visualisation level by proposing new notations. Accordingly, current techniques cannot express emotional goals as no formal representation is available for visualising them. Second, the current techniques are not equipped with techniques for converting soft goals into software specifications. As the previous studies show, the challenge of converting soft goals into design choices remains generally unsolved. The current techniques cannot be used to analyse people’s emotional goals and incorporate them into design parameters Bode and Riebisch (2011); Xu et al. (2006).
Third, the main focus of the previous studies in considering the emotional goals is limited to developing emotion recognition methods for evaluating usability issues. As we reviewed, they don’t directly focus on people’s emotional goals in the early stage of the system design process. They only focus on understanding users’ feelings and emotions about a software system and its interface and not the people’s emotional goals for designing a system. Fourth, the output of these techniques cannot be traced back and find how people’s emotional goals have been addressed by the system specification or integrated within the system. Although these approaches facilitate exploring people’s emotional goals, they may not suggest a process for turning these emotional goals into concrete software requirements that can be implemented.
2.3 Function Analysis System Technique
As the proposed technique in this paper was built on Function Analysis System Technique (FAST) Borza (2011), in this section, we briefly review this technique. FAST is a tool for idea generation that Charles W. Bytheway initially proposed as a paper to the Society of American Value Engineers (SAVE) conference in 1965 and contributed significantly to perhaps the most important phase of the Value Methodology (VM) Bytheway (2007). The success of using FAST in problem formulation and function analysis makes this technique an attractive candidate for middle-level creativity, and problem-solving Gerhardt and Rand (2006); Hanik and Kaufman (2005). Figure 1 shows a simple sample FAST diagram for designing a mouse trap val (2016).
FIGURE 1. FAST Diagram for a Mouse Trap val (2016).
The main philosophy of FAST is that constructing a diagram in doing any analysis helps more than introspection analysis because diagramming rules organize the analysis process and structures its outputs. As a result, analytic efforts go forward structured and not fragmented as in a random process. Therefore, there is less likelihood of confusion and overlooking the different aspects of the subject under analysis. All this leads to rigour and insightful analysis Fowler (1990). In addition, the determinate logic used in the FAST analysis and its diagram can be used for measuring the correctness and completeness of the analysis. The other advantage of the FAST is its higher capability to generate novel ideas. As the FAST provides a systematic analysis method, it is expected to generate more ideas in the problem-solving process with higher quality than what is expected from other problem-solving techniques such as brainstorming because it both provides constraints while giving freedom within those constraints Kaufman and Woodhead (2006). In this technique, there is no right or wrong model or result, and analysts work until the system’s actual functionality is identified, a consensus is reached, and analysts are satisfied that required requirements and functionality are expressed in the model. Using the FAST helps analysts to consider requirements as a complete unit, rather than analyzing them individually Kaufman and Woodhead (2006). One of the advantages of the FAST approach is its ability to represent function dependencies graphically. This ability facilitates stakeholders understanding and interpreting of the system’s functionality.
3 Proposed Method
System analysts need to produce the software requirements that will support emotional goals. Accordingly, any method for supporting emotional goals in software design needs to contain at least two elements: 1) a method for eliciting emotional goals; and 2) a method for analyzing emotional goals and proposing high-level solutions for addressing emotional goals. We address the first element using the Emotional Attachment Framework Sherkat et al. (2018). This paper addresses the second element by providing an analysis method that addresses emotional goals by deriving functional and quality goals to support them. This section describes the overall structure and components of the proposed method and its process model to facilitate finding software system capabilities to address emotional goals in software design.
3.1 Design Rationale
In developing the proposed method in this paper, we have the following considerations and assumptions based on our discussions in the previous sections:
• People’s emotional goals are usually addressed by functional and quality goals Booch (2005); Miller et al. (2015). Accordingly, it is our assumption in this research that any method for analyzing emotional goals and addressing them needs to link emotional goals to functional and quality goals.
• There are several mature analysis techniques for converting functional and quality goals into system specifications, as we discussed in Section 2. Accordingly, existing software engineering methodologies can be used to develop these into a system if we can find associated functional and quality goals for addressing emotional goals.
• Emotional goals are often high level, and abstract Sherkat et al. (2018). As a result, any proposed method for analysing emotional goals should break them down into more concrete concepts for analysing them and should be traceable.
• Due to the unstructured and ambiguous nature of emotional goals Sherkat et al. (2018), the analytic approaches that usually are used for defining the requirement specifications for functional and quality goals are not sufficient on their own. Finding functional and quality goals needs creative approaches that use idea-producing processes Young (2003) to generate a number of solutions. Once a list of potential requirement specifications is generated to address emotional goals, analytic processes can be used to select the feasible solution.
Our approach aims to provide the right level of constraints to guide the process of analyzing emotional goals without overly constraining creativity and preserves the traceability of emotional goals through to the design features that support them.
3.2 Emotional Attachment Framework
Before analysing emotional goals, we first need to elicit them. One way to achieve this is via the Emotional Attachment Framework (EAF) from our previous work Sherkat et al. (2018). Other requirements elicitation techniques may also be effective in uncovering emotional goals. However, we give an overview of the EAF here to illustrate the range of emotional goals that are expected and possible to use as inputs to the analysis process.
Emotional goals can be associated with a range of emotional attachment drivers such as ideal-self, public-self, social pleasure, etc. (Figure 2). The hierarchical classification nature of EAF can reveal emotional goals that overlap, conflict or require consolidation to avoid confusion in the requirement engineering process Sherkat et al. (2018). It also provides analysts with an understanding of the underlying drivers of each emotional goal, such as whether the need is social or not. For instance, a socially driven emotional goal may be better implemented in a software application with the ability to connect with other people. In short, a contextual understanding of the drivers of each emotional goal is valuable in the later consideration of software features that will support it. EAF categorizes the main drivers of forming emotional attachment under four categories, including Self-expression, Affiliation, Pleasure and Memories Sherkat et al. (2018).
FIGURE 2. Emotional attachment framework Sherkat et al. (2018).
Elicited emotional goals provide a foundation for system design but do not necessarily provide complete insight required for the design process. In the current paper we present a method for analyzing emotional goals and converting them to something that existing software engineering techniques can use for system design purposes.
3.3 Emotional Goal Systematic Analysis Technique
In this section, we introduce our proposed method entitled Emotional Goal Systematic Analysis Technique (EG-SAT), which provides step-wise guidelines for analyzing people’s emotional goals. The EG-SAT enables the requirements engineering process to deal with the complexity of emotional goals analysis by using ‘How’ and ‘Why’ questions in the form of a structured diagram. The EG-SAT aims to help find functional and quality goals that address emotional goals.
We adopt the notation proposed by Sterling and Taveter (2009), shown in Figure 3. The heart, cloud and parallelogram shapes represent the emotional, quality and functional goals, respectively. These notations refer to the following definitions:
• Functional Goal: what people expect a software system should or should not do.
• Quality Goal: what people expect a software system should or should not be.
• Emotional Goal: what people would or would not expect to feel by using a software system.
FIGURE 3. EG-SAT notations.
Consider a social media application like Facebook™. The goal of connecting friends is a functional goal that is quite different from the emotional goal of feeling connected. However, the functionality that connects friends supports a feeling of connectedness.
The EG-SAT promotes a hierarchical structure linking high-level emotional goals to more detailed emotional goals or functional and/or quality goals. In the EG-SAT hierarchy, any high-level emotional goal can be fulfilled by satisfying functional and/or quality goals in the next level of hierarchy. Figure 4 represent a schematic view of the EG-SAT hierarchy. Each descending level in the EG-SAT hierarchy represents an increasingly detailed description of the emotional, functional and quality goals. Functional and quality goals in the lower layers represent the high-level solutions that address emotional goals.
FIGURE 4. A schematic view of EG-SAT hierarchy.
The attached quality goal to the functional goal in Figure 4 shows that quality goals may support functional goals. The ‘How’ and ‘Why’ arrows in Figure 4 — as we will discuss in detail in Section 3.4 — show the direction of analysis of emotional goals in the EG-SAT. Each layer must contain all the goals (i.e. emotional, functional and quality) needed to ensure stakeholders achieve the next higher-level goals. This prevents extra goals that do not address emotional goals. Through the hierarchical structure of the EG-SAT, system analysts can always trace back to an emotional goal for specific functional and quality goals, meaning that the EG-SAT can be used for tracing the system capability in addressing people’s emotional goals.
3.4 Process Model
In this section, we outline a process model for the EG-SAT, outlined in Figure 5. The input to the process model is a list of emotional goals, which can elicited using any technique such as EAF Sherkat et al. (2018), POSE Miller et al. (2015), ethnography Neuman (2005), etc.
FIGURE 5. Process model.
The output of the EG-SAT is a list of functional and quality goals that support the emotional goals. These functional and quality goals will vary based on system analysts expertise and the project context. As shown in Figure 5, the EG-SAT process includes the following steps: 1) emotional goal decomposition and analysis; 2) functional and quality goal appraisal; and 3) functional and quality goal consolidation.
3.4.1 Emotional Goal Decomposition and Analysis
The first step aims to help system analysts find sets of functional and quality goals to address the emotional goals. This starts by listing elicited emotional goals at the top of the EG-SAT hierarchy. The EG-SAT vertical hierarchy helps macro analysis of emotional goals until the key functional and quality goals for addressing emotional goals be identified. For this purpose, system analysts start asking the ‘How’ question that primes the analyst for getting down to a solution Berger (2014). This line of questioning and thinking is read from top to bottom. Asking this question in EG-SAT helps system analysts get down to functional and quality goals that can be used to address emotional goals. A ‘How’ question may be answered by functional goals, quality goals, or even other emotional sub-goals. It should be answered from the viewpoint of different stakeholders to capture their perspectives and create a variety of ideas.
Emotional goals that are first elicited are usually high-level objectives. It means that if system analysts want to analyze abstract/combined emotional goals, they should first refine/decompose them to have sufficient detail for further analysis. In the case of having an abstract/combined emotional goal, the ‘How’ question decomposes an emotional goal into a set of alternative emotional sub-goals such that satisfaction of one or all of them leads to the satisfaction of the original emotional goal. Accordingly, there are two decomposition cases; 1) AND-decomposition: when every emotional sub-goal needs to be satisfied for the original emotional goal; and 2) OR-decomposition: when the satisfaction of one emotional sub-goal is sufficient for the satisfaction of the original emotional goal. Figure 6 shows sample AND and OR decompositions.
FIGURE 6. Sample of AND and OR decomposition.
For answering the ‘How’ question, different creative problem-solving techniques such as Brainstorming methods Gallagher (2013), the Systematic Inventive Technique Goldenberg et al. (2001), or the Theory of Inventive Problem Solving (TRIZ) Altshuller (1996) can be used. In this step, it is important to avoid judgmental thinking as it constrains the initial creative process. What is important in asking the ‘How’ question is that possible answers should identify what is to be designed and not how it is to be implemented. In other words, the ‘How’ question determines how to fulfil the emotional goals with functional and quality goals, but not necessarily how these functional and quality goals should be exactly implemented in the software engineering process.
Asking the ‘How’ question for each emotional goal should be continued until at least one functional or quality goal is achieved and system analysts are satisfied that a relevant functional or quality goal is identified. In other words, the termination condition of asking the ‘How’ question is when there are no (sub-)emotional goals at the bottom of the EG-SAT hierarchy. This is because emotional goals are properties of people, not software, so they cannot be implemented.
As an example, the possible answer for ‘How can sense of completion be addressed in a learning application?’ would be a functional goal like “Documenting Learning Achievement”, “Credential Acknowledgement”, and “Giving Feedback”. These functional goals can be implemented in different ways and through different software specifications and would require significant further analysis. Asking the ‘How’ question helps system analysts to avoid thinking just about a technical feature and miss the opportunity to engage in divergent thinking about other alternatives that can be used for addressing emotional goals.
Figure 7 shows the EG-SAT hierarchy for a sample emotional goal.
FIGURE 7. Sample of How question analysis.
3.4.2 Functional and Quality Goal Appraisal
The second step aims to help system analysts to evaluate the achieved functional and quality goals and make sure that they are relevant, and address the emotional goals. In the first step, answering the ‘How’ questions, analysts should avoid judgmental thinking. In the second step, we answer ‘Why’ questions. This line of questioning is bottom-up and should switch from creative to critical thinking. ‘Why’ questions are interrogative questions whose primary goal is to help system analysts understand which functional and/or quality goals do not address the related emotional goal and should be eliminated or improved. This is an iterative process and can be repeated several times until the systems analyst is satisfied with the correctness of all the achieved functional and quality goals. As an example, we use the EG-SAT hierarchy discussed in the previous step (Figure 7). The possible answer to Why is “credential acknowledgement” necessary? is “because this functionality can help learners to see that they have completed learning tasks to a particular point”.
The ‘Why’ question can also be used for tracing functionality back to emotional goals. In other words, the ‘Why’ question can be used as a traceability technique to determine which users’ emotional goals can be addressed by the existing system’s specifications.
3.4.3 Functional and Quality Goals Consolidation
Consolidation is defined as an operation that combines two or more similar functional or quality goals. This occurs when two or more goals represent the same main concept. For this purpose, once the previous steps are complete, system analysts begin to group and consolidate similar functional and quality goals. As an example, “Documenting Learning Achievement” and “Acknowledging the Results” are two functional goals that have been achieved and evaluated in goal decomposition (Section 3.4.1) and goal appraisal (Section 3.4.2) respectively. However, both of these functional goals refer to the same concept, “Making Learning Progress Visible”. Accordingly, we can merge these two functional goals and replace them with a non-repetitive goal in the EG-SAT hierarchy (Figure 8). Combined functional goals inherit their associated quality goals to the new functional goal resulting from the consolidation process.
FIGURE 8. Sample of merging goals.
3.4.3.1 Summary
In EG-SAT, each emotional goal will be analyzed until it reaches to a specific functional and/or quality goal. The main focus of the proposed method is supporting the ideation process for addressing emotional goals. This method in this research is incremental and iterative so system analysts may switch between tasks as new ideas emerge. The lower level in EG-SAT shows functional and quality goals that the system analysts have more control over and can be used by system analysts for further analysis via existing software engineering methodologies.
4 Evaluation
Any methods in information systems and software engineering are developed to improve task performance in two ways: 1) improving the quality of the result; and 2) reducing effort required to complete the task Moody (2003); Wieringa (2014); Sonnenberg and Vom Brocke (2011); Prat et al. (2014). Accordingly, the aims of our evaluation in this research are as below:
• Measuring the proposed method’s effectiveness: to what extent can the proposed method help system analysts to understand the capabilities required to address emotional goals?
• Measuring the proposed method’s efficiency: to what extent does the proposed method reduce the effort required to understand the capabilities required to address emotional goals?
For measuring the effectiveness of the proposed method, completeness, correctness and consistency (3Cs) were chosen based on popular evaluation approaches in software engineering literature Pennotti et al. (2009); Zowghi and Gervasi (2002); Lee (2014); Pressman (2005). In this paper, we define these quality measures as below in the context of our proposed method:
• Completeness: the proposed method leads to a complete analysis, if all the required functional and quality goals for addressing people’s emotional goals have been specified.
• Correctness: the proposed method leads to a correct analysis, if it represents the accurate and correct functional and quality goals for addressing people’s emotional goals.
• Consistency: According to the definition of consistency Trochim and Donnelly (2001), the proposed method leads to consistent results if 1) the achieved results are consistent within itself (internal consistency) and 2) the same result can be repeatedly derived (external consistency) Leung (2015). Creative problem-solving approaches such as EG-SAT are subjective, with different factors like context, experience and ideation technique used affecting the results. However, we believe that the high-level insights generated by the proposed method should be consistent and that different people will be able to consistently derive high-quality functional and quality goals that achieve the emotional goals. Thus, we hypothesise that if different people apply EG-SAT on the same data set, their main goals will be the same in concept.
In this research, by reviewing the literature Moody (2003); Davis (1989); Fitzgerald (1991); Mendoza et al. (2010b,a), the following metrics were used for measuring the method’s efficiency:
• Time: this metric measures the time taken to complete the task by using a method.
• Perceived Ease of Learning: this metric measures to what extent a method would be easy to learn.
• Perceived Ease of Use: this metric measures to what extent a method would be easy to use.
• Perceived Usefulness: this metric measures to what extent a method would be effective in achieving its intended objectives.
• Intention to Use: this metric measures to what extent a person intends to use a particular method.
To address the evaluation aims and measuring the effectiveness and efficiency criteria, we undertook two main activities: 1) a case study analysis; and 2) a semi-controlled experiment.
We recruited 7 independent domain experts in our application domain. The case study is described in detail in Section 4.1. Five of the domain experts were exceedingly well-versed in Australia’s building sector and education and were heavily involved in sustainable urban design and energy efficiency. The other two domain experts were also part of the Cooperative Research Centre for Low-Carbon Living (CRCLCL) project and had large experience in designing and developing software applications. In each evaluation study, domain experts worked independently, except when they required clarifications for doing the tasks.
We also invited 17 trainees and apprentices in the building and construction industry to participate in an evaluation. All of the participants were senior apprentices and trainees who had combined paid work and structured training between 36 and 48 months at the time of the study. 9 out of 17 trainees and participants had also three to 5 years of experience in industry/trade. For the semi-controlled experiment, 12 participants were recruited from a range of experience and expertise in software engineering and administered surveys to each. All the participants had a master’s degree or higher in software engineering with three to 5 years of working experience. Seven participants had specific training or experience in requirements engineering. Table 1 shows a summary of evaluation techniques used in this study.
TABLE 1. The summary of evaluation techniques.
In the following sections, we discuss the case study and semi-controlled experiment. For each activity, an overview of the results will be discussed. The last part of this section is dedicated to reviewing some of the lessons that we learned.
4.1 Case Study Analysis
The case study is based on a real-world project, collaborating with industry partners to develop an application to support carbon reduction and sustainable living. The application’s target users were those in the construction industry, with a key objective of the application being to increase motivation, enable collaboration, and stimulate action in implementing low carbon living products and services. According to “A Vision for Australia’s Property and Construction Industry” Hampson and Brandon (2004), sustainable built environments and reducing greenhouse gas emissions is one of the top goals in the building sector in Australia over the next 20 years.
One of the authors of this paper applied EG-SAT in collaboration with development efforts within this project. The outcome was a mobile learning prototype application called Building Quality Passport Winfree et al. (2017).
As part of this project, it was decided that the team should design and develop a mobile learning application entitled the Building Quality Passport application to equip and motivate tradespeople and professionals in the building sector to engage with education on low-carbon building technologies and services. According to the anonymity, diversity and variety of Building Quality Passport’s potential users, it is a people-oriented system.
4.1.1 Method
After eliciting emotional goals using the Emotional Attachment Framework Sherkat et al. (2018), the first author led the application of EG-SAT to analyze the emotional goals of trainees and apprentices in the building sector in Australia for designing the digital prototype of the Building Quality Passport that fulfilled the elicited emotional goals. Simultaneously, an application design and development company was contracted to undertake a design using the same elicited emotional goals and to apply their method of choice. Their choices were independent of the authors.
4.1.1.1 Emotional Goals
The first step was to find the list of emotional goals for the application to serve as input to the EG-SAT. For this, we applied the Emotional Attachment Framework Sherkat et al. (2018). To gather sufficient data for the Emotional Attachment Framework, three different questionnaires were used with 16 participants including 11 building and trades trainees and apprentices, two employers and workplace mentors and, three training facilitators and trade teachers1. The online questionnaires were focused on trainees and apprentices emotional goals for designing a mobile learning application entitled Building Quality Passport. In each questionnaire, a series of general questions were asked, based on the following themes: 1) what should a mobile learning application do for you? 2) how should it be? and 3) how do you want to feel when using a mobile application for learning purposes? These questions were not asked directly as stated above but were based on these themes. For those participants with experience in using mobile learning applications, also some questions were asked regarding problems they experienced using mobile learning applications. The data was analyzed using the Emotional Attachment Framework approach Sherkat et al. (2018) to extract and model the key emotional goals and concerns by different stakeholders. As a result, 56 emotional goals were elicited and presented to the research group2. Based on the similarity between the achieved emotional goals, the research group consolidated similar emotional goals to achieve a list of emotional goals. In this study, the 56 initial emotional goals were grouped into 24 emotional goals3. Table 2 represents a summary of results in the Building Quality Passport case study.
TABLE 2. Summary of emotional goals in Building Quality Passport case study.
The fourth column in Table 2 represents the frequency of each emotional goal; for example, four different emotional goals in the data had the same emotional concept of ‘learning at my own pace. This indicates higher importance and priority. By analyzing the online survey data, we categorized the achieved emotional goals under the four main emotional drivers4.
4.1.1.2 EG-SAT Application
We analyzed the set of emotional goals using our EG-SAT process model (Figure 5). The authors then conducted internal brainstorming sessions to find detailed design solutions (software features) for each functional and quality goal. Then the first author used these to design a digital prototype for the Building Quality Passport5.
4.1.1.3 Baseline
To form a baseline for our method, the project funded the development of a second digital prototype. An application design and development company with several years of experience in this field and who has developed various successful projects were contracted to build this prototype to create a digital prototype. As input to their process, they were given all previous findings, including data, the list of elicited emotional goals, and access to domain experts. A designer from this company gathered some additional data using its own data-gathering techniques and used their user experience methods for analyzing the emotional goals provided by the authors. Finally, they produced a digital prototype of their design. The authors of the present paper were not involved in this process except to provide the list of emotional goals and data.
4.1.1.4 Feature Merging
Given that the scope of the EG-SAT ends with functional and quality goals, rather than design features, we merged common features (e.g., log-in and some basic features such as photo uploading and tagging) between both the baseline and the EG-SAT prototype. This enabled us to control for the variable of feature design to ensure that participant ratings were about the features selected rather than how they were represented. We call the professionally-developed prototype ‘Baseline’ and ours the ‘EG-SAT Version’. Figures 9, 10 represent some sample screens of baseline and EG-SAT version respectively.
FIGURE 9. Some sample screens of the designed digital prototype - baseline.
FIGURE 10. Some sample screens of the designed digital prototype - EG-SAT version.
4.1.2 Effectiveness Analysis
We presented both prototypes to five of the domain experts (including three CRCLCL members and two training facilitators and trade teachers) and 17 trainees and apprentices over three focus groups and gathered both qualitative feedback and quantitative ratings of the two prototypes. The following steps were conducted in the process of measuring the proposed method’s effectiveness based on the case study:
• The list of elicited emotional goals used for developing the both versions of the digital prototypes (baseline and EG-SAT version) and the list of functional and quality goals (EG-SAT analysis output) used for developing the EG-SAT version was presented to the domain experts and trainees, and apprentices separately and then they were asked to review them.
• Two versions of the digital prototypes (baseline and EG-SAT version) were presented to the participants. Note that these two versions were presented to the domain experts, trainees, and apprentices as two potential designs and both versions were products of the same joint project. The baseline version was presented by a non-author and the EG-SAT version by the first author of this paper, thus eliminating any potential subject bias.
• The domain experts and trainees and apprentices were asked to complete two tasks: 1) compare the baseline version and EG-SAT version regarding their functionality and determine which version better addresses the elicited emotional goals; 2) answer three open-ended questions: a) identify any additional functional or quality goals are needed for addressing the emotional goals; b) identify any incorrect functional, or quality goals are, and c) identify any inconsistency within functional or quality goals. They were also asked to reflect their attitudes towards the designed digital prototypes, elicited emotional goals and associated functional and quality goals with other group members.
For this purpose, the domain experts and trainees and apprentices were asked to answer a questionnaire6. One of the authors of the present paper took notes and recorded the vital points raised by the participates during the evaluation process.
To avoid any bias, both of the digital prototypes were developed by using the InVision®7 platform to minimize the effects of interface and graphical design on the participants’ judgment.
4.1.3 Results
As we discussed at the start of Section 4, we investigated three evaluation criteria for measuring the effectiveness of the proposed method; completeness, correctness and consistency. In the following, a summary of results for effectiveness analysis will be discussed.
Figures 11, 12 show the mean and standard deviation of the responses by domain experts and end-users, respectively, as to which prototype best addresses the emotional goals. The IDs on each side of distributions refer to each emotional goal as was explained in Table 2. The dark bullet shows the average of the participants’ responses, therefore being closer to the left means the baseline is preferred, averaged over all participants in each study, and on the right, EG-SAT is preferred.
FIGURE 11. Domain experts analysis.
FIGURE 12. The summary of effectiveness analysis results.
These figures show a strong preference over most emotional goals from both participant groups, which shows that the participants rated that the EG-SAT version better addresses the emotional goals than the baseline. They also show that the average answers of the trainees and apprentices (end users) are higher than the domain experts. Understanding the main reason for this difference is not so complicated if we consider that the domain experts’ main concern is learning. At the same time, the trainees and apprentices are more interested in career outcomes.
4.1.3.1 Completeness
From our results, we conclude that EG-SAT, compared with the method used to derive the baseline, was more comprehensive for analyzing the emotional goals in terms of the level of abstraction of emotional goals as well as the required solutions for addressing the emotional goals. The proposed method has a higher degree of completeness, both at the analytical level and at the level of presentation, compared with the method used to derive the baseline. Analyzing the domain experts responses to the qualitative questions shows that the domain experts acknowledge the completeness and correctness of the EG-SAT version. For instance, domain experts acknowledged that considering the emotional goals in designing the application can engage users more. One domain expert stated:
“It [baseline] incorporates just some basic features. It was quiet basic in terms of current available. [The] EG-SAT version was more engaging,….it [EG-SAT version] has more modern feel.”
As the average answers of the domain experts show, EG-SAT version by address the potential users’ emotional goals Another domain expert stated:
“[The EG-SAT version] is more fulfilling to use…\enleadertwodots it better responds to requirements.”
4.1.3.2 Correctness
None of the domain experts raised a case that is incorrect and needs to be changed or deleted from their opinions. It shows that the proposed method could lead to correct results from the domain experts’ point of view. Responding to the question about what they would like to add/change, one domain expert stated:
“Nothing, covers requirements very well”
One domain expert during presenting the EG-SAT version stated:
“It [EG-SAT version] makes it [learning process] a nicer, fuller experience that is not purely tidy-up in that one [baseline].”
and,
“They [trainees and apprentices] can use it [EG-SAT version] for healthy means, that is great!. We want it [EG-SAT version] to engage them [trainees and apprentices].”
The trainees and apprentices comments in the questionnaire and in discussing others provided some valuable points. For example, one stated:
“Somehow feel more comfortable and motivated. It stimulates me to explore it.”
Although there are some suggestions regarding the interface in the trainees and apprentices comments, none identified incorrect or incomplete requirements. It acknowledges the completeness and correctness of the EG-SAT version’s specified functional and quality goals for addressing the emotional goals.
4.1.3.3 Consistency
For measuring to what extent the achieved results are consistent within themselves (internal consistency), we asked the domain experts and trainees and apprentices to determine whether any inconsistency exists 1) within the proposed quality goals; and 2) within the proposed functional goals. No participant noted inconsistencies in the goals or prototype.
4.2 Semi-Controlled Experiment
The goals of this semi-controlled experiment are two-fold. First, we evaluate whether our proposed method leads to complete, correct and consistent results when it is used by people independent of the authors (effectiveness). Second, we evaluate whether our proposed method improves performance in finding functional and quality goals (efficiency).
4.2.1 Method
To conduct the semi-controlled experiment, 12 participants were recruited with a variety of experience and expertise in software engineering. Based on their responses in a screening survey, all of the participants had a master’s degree or higher in the field of software engineering with three to 5 years of working experience. Seven participants had specific training in requirements engineering. The participants were asked to apply both 1) EG-SAT and 2) an alternative method of their choice to extract functional and quality goals from a subset of the emotional goals of the Building Passport Quality case study and measured the effectiveness and efficiency criteria (Table 1).
The experiment used a within-subject design, comparing two activities. In each activity, each participant was presented with the same sample of 12 emotional goals of the Building Passport Quality case study. To mitigate the potential bias, the sample emotional goals in each activity were selected randomly. In the first activity, participants were given the option to select any creative problem-solving techniques that they were familiar with to derive functional and quality goals from the 12 emotional goals. In the second activity, the EG-SAT technique was introduced to the participant, who was then asked to apply EG-SAT to derive functional and quality goals. To avoid an order effect, we counterbalanced by asking half of the participants to use EG-SAT in the first activity and half to use their method of choice in the second activity; and then switched. Participants worked independently and requested only to ask questions to clarify the process.
4.2.2 Efficiency and Effectiveness Analysis
For measuring the efficiency and effectiveness criteria (Table 1), we gathered both qualitative feedback and quantitative ratings. As such, the following measures were taken:
• How long each participant used to complete their analysis in each round. There were no time limits on tasks, and the average time spent by the participants was calculated in minutes.
• For measuring the perceived ease of learning, ease of use, usefulness and intention to use, we administered a post-activity survey and asked participants in each group some open-ended qualitative questions about the used methods such as: 1) how comfortable they felt learning the method (easy to learn); 2) how comfortable they would feel using the method for analysing emotional goals (easy to use); 3) to what extent they found the used method useful (usefulness); and 4) which method is their preference if they had to analyse people’s emotional goals in the future? (intention to use)8. In the designed questionnaire, some general questions were also asked about participants general feelings about the methods.
As it is difficult to measure the participants’ functional and quality goals objectively, we went back to the domain experts to assess the participants’ output. We supplied four domain experts (including two CRCLCL members and two others with software engineering backgrounds) with the sample emotional goals used by the participants in semi-controlled experiment and two lists of functional and quality goals by each participant, corresponding to the two rounds. Domain experts did not know which methods were used for each list. The domain experts were asked to do the following tasks:
• Task 1: Review the lists and identify any inconsistency within the functional and quality goals suggested by the same participant in the two rounds. The output of this task was two lists of functional and quality goals, which were deemed consistent from the domain experts point of view.
• Task 2: Review the lists and identify functional and quality goals that were deemed relevant for addressing the sample emotional goals. The output of this task was two lists of functional and quality goals, which the domain experts endorsed their correctness.
• Task 3: Define non-repetitive functional and quality goals from what they had endorsed their correctness. For this purpose, the domain experts were asked to review the first list of the correct functional and quality goals and identify any functional and quality goals that they cannot map to any correct functional and quality goals suggested by the same participant in the second list of the correct functional and quality goals, and vice versa.
4.2.3 Efficiency Results
Table 3 and Figure 13 summarize the results for two experimental groups and evaluation metrics respectively. This shows the baseline methods uses and the average number of relevant proposed functional and quality goals by the participants, as determined by the domain experts.
TABLE 3. The Summary of semi-controlled experiment results.
FIGURE 13. The summary of efficiency analysis results.
As Table 3 shows, over the 12 participants, eight used brainstorming, and four others used techniques used Synectics, POSE, SCAMPER and Attribute Listing, respectively. Figure 13 shows the mean and standard deviation of the responses for the questions associated with qualitative metrics. From Figure 13 we can see several expected results. First, participants have a stronger preference for using EG-SAT, largely because it has a hierarchical layout, well-structured and easy to follow process model, leading to a more natural way to analyze emotional goals. Second, participants found the EG-SAT is easier to learn and use.
For measuring to what extent the difference between the number of achieved functional and quality goals by using the baseline methods and EG-SAT and spent time is important, we conducted Wilcoxon signed-rank test Sheskin (2003). Our null hypothesis is no statistically significant difference between the number of functional and quality goals achieved and time spent by baseline methods and the EG-SAT. We conducted the Wilcoxon signed-rank test at the 95% level. Accordingly, the null hypothesis will be rejected if the p-value be equal to or less than 0.05. Table 3 shows the p-values for several functional and quality goals and time spent are 0.00222( <0.05), so they are significant at this level. These results support our hypothesis that the EG-SAT can help produce higher quality functional and quality goals with less time/effort than some other techniques.
The participants’ responses to the quantitative questions provide further evidence of the EG-SAT efficiency. Participants’ responses support this argument that the EG-SAT is a more helpful method than other techniques for analysing the emotional goals in the system analysis process. As Figure 13 shows, all participants believe that the EG-SAT is easy to learn and use for analysing people’s emotional goals. For example, the following quotes are from three participants:
“ It’s simplicity makes it both easy to learn and easy to apply.”
“The method B [EG-SAT] is easy for me to use, it directs my thinking in a systematic manner, it is good recommended technique to analyze requirements prior to starting system development.”
“it provides the relation between the emotional goals and associated functional and quality goals explicitly. It makes design justification and validation more straightforward.”
However, one of the participants expressed a preference for another technique. This participant commented that he/she preferred Brainstorming because he/she believes:
“It is more convenient for me. I used it several times before. I feel more confident with it, so I will go for it.” …“I think B [EG-SAT] is more structured so probably more useful for majority of people. It is also very useful for people how are not good at analysis as it provides something to work with.”
4.2.4 Effectiveness Results
The results of domain experts analysis show that our proposed method helped participants. Table 4 shows the results of the domain experts’ analysis.
TABLE 4. The summary of domain experts evaluation results.
4.2.4.1 Completeness and Correctness
As Table 4 shows, from the domain experts point of view, participants found more non-repetitive and relevant ways to address the emotional goals using the EG-SAT compared with other techniques. Although we acknowledge that achieving more non-repetitive and relevant functional and quality goals is not a benchmark for measuring the proposed method completeness and correctness, the uniqueness and relevance of achieved functional and quality goals support the claim that the EG-SAT has succeeded to provide the middle-level creativity for analyzing people’s emotional goals and higher capability to generate novel correct and complete ideas for addressing the emotional goals.
We conducted the Wilcoxon signed-rank test at a 95% level for these results, with the null hypothesis that there are no statistically significant differences between the number of non-repetitive and relevant functional/quality goals using the EG-SAT and the other baseline techniques. Table 4 shows the results for, with p-values 0.00328 and 0.00222 respectively, therefore we reject the null hypotheses.
4.2.4.2 Internal Consistency
Although all the participants used the same data set and the main findings in the semi-controlled experiment were adapted from a well-defined method (i.e. EG-SAT), there is a potential for inconsistency within the functional and quality goals suggested by each participant (internal consistency) and between the functional and quality goals suggested by the participants (external consistency).
Table 4 shows that, on average, participants’ goals were more consistent when using EG-SAT than their baseline technique. The results show that the average number of inconsistent functional and quality goals was more than double in the baseline methods. We again a Wilcoxon signed-rank test for a 95% level, with the null hypothesis that there is no statistically significant difference between the number of inconsistent goals by using the EG-SAT and the other baseline techniques. Table 4 shows the p-value for functional and quality goals are 0.00338 and 0.00758 respectively. Therefore, we reject the null hypothesis.
4.2.4.3 External Consistency
For measuring external consistency (consistency between participants), we used Cohen’s Kappa values to measure the inter-rater reliability to understand the extent to which the proposed method leads to consistent results. Cohen’s Kappa statistical measurements range from −1.0 to 1.0; larger numbers represent better reliability, and smaller numbers near zero suggest agreement has happened by chance Saeed et al. (2013). As we discussed earlier, for such a creative problem-solving approach as EG-SAT, the output is subjective. Different factors like context, experience and the ideation technique used can affect the results. However, we hypothesise that the main idea will be the same if other people use the EG-SAT for the same data set, regardless of the term used to describe the functional and quality goals.
As a part of the process, one of the authors of the present paper analysed the participants’ responses and categorised the associated functional and quality goals for each emotional goal based on their similarities. Then the Cohen’s Kappa values for measuring the proposed method consistency was calculated. Table 5 shows the statistical values for the Cohen’s Kappa index. As all the Cohen’s Kappa values for both functional and quality goals are above 70%, which is considered the minimum value for inter-rater agreement to be considered consistent Boudreau et al. (2001). It supports our hypothesis that the proposed method can lead to consistent results.
TABLE 5. Consistency analysis - Cohen’s kappa values.
4.3 Limitations
There are some limitations to this research. First, we considered only one case study and two different design projects. This is the trade-off of grounding this evaluation in a real industrial case study. Accordingly, generalizing the effectiveness and efficiency of the proposed method is limited and further case studies and evaluations with larger numbers would be a logical next step for this research. Second, The case study is subject to bias in that the participants in the semi-controlled experiment knew that the initial baseline results were used for comparison, which may have distorted their answers and lead to inaccuracies in our results. Additional studies would improve the validity of the proposed method for analyzing emotional goals. Third, the analyzed data in the industry case study focused only on the trainees and apprentices emotional goals. In contrast, data from other stakeholders such as employers, workplace mentors, training facilitators, and trade teachers may be necessary for further validation. Finally, we used the time spent on analysis and several suggested functional and quality goals that may not be entirely accurate for measuring the efficiency of the proposed method.
5 Discussion and Lessons Learned
In this paper, the research question, “How can system analysts achieve a better perception regarding the capabilities required to address emotional goals systematically?” was addressed. To this effect, we designed and developed a new technique to facilitate the process of finding high-level software system capabilities in software design from emotional goals. Although emotional needs have received some attention in the software engineering domain, to the best of our knowledge, the proposed method in the current paper is the first method that can help system analysts to systematically analyze people’s emotional goals for system design purposes.
The proposed method in this study was evaluated via a semi-controlled experiment and designing a digital prototype of a mobile learning application. The case study analysis results show that the EG-SAT can lead to improved outcomes of the designed digital prototype. The results of the semi-controlled experiment also show that the EG-SAT is a more useful method than other used techniques for analyzing the emotional goals in the system analysis process as all the participants believe that the EG-SAT is easy to learn and use for analyzing people’s emotional goals. In terms of effectiveness metrics, the results show that participants found more non-repetitive, relevant and consistent ways to address the emotional goals using the EG-SAT compared with other techniques. The results of the case study analysis and the semi-controlled experiment support the argument in this study that the EG-SAT can help system analysts to achieve a better perception regarding the capabilities required to address emotional goals.
As we experienced in this study, asking the How question helped us to draw out the functional and quality goals while preventing us from thinking just about a technical solution. Using the EG-SAT questioning structure to analyse and validate the emotional goals enabled greater focus and more freedom for creative and intense exchange between the project team members. Asking the Why question helped the research team to validate the results systematically and find the overlap between the suggested functional and quality goals. Further, questioning Why helped us to avoid assumptions and logic traps and instead directly trace the chain of causality from the proposed functional and quality goals to an emotional goal. However, we acknowledge the outcomes of questioning depends upon the knowledge and experience of the people involved.
As expected, the diagramming structure in the EG-SAT reduced confusion in analysing the emotional goals. The EG-SAT hierarchy was effective at decomposing emotional goals. Based on our experience, the visualisation of emotional, functional and quality goals in one diagram made research team conversions more advantageous compared to ordinary tables or text that we used in other projects9. The EG-SAT hierarchy also helped us represent which functional and quality goals must be fulfilled in the final application to an emotional goal.
6 Conclusion and Future Work
Over the past decade, we have seen a paradigm shift from designing software systems for satisfying functional goals towards applications trying to enhance people’s quality of life. Due to this, software engineers need to engage with emotional relationships between software systems and people. Although software engineering studies have highlighted the significance of emotional goals in software design, there has been little research to suggest a systematic and repetitive technique for this purpose.
As we investigated in this paper, the general advice for incorporating soft goals such as emotional goals into system design by the existing techniques have some limitations in software engineering: 1) they are predominately representation techniques, and most of them only work at the visualisation level by proposing new notations; 2) the current techniques are not equipped with systematic ways of converting soft goals into software specifications; 3) the main focus of the previous studies in considering the emotional goals is limited to developing emotion recognition methods in the context of user experience and interaction after the design of systems; and 4) the output of these techniques are limited to tracking back to how people’s emotional goals have been addressed by the system specification or are integrated within the system.
In this paper, we have addressed the existing gap and the research question and introduced a novel method for analysing people’s emotional goals and converting them to some functional and quality goals. These methods were trialled within three real-world case studies (related to issues such as low carbon living and homelessness that are important to society), semi-controlled experiments, comparison analysis, domain expert evaluation and end-user evaluations to assess their effectiveness and efficiency.
This study is significant from several aspects. First, it addresses the challenge and complexity of considering emotional goals in the software system design process by investigating the emotional goal’s characteristics. Second, it proposes a novel method for systematically analysing people’s emotional goals in cooperation with functional and quality goals. It allows in-depth analysis of emotional goals to build a software system and provides a visual annotation for representing the analysis, facilitating communication and documentation. Fourth, it provides traceability of emotional goals in system design by connecting them to functional and quality goals. Finally, it bridges the gap between emotional goals elicitation and the software system design process.
In our future work, we will apply EG-SAT in other collaborative projects. Our current study focused on evaluating the EG-SAT in analysing people’s emotional goals. However, as discussed in this paper, the EG-SAT can be used reverse to analyse the system maturity level in addressing people’s emotional goals. As a part of our future study, we would like to understand this better. We encourage other researchers to use the proposed method in longer-term projects to design software systems.
Data Availability Statement
The original contributions presented in the study are included in the article/Supplementary Material, further inquiries can be directed to the corresponding author.
Ethics Statement
The studies involving human participants were reviewed and approved by The Engineering Human Ethics Advisory Group - University of Melbourne. The patients/participants provided their written informed consent to participate in this study.
Author Contributions
MS conceived the presented idea, developed the theoretical framework, derived the models, analysed the data, carried out the implementation, performed the calculations and drafted the article. TM and AM supervised the work, provided critical feedback and helped shape the research and worked on the manuscript. RB aided in interpreting the results. All authors discussed the results and commented on the manuscript.
Funding
This research is funded by the Australian Research Council Discovery Grant DP160104083 Catering for individuals’ emotions in technology development. The first author is funded by a University of Melbourne MIRS scholarship and a top-up from the CRC for Low-Carbon Living grant Increasing knowledge and motivating collaborative action on Low Carbon Living through team-based and game-based mobile learning.
Conflict of Interest
The authors declare that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.
Publisher’s Note
All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.
Acknowledgments
The authors would like to express their gratitude to participants for their participation in this study. They are also thankful for the valuable feedback they received on the proposed method and digital prototype from Tomi Winfree, Gavin Melles, Peter Graham, Paul Goldacre, and Tom Mansfield.
Footnotes
1The questionnaires are available at https://goo.gl/forms/qlkkQwN0L0SL3Ls73, https://goo.gl/forms/9EgIjz2CvZ8IIsZN2, https://goo.gl/forms/9EQmwcvM3QW91VSJ2 and, https://goo.gl/forms/oh1jOxX64npgYLjb2.
2The complete list is available at https://tinyurl.com/ya3fny4b.
3The complete list of emotional goals is available at https://tinyurl.com/y9c2hlqc.
4Summary of results is available at https://tinyurl.com/y9l8mpdp.
5EG-SAT analysis is available at https://tinyurl.com/ybucrqwh and https://tinyurl.com/yahjsvuk respectively.
6The questionnaire is available at https://tinyurl.com/yalts3wo.
7https://www.invisionapp.com/.
8The questionnaire is available at https://tinyurl.com/ydaoj35p.
9The diagram is available at https://tinyurl.com/yahjsvuk.
References
Altshuller, G. (1996). And Suddenly the Inventor Appeared: TRIZ, the Theory of Inventive Problem Solving. los angeles, CA: Technical Innovation Center, Inc.
Anton, A. I. (1996). “Goal-based Requirements Analysis,” in Requirements Engineering, 1996., Proceedings of the Second International Conference on, Colorado Springs, CO, April 15–18, 1996 (IEEE), 136–144.
Bahsoon, R., Emmerich, W., and Macke, J. (2005). Using Real Options to Select Stable Middleware-Induced Software Architectures. IEE Proc. Softw. 152, 167–186. doi:10.1049/ip-sen:20045059
Bates, J. (1994). The Role of Emotion in Believable Agents. Commun. ACM 37, 122–125. doi:10.1145/176789.176803
Beale, R., and Creed, C. (2009). Affective Interaction: How Emotional Agents Affect Users. Int. J. Human-Computer Stud. 67, 755–776. doi:10.1016/j.ijhcs.2009.05.001
Bentley, T., Johnston, L., and von Baggo, K. (2002). “Putting Some Emotion into Requirements Engineering,” in Proceedings of the 7th Australian workshop on requirements engineering, Melbourne, Victoria, December 2–3, 2002, 227–244.
Berger, W. (2014). A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas. New York, NY: Bloomsbury Publishing USA.
Beyer, H., and Holtzblatt, K. (1999). Contextual Design. interactions 6, 32–42. doi:10.1145/291224.291229
Bianchi-Berthouze, N., and Lisetti, C. L. (2002). Modeling Multimodal Expression of User’s Affective Subjective Experience. User Model. User-Adapted Interaction 12, 49–84. doi:10.1023/a:1013365332180
Bode, S., and Riebisch, M. (2011). “Tracing the Implementation of Non-functional Requirements” in Non-Functional Properties in Service-Oriented Architecture: Requirements, Models and Methods. Hershey, PA: IGI, 1–23. doi:10.4018/978-1-60566-794-2.ch001
Borza, J. (2011). Fast Diagrams: The Foundation for Creating Effective Function Models. General Dynamics Land Systems.
Boudreau, M.-C., Gefen, D., and Straub, D. W. (2001). Validation in Information Systems Research: a State-Of-The-Art Assessment. MIS Q., 1–16. doi:10.2307/3250956
Browne, G. J., and Ramesh, V. (2002). Improving Information Requirements Determination: a Cognitive Perspective. Inf. Manage. 39, 625–645. doi:10.1016/s0378-7206(02)00014-9
Bytheway, C. W. (2007). FAST Creativity and Innovation: Rapidly Improving Processes, Product Development and Solving Complex Problems. Plantation, FL: J. Ross Publishing.
Callele, D., Neufeld, E., and Schneider, K. (2006). “Emotional Requirements in Video Games,” in Requirements Engineering, 14th IEEE International Conference, Minneapolis, MN, September 11–15, 2006 (IEEE), 299–302. doi:10.1109/re.2006.19
Chapman, J. (2015). Emotionally Durable Design: Objects, Experiences and Empathy. London: Routledge.
Chung, L., Nixon, B. A., Yu, E., and Mylopoulos, J. (2012). Non-functional Requirements in Software Engineering, Vol. 5. Springer Science & Business Media.
Colomo-Palacios, R., Hernández-López, A., García-Crespo, Á., and Soto-Acosta, P. (2010). “A Study of Emotions in Requirements Engineering,” in Organizational, Business, and Technological Aspects of the Knowledge Society (Springer), 1–7. doi:10.1007/978-3-642-16324-1_1
Cysneiros, L. M., do Prado Leite, J. C. S., and de Melo Sabat Neto, J. (2001). A Framework for Integrating Non-functional Requirements into Conceptual Models. Requirements Eng. 6, 97–115. doi:10.1007/s007660170008
Dardenne, A., Van Lamsweerde, A., and Fickas, S. (1993). Goal-directed Requirements Acquisition. Sci. Comput. programming 20, 3–50. doi:10.1016/0167-6423(93)90021-g
Davis, F. D. (1989). Perceived Usefulness, Perceived Ease of Use, and User Acceptance of Information Technology. MIS Q. 13, 319–340. doi:10.2307/249008
Demir, E. (2008). The Field of Design and Emotion: Concepts, Arguments, Tools, and Current Issues. J. Fac. Architecture 25, 135–152.
Desmet, P. M., and Hekkert, P. (2002). The Basis of Product Emotions. Pleasure Prod. beyond usability, 60–68. doi:10.1201/9780203302279.ch4
Dieste, O., Juristo, N., and Shull, F. (2008). Understanding the Customer: what Do We Know about Requirements Elicitation. IEEE Softw. 25, 11–13. doi:10.1109/ms.2008.53
Dix, A., Finlay, J. E., Abowd, G. D., and Beale, R. (2003). Human-Computer Interaction. 3rd Edition. Prentice-Hall.
Djajadiningrat, J. P., Gaver, W. W., and Fres, J. (2000). “Interaction Relabelling and Extreme Characters: Methods for Exploring Aesthetic Interactions,” in Proceedings of the 3rd conference on Designing interactive systems: processes, practices, methods, and techniques (ACM), 66–71.
Draper, S. W. (1999). Analysing Fun as a Candidate Software Requirement. Personal. Tech. 3, 117–122. doi:10.1007/bf01305336
Eric, S. Y. (2009). “Social Modeling,” in Conceptual Modeling: Foundations and Applications (Springer), 99–121.
Fitzgerald, G. (1991). “Validating New Information Systems Techniques: a Retrospective Analysis,” in Information Systems Research: Contemporary Approaches and Emergent Traditions. Amsterdam, Netherlands: North Holland, 657–672.
Friedman, B., Kahn, P. H., Borning, A., and Huldtgren, A. (2013). “Value Sensitive Design and Information Systems,” in Early Engagement and New Technologies: Opening up the Laboratory (Springer), 55–95. doi:10.1007/978-94-007-7844-3_4
Fulton Suri, J. (2003). Empathic Design: Informed and Inspired by Other People’s Experience. Empathic Design: User Experience Product. Design, 51–58.
Gaver, B., Dunne, T., and Pacenti, E. (1999). Design: Cultural Probes. interactions 6, 21–29. doi:10.1145/291224.291235
Gerhardt, D. J., and Rand, P. I. (2006). Managing Value Engineering in New Product Development. Value World 29, 26.
Gogueny, J. A. (1994). “Requirements Engineering as the Reconciliation of Technical and Social Issues,” in Requirements Engineering: Social and Technical Issueswith. Editor J Marina (Academic Press), 165–199.
Goldenberg, J., Lehmann, D. R., and Mazursky, D. (2001). The Idea Itself and the Circumstances of its Emergence as Predictors of New Product success. Manage. Sci. 47, 69–84. doi:10.1287/mnsc.47.1.69.10670
Gonzales, C. K., and Leroy, G. (2011). Eliciting User Requirements Using Appreciative Inquiry. Empir Softw. Eng 16, 733–772. doi:10.1007/s10664-011-9156-x
Hampson, K. D., and Brandon, P. (2004). Construction 2020-A Vision for Australia’s Property and Construction Industry. Brisbane, Australia: CRC Construction Innovation.
Hanik, P., and Kaufman, J. J. (2005). “Ve/triz: A Technology Partnership,” in Proceedings of the Society of American Value engineers Annual Meeting 2005, San Diego, California, June 27, 2008.
Hassenzahl, M., Beu, A., and Burmester, M. (2001). Engineering joy. IEEE Softw. 18, 70–76. doi:10.1109/52.903170
Holbrook, H. (1990). A Scenario-Based Methodology for Conducting Requirements Elicitation. SIGSOFT Softw. Eng. Notes 15, 95–104. doi:10.1145/382294.382725
Kaufman, J. J., and Woodhead, R. (2006). Stimulating Innovation in Products and Services: With Function Analysis and Mapping, Vol. 45. John Wiley & Sons.
Krumbholz, M., Galliers, J., Coulianos, N., and Maiden, N. A. M. (2000). Implementing enterprise Resource Planning Packages in Different Corporate and National Cultures. J. Inf. Technol. 15, 267–279. doi:10.1177/026839620001500403
Le Dantec, C. A., Poole, E. S., and Wyche, S. P. (2009). “Values as Lived Experience: Evolving Value Sensitive Design in Support of Value Discovery,” in Proceedings of the SIGCHI conference on human factors in computing systems (ACM), Boston, MA, April 4–9, 2009, 1141–1150.
Lee, M.-C. (2014). Software Quality Factors and Software Quality Metrics to Enhance Software Quality Assurance. Bjast 4, 3069–3095. doi:10.9734/bjast/2014/10548
Leung, L. (2015). Validity, Reliability, and Generalizability in Qualitative Research. J. Fam. Med Prim Care 4, 324. doi:10.4103/2249-4863.161306
Levy, M. (2020). “Emotional Requirements for Well-Being Applications: The Customer Journey,” in 2020 IEEE First International Workshop on Requirements Engineering for Well-Being, Aging, and Health (REWBAH), Zurich, Switzerland, August 31, 2020 (IEEE), 35–40. doi:10.1109/rewbah51211.2020.00011
Lopez-Lorca, A. A., Miller, T., Pedell, S., Mendoza, A., Keirnan, A., and Sterling, L. (2014a). “One Size Doesn’t Fit All: Diversifying the User Using Personas and Emotional Scenarios,” in Proceedings of the 6th International Workshop on Social Software Engineering (ACM), 25–32.
[Dataset] Lopez-Lorca, A. A., Miller, T., Pedell, S., Sterling, L., and Curumsing, M. K. (2014b). Modelling Emotional Requirements.
Marcus, A. (2015). “The Emotion Commotion,” in HCI and User-Experience Design (Springer), 83–89. doi:10.1007/978-1-4471-6744-0_11
McDonagh, D., Bruseberg, A., and Haslam, C. (2002). Visual Product Evaluation: Exploring Users' Emotional Relationships with Products. Appl. Ergon. 33, 231–240. doi:10.1016/s0003-6870(02)00008-x
Mendoza, A., Carroll, J., and Stern, L. (2010a). Software Appropriation over Time: from Adoption to Stabilization and beyond. Australas. J. Inf. Syst. 16. doi:10.3127/ajis.v16i2.507
Mendoza, A., Miller, T., Pedell, S., and Sterling, L. (2013). “The Role of Users’ Emotions and Associated Quality Goals on Appropriation of Systems: Two Case Studies,” in 24th Australasian Conference on Information Systems (Citeseer), Melbourne, VIC, December 4–6, 2013.
Mendoza, A., Stern, L., and Carroll, J. (2010b). “Learnability’as a Positive Influence on Technology Use,” in The 4th International Multi-Conference on Society, Cybernetics and Informatics: IMSCI 2010, Orlando, FL, June 29–July 2, 2010. Retrieved from http://www.iiis.org/CDs2010/CD2010SCI/IMSCI_2010/index.asp.
Miller, T., Pedell, S., Lopez-Lorca, A. A., Mendoza, A., Sterling, L., and Keirnan, A. (2015). Emotion-led Modelling for People-Oriented Requirements Engineering: the Case Study of Emergency Systems. J. Syst. Softw. 105, 54–71. doi:10.1016/j.jss.2015.03.044
Miller, T., Pedell, S., Sterling, L., Vetere, F., and Howard, S. (2012). Understanding Socially Oriented Roles and Goals through Motivational Modelling. J. Syst. Softw. 85, 2160–2170. doi:10.1016/j.jss.2012.04.049
Moody, D. L. (2003). “The Method Evaluation Model: a Theoretical Model for Validating Information Systems Design Methods,” in ECIS 2003 proceedings, Naples, Italy, June 16–21, 2003, 79. doi:10.1353/lan.2003.0257
Neuman, W. L. (2005). Social Research Methods: Quantitative and Qualitative Approaches, Vol. 13. Allyn and Bacon Boston.
Papakostas, C., Troussas, C., Krouska, A., and Sgouropoulou, C. (2021). Measuring User Experience, Usability and Interactivity of a Personalized mobile Augmented Reality Training System. Sensors 21, 3888. doi:10.3390/s21113888
Pennotti, M., Turner, R., and Shull, F. (2009). “Evaluating the Effectiveness of Systems and Software Engineering Methods, Processes and Tools for Use in Defense Programs,” in Systems Conference, 2009 3rd Annual IEEE (IEEE), 319–322. doi:10.1109/systems.2009.4815819
Petermann, B. (2013). The Gestalt Theory and the Problem of Configuration. Oxfordshire, England: Routledge.
Prat, N., Comyn-Wattiau, I., and Akoka, J. (2014). Artifact Evaluation in Information Systems Design-Science Research-A Holistic View. PACIS 23.
Preece, J., Sharp, H., and Rogers, Y. (2015). Interaction Design: Beyond Human-Computer Interaction. 6th edition. John Wiley & Sons.
Preiser, W. F., and Ostroff, E. (2001). Universal Design Handbook. New York, NY: McGraw Hill Professional.
Proynova, R., Paech, B., Koch, S. H., Wicht, A., and Wetter, T. (2011). “Investigating the Influence of Personal Values on Requirements for Health Care Information Systems,” in Proceedings of the 3rd Workshop on Software Engineering in Health Care (ACM), Honolulu, HI, May 22–23, 2011, 48–55. doi:10.1145/1987993.1988004
Robertson, S. (2001). Requirements Trawling: Techniques for Discovering Requirements. Int. J. Human-Computer Stud. 55, 405–421. doi:10.1006/ijhc.2001.0481
Saeed, K., Chaki, R., Cortesi, A., and Wierzchoń, S. (2013). Computer Information Systems and Industrial Management: 12th IFIP TC 8 International Conference, CISIM 2013, Krakow, Poland, September 25-27, 2013 (Springer). Proceedings, vol. 8104.
Samavi, R., Yu, E., and Topaloglou, T. (2009). Strategic Reasoning about Business Models: a Conceptual Modeling Approach. Inf. Syst. E-bus Manage. 7, 171–198. doi:10.1007/s10257-008-0079-z
Sanders, E. B.-N. (2002). “From User-Centered to Participatory Design Approaches,” in Design and the Social Sciences: Making Connections 1. doi:10.1201/9780203301302.ch1
Sherkat, M., Mendoza, A., Miller, T., and Burrows, R. (2018). Emotional Attachment Framework for People-Oriented Software. arXiv preprint arXiv:1803.08171.
Sheskin, D. J. (2003). Handbook of Parametric and Nonparametric Statistical Procedures. London: CRC Press.
Shneiderman, B., Plaisant, C., Cohen, M. S., Jacobs, S., Elmqvist, N., and Diakopoulos, N. (2016). Designing the User Interface: Strategies for Effective Human-Computer Interaction. New York, NY: Pearson.
Sim, W. W., and Brouse, P. (2015). Developing Ontologies and Persona to Support and Enhance Requirements Engineering Activities - A Case Study. Proced. Comput. Sci. 44, 275–284. doi:10.1016/j.procs.2015.03.060
Sleeswijk Visser, F., Van der Lugt, R., and Stappers, P. J. (2007). Sharing User Experiences in the Product Innovation Process: Participatory Design Needs Participatory Communication. Creativity Inn Man. 16, 35–45. doi:10.1111/j.1467-8691.2007.00414.x
Smith, H. S. (2008). “Emotional Evaluation of a Product/system,” (Orlando, Florida: University of Central Florida). Ph.D. thesis.
Song, X., Duan, Z., and Tian, C. (2010). Non-functional Requirements Elicitation and Incorporation into Class Diagrams. Intell. Inf. Process. V, 72–81. doi:10.1007/978-3-642-16327-2_12
Sonnenberg, C., and Vom Brocke, J. (2011). “Evaluation Patterns for Design Science Research Artefacts,” in European Design Science Symposium (Springer), 71–83.
Sutcliffe, A. (2009). Designing for User Engagement: Aesthetic and Attractive User Interfaces. Synth. lectures human-centered Inform. 2, 1–55. doi:10.2200/s00210ed1v01y200910hci005
Sutcliffe, A., and Thew, S. (2010). “Analysing ”people” Problems in Requirements Engineering,” in 2010 ACM/IEEE 32nd International Conference on Software Engineering, Cape Town South Africa, May 1–8, 2010 (IEEE) 2, 469–470.
Thew, S., and Sutcliffe, A. (2017). Value-based Requirements Engineering: Method and Experience. Requirements Eng. 1–22. doi:10.1007/s00766-017-0273-y
Trochim, W. M., and Donnelly, J. P. (2001). Research Methods Knowledge Base. Mason, Ohio: Atomic Dog/Cengage Learning.
Tzvetanova, S., Tang, M.-X., and Justice, L. (2007). “Emotional Web Usability Evaluation,” in Human-Computer Interaction (Berlin, Heidelberg: HCI Applications and Services), 1039–1046.
Whittaker, B. (1999). What Went Wrong? Unsuccessful Information Technology Projects. Info Mngmnt Comp. Security 7, 23–30. doi:10.1108/09685229910255160
Wieringa, R. J. (2014). Design Science Methodology for Information Systems and Software Engineering. Springer.
Winfree, T., Goldacre, P., Sherkat, M., Graham, P., Mendoza, A., and Miller, T. (2017). Learning for Low Carbon Living: The Potential of mobile Learning Applications for Built Environment Trades and Professionals in australia. Proced. Eng. 180, 1773–1783. doi:10.1016/j.proeng.2017.04.340
Xu, L., Ziv, H., Alspaugh, T. A., and Richardson, D. J. (2006). An Architectural Pattern for Non-functional Dependability Requirements. J. Syst. Softw. 79, 1370–1378. doi:10.1016/j.jss.2006.02.061
Keywords: people-oriented software, requirements engineering, emotional goals, emotional attachment framework
Citation: Sherkat M, Miller T, Mendoza A and Burrows R (2021) Emotionalism Within People-Oriented Software Design. Front. Comput. Sci. 3:717787. doi: 10.3389/fcomp.2021.717787
Received: 31 May 2021; Accepted: 25 October 2021;
Published: 22 November 2021.
Edited by:
Claire Craig, Sheffield Hallam University, United KingdomReviewed by:
Raja Jamilah Raja Yusof, University of Malaya, MalaysiaChristos Troussas, University of West Attica, Greece
Copyright © 2021 Sherkat, Miller, Mendoza and Burrows. This is an open-access article distributed under the terms of the Creative Commons Attribution License (CC BY). The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.
*Correspondence: Mohammadhossein Sherkat, bWguc2hlcmthdEBnbWFpbC5jb20=