DataPDF Available

Emotion-led modelling for people-oriented requirements engineering: the case study of emergency systems

September 2015

September 2015

Authors:

Tim Miller

University of Melbourne

Sonja Pedell

Swinburne University of Technology

Antonette Mendoza

University of Melbourne

Show all 6 authorsHide

Content uploaded by Tim Miller

Content may be subject to copyright.

Emotion-led modelling for people-oriented

requirements engineering: the case study of

emergency systems

Tim Miller, University of Melbourne

Sonja Pedell, Swinburne University of Technology

Antonio A. Lopez-Lorca, Swinburne University of Technology

Antonette Mendoza, University of Melbourne

Leon Sterling, Swinburne University of Technology

Alen Keirnan, Swinburne University of Technology

Abstract—In the ﬁeld of design, it is accepted that users’ perceptions

of systems are inﬂuenced by emotion as much as cognition, and

functionally-complete products will not be adopted if they do not appeal

to emotions. While software engineering methodologies have matured

to handle non-functional requirements such as usability, what has not

been investigated fully is the emotional needs of people. That is, what do

users want to feel, and how do they feel about a system? In this paper,

we argue that these emotional desires should be treated as ﬁrst-class

citizens in software engineering methodology, and present preliminary

work on including emotions in requirements models using emotional

goals. We evaluate these models both with a controlled user study, and

on a case study of emergency systems for older people. The results

of the controlled user study indicate that people are comfortable inter-

preting and modifying our models, and view the inclusion of emotions

as ﬁrst-class entities as a positive step in software engineering. The

results of our case study indicate that current emergency systems fail

to address the emotional needs their users, leading to low adoption and

low usage. We conceptualised, designed, and prototyped an improved

emergency system, and placed it into the homes of nine older people

over a period of approximately two weeks each, showing improved user

satisfaction over existing systems.

1 INTRODUCTION

“. . . even if a design is elegant and functional, it will

not have a place in our lives unless it can appeal

at a deeper level, to our emotions.” — Hartmut

Esslinger [46, p. 9].

Evidence suggests that inadequate consideration of

requirements are a major cause of software project failure

[12]. In the context of technology adoption, users reject

a technology or use it in limited ways when their needs

and experiences with that technology are not addressed

[23, 24]. As the famous quote from Esslinger above

conveys, this is especially true in the case of social

objectives such as the emotional needs of users. The

consideration of emotion in addition to cognition has

become more prevalent in design in recent years [30],

including human-computer interaction design, but such

considerations have not transferred successfully to soft-

ware engineering, despite evidence showing that a user’s

acceptance of product is typically based on emotion

rather than cognitive [30]. This is especially important in

domestic or social systems, in which workﬂows are loose

and people do not generally have the well-deﬁned roles

and responsibilities found in organisational settings.

Software engineers are trained to build systems

with desired functionality and non-functional properties.

However, software systems are often designed1poorly,

detracting from the user experience. Cooper [8] refers

to this as “the inmates running the asylum”: software

engineers elicit functional and non-functional require-

ments from users, then design a product to fulﬁl these

requirements as they themselves would like it to be,

resulting in software that fails to fulﬁl the desires of

its intended users. This problem is made worse by a

common misconception that problems with the interac-

tion design can be addressed after the development by

simply ﬁxing up the user interface.

From the perspective of software engineering, a ﬁrst

important step of addressing user experience is eliciting

the emotional desires of stakeholders. A growing appre-

ciation can be found in literature that existing software

engineering methods are limited by not considering

social objectives [2, 39, 51], a view expressed well by

Baxter and Sommerville [2, p. 14] in their comprehensive

review of design methods for socio-technical systems:

“Modelling and abstraction is fundamental to software en-

gineering, with models of different types being used by en-

gineers to communicate. The practical use of socio-technical

approaches has to acknowledge this by providing a means of

modelling, and by integrating with existing approaches. [. . . ]

The abstractions currently used in technical system modelling

(e.g., use-cases, objects, etc.) do not seem to us to be sufﬁcient

to represent socio-technical considerations.”

In previous work [27, 36], some of the authors pre-

sented a systematic and repeatable process and method

for understanding the roles and goals within a social

domain for the purpose of informing technology design.

At the heart of the method were agent-oriented models

[43]. Ethnographic data was collected using a variety

of means, and analysed using a grounded analysis. We

used agent-oriented models to record the ground theory

1. By “design” here, we refer to the design of the product, not of the

software architecture or detailed designs.

that resulted from that analysis. An important aim of

the work was to provide a simple yet ﬂexible modelling

notation that could be used to create boundary objects,

which, as Paay et al. [32] demonstrate, can be used

as shared artifacts between stakeholders from different

disciplines. We designed and implemented technology

probes [17], and modelled the data collected from these

probes as agent-oriented models. These models allowed

us to represent human activities as well as software

system behaviour. One novel outcome was the use of

quality goals to represent socially-oriented requirements

such as “having fun” and “being playful”.

In this paper, we improve our previous work by

adding the concept of emotional goals [21] to the notation

and method, which capture the desired feelings of stake-

holders in a socio-technical system, and how these relate

to the system and each other. We call these models people-

oriented software engineering (POSE) models, because of

their focus on the people within the system, as well as

the software.

In this paper, we present a two-part evaluation of

our models. First, we present a user study in which we

compare our notation for capturing user needs against

the well-known social modelling notation i∗[54]. We

asked a set of participants, some technical and some

non-technical, to answer a series of questions about

an i∗model and a POSE model, and measured the

time and accuracy of their responses. We then asked

a set of qualitative questions around their preferences

between the models. The results show that participants

understand POSE models better and more quickly, prefer

POSE models as boundary objects for modelling socio-

technical systems, and prefer the use of explicit emo-

tional goals in models over our previous approach of

using quality goals to represent these social aspects.

Second, we evaluate the concept of emotional goals

via a case study on emergency alarm systems. These

systems allow a person to raise an alarm in the case of

an emergency, and also to “check in” (wellbeing check)

each day to convey that they are well by pressing a

button. We interviewed 12 participants about emergency

systems and their feelings towards technology in gen-

eral. Using the ethnographic data collected, we modelled

the emotional, functional, and quality goals of the key

stakeholders using our models. Based on the ﬁndings

of the case study, we discovered that many users of

emergency systems, as well as their families, were not

happy with the way the system operates for them.

While the technological systems themselves were well-

engineered, reliable products that fulﬁlled the functional-

ity of alarms and wellbeing checks, the emotional needs

of users were not met, leading to failure of the overall

goals of the system. That is, older people did not receive

assistance when needed because they were not carrying

their devices, and did not feel that the wellbeing check

supported their wellbeing. In the process, we learnt

lessons about our models, and how to improve them.

From the resulting models, we designed and built a new

prototype of an emergency system. Evaluation of this

prototype demonstrated an improved user experience

over existing emergency alarms.

We next present our argument as to why emotions

should be embedded as ﬁrst-class citizens in software

engineering, and in Section 3, we present relevant back-

ground for the paper. In Section 4, we present our

modiﬁcation to our previous modelling notation to in-

clude emotional goals. In Sections 5 and 6 discuss our

evaluations of this using a user study and the case study

of emergency alarm systems.

2 EM OTIONS AS FIRST-CLASS CITIZENS IN

SOFTWARE ENGINEERING

In this section, we outline our argument for why emo-

tions should be considered as ﬁrst-class citizens in soft-

ware engineering methodology.

The consideration of emotions in requirements engi-

neering is not new, but has received insufﬁcient attention

outside of the games community, with only a handful of

papers addressing the issue of how to address emotions

in software engineering [3, 6, 7, 40, 47]. Further, as far as

the authors are aware, integrating emotions fully within

requirements engineering has not been explored, nor

has carrying emotions through the software engineering

lifecycle. As part of our larger research program, we

aim to model emotions as ﬁrst-class entities in software

engineering, carrying these goals through the software

engineering process, including requirements engineer-

ing, product design, software design, implementation,

testing, and validation.

2.1 The case for emotions

The idea of eliciting emotional desires for product design

is not new, and there has been a large body of work over

the previous two decades; see Desmet and Hekkert’s

editorial for the special issue Design & Emotion in the

International Journal of Design [10] for an excellent

overview of this work.

Norman’s book on emotional design [30] is one of the

most seminal pieces of work on this topic. He argues

that designers must elicit desired user emotions and

explicitly address them as part of the design process.

Norman describes how three levels of the human brain

affect emotion, and what this means for designers:

1) Visceral processing is the automatic, pre-conscious

processing that makes fast judgements. Visceral pro-

cessing is programmed in humans, meaning that

its effect is fairly consistent across different people.

With regards to design, a person’s emotional state is

affected by visceral processing based on the appear-

ance or “look & feel” of a product, such as colours

and style.

2) Behavioural processing is sub-conscious, and is the

part that controls “everyday” behaviour. With re-

gards to design, behavioural processing is about

TABLE 1

Norman’s simpliﬁed model of emotional design

Level Product characteristics

Visceral design Appearance

Behaviour design The pleasure and effectiveness of use

Reﬂective design Self-image, personal satisfaction, memories

the use and experience with a product, with the

experience related to “function, performance, and

usability” [30]. Like the visceral level, emotional

responses to the same event at this level are quite

consistent across different people.

3) Reﬂective processing is conscious, and is the contem-

plative part of processing. It is only at this level

that “the highest levels of feeling, emotions, and

cognition reside” [30]. With regards to design, it

is about the meaning of a product and its use. Of

signiﬁcance is that the reﬂective level extends much

longer over time than the visceral or behavioural

levels, which are typically about “now”. Unlike the

previous two layers, emotional responses to the

same event at this level often differ signiﬁcantly

between individuals.

The reﬂective level can enhance or inhibit the be-

havioural level, and the behavioural level can in turn

enhance or inhibit the visceral level. Activity can be

initiated “bottom-up” from the visceral level, or “top-

down” from the reﬂective level, and any activity has

both a cognitive component, which assigns meaning,

and an emotional or affective component, which assigns

value. The emotional state inﬂuences the way in which

people think, including cognitive thought.

Norman provides a simple model that maps the three

levels of processing to product characteristics (see Ta-

ble 1). He emphasises that visceral design is all about

immediate impact, and that physical characteristics such

as look, feel, and sound dominate. It can be measured

by showing products to people and observing their

reactions. Behavioural design is more about use, and

appearance does not matter. Behaviour design must

consider functionality, understandability, usability, and

performance, and can be measured quite objectively us-

ing metrics. Reﬂective design is about culture, meaning,

and self image. Measuring such properties is intrinsically

more difﬁcult than the visceral and behavioural levels,

partly because metrics for reﬂectiveness are hard to

deﬁne, and partly because reﬂective processing hap-

pens over much longer time periods than visceral or

behavioural processing. Norman emphasises, however,

that reﬂective processing often determines a person’s

overall impression of a product, so is perhaps the most

important in determining whether people actually use

or recommend a product.

2.2 The case for emotions as ﬁrst-class citizens in

software engineering

To relate Norman’s three levels to software engineering,

we consider the methods used to achieve them. Good

visceral designs are achieved using aesthetically appeal-

ing interfaces between user and software; in most cases,

they are of the form of graphical user interfaces.

Good behavioural designs are achieved by implement-

ing useful functionality, and making products usable.

These are the common traits that are considered in

software engineering, and are typically divided into

functional and non-functional categories, with usability,

performance, reliability, etc., falling into the latter cate-

gory. These non-functional properties are often termed

qualities,quality goals, or soft goals.

Good reﬂective design is achieved with software that

appeals to cultural perceptions and messages, and mean-

ing. It is our view that modern software engineering

methodology fails in providing systematic and repeat-

able support for reﬂective design.

We propose that properties desired by people at a

reﬂective level should be termed emotional desires or

emotional goals. While related terms such as value and

motivation could be used here, we use “emotion” be-

cause our experience suggests that people relate the

term “emotion” to these subjective and hard-to-measure

properties, and because it is more clearly tied to people

rather than software.

Based on Norman’s theories and the discussion above,

we make two observations:

1) Emotional goals or desires are not just another form of

usability. Usability is a behavioural-level experience,

not a reﬂective level experience. While the usability

of a product can inﬂuence the reﬂective level, as de-

scribed by Norman’s theory, it extends well beyond

immediate use and into long-term reﬂection.

2) Emotional goals or desires are not just qualities. Simi-

lar to item 1 above, qualities are behavioural, not

reﬂective. Pragmatically, people relate qualities of a

system to the visceral and behavioural aspects, not

to culture and meaning, so describing the inﬂuence

a software system has on the reﬂective level as a

quality is unsuitable, as it conﬂates behavioural and

reﬂective levels. For example, consider the well-

known Facebook application2. A goal of Facebook is

to make people feel part of their friendship group.

Is it reasonable to label this a quality goal, when

its success depends on users’ establishing social re-

lationships with friends and participating in mean-

ingful interaction? A single person using Facebook

will not feel part of their friendship group. Such a

goal can be triggered or helped by the application,

but is only achieved for speciﬁc groups of people

over a speciﬁc period of time. This property must

be interpreted from a social perspective, as distinct

from the application’s functionality and usability.

2. See https://www.facebook.com/.

Further to this, as noted by Hudlicka [13], emotions

have scales of intensity, which change over time.

Assigning an intensity to a property such usability

is meaningless. The intensity of an emotion expe-

rienced during an interaction with a system is a

property of the person, not of the system, even

though a system can contribute to this.

Several authors have made the case for emotions in

requirements engineering [3, 5, 6, 7, 40, 47, 20], and

this work is discussed in the related work (Section 3.1).

However, such work has had minimal impact. Maiden

[20] argues that the reason requirements people do not

take emotion seriously is because they are Spocks, in a

reference to the emotion-free Vulcan character from Star

Trek, rather than Kirks, the passionate captain. Require-

ments engineering methodologies tend to focus on the

software, rather than the people. While the last couple

of decades have seen some move away from this, such

as social modelling [54] and user stories, which focus

on why users want something in addition to what they

want, the focus is still very much on the behavioural

why, rather than the reﬂective why.

Further to this, we propose that emotions need to be

considered further than just requirements engineering –

they must be traceable throughout the entire software

engineering process.

Emotional goals are abstract and subjective, so cannot

be implemented directly. We propose that emotional

goals are not software requirements, but merely drivers

to elicit new requirements, either functional or non-

functional. For example, one of our current projects is on

a web application to support people with psychosis. An

important emotional goal is for the supported person to

feel normal. Such a goal cannot be implemented directly,

because it is a property of a person, not of the system.

In this project the feeling of being normal is conveyed

by the contents of videos in which people recovering

from psychosis narrate their experiences. The emotional

goal feel normal provoked the addition of the functional

requirement of using people with lived experience in the

videos.

In addition, unlike other qualities such as performance

and usability, we are not aware of metrics that can be

applied to the system to evaluate whether it makes a

person feel normal, other than asking users directly.

While usability evaluations can be used to measure user

perception, the longer-term nature of reﬂective process-

ing means that such evaluations must be improved to

evaluate whether emotional goals have been met.

We propose that emotions should be embedded as ﬁrst

class citizens of people-oriented software engineering

methodology for two reasons:

1) It is clear that the abstract, subjective, and difﬁcult-

to-measure nature of emotional goals make them

challenging. It is our view that by not explicitly

considering emotions throughout the entire soft-

ware engineering process, important emotional con-

siderations risk being sidelined. They can be ig-

nored or missed at the requirements stage, but their

challenging nature means that under constrained

deadlines, they will be the ﬁrst things discarded in

development if they are not explicitly considered –

yet they are often the most important.

2) Stakeholders are unlikely to communicate emotional

requirements without explicit prompts, as this is

not their view of software as a cold, hard calculat-

ing machine. In our experience, stakeholders focus

on functional requirements, sidelining ‘soft’ issues

such as socially-oriented requirements, including

emotions. Yet, their perception of any system will

depend heavily on their emotional reaction to the

system [30].

While we do not claim this view is required for every

software system, we believe that systems embedded in

social or domestic domains, and systems with loosely-

deﬁned workﬂow, will beneﬁt from this most.

3 BACKGROUND AND RELATED WORK

In this section, we present related work on emotions

in requirements engineering and agent-oriented require-

ments engineering.

3.1 Related work

3.1.1 Emotions in requirements engineering

While the role of emotions is prevalent in the ﬁeld of

human-computer interaction (e.g. [1, 48]), it has been

scarcely explored in the software engineering literature,

despite its importance being identiﬁed by prominent

researchers in the ﬁeld (e.g. [20, 47]). Existing work

mostly considers emotions in relation to requirements

engineering. In some cases, the emphasis is on acknowl-

edging that emotions can signiﬁcantly impact the re-

quirements engineering process; for instance Thew and

Sutcliffe [44, 45, 47]. They identify a number of values

and motivations — referred to as soft issues — that can

have different effects on requirements. They distinguish

between those that are critical for the success of the

project from those that have a lesser impact if not treated.

Similarly, Proynova et al. [38] use personal values to

identify features that are then mapped to requirements

that may have otherwise remained uncovered. In both

cases, the authors use personal values to prioritise or

discover requirements. For us, however, emotions have

a deﬁnite effect in the requirements, and personal values,

in turn, determine how different people react to the same

emotion.

In the requirements modelling notation i*, Yu [54] uses

softgoals to model non-functional requirements. Besides

classic non-functional requirements such as “reliable”

or “secure”, other less traditional factors (better aligned

with emotional issues) are also included, such as “trust-

worthy”, “ﬂexible”, “minimal intrusion” or “normal

lifestyle”.

Colomo-Palacios et al. [6, 7] explicitly ask stakeholders

about their feelings regarding particular requirements.

Their response is recorded in a grid which represents in

the X axis the arousal caused by the requirement and

in the Y axis the pleasure. Comparing the responses

with the evolution of the requirements throughout the

requirement engineering process iterations, they con-

clude that high levels of pleasure and low levels of

arousal seem to indicate accepted requirements. Al-

though Colomo-Palacios et al. provide an interesting

insight on the correlation between pleasure and arousal

and requirements stability, this approach measures stake-

holders’ emotional perceptions of requirements around

emotional-related qualities such as pleasure and arousal,

whereas we aim to use emotions to explore and deﬁne

requirements with stakeholders, inline with Maiden’s

argument [20].

In this sense, the work of Ramos et al. [41] is better

aligned with our approach. They present examples of

projects where requirements were affected by emotions,

values or beliefs, and argue that the impact of these

factors, traditionally ignored, is as important as function-

ality or qualities. They advocate identifying these issues

as soon as possible and then tackling them with some

managerial or technical treatment, and suggest a number

of psychological techniques to identify emotional issues

when talking to the stakeholders. Once identiﬁed, the

requirements engineering process continues as per usual.

We build on this work to elaborate on the deﬁnition of

emotions relevant for the development process and to

deﬁne a notation to graphically represent emotions in

the context of the requirements engineering process.

3.1.2 Agent-oriented requirements engineering

With the agent paradigm increasingly becoming a pop-

ular and successful way for modelling complex systems

[29], agent-oriented requirements engineering has been a

focus of much research. Several methodologies for agent-

oriented software engineering have been proposed, such

as Tropos [4], Prometheus [33], Gaia [55], INGENIAS

[35], and ROADMAP [43]. These different methodologies

offer differing processes, methods, and notations for

using the agent paradigm to engineer a complete system.

However, the methodologies have several modelling

concepts in common, including the use of agents or roles

to capture the idea of people and systems interacting,

the use of goals instead of functional requirements to

capture desired behaviour, and the use of quality goals

to capture non-functional requirements. The concepts are

used because it is believed that they offer a natural way

for describing software systems as well as the larger

socio-technical system in which they operate.

In our earlier work [27, 36], we have investigated

software engineering for people-oriented systems. In

particular, we have focused on methods and processes

for identifying the functional goals of users, the qualities

of these functional goals, the roles they play in systems,

and how these goals are translated from requirements

to design, implementation, and validation. We used

the agent-oriented paradigm for high-level modelling

because we are particularly interested in capturing the

goals and needs of the users and stakeholders of systems,

and not just functional and non-functional requirements

of the software. We used the concepts of roles, functional

goals, and quality goals to capture users, what they want

to achieve, and how they want this to be achieved; and

also to capture software requirements.

From the perspective of requirements engineering, we

identify stakeholders of the system, which are modelled

as roles, and elicit information that answers the follow-

ing two questions: (1) what do you want to achieve (func-

tional goals)?; and (2) how should it be achieved (quality

goals)? For example, a potential user may want to be able

to share pictures to their friends (functionality), and they

want this to be fast and easy, hinting at non-functional

qualities of performance and usability.

We believe that a third, yet very important question

should be asked: (3) how do you want to feel? The

emotional factors related to software and systems are

important parts of technology appropriation, as well

as important in determining long-term use [24]. In the

example of sharing pictures with friends, users may

want to feel engaged. Offering a server where photos can

be uploaded satisﬁes the functional and quality goals,

but not the emotional goals, such as being engaged or

feeling connected. For this, functionality such as tagging,

commenting on, and perhaps modifying photos could be

implemented.

As far as the authors are aware, there has been no

research integrating emotional factors into the agent-

oriented requirements engineering process. Given that

many agent-oriented modelling notations capture the

essence of goals, roles, qualities, and the connections be-

tween these, we choose to extend Sterling and Taveter’s

notion [43] agent-oriented modelling notation to capture

emotions.

3.1.3 Integration of ethnographic data into software en-

gineering

Using ethnography to inform technology design is not

a new concept. However, despite some excellent work

in the area [15, 16, 51, 39, 42, 32], bridging the gap

between ethnographers and software engineers is still in

its infancy, especially for systems in the social domain

[2].

Several existing methods have been successful in com-

bining ethnography with software engineering models

to produce requirements speciﬁcations. Hughes et al.

[14] were among the ﬁrst to recognise the value of

ethnography in software design, and among the ﬁrst to

recognise the importance using boundary objects to al-

low ethnographers and software engineers to share their

understanding. Viller and Sommerville [49, 50] prescribe

a method for documenting the results of ethnographic

studies using UML use cases and domain models. Millen

[26] presents rapid ethnography, which is a collection of

ﬁeld work to help understand a socio-technical system

for which technology is being designed. Ethnographers

observe users in the ﬁeld, and answer a structured

questionnaire after the observations. The resulting data

is used to derive a causal model that informs the sys-

tem design. Diggins and Tolmie [11] model the shared

understanding of terminology between ethnographers

and other ﬁeld workers using Grounded Innovation Maps,

which is a boundary object that organises ethnographic

data in a manner that is palatable to both system design-

ers and the ﬁeld workers.

Many of these methods have been successfully applied

to socio-technical systems, however, with a focus on

functionality, they do not capture the emotional needs

of users. We believe that some of the lessons learnt in

our work could be integrated into these methods.

3.2 Motivational modelling and notation

In this section, we present the necessary background on

the modelling notation that we use in our work. We

believe that our ideas can be generalised to other agent-

based notations.

POSE models are based on syntax and semantics of

Sterling and Taveter [43]. Their aim is to make high-level

models palatable to non-technical stakeholders. This is

achieved by using models with a straightforward and

minimal syntax and semantics, and based on the agent

paradigm, which is a natural way to consider socio-

technical systems. The early requirements phase models,

which Sterling and Taveter call motivation models, are

particularly lightweight, and we have adopted them due

to their simple nature, and ability to easily capture the

important concepts of roles, functional goals, quality

goals, and the relationships between them.

Motivational goal models. Motivation goal models are

useful in early stage requirements engineering to cap-

ture initial understandings, and share these with other

stakeholders. Roles and goals capture the users and their

wants, and agents (human or artiﬁcial) can then fulﬁl

these roles. We deﬁne these concepts based on Sterling

and Taveter’s deﬁnitions.

Deﬁnition 1 (Functional goal).Functional goals are based

on motives, and describe an intended state of the envi-

ronment. Functional goals can consist of sub-goals.

Deﬁnition 2 (Quality goal).Quality goals are non-

functional goals (sometimes referred to as soft goals).

Quality goals are attached to functional goals, captur-

ing that the functional goal should be achieved while

maintaining the quality.

Deﬁnition 3 (Role).Roles are some capacities or posi-

tions that facilitate the achievement of functional goals.

Roles are played by agents, which can be humans or ar-

tiﬁcial. Roles have responsibilities, which determine what

the agent must do to achieve the functional goals, and

constraints, which determine the conditions that must be

considered when trying to achieve functional goals.

Figure 1 deﬁnes the notation employed by Sterling and

Taveter in their motivational goal models. Functional

(a) Functional goal (b) Quality goal (c) Role

Fig. 1. Sterling and Taveter’s notation for motivational

goal modelling

goals are represented as parallelograms, quality goals are

clouds, and roles are stick-like ﬁgures. These constructs

can be connected using arcs, which indicate relationships

between them. Typically, arcs are used to connect the

following:

1) Roles to functional goals: this represents that the agent

playing the role is responsible for achieving the

functional goal. For example, a person playing the

role of Manager is responsible for the functional goal

of approving a piece of external correspondence.

2) Functional goals to quality goals: this represents that

the functional goal should be achieved under con-

sideration of this quality. For example, the func-

tional goal should be achieved efﬁciently, where

“efﬁciently” may be deﬁned more precisely.

3) Goals to sub-goals: this represents that the functional

goals are related. We use undirected arcs to denote

that one goal is a sub-goal of the other, and therefore

the sub-goal contributes to achieving the higher-

level goal. To distinguish the goal from its sub-goal,

we place the sub-goal below the goal, thus enforcing

a hierarchical goal model, rather than adopting no-

tation from existing software engineering notations,

such as directed arcs. We have found this to be a

simple and natural way of expressing sub-goals for

non-technical stakeholders.

This notation is lightweight, yet ﬂexible enough to

capture the important high-level goals of stakeholders,

and system qualities.

Motivational scenarios. Motivational scenarios also play

a key role at this level. Motivational scenarios provide

concrete instantiations of the system, provide some tem-

poral alignment with the functional goals in the model,

and help to capture the dynamics of the greater socio-

technical system.

Role models. In addition, role models complement the

motivational goal models and scenarios. Role models are

descriptions of the roles captured on the motivational

models, which include the role name, the responsibilities

of the role, and the constraint under which the role may

operate.

4 EM OTION-LED MOTIVATION MODELLING

In this section, we present our conceptualisation of

emotion-led motivation models, which we call people-

oriented software engineering (POSE) models. POSE mod-

els extend those of Sterling and Taveter [43] by adding

adding emotional goals. We suggest additions to goal

models, motivational scenarios, and role models. We

believe these additions provide a ﬂexible way to model

the emotions of people and agents playing roles in a

system.

4.1 Emotions in systems and software

Before we present our conceptualisation, we ﬁrst deﬁne

what it is that we want POSE models to capture.

Deﬁnition 4 (Emotion).An emotion is a feeling that

characterises a state of mind. Examples of emotions

include feeling joy, terror, safe, empowered, or normal.

We aim to produce systems that both support peo-

ple’s emotional desires, and also inﬂuence their state of

mind to enhance the feeling of some emotions. Our key

addition to Sterling and Taveter’s models are emotional

goals, conceptualised by Marshall [22]. Emotional goals

are different from functional goals, which address the

functional intent of users, and from quality goals, which

detail the qualities of systems (e.g. “secure” or “usable”).

Emotional goals address how people feel, and as such,

are not properties of a system (or a goal), but of people

engaged in the greater socio-technical system.

Types of emotions. We offer an important distinction

between two types of emotion in the context of systems

and software:

1) Personal emotions: These are the emotions that a per-

son feels (or wants to feel) irrespective of the system

being studied. Examples include emotions such as

feeling loved, feeling safe, or feeling normal. Al-

though the emotions are independent of the system,

it is clearly useful to model those personal emotions

that are in the scope of the system; that is, they can

be inﬂuenced by or can inﬂuence the system. While

a technological system can inﬂuence these emotions,

they are desires of users that exist independently of

any speciﬁc support that is provided.

2) Context-speciﬁc emotions: These are the emotions that

a person feels (or wants to feel) about a system,

or piece of technology. Examples include feeling

engaged with the system, feeling frustrated by the

system, or feeling that the system is integrated in

their life. These are distinctly emotions about the

system, and exist only in response to the system.

We believe that the above mentioned two different

types of emotion are sufﬁcient to capture the emotional

desires with respect to systems, such that POSE models

can inform system design.

Making a distinction between these two is important

from an engineering perspective, because if some par-

ticular part of a system (or design) is removed, if it

supports a personal emotional desire, additions must be

made to address the emotion. However, this is not (nec-

essarily) the case for context-speciﬁc emotional desires.

4.2 Emotional goals

To model emotions, we extend Sterling and Taveter ’s

motivational models to include emotional goals.

Deﬁnition 5 (Emotional goal).Emotional goals are non-

functional goals that describe a desired reﬂective-level

emotion of a role.

Emotional goals differ from quality goals in that they

represent the reﬂective-level emotions in Norman’s the-

ory [30] (discussed in Section 2), whereas quality goals

(and functional goals) represent intended properties of

the system that affect the behavioural levels, and possi-

bly the visceral levels in some cases; e.g. qualities about

aesthetics.

Figure 2 shows the syntax used for emotional goals,

although we omit the lines whenever the relationship

is clear. One can see that the relationship is ternary:

emotions are attached both to a role and to a goal. In

Figure 2, the emotion is related to a functional goal,

but this can also be attached to quality goals and other

emotional goals; e.g. a parent seeing their child excited

to open a birthday gift may excite the parent themselves.

Fig. 2. Notation for modelling emotional goals

Linking of the role to the emotional goal is important,

as this allows us to model conﬂicting emotional goals

in response to the same goal for different stakeholders.

That is, for a particular goal, it is natural that different

stakeholders may (want to) have different emotional

goals, so the emotional goals are inherently linked to

the people playing the roles, not just the corresponding

system property.

If the emotion is a personal goal, then the syntax from

Figure 2 is read as: “Role Rfeels the personal emotion

EG, and the goal Ghelps to support this emotional

goal”.

If the emotion is a context-speciﬁc goal, then this is

read as: “Goal Gsupports the context-speciﬁc emotion

EG for role R.” That is, the system should inﬂuence the

role Rto feel the emotional goal EG via the goal G.

In our experience, we have not found it important to

use notational differences between personal and context-

speciﬁc emotional goals. Instead, we opt for simplicity

of high-level models, rather than detail, which we ﬁnd

confuses stakeholders. In our projects, we have used the

context in which the goal falls, or additional information

in other models, to determine the type. However, we

acknowledge that grouping emotional goals by type will

not necessarily be sufﬁcient in all cases.

Our proposal, shown in Figure 3, is to simply anno-

tation context-speciﬁc goals with an icon representing a

(a) Personal emotional

goals

(b) context-speciﬁc

emotional goals

Fig. 3. Our notation for modelling personal and context-

speciﬁc emotional goals

functional goal, to indicate that the emotion is explicitly

tied to the context.

As a minor addition to Sterling and Taveter’s models;

our models add one new symbol, and two concepts (per-

sonal and context-speciﬁc emotions). This is certainly

our aim: to offer minor variations on existing notations

and methodologies in order to capture important aspects

of the greater socio-technical system. We believe that

the notation could be readily included into other goal-

oriented notations, such as i∗[54], KAOS [9], or Jacob-

son’s UML use case diagrams [18].

Example — Gift giving goal model. To illustrate our

notation, we adopt the gift giving model from our earlier

work [27]. The model, shown in Figure 4, consists of

two roles: gift giver and gift receiver. The goals of the

giver are to choose an appropriate gift that makes the

receiver feel special, and to present the gift in a creative

way. The goal of the receiver is not just to receive the

gift as one would during a commercial exchange, but to

acknowledge the receipt of the gift and show that they

appreciate the feelings that the giver is conveying. The

emotional goals play an important part in the description

of gift giving. Simply choosing or giving a gift is not the

primary motivation of the gift giver. Instead, they want

to choose a gift such that the receiver is made to feel

special in the eyes of the giver.

Gifting is a good example to illustrate the complexities

of emotions and social interaction. There are many differ-

ent attributes to gift giving, and these differ over cultures

and even age groups. It is not possible (or perhaps

even desirable) to capture these in one single model. For

example, as described by Otnes and Beltramini [31], one

property of giving gifts is that the gift giver generally

obtains more satisfaction from the interaction than the

receiver. This is not captured by the model in Figure 4,

which is just an illustration of emotional goals.

4.3 Motivational scenarios

For traceability and completeness, we also adapt moti-

vational scenarios to consider emotional goals. Sterling

and Taveter’s motivational scenarios consist of a scenario

name, a scenario description, which speciﬁes how the

roles and goals come together, and a quality description,

which speciﬁes what qualities should result from these

goals.

Our straightforward addition to this is to add a ﬁeld

to the motivational scenario tables: emotional descriptions,

which describes the key emotions that are part of the

scenario.

Example — Gift giving scenario. A motivational sce-

nario for gift giving is shown in Table 2. The motiva-

tional scenario outlines the process of gift giving, and re-

lates this to the functional, quality, and emotional goals.

The key emotional properties that we aim to achieve in

the gift giving motivational scenario are outlined, and

these can be traced back to corresponding emotions in

the goal model.

TABLE 2

Motivational scenario model for gift giving

Scenario Name Gift giving

Scenario

description

A gift giver chooses and presents a gift

to the receiver, who acknowledges the

effort that the giver put into choosing

and presenting.

Quality description The gift should be appropriate, and the

interaction should promote a sense of

sharing.

Emotional descrip-

tion

The gift giving should promote a feeling

of friendship, make the receiver feel

special, and make the giver feel appre-

ciated.

4.4 Role models

We add emotional considerations to role models. Each

role model describes the emotions that an agent playing

the role may feel, and, if necessary, how the responsibil-

ities and constraints affect this emotion. This is achieved

with two ﬁelds in the role models: (1) personal emotional

goals; and (2) context-speciﬁc emotional goals. These are lists

describing the relationships of roles to their respective

emotional goals.

In addition, the scopes of the role responsibilities and

constraints are expanded to include emotional aspects.

That is, a role can be responsible for performing a

functional goal that affects the emotions of another role,

or can be constrained by the fact that it has to consider

the emotional goals of a role, including itself.

Quality goals are not part of role models because qual-

ity goals are properties of the system. However, emotions

are included because they are properties related to the

roles as well as the system.

Example — Gift giver role model. Table 3 shows a role

model for the gift giver role. Note that the emotional

goal of making the receiver feel special is considered

a responsibility for the gift giver. A second role model

for the gift receiver must also be considered, but it is

omitted here. While this role model is straightforward

and adds little to our understanding of the domain, in

our case studies, role models are often used to provide

more detail and more precision about the responsibilities

and constraints of agents playing roles that cannot be

captured in goal models.

Fig. 4. A partial motivation model for gift giving

TABLE 3

Role model for Gift Giver

Role Name Gift Giver

Description The Gift Giver chooses and gives a gift to

the receiver.

Responsibilities 1. Choose a gift that makes the receiver feel

special.

2. Present the gift in a creative way.

Constraints The gift should be appropriate.

Personal emotional

goals

The giver wants to feel close to the receiver.

Context-speciﬁc

emotional goals

The giver should feel appreciated by the

receiver’s acknowledgement.

4.5 Process model

In this section, we outline our process model for

emotion-led requirements modelling. Figure 5 outlines

the process model that we follow in our requirements

elicitation exercises, which is an extension of the process

outlined in our earlier work [27].

In this model, we advocate an incremental process in

which different activities within the domain are studied

provide an overview of the motivations in the domain.

Identifying these activities is the ﬁrst step, after which

we study each activity, building on the previous study.

These can be studied concurrently or otherwise.

The third step is to obtain data on the activity, which

is used to inform the model. In our projects, we have

focused in rich ethnographic data, obtained via combina-

tions of interviews, observations, and technology probes,

however the data can be in many forms, from surveys,

brainstorming, domain research, user feedback, etc.

Once data is obtained, modelling commences. Our

initial focus is on the primary emotional goals and their

related roles, as we believe these are the most important

motivators for adopting and continuing to use systems.

Fig. 5. Process model

Next we extract the key functional goals for the system,

and the quality and context-speciﬁc emotional goals that

relate to these. In parallel, we deﬁne the motivational

scenarios, which depend on all of the types of goals.

Finally, the role models are completed, which involved

both identifying any additional roles that are important

to the system that are not identiﬁed with the personal

emotional goals, and also completing the role models

themselves. This process has been described in further

detail in a related paper [37], in which we discuss how to

increase the validity of the results using different levels

of group analysis.

This process is repeated on the different activities that

are identiﬁed at the start of the process. For example, if

we are studying ways in which close friends interact,

the activity of gift giving outlined in Figure 4 could

serve as one activity, while the activity of inviting some-

one to lunch could serve as another. Studying several

interactions of this nature provides us with a view of

how friends interact, what motivates them to do so, and

what their speciﬁc aims may be as part of interactions. In

our earlier work [27], we discuss how studying several

such activities provides us with a more valuable under-

standing of a domain than trying to generalise all such

activities.

5 EVALUATION OF EMOTIONAL MODELS

In this section, we present a controlled experimental

evaluation of our proposed models. The goals of this

study are to answer the following two research ques-

tions:

1) Are POSE models suitable as boundary objects,

compared with existing goal-oriented modelling no-

tations such as i∗?

2) Do people prefer the use of emotional goals instead

of quality goals for capturing emotional desires?

We compare POSE with i∗because both notations aim

to include the social elements of socio-technical systems,

and i∗is perhaps the most commonly applied social

modelling language in academia. Like POSE, i∗supports

concepts such as functional goals, quality goals, roles,

and goal decomposition, but also introduces many ad-

ditional concepts, including tasks, resources, and agents,

and several types of relation between these, including

means-end relationships, decomposition, and dependen-

cies.

i∗models were designed as a tool for software engi-

neers to map their ideas of how a socio-technical system

operates and to deﬁne the problem to be solve. POSE

models were empirically designed as a tool for soft-

ware engineers and non-technical stakeholders to col-

laboratively deﬁne their joint understanding of a socio-

technical system. Because non-technical stakeholders are

generally unconcerned with the difference between roles

and agents, and the different types of dependency, these

more detailed concepts are not included in the POSE

notation.

Our hypothesis is that POSE models are more suitable

as boundary objects because the sets of concepts are

constrained, allowing people to more easily engage with

the models, and correctly interpret meaning, even if the

notation is unfamiliar, while still maintaining high ex-

pressiveness and ﬂexibility required for social modelling.

5.1 Experiment design

We recruited a total of 20 participants from a range of

backgrounds, and administered surveys to each. Pre-

experiment questions assessed their background, such as

experience in a computing-related ﬁeld, familiarity with

the modelling notations, etc.

In our ﬁnal set of participants, we had 10 participants

with training or experience in computing or a cognate

discipline, such as computer science, software engineer-

ing, and web design; and 10 participants without train-

ing in a cognate discipline, including occupations such

law, graphic design, business analysis, and accounting.

We had no participants with experience in i∗or POSE,

and participants were not informed as to the study goals

(except for the ﬁnal qualitative question).

Each participant was given a survey document that

consisted of models from two domains: a meeting sched-

uler system, taken from Yu [52], and a patient care

system, taken from Yu [53]. Each participant received one

system modelled in i∗and the other modelled in POSE.

To mitigate potential bias, we split participants into two

groups, A and B. Group A received the meeting sched-

uler in i∗and the patient care system in POSE, while

group B received the meeting scheduler in POSE and

the patient care system in i∗. To mitigate experimenter

bias, we used only i∗models from existing literature,

and derived models of these domains in POSE. Fur-

ther, participants worked independently, and requested

to only ask questions to clarify notation (although no

such questions were asked). To mitigate selection bias,

we recruited participants with experience in software

modelling, and some without.

The survey was broken into three tasks3. In task 1,

participants were asked to answer ﬁve questions about

the meeting scheduler system, such as which roles are

responsible for certain tasks or which goals (or tasks) are

required to fulﬁl a particular goal. In task 2, participants

were asked to answer six questions about the patient

care system, of a similar type to that in task 1. In task 3,

participants were presented with two alternative models

of a photo-sharing application: one in i∗and one in

POSE, each modelled by us. This was the only time

that participants saw alternatives of the same domain.

Participants were then asked qualitative questions about

the models they had seen, and which notation they

found easier to understand, how comfortable they would

feel modifying such a model, and how much information

each captures. In particular, the ﬁnal question asked

participants which type of model they though better cap-

tures the emotional desires of people involved in systems.

3. The questionnaires are available at http://tinyurl.com/

pose-survey-1 and http://tinyurl.com/pose-survey-2 respectively.

Before the participants began, we gave each partic-

ipant a one minute overview of the POSE modelling

notation, and a two minute overview of the i∗notation.

The i∗notation was afforded a longer overview because

of the additional concepts it uses. In our experience and

one-two minute overview is about as long as possible

before stakeholders lose focus.

For tasks 1 and 2, we took two measures: time and

correctness. For each question, we timed how long it

took the participant to complete the task. There were no

time limits on tasks. After the questions were completed,

answers were judged on correctness. These two mea-

sures were proxies for how well the participants could

understand the models. The questions in the tasks were

such that assessing correctness was straightforward. We

measured correct answers as 1, incorrect answers as 0,

and partially correct answers as 0.5. A partially correct

answer includes cases such as correctly listing only some

of the tasks that a role is responsible for, instead of

correctly listing all tasks.

5.2 Results

Tables 4 and 5 show the results of the experiment and

qualitative questions respectively. Table 4 shows the

percentage of participants who answered each question

correctly, the mean and standard deviation of the num-

ber of questions correct per participant, and the mean

and standard deviation required to complete the task.

From this table, one can see that on average, par-

ticipants answered more questions correctly from the

POSE models than the i∗models, and in a faster average

time. Given that these measures are our proxies for

understandability and usability, they imply that POSE

models are easier to understand by participants. Over

the eleven questions, eight had an equal or higher per-

centage of correct answers, and the overall number of

correct answers given per participant was higher – in

the case of the meeting schedule system, by almost one

complete mark. The times were also lower for the POSE

models.

We attribute these results to the simpler nature of the

modelling notation, and the hierarchical layout of the

models, which lead to a more natural way to read them

(left to right, top to bottom). As well as the quantitative

results, the participants’ comments provide further ev-

idence of this. For example, the two quotes below are

from participants who had a strong preference for POSE

notation:

Far more clear, seems to capture what is important,

[and] constrains models to be sensible. [Peter, Com-

puter science student]

It makes implicit use of space rather than explicitly

using lines. [Danny, Experienced software engi-

neer and data modeller]

Table 5 shows the average responses for the qualitative

questions as a distribution over the responses. The expla-

nations each side of the distributions show the extreme

points of the ﬁve-point scale used.

From these results, we can see several expected results.

First, participants have a stronger preference for using

POSE models, largely because they are clearer, the icons

are easier to interpret, the models are simpler & “less

busy”, and the relationships are easier to identify. We

attribute this to the deliberately-constrained notation of

the POSE models.

Participants were also not conﬁdent that they could

modify i∗models if required, but were far more conﬁ-

dent that they could do so with POSE models. One par-

ticipant commented that they would be very conﬁdent

modifying a POSE model because they were able to:

... understand who performs task, and whether it is

essential, emotional, or desirable quality of a task.

[Bree, Lawyer]

Another commented that they would be not at all

conﬁdent modifying an i∗model because the model

presented in the survey was:

Extremely confusing; I have difﬁculty following it

[Pedro, Computer Science Student].

Many participants considered that i∗models capture

more information. From the qualitative comments, this is

almost entirely due to the fact that i∗has more types of

relationships between different elements, and little to do

with additional concepts such as tasks, resources, etc.:

Relations and dependencies seem at least more ex-

plicit/detailed. [Phillip, Computer science post-

doc]

However, several participants commented that while

i∗could capture more, it may not be useful:

Yes, but not necessarily relevant/essential informa-

tion. [Tanya, Business analyst]

With regards to modelling emotional goals, there was

a clear preference for the POSE models, with only one

participant expressing a preference for i∗’s notation. This

participant commented that they preferred i∗’s way of

modelling emotion because POSE models are:

... organised by hierarchy, in my opinion we can’t

classify emotional things and feelings like this. [In-

grid, Digital media designer]

Despite this, Ingrid preferred the hierarchical nature

of POSE models.

The preference for explicit emotional goals reﬂects

our previous experience using these models with stake-

holders in projects. We have observed that people like

the explicit emotional goals because emotional goals

provide a clear separation from quality goals. Several

participants expressed similar views:

Love hearts indicate emotion & link back to a person

represented as a ﬁgure. [Bree, Lawyer]

Easy to misinterpret the i∗emotions as other soft

goals. [Nathan, Computer Science postdoc]

TABLE 4

Task analysis results

Percentage of correct answers Mean Stdev Mean Stdev

Notation Q1 Q2 Q3 Q4 Q5 Q6 Score Score Time Time

Meeting scheduler

i∗40.0% 25.0% 55.0% 60.0% 70.0% 2.50 1.27 9:21 2:52

POSE 70.0% 60.0% 80.0% 75.0% 60.0% 3.45 1.55 7:40 3:50

Patient care

i∗70.0% 60.0% 80.0% 50.0% 50.0% 40.0% 3.50 1.39 9:50 3:50

POSE 60.0% 80.0% 70.0% 80.0% 75.0% 40.0% 4.05 1.86 6:43 2:24

TABLE 5

Qualitative questions

Distribution

Property ++ + ◦+ ++

Understandability i∗preferred 0.0% 5.0% 0.0% 45.0% 50.0% POSE preferred

Modifying i∗Not at all conﬁdent 45.0% 25.0% 25.0% 5.0% 0.0% Very conﬁdent

Modifying POSE Not at all conﬁdent 0.0% 0.0% 20.0% 50.0% 30.0% Very conﬁdent

Concepts i∗captures more 15.0% 55.0% 20.0% 5.0% 5.0% POSE captures more

Structure i∗preferred 5.0% 10.0% 5.0% 45.0% 35.0% POSE preferred

Emotions i∗preferred 0.0% 5.0% 15.0% 35.0% 45.0% POSE preferred

Interestingly, there is no signiﬁcant difference in the

results between those participants with training in com-

puter science or software engineering, and those with-

out. That is, participants familiar with modelling nota-

tions such as UML, ER modelling, etc., still preferred the

simpliﬁed view.

5.3 Threats to validity

There are two main threats to external validity. First,

only two domains were modelled and used as part

of the experiment. Additional studies would improve

the generalisability of the results. Second, while 20 is

a reasonable number, the sample is biased towards pro-

fessionals, mostly with university degrees in areas where

modelling notations such as decision trees are used, and

did not include other representatives, such as children

or older people.

A threat to internal validity is that time and correct-

ness were used as proxies for understandability and

usability, and may not be entirely accurate. Another in-

ternal threat is the questions posed, which may have po-

tentially biased the results towards POSE. However, we

explicitly included questions that we believed would be

easier to answer in i∗, such as identifying which things

a role was responsible for (Question 5 of the patient care

system), which we believed would be straightforward to

identify in i∗due to their use of actor boundaries.

5.4 Discussion

The results of this evaluation support our hypothesis

that POSE models are suitable boundary objects. With

one of our primary criteria being a modelling notation

that is palatable to non-technical stakeholders, many of

whom will not have the desire to learn a new notation,

it is paramount that a simple and clear notation is

used. On top of this, we did not see a large divergence

in results between participants with computer science

training and those without. That is, the participants with

a computer science background also preferred the POSE

notation over i∗. From this, we conclude that POSE

models have the capability to carry the voice of the user,

and keep many stakeholder groups involved throughout

the requirements process.

6 CA SE STUDY — EMERGENCY ALARM SYS-

TE MS

In Section 5, we demonstrated the general suitability of

POSE models for emotional modelling. In this section,

we extend this work to a case-study evaluation of POSE

models on a real development project. The case study

is of emergency systems, discussed in the introduction.

The primary focus of this evaluation is to answer the

following qualitative research questions:

1) Do our motivation models capture the important

emotional aspects of peoples’ needs?

2) Does the consideration of emotions provide us with

useful information to improve systems and soft-

ware?

3) Are the resulting models useful as communication

tools between stakeholders, including software en-

gineers?

Thus, this evaluation is a preliminary investigation

into the use of emotional goals, and emotions in general,

for improving software and systems.

6.1 Emergency systems

Our case study is that of emergency systems. The aim of

these systems is to support a person, generally an older

person, to remain living at home longer.

Emergency systems typically have two features: (1)

an emergency alarm: the older person can raise an alarm

if they require emergency attention, via e.g. pushing a

button on a pendant worn around their neck or wrist;

and (2) a wellbeing check: the older person informs a

service provider that they are well, on a daily basis,

via e.g. a button on a base station. If no indication

of wellbeing is received during a speciﬁed period, the

service provider initiates checks on the older person.

The emergency system is installed in an older person’s

home, and data from the system is monitored by a

service provider. If the older person raises an alarm,

the service provider contacts the person to ask if they

require help, or to check that the call is not a false

alarm (accidental triggering of the alarm). If they fail

to make contact, or they make contact but the older

person is in need of help, the service provider calls a

nominated relative or friend to provide assistance, and

ultimately, emergency services (e.g. ambulance) if none

of the nominated contacts can attend.

For the wellbeing check, the older person is required

to register their wellbeing each day, generally between a

ﬁxed period of time; e.g. 7am–11am. If they do not check

in by the end of the period, the service provider calls the

older person. In most cases, the older person has simply

forgotten to press the button. If they cannot be reached,

a similar process as for raising an emergency is initiated.

6.2 Method

To uncover user needs and emotions in the emergency

system domain, we undertook an ethnographic study

using range of data collection methods, primarily in-

terviews and participant observation. We interviewed a

range of people about emergency alarms and technol-

ogy in general, we modelled the ﬁndings using POSE

models, and used these models as communication tools

with various stakeholders. This section details the study

design.

6.2.1 Study design

To answer the research questions identiﬁed at the start of

this section, we designed the study along the following

steps:

1) We modelled our initial thoughts on the relevant

functional, quality, and emotional goals for emer-

gency systems, based on existing literature and any

anecdotal stories that we had heard. This gave us a

baseline model against which to compare our ﬁnal

model, and helped to guide the interviews (research

question 1).

2) We interviewed 12 participants, categorised into

three groups: (a) older people who have or had

previously had an emergency alarm (four people);

(b) relatives of older people who have or had pre-

viously had an emergency alarm (four people); and

alarm (four people).

3) The interview data was analysed using ethno-

graphic content analysis to extract the key themes

or aspects, such as functionality, qualities, and emo-

tions desired by different stakeholders.

4) The key themes or aspects were modelled using

POSE models (research question 1).

5) The emotional goals were used to inform new func-

tional and quality goals for the model, and to then

provide some high-level design concepts for new

emergency systems (research question 2).

6) Finally, the models were used as communication

tools between the research team, our partners, and a

separate team of software engineers who developed

a new prototype for us (research questions 2 and 3).

6.2.2 Participants

Our primary data collection technique was face-to-face

interviews. We interviewed 12 people about their use of

technology in general, and on emergency systems. All

participants lived in Melbourne, Australia. In addition,

we took notes on the interview participants and their

domestic environment, such as where their emergency

alarm was located.

As mentioned previously, our interview participants

consist of three broad groups:

1) Four participants were older people who either

have or have had an emergency system installed

in their home. Their ages ranged from 85–91. Three

of the four participants lived on their own, while

the fourth lived with their spouse. All were sup-

ported in their wellbeing by family, friends, and

neighbours, and all had the emergency system as

additional support.

2) Four participants were family members (either chil-

dren, nieces, or nephews) of older people who either

had or have had an emergency system installed

at home. In all cases, the older person lived on

their own during the period in which they had the

system installed, and all had the emergency system

as additional support.

3) Four participants were older people who never had

an emergency system installed in their home, and

had not used one before. Their ages ranged from 69–

79. All participants in this category lived with their

spouse. From this group, we expected insights from

people who are not taking up emergency systems.

6.2.3 Data collection

The main source of data collection was via semi-

structured interviews with each of the participants. We

interviewed each participant once, with each interview

taking between 30–60 minutes. The interviews were

focused on the three different types of goals: functional,

quality, and emotional; and how these should be played

out in emergency systems and in technology in general.

Some participants were contacted for follow-up ques-

tions. All interviews were recorded and transcribed.

Interviews were semi-structured, allowing the par-

ticipants to explore their thoughts and feelings. Each

interview followed a similar pattern of asking three

broad types of questions about technology in general,

and about emergency systems:

1) What should technology (emergency systems) do

for you? This question relates to functional goals.

2) How should it be? This question relates to quality

goals.

3) How do you want to feel? The question relates to

emotional goals.

These questions were not asked directly as they are

stated above, but were based on these themes.

For those participants with experience in using emer-

gency systems, we also asked questions regarding the

contexts surrounding the emergency system, including

why they signed up, what problems they experienced

using the system, the key beneﬁts of the system, what

actions they believe are required to use the system,

and what they believe happens when they initiate an

emergency.

6.2.4 Data analysis

The interview data was analysed using ethnographic

content analysis according to Patton [34]. This involves

careful reading of the interview data, highlighting im-

portant and recurring themes from the participants’

responses. It identiﬁes core consistencies and meaning

of the data. At least two researchers would analyse each

interview, and would compare their ﬁndings to reach

an agreement on the important themes. This summary

data was then presented to the research group, consisting

of six people, and was subject to further analysis in

the group until we reached agreement on the important

themes over all interviews. The focus of this analysis was

on the emotional and quality attributes of the emergency

systems.

Pedell et al. [37] provide further details of the ﬁeld

study, including the ethnographic method followed, in-

formation about the participants, the questions, and the

ﬁndings, and also how the ethnographic data informed

and supported the models.

6.2.5 Limitations

There are several limitations to our evaluation. First, we

consider only one system, and as such, generalising to

all systems is not possible. Second, we have not repeated

our evaluation, so cannot determine how repeatable it is

from a software engineering perspective; that is, whether

another team would come up with the same models

from the same data. Despite this, content analysis [34]

is a well-accepted ethnographic technique, and informs

much of this part of the approach. Finally, the case study

is subject to bias, in that we knew that our initial baseline

models would be used for comparison, which may have

distorted our approach.

7 RESULTS AND LESSONS LEARNT

In this section, we present the results of the emergency

system case study, and discuss some of the lessons learnt.

We divide the presentation into what we learnt about

emergency systems design, and what we learnt about

our modelling approach.

We brieﬂy discuss the design of a new emergency sys-

tem based on our ﬁndings, which we have prototyped

and evaluated. Pedell et al. [37] present more detailed

results and discussion about the design of emergency

systems, the prototype, and the resulting prototype eval-

uation. Our focus in this paper is on the emotional goals

and related models.

7.1 Emergency systems

First, we discuss what we learnt about the design of

emergency systems. We present this by contrasting the

models that we derived prior to the interviews with the

models that were informed by the interviews. These goal

models provide a sufﬁcient overview of our particular

ﬁndings. Figure 6 shows the goal model prior to the in-

terviews, while Figure 7 shows it after the interviews. We

present our ﬁndings based on the changes and otherwise

between these two models. While functional and quality

goals have also changed, our analysis here is limited to

emotional goals. In Figure 7, we highlight changes made

to the emotional, quality and functional goals.

In this paper, we concern ourselves only with the

emotional goals. For each ﬁnding, we present a short

quote from interviews with participants, to supports this

ﬁnding, however each emotional goal is backed by ad-

ditional ethnographic data. Further details are available

in Pedell et al. [37].

7.1.1 Conﬁrmation of existing emotional goals

Reassured. Our ﬁrst model (Figure 6) seems to correctly

capture the idea that the primary motivation for wanting

to install an emergency system into a relative’s home is

to provide the carer or relative with reassurance that the

older person is safe. The interview data conﬁrms this.

For example:

We just felt that if she had a fall or something

happened to her ... we would at least know that she

was OK [Christine – daughter of an emergency

system user].

Safe. Feeling safe is a key theme for the people using

the pendants:

... but basically because I’ve got this, I’ve got con-

ﬁdence when I’m on my own [Jane – emergency

system user].

Independent. From anecdotal evidence, we had learnt

that independence was a key theme in emergency sys-

tems. However, we learnt the perceptions of indepen-

dence vary greatly between different people who had

an emergency system.

Fig. 6. The goal model prior to the interviews

On the one hand, emergency systems were seen to

preserve independence for many people who would oth-

erwise have to live in a shared home, or with relatives:

I think she felt that she’d got her independence back.

“I can stay here by myself because I’ve actually

now got something that if something happens to me,

she is not going to fret” [Feelings of her mother

described by Christine].

On the other hand, emergency systems were seen by

some as a threat to their independence:

It threatened her independence. She felt that it

branded her in a way that made her less independent

[Feelings of his aunt described by Joe].

Thus, some people felt that having an emergency

system attracted a stigma that they could not take care

of themselves because they were old.

We identiﬁed a clear distinction between these two

groups. The group that felt the emergency systems gave

them a feeling of independence had asked to have it

installed. That is, they felt that they could no longer live

independently without support for their wellbeing, and

this system gave them their independence by allowing

them to stay in their home for longer. The group that

felt their independence threatened had been told by their

relatives that they would need one. That is, the relative

gave them an ultimatum of living in a nursing home, or

getting an emergency system.

Those people who felt the system threatened their

independence tended not to wear the emergency pen-

dant. Joe, who insisted that his aunt have an emergency

system installed, described that the two times that his

aunt fell over and was unable to get up — in one case,

breaking her hip — she was not wearing her pendant

either time, and had to wait until neighbours or Joe

himself visited. His aunt later admitted that she only

wore the emergency pendant when she knew Joe was

coming to visit.

7.1.2 Removal of existing emotional goals

Accessible, uniﬁed, and natural. The three context-

speciﬁc emotional goals in Figure 6 that we had initially

considered as important did not reveal themselves as

themes from the interview data. We note that these were

the only context-speciﬁc emotional goals that we had

considered, and thus, these were all different to those of

our participants. This results demonstrates the impor-

tance of stakeholder input for these types of systems.

7.1.3 Addition of new emotional goals

In touch — personal goal. A new theme was the feeling,

for the older person, of being in touch with others

— especially family and friends, which is modelled in

Fig. 7. The goal model after the interviews

Figure 7. We expect that this is especially prevalent in our

interview data because most of the emergency system

users in our study were living alone, and felt isolated —

something that is common with many emergency system

users in Australia. This more general emotional goal of

being in touch is supported by the emergency systems

in a small way, in that the older persons felt that they

were not totally alone:

Very comforting that you’ve got that contact, other-

wise you’re on your own [Jane, emergency system

user].

Two participants noted that they enjoyed talking with

the support staff, even if over the phone, noting how

courteous and caring they were.

In control — context-speciﬁc goal. One theme that

was identiﬁed was that of being in control. Participants

stressed the importance of being in control of their lives

(not just in control of technology):

Technology ... should enable me to do things that I

can’t do otherwise. It should not be an instrument

of control or surveillance [Martin, non user].

The emergency systems were seen to be a source of

resentment regarding the control in their life, which

stressed out some users:

We actually turned off the services at the end of the

month, because we were not happy with it. It was

stressing my mother, it was stressing me [Lucas,

son of emergency system user].

The feeling of being in control is closely related to

that of feeling independent. Our analysis showed that

some people could feel independent, but not have the

feeling of control over the emergency system. For this

reason, we modelled the feeling of “in control” as a

context-speciﬁc emotional goal (Figure 7) — while an

older person wants to feel in control of their own life,

an emergency system cannot give them this control, but

should be designed to give them control of the system

itself.

Integrated — context-speciﬁc goal. A recurring theme

about emergency systems and technology in general is

that they should feel integrated into one’s life, modelled

in Figure 7. For example, in the context of emergency

systems, any disruption that it would cause to the older

person’s regularly daily routine was considered a nega-

tive:

The biggest problem is it didn’t get integrated into

my mother’s life and part of the routines that she

had. If I use jargon, she didn’t ever really appropriate

the technology. It didn’t become part of her life. And

she never really viewed it positively [Lucas, son of

emergency system user].

7.1.4 Modiﬁcation of existing emotional goals

Cared for →Cared about. An important ﬁnding of our

study is the feeling of caring. We initially modelled feel-

ing cared for as an emotional goal in Figure 6. However,

from our interview data, it became clear that none of the

older persons wanted to be cared for. In particular, two

older women who had worked in the aged care sector

all their career did not want to receive care:

She worked for disability services all her life. This

transition was difﬁcult for her, because she went

from being the carer to being someone who didn’t

want to be cared for [Joe, nephew of emergency

system user].

Instead, the participants in our study were more con-

cerned with being cared about, which has been modelled

in Figure 7. The older persons appreciated that their

families, friends, and neighbours cared enough about

them to want to them to be safe:

We were actually clear on the objectives of why

we were doing it. And, again, that was an easy

message, saying, “Look, we’re not here to alarm,

but we’re doing it because we care” [Lucas, son

of emergency system user].

This theme was common, and some participants felt

that older people were treated patronisingly when get-

ting care they did not particularly want. The distinction

is important for the interaction design of systems: the

systems should support the notion that people care

about the older person, while not making them feel like

patients.

7.1.5 Summary of ﬁndings about emergency systems

From the interviews and analysis, we learnt several

important considerations about emergency systems, and

technology design in general. As well as the obvious

feeling of safety, two prominent emotions were that the

older person wanted to feel in control of the system, and

more generally, they wanted to feel in touch — some-

thing that emergency systems could contribute to, but

do not currently address particularly well. In addition,

we learnt that the older people did not want to be cared

for, but they wanted to be cared about.

7.2 Design improvement

In this section, we discuss the design of a prototype

emergency system that we believe fulﬁls some of the

key emotional goals. A more detailed description of this

design and how it came about, as well as detailed results

of a ﬁeld study trailing this prototype, are presented in

other work [37].

This prototype is not intended to offer a serious and

complete replacement for emergency systems, but in-

stead demonstrates how emotional goals, and the ethno-

graphic data supporting them, can be used to guide the

design process, and how more general socially-oriented

systems can achieve some of the goals of emergency

systems.

This improvement focuses on adding new functional

and quality goals to complement or fulﬁl some of the

emotional goals identiﬁed. Our particular focus is on the

emotional goals of the older person, as the emotional

goal of feeling reassured for family members and carers

is strongly supported by existing emergency systems, so

the design is based around the wellbeing check.

7.2.1 System design and implementation: staying in

touch

We have implemented a complete prototype, with a

particular focus on the I’m in touch goal from Figure 7.

The prototype contains (among other functionality) a

digital photo frame on a tablet, which displays photos

sent to it from relatives and friends, via email. The

older person can place the frame in a location of their

choosing, and can view photos, comment on photos,

which sends the comments back to the sender (these can

be further replied to by the sender), and scroll through

older photos. When the older person has not interacted

with the frame for a speciﬁc amount of time, where the

time is conﬁgurable for each person, the carer can contact

the person. The older person can press a button that is

the same as the previous wellbeing check. Additionally,

the tablet’s accelerometer is used to detect movement,

which is logged as interaction with the system.

Any interaction from the older person establishes that

they are well, so the wellbeing check is not required if

they move or interact with the picture frame. Settings

can be changed, so that instead of the older person

being required to interact within a ﬁxed period, they can

specify different time periods, giving them control.

Allowing the sender of the message to acknowledge a

response via another message permits a two-way com-

munication, which fulﬁls the emotional goals of feeling

in touch and cared about (Figure 7).

As an illustration of how we use POSE models to

design more speciﬁc requirements for systems, Figure 8

shows part of a goal model for our new system. This

goal model breaks down the goal I’m in touch into more

speciﬁc goals that are closer to functional requirements.

This model is not complete, but is for illustration pur-

poses only.

We have translated the goal of feeling “in touch”

directly into a functional goal called I’m in touch (Fig-

ure 7). The primary idea is that instead of sending a

one-way signal via a button, the older person using the

emergency system to stay in touch with their family, who

can respond (and therefore acknowledge) this, delivering

a sense of being in touch, while also fulﬁlling the goal

of communicating that they are well.

In Figure 8, we decompose this functional goal into a

more reﬁned set of goals that are speciﬁc to our product

design. For example, to communicate with a carer or

relative, an older person can look at a picture (implicitly

communicate), or they can like the picture or send a

message (explicitly communicate).

The design was inspired by our participants, many of

whom talked about how much their family means to

them, and proudly displayed photos of their families on

tables, bookshelves, etc. In particular, one participant hid

Fig. 8. Part of a reﬁned goal model for the emergency system.

his emergency system base station by covering it with

photo frames containing pictures of his grandchildren.

7.2.2 System evaluation

This prototype was placed into the homes of nine older

people over a period of approximately two weeks each.

Interviews were conducted both before and after the

deployment period to evaluate how well the design and

implementation fulﬁlled the goal model from Figure 7.

The evaluation demonstrated four key ﬁndings:

1) Those older people who had or have had an emer-

gency alarm reported a more positive experience us-

ing the prototype developed according to emotional

goals than using their existing alarm.

2) The older people enjoyed the social interaction of

viewing photos and sending messages to their car-

ers.

3) The beneﬁts of the emotion-led design are particu-

larly apparent when the users are not particularly

tech-savvy, or when they are an existing emergency

system user.

4) Some participants still did not feel in control, as

they did not want carers to be informed about their

actions.

Further details on the prototype, on the evaluation

study, including the results are available in Pedell et al.

[37].

7.3 Emotion-led modelling

In this section, we discuss some of the lessons that we

learnt about our emotion-led modelling.

7.3.1 Personal vs. context-speciﬁc emotional goals

In Section 4.2, we made a clear distinction between per-

sonal and context-speciﬁc emotional goals. In previous

work on emotions and emotional goals [3, 5, 40, 47, 21],

we have not seen such a distinction made.

It was not until we attempted to model the outcomes

of initial brainstorming session for the emergency system

case study that this difference was identiﬁed. When

analysing and ﬁnding the key emotional factors, it be-

came clear that some factors were personal and persisted

outside of the scope of emergency systems, and some

were tied directly to the system itself.

In our initial attempts to model these two distinc-

tions, we used notational differences, such as placing

the role between the functional goal and emotional goal

for context-speciﬁc emotional goals. However, as we

progressed further, we realised that our research group

and other stakeholders could determine the difference

from the context, so we used one syntax for both.

7.3.2 All quality goals are implicitly context-speciﬁc

emotional goals

In both our initial brainstorming and our data analysis,

we found that many of the quality goals that were

derived also came up as emotional goals — mainly

context-speciﬁc emotional goals. For example, the goal

of the call for help being immediate was derived as both

a quality goal and an emotional goal from different

analyses. This is consistent with Norman’s theory [30]:

events are processed at one level, but the emotional

response can trigger responses at other levels. Therefore,

if one desires a particular quality in a system, then

they also want to feel (or perceive) that the system has

that quality. In short, each quality goal has an implicit

emotional goal associated with it.

In initial data collection, we often categorised both,

however, during modelling, we categorise these as either

quality goals (related to behavioural level) or emotional

(related to reﬂective). In the example of an immediate call

for help, this is clearly related to system performance,

so is behavioural. However, there could also be a clear

reﬂective emotional response to this, and quality goals

in models can be read this way.

7.3.3 Emotion-led models as analysis tools

The resulting model in Figure 7 is simple, and conveys

only part of the important information of the domain;

e.g. we supplement the goals with quotes in Section 7.1

to provide additional context. While it is easy to dismiss

the model as being superﬂuous in the context of sur-

rounding discussion and quotes, this does not consider

that the quotations and analysis of them are a result of

the modelling. That is, we use a grounded analysis to

sift, select, and organise the many pieces of information

and abstract them into a sensible and coherent grounded

theory, which we record using our models. The quotes

in the paper were selected because they represented

particular emotional goals, rather than being picked

directly out of the large amount ethnographic data.

Our transcribed interviews consisted of almost 40,000

words. We found that the modelling provided a useful,

structured way to sift and organise ethnographic data.

The difﬁculty is, of course, in gauging the right level

of detail, and deciding what should be discarded, what

should be included, and what should be merged with

other concepts. Including all relevant detail would result

in a unwieldy model that is not useful for commu-

nication, while including too little would result in a

meaningless model. Having validated the emergency

alarm models with several participants, we believe that

our models are at an appropriate level for understanding

the problem domain.

7.3.4 Emotion-led models as communication tools

In much of our previous work [28, 27, 36], our focus

has been on the use of agent-oriented models as shared

communication tools between stakeholders. In our expe-

rience, the lightweight notation and focus on high-level

concepts make them useful in early-phase requirements

engineering.

This section presents our experiences in using this

novel emotion-led models for communicating with

stakeholders in this project.

Communication within the research team. The models

were used extensively and effectively within the research

team to keep track of our current understanding of the

domain. As well as providing a way to document our

understanding, they were used in meetings to discuss

ﬁndings, design ideas, and future work.

Communication of results. Our POSE models were used

as a way to communicate our results, much as they have

been in this paper. As well as a presentation of the model

to record our understanding, we presented reports to

one of our funding bodies based on the structure of the

model. That is, headings in the report were taken directly

from the model, and discussions centred around the

goals on the model. In addition to providing a structure

for reports, we found that this provided readers with

a clear summary of results that could be referred to in

order to put the results in perspective.

Communication with developers. Our POSE models

were given to the team that developed our prototype. As

well as giving the development team an understanding

of the domain, the models helped us to provide them

with clear motivation for the functionality that they were

implementing.

One unexpected use of the models in this context was

the developers employing them as a project management

tool. The development team, who are separate from

our research team, use a lean software development

process, and, roughly speaking, manage progress by

noting which stage of completion project tasks are in.

The development team used the goal model to derive

the tasks, adding each goal as a task to their project plan,

and “ticking off” goals once the corresponding task is

complete.

Although we have used the goal models for similar

purposes in the past, and Marshall [21] reports on using

goal models for project management, the development

team on the project were unaware of this work. Clearly,

the goal models worked for them, and were used directly

in the development.

Communication with aged-care providers. Although

we have not typically shown the models to aged-care

providers, in discussing our work with them, the models

and the particular abstraction we have chosen continues

to provide a structured way to communicate what we

have learnt from the project.

Abstraction and hierarchy. Consistent with our previ-

ous work [28], the higher-level graphical goal models

were more useful as shared artifacts in meetings and

discussions than the more detailed role models. Further,

the hierarchical nature of the goal models allowed us to

focus on the highest-level models for the most part, and

then drill down into more detail at the lower level for

more speciﬁc discussions.

Notation. The emotional goal notation is straightfor-

ward. However, one problem that we are encountering in

our projects is that they result in a signiﬁcant increase in

repeated role ﬁgures and arcs on the models, compared

to models without emotional goals. That is, they do not

increase the number of roles, but result in repeated roles

on models, or additional arcs that cross each other. We

identify three reasons for this: (1) we often represent

additional information that we did not otherwise con-

sider, by asking additional questions about emotions; (2)

the notation of an emotional goal requires three graph

nodes (a role, an emotion, and a functional goal), and

two arcs; and (3) it is often the case that emotional goals

are attached to functional goals in which the roles that

achieve the goals are not the same as the role that has

the emotional goal. For example, in the gifting model

in Figure 4, the roles attached to the emotional goals are

not the same as the roles that achieve the functional goal

that fulﬁls those emotional goals.

Despite this, our models have not become overcompli-

cated in our view, because we use the hierarchical nature

of the models to split them into several smaller models.

We also avoid excessive arcs by implicitly using space to

convey the relations instead of lines. In our experience,

this is possible in most cases, and our experiments

from Section 5 demonstrate that it is preferred by many

participants.

Summary of communication beneﬁts. Overall, we

found our goal models to be effective communication

tools between different stakeholders. The models do

not capture all of the ethnographic data, nor all details

required to build a system. However, as tool for rep-

resenting a shared understanding of the problem, we

found them useful.

We ultimately did not show the goal models to our

participants. However, we are currently working on

other projects in which end users are encouraged to

create and edit goal models. We are ﬁnding that models

that include emotional goals resonate with stakeholders

— especially non-technical stakeholders. We are explor-

ing areas such as depression care, sleep disorders, and

other areas related to wellbeing, and are ﬁnding that

non-technical stakeholders embrace POSE models. The

idea of considering emotions at a early stage resonates

especially strongly in these areas in which the user’s

state of mind is paramount.

7.4 Discussion

In this section, we reﬂect on the research questions

identiﬁed at the start of Section 6.

Can our emotion-led goal models capture important emo-

tional aspects of peoples’ needs? Based on our ﬁndings,

we captured many of the important emotional aspects

for the emergency systems. As well as extracting the

important themes from the ethnographic data, the eval-

uation of our prototype showed high user satisfaction,

especially for the group of users who had previous

experience with an emergency system.

Our models do not capture all relevant information,

and further, the quality of the models is only as good

as the data that backs them. However, we believe that

the high-level view of motivations, including functional,

quality, and emotional goals, is an important factor in

software and systems engineering.

Does the consideration of emotions provide us with useful

information to improve systems and software? Evaluations of

our prototype provide support that that the considera-

tion of emotions can lead to improved systems and soft-

ware, and ultimately, better outcomes for users. Further

evidence for this is the continued engagement from our

industry partner who develops software for emergency

systems, and interest from several new partners in the

aged-care service industry.

While we believe that considering emotions would

have the most visible impact in socially-oriented sys-

tems, we also believe that the consideration on emotions

can have an impact on systems employed in organisa-

tions, which is consistent with related ﬁndings [25].

Are the resulting models useful as communication tools

between stakeholders, including software engineers? While

we can offer only anecdotal evidence of support for this

question, our experience in this and other projects indi-

cates that the most valuable aspect of POSE models is not

as a summary of the ethnographic ﬁeld data for our own

purposes, but as a tool to share our understanding of this

data with others. Being able to present a 1–2 page dia-

gram outlining the most important motivations of users

is key to communicating and motivating system design.

The use of the models by the team that developed the

prototype further demonstrates the value of the models

for organising and understanding the key motivations.

8 CONCLUSIONS

In this paper, we introduced a straightforward notation

of modelling emotional goals in agent-oriented mod-

elling. We distinguish between two types of emotional

goals: personal emotional goals, which model the emotional

desires of users; and context-speciﬁc emotional goals, which

model the desired effects that a system has on its users.

These models were evaluated both via a controlled

user study, and in the context of emergency systems,

demonstrating that emotional goals can capture the key

emotional desires of users, and can lead to improved

design of systems and software. We have designed,

implemented, and evaluated a new prototype for an

emergency system, focusing on the “wellbeing check”,

and demonstrated that asking a few simple questions re-

garding users’ emotions can lead to improved outcomes

of systems.

Based on our project, we have attracted further fund-

ing from grant schemes and industry partners to apply

our emotion-led models in areas such as depression

care, support for sleep deprivation, and home care for

the elderly, and applications for promoting low-carbon

living. While some of these are currently undergoing

trials that appear to be successful, further work needs

to be done.

Our future work will focus on mapping the idea of

emotional goals from requirements to software design,

implementation, testing, and system evaluation, allow-

ing us to trace emotion-led requirements throughout the

software development lifecycle. Furthermore, we will

aim at gaining deeper understanding on how we can

map emotional goals to system designs, providing more

systematic methods for considering emotions in design.

Finally, as a method of validation and repeatability of our

modelling approach, the study data will be interpreted

and modelled by others.

In recent work [19], we have considered how to accom-

modate the differing reactions between individuals at the

reﬂective level. We used the notions of personas [8] and

scenarios to evaluate how different people may react to

the same designs. Cooper [8] deﬁnes personas as hypo-

thetical archetypes for actual users. For several projects,

we have used ethnographic data to derive several rich,

realistic personas representing different people who hold

a stake in proposed systems. We then walk through pre-

deﬁned scenarios to help us reason empathetically in

place of those personas, improving our evaluation of

design decisions, and potentially leading to new design

ideas.

Acknowledgements

This research is funded by the Australian Research

Council Discovery Grant DP130102660 and the Smart

Services CRC.

REFERENCES

[1] M Alvarez-Jimenez, S Bendall, R Lederman, G Wadley, G Chin-

nery, S Vargas, M Larkin, E Killackey, PD McGorry, and JF Glee-

son. On the horyzon: moderated online social therapy for long-

term recovery in ﬁrst episode psychosis. Schizophrenia research,

143(1):143–149, 2013.

[2] G. Baxter and I. Sommerville. Socio-technical systems: From de-

sign methods to systems engineering. Interacting with Computers,

23:4–17, 2010.

[3] T. Bentley, L. Johnston, and K. von Baggo. Putting some emotion

into requirements engineering. In Proceedings of the 7th Australian

Workshop on Requirements Engineering, pages 227–244, 2002.

[4] P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, and J. My-

lopoulos. Tropos: An Agent-Oriented Software Development

Methodology. Autonomous Agents and Multi-Agent Systems, 8(3):

203–236, 2004.

[5] D. Callele, E. Neufeld, and K. Schneider. Emotional requirements

in video games. In 14th IEEE International Conference Requirements

Engineering, pages 299–302. IEEE, 2006.

[6] R. Colomo-Palacios, C. Casado-Lumbreras, P. Soto-Acosta, and

A. Garc´

ıa-Crespo. Using the affect grid to measure emotions in

software requirements engineering. Journal of Universal Computer

Science, 17(9):1281–1298, 2011.

[7] Ricardo Colomo-Palacios, Adri´

an Hern´

andez-L´

opez, ´

Angel

Garc´

ıa-Crespo, and Pedro Soto-Acosta. A study of emotions

in requirements engineering. In Organizational, Business, and

Technological Aspects of the Knowledge Society, pages 1–7. Springer,

2010.

[8] Alan Cooper. The inmates are running the asylum: Why high-tech

products drive us crazy and how to restore the sanity, volume 261.

Sams Indianapolis, 1999.

[9] Anne Dardenne, Axel Van Lamsweerde, and Stephen Fickas.

Goal-directed requirements acquisition. Science of computer pro-

gramming, 20(1):3–50, 1993.

[10] PMA Desmet and P Hekkert. Special issue editorial: Design &

emotion. International Journal of Design, 3(2):1–6, 2009.

[11] T. Diggins and P. Tolmie. The ‘adequate’ design of ethnographic

outputs for practice: some explorations of the characteristics of

design resources. Personal and Ubiquitous Computing, 7(3):147–158,

2003.

[12] K. El Emam and A.G. Koru. A replicated survey of IT software

project failures. IEEE software, 25(5):84–90, 2008.

[13] Eva Hudlicka. What are we modeling when we model emotion?

In AAAI Spring Symposium: Emotion, Personality, and Social Behav-

ior, pages 52–59, 2008.

[14] J. Hughes, V. King, T. Rodden, and H. Andersen. The role of

ethnography in interactive systems design. Interactions, 2(2):65,

1995.

[15] J. Hughes, J. O’Brien, T. Rodden, M. Rounceﬁeld, and I. Som-

merville. Presenting ethnography in the requirements process. In

Proceedings of the Second IEEE International Symposium on Require-

ments Engineering, pages 27–34. IEEE Computer Society, 1995.

[16] J.A. Hughes, J. O’Brien, T. Rodden, M. Rounceﬁeld, and S. Bly-

thin. Designing with ethnography: a presentation framework for

design. In Proceedings of the 2nd conference on Designing interactive

systems: processes, practices, methods, and techniques, pages 147–158.

ACM, 1997.

[17] H. Hutchinson, B. Westerlund, B.B. Bederson, A. Druin,

M. Beaudouin-Lafon, H. Evans, and N. Roussel. Technology

probes: inspiring design for and with families. In Proceedings of

the SIGCHI conference on Human factors in computing systems, pages

17–24. ACM New York, 2003.

[18] Ivar Jacobson. Object oriented software engineering: a use case

driven approach. 1992.

[19] Antonio A Lopez-Lorca, Tim Miller, Sonja Pedell, Antonette Men-

doza, Alen Keirnan, and Leon Sterling. One size doesn’t ﬁt all:

Diversifying “the user” using personas and emotional scenarios.

In Proceedings of the 6th International Workshop on Social Software

Engineering, pages 25–32. ACM, 2014.

[20] Neil Maiden. Spocks and kirks in the requirements universe. IEEE

software, 29(4):0084–85, 2012.

[21] J. Marshall. Using goal models for project management in

teaching. In Flash Talk at OZCHI, 2012.

[22] James Marshall. Agent-based modelling of emotional goals in

digital media design projects. International Journal of People-

Oriented Programming, 3(1):44–59, 2014.

[23] A. Mendoza, J. Carroll, and L. Stern. Software appropriation over

time: from adoption to stabilization and beyond. Australasian

Journal on Information Systems, 16(2):5–23, 2010.

[24] A. Mendoza, J. Carroll, and L. Stern. Support mechanisms for

early, medium and longer-term use of technologies. In 21st

Australasian Conference on Information Systems, pages 1–10. ACIS,

2010.

[25] A. Mendoza, T. Miller, S. Pedell, , and L. Sterling. The role of

users’ emotions and associated quality goals on appropriation

of systems: two case studies. In 24th Australasian Conference on

Information Systems, 2013. (In press).

[26] D.R. Millen. Rapid ethnography: time deepening strategies for

HCI ﬁeld research. In Proceedings of the 3rd conference on Designing

interactive systems: processes, practices, methods, and techniques, pages

280–286. ACM, 2000.

[27] T. Miller, S. Pedell, L. Sterling, F. Vetere, and S. Howard. Under-

standing socially oriented roles and goals through motivational

modelling. Journal of Systems and Software, 85(9):2160–2170, 2012.

[28] Tim Miller, Bin Lu, Leon Sterling, Ghassan Beydoun, and Kuldar

Taveter. Requirements engineering using the agent paradigm: a

case study of an aircraft turnaround simulator. IEEE Transactions

on Software Engineering, 40(10):1007–1024, Oct 2014.

[29] S. Munroe, T. Miller, R. Belecheanu, M. Pechoucek, P. McBurney,

and M. Luck. Crossing the agent technology chasm: Lessons,

experiences and challenges in commercial applications of agents.

Knowledge Engineering Review, 21(4):345–392, December 2006.

[30] D. Norman. Emotional design: Why we love (or hate) everyday things.

Basic books, 2007.

[31] C. Otnes and R.F. Beltramini. Gift giving: A research anthology.

Popular Press, 1996.

[32] J. Paay, L. Sterling, F. Vetere, S. Howard, and A. Boettcher.

Engineering the social: The role of shared artifacts. International

Journal of Human-Computer Studies, 67(5):437–454, 2009.

[33] L. Padgham and M. Winikoff. Developing Intelligent Agent Systems:

A practical guide. John Wiley and Sons, August 2004.

[34] M.Q. Patton. Qualitative research and evaluation methods. Sage

Publications, Thousand Oaks California, 2002.

[35] J. Pav´

on and J. G´

omez-Sanz. Agent oriented software engineering

with INGENIAS. In Multi-Agent Systems and Applications III,

volume 2691 of LNCS, pages 394–403. Springer, 2003.

[36] S. Pedell, T. Miller, F. Vetere, L. Sterling, and S. Howard. Socially-

oriented requirements engineering — software engineering meets

ethnography. In Perspectives on Culture and Agent-based Simulations,

volume 3 of Studies in the Philosophy of Sociality, pages 191–210.

2014.

[37] Sonja Pedell, A Lopez-Lorca, Tim Miller, and Leon Sterling. Don’t

Leave Me Untouched: Considering Emotions in Personal Alarm Use and

Development, pages 96–127. IGI Global, 2014.

[38] R. Proynova, B. Paech, S. Koch, A. Wicht, and T. Wetter. Investi-

gating the inﬂuence of personal values on requirements for health

care information systems, 2011.

[39] I. Rahwan, T. Juan, and L. Sterling. Integrating social modelling

and agent interaction through goal-oriented analysis. International

Journal of Computer Systems Science & Engineering, 21(2):87–98,

2006.

[40] I. Ramos and D. Berry. Is emotion relevant to requirements

engineering? Requirements Engineering, 10(3):238–242, 2005.

[41] I. Ramos, D. Berry, and J. Carvalho. Requirements engineering for

organizational transformation. Information and Software Technology,

47(7):479 – 495, 2005.

[42] D. Randall, R. Harper, and M. Rounceﬁeld. Fieldwork for design:

theory and practice. Springer-Verlag, 2007.

[43] L. Sterling and K. Taveter. The Art of Agent-Oriented Modelling.

MIT Press, 2009.

[44] Alistair Sutcliffe. Emotional requirements engineering. In 21st

IEEE International Requirements Engineering Conference, pages 321–

322, 2011.

[45] Alistair Sutcliffe and Sarah Thew. Analysing “people” problems

in requirements engineering. In International Conference on Software

Engineering, volume 2, pages 469–470. IEEE, 2010.

[46] F. Sweet. Frog: form follows emotion. Thames & Hudson, 1999.

[47] S. Thew and A. Sutcliffe. Investigating the role of ‘soft issues’ in

the RE process. In IEEE International Conference on Requirements

Engineering, pages 63–66. IEEE, 2008.

[48] Clare Thompson, Neil Maiden, Mobina Nouri, and Konstantinos

Zachos. Evoking emotion through stories in creative dementia

care. In Proceedings of the 8th Knowledge, Information and Creativity

Support Systems Conference, pages 635–646, 2013.

[49] S. Viller and I. Sommerville. Coherence: an approach to represent-

ing ethnographic analyses in systems design. Human-Computer

Interaction, 14(1):9–41, 1999.

[50] S. Viller and I. Sommerville. Ethnographically informed analysis

for software engineers. International Journal of Human-Computer

Studies, 53(1):169–196, 2000.

[51] A. Walenstein. Finding boundary objects in SE and HCI: An ap-

proach through engineering-oriented design theories. Bridging the

Gaps Between Software Engineering and Human-Computer Interaction,

pages 92–99, 2003.

[52] E. Yu. Towards modelling and reasoning support for early-

phase requirements engineering. In Proceedings of the 3rd IEEE

International Symposium on Requirements Engineering (RE’97), page

226. IEEE Computer Society, 1997.

[53] E. Yu. Agent-oriented modelling: software versus the world.

In Agent-Oriented Software Engineering II, volume 2222 of LNCS,

pages 206–225. Springer, 2002.

[54] E. Yu. Social modeling and i∗.Conceptual Modeling: Foundations

and Applications, pages 99–121, 2009.

[55] F. Zambonelli, N. R. Jennings, and M. Wooldridge. Developing

multiagent systems: The Gaia methodology. ACM Transactions on

Software Engineering Methodology, 12(3):317–370, 2003.

Content uploaded by Tim Miller

Author content

emotional-goa

ls.pdf

PDF

1.45 MB

Download file

RP: 3015 Learning for Low Carbon Living The Building Quality Passport -Mobile Learning for Australian built environment trades and professionals Learning for Low Carbon Living The Building Quality Passport 1 Title RP3015: Learning for Low Carbon Living Mobile learning for Australian built environment trades and professionals ISBN Date Preferred citation Learning for Low Carbon Living The Building Quality Passport 2 Acknowledgements

Technical Report

Full-text available

Nov 2019

Executive Summary This final report supports the completion of the Cooperative Research Centre for Low Carbon Living (CRC LCL) Research Project (RP) 3015: Increasing knowledge and motivating collaborative action on Low Carbon Living through team-based and game-based mobile learning (2014-2018). The project aims to address a challenge which is central to the CRC LCL's stated purpose, of overcoming barriers to the adoption of low-carbon construction processes, products and services. Regardless of technological advances or policy changes toward energy efficient and low carbon building design, the quality of construction practices needs to improve to harness the significant opportunities available in the market. The central question for this project was: How might we facilitate a sense of responsibility toward embedding sustainable practice into the culture of the tradespeople and builders? Input from project industry partners, as well as semi-structured interviews and surveys with trades instructors, builders and students supported the contention that leveraging situated peer to peer and authentic learning on the building site (contextualising rather than abstract instruction), combined with social learning strategies might be well suited to addressing these issues during teaching of trades apprentices, builders and design professionals. This project therefore focussed on how this could be facilitated by mobile learning (M-Learning) using smart-phone technology to align the learning needs of apprentices, the instructional needs of trainers, and builders needs for work-site efficiency, business benefits through continuous improvement, compliance, quality assurance tracking, and documentation. It recognises that “…learning and acting are interestingly indistinct, learning being a continuous, life-long process resulting from acting in situations” (Brown, Collins and Duguid 1989).

On the Unhappiness of Software Developers

Conference Paper

Full-text available

Jun 2017

The happy-productive worker thesis states that happy workers are more productive. Recent research in software engineering supports the thesis, and the ideal of flourishing happiness among software developers is often expressed among industry practitioners. However, the literature suggests that a cost-effective way to foster happiness and productivity among workers could be to limit unhappiness. Psychological disorders such as job burnout and anxiety could also be reduced by limiting the negative experiences of software developers. Simultaneously, a baseline assessment of (un)happiness and knowledge about how developers experience it are missing. In this paper, we broaden the understanding of unhappiness among software developers in terms of (1) the software developer population distribution of (un)happiness, and (2) the causes of unhappiness while developing software. We conducted a large-scale quantitative and qualitative survey, incorporating a psychometrically validated instrument for measuring (un)happiness, with 2,220 developers, yielding a rich and balanced sample of 1,318 complete responses. Our results indicate that software developers are a slightly happy population, but the need for limiting the unhappiness of developers remains. We also identified 219 factors representing causes of unhappiness while developing software. Our results, which are available as open data, can act as guidelines for practitioners in management positions and developers in general for fostering happiness on the job. We suggest future research in software engineering should consider happiness in studies of human aspects and even in seemingly unrelated technical areas.

Stakeholder-Centric Clustering Methods for Conflict Resolution in the Requirements Engineering Process

Chapter

Feb 2022

This paper describes the development and evaluation of a framework that combines expert-based and clustering methods for resolving conflicts in requirements elicited from stakeholders. The purpose of the framework was to identify and resolve conflicts among expectations by multiple stakeholders that often arise during the requirements elicitation phase. By means of qualitative and quantitative research approaches, face-to-face oral interviews, quantitative surveys, brainstorming sessions, and focus groups, scenarios were generated with stakeholders of a given problem domain. Our approach was implemented within an interactive system that empirically supports the adequacy of our framework with the involvements of experts and other stakeholders of the chosen problem domain. In addition, we presented a dataset of requirements with their weight scales that formed the basis for resolving conflicting views by stakeholders by applying scientific criteria. The framework was validated in a real-life case study. The results demonstrated 85.71% of correctly clustered instances of requirements, based on which the experts agreed that the interactive system was good enough for resolving conflicting subjective views in requirements analysis. The research performed has the two-fold threat to validity, which suggests (i) the need to adequately capture and harmoniously represent the views by different stakeholders in a multicultural and multidisciplinary domain and (ii) the need to validate the framework in other real life case studies in different domains. The research performed has a high potential for reducing software development costs and saving time at the early stage of the development of software products.

XtraLibD: Detecting Irrelevant Third-Party Libraries in Java and Python Applications

Chapter

Full-text available

Jan 2022

Software development comprises the use of multiple Third-Party Libraries (TPLs). However, the irrelevant libraries present in software application’s distributable often lead to excessive consumption of resources such as CPU cycles, memory, and modile-devices’ battery usage. Therefore, the identification and removal of unused TPLs present in an application are desirable. We present a rapid, storage-efficient, obfuscation-resilient method to detect the irrelevant-TPLs in Java and Python applications. Our approach’s novel aspects are i) Computing a vector representation of a .class file using a model that we call Lib2Vec. The Lib2Vec model is trained using the Paragraph Vector Algorithm. ii) Before using it for training the Lib2Vec models, a .class file is converted to a normalized form via semantics-preserving transformations. iii) A eXtra Library Detector (XtraLibD) developed and tested with 27 different language-specific Lib2Vec models. These models were trained using different parameters and >30,000 .class and >478,000 .py files taken from >100 different Java libraries and 43,711 Python available at MavenCentral.com and Pypi.com, respectively. XtraLibD achieves an accuracy of 99.48% with an F1 score of 0.968 and outperforms the existing tools, viz., LibScout, LiteRadar, and LibD with an accuracy improvement of 74.5%, 30.33%, and 14.1%, respectively. Compared with LibD, XtraLibD achieves a response time improvement of 61.37% and a storage reduction of 87.93% (99.85% over JIngredient). Our program artifacts are available at https://www.doi.org/10.5281/zenodo.5179747.KeywordsThird-party library detectionCode similarityParagraph vectorsSoftware bloatObfuscation

Human-centric Requirements Engineering for Artificial Intelligence Software Systems

Conference Paper

Sep 2021

Khlood Ahmad

Human-centric Software Engineering for Next Generation Cloud- and Edge-based Smart Living Applications

Conference Paper

May 2020

John Grundy

Humans are a key part of software development, including customers, designers, coders, testers and end users. In this keynote talk I explain why incorporating human-centric issues into software engineering for next-generation applications is critical. I use several examples from our recent and current work on handling human-centric issues when engineering various ‘smart living’ cloud- and edge-based software systems. This includes using human-centric, domain-specific visual models for non-technical experts to specify and generate data analysis applications; personality impact on aspects of software activities; incorporating end user emotions into software requirements engineering for smart homes; incorporating human usage patterns into emerging edge computing applications; visualising smart city-related data; reporting diverse software usability defects; and human-centric security and privacy requirements for smart living systems. I assess the usefulness of these approaches, highlight some outstanding research challenges, and briefly discuss our current work on new human-centric approaches to software engineering for smart living applications.

Adding Emotions to Models in a Viewpoint Modelling Framework From Agent-Oriented Software Engineering: A Case Study With Emergency Alarms

Chapter

May 2018

In modern software development, considering the viewpoints of stakeholders is an important step in building the right system. Over the past decade, several authors have proposed solutions to capture and model these viewpoints. While these solutions have been successful, emotions of stakeholders have been largely ignored. Considering the emotional needs of stakeholders is important because both the users ' perceptions of a product and their use of a product are influenced by emotion as much as cognition. Building on recent work in modelling the emotional goals of stakeholders, the authors extend an existing viewpoint framework to capture emotions, and to use emotions in models from early-phase requirements to detailed software design. They demonstrate the models and framework with a case study of an emergency alarm system for older people, presenting a complete set of models for the case study. The authors introduce recent experience in using emotional models in requirements elicitation within an agile process.

Designing an Evaluation Tool to Measure Emotional Goals

Chapter

Jan 2017

Human emotions have been widely researched in many disciplines such as psychology, philosophy, neuroscience and medicine. Their importance cannot be underestimated. Unfortunately, so far in software engineering, requirements engineers focus mostly on gathering functional and quality requirements and rarely consider how stakeholders feel or would like to feel when using a software product. Incorporating the user’s emotional goals in software engineering can be very challenging considering that emotions are very complex and subjective. Moreover, when it comes to incorporating user emotions in software engineering, existing methodologies or frameworks provide very little guidance to software professionals. In this paper, the authors present work on evaluating emotional goals in a software engineering context. The authors describe the development of a questionnaire as an evaluation tool and evaluate the questionnaire in the context of a digital photo frame placed in the homes of nine older persons living on their own. Further improvements to the tool are proposed based on the findings from the study.

Bringing Service Design Thinking into the Public Sector to Create Proactive and User-Friendly Public Services

Conference Paper

Full-text available

Jul 2016

Multiple stakeholders need to be taken into consideration when designing and implementing public sector services and processes. It will be asked in this article whether agent-oriented modeling could be beneficial to understand the interactions between these stakeholders and to support the design of proactive, user-friendly, and usable services of e-government. We propose a methodology for service design that can help to design better and more proactive services and hereby promote service design thinking in the public sector. For this on-going research, we take a look into how the family benefits service works in Estonia. To aid this task, structured interviews were conducted with the officials of the Social Insurance Board. The current article makes a contribution to a new way of approaching the design and development of public electronic services.

One size doesn't fit all: Diversifying "the user" using personas and emotional scenarios

Article

Full-text available

Nov 2014

It is common practice in software engineering to develop a product for the "user". The concepts of users and actors typically oversimplify the variety of people that could use a system in a given scenario. By developing the system for actors, many software engineers effectively develop the system for themselves, embodying the abstract actors with their own personalities - i.e. how would I use the system if I was this actor? A single perspective may be sufficient for situations with a well-defined workflow, however, many systems in the social and domestic domains should consider people's emotional response to systems, which impact product acceptance. To ensure that emotional desires are met and that a product appeals to the intended audience, we advocate the use of personas within emotional scenarios. Personas and scenarios can be used to explore the diversity of people's background, emotions and motivations, and how they would react emotionally to design decisions. We describe our experience using personas and emotional scenarios in three projects related to people's health, where emotions are ever present, in the domains of aged wellbeing and mental health.

Gift Giving: A Research Anthology

Article

Nov 1997

Qualitative research and evaluation methods. London: Sage Publications

Article

Jan 2001

M.Q. Patton

Don't Leave Me Untouched: Considering Emotions in Personal Alarm Use and Development

Chapter

Jan 2014

Older adults want to live independently in their home for as long as possible, and technologies can support them with this goal. However, solutions to help with living alone are often designed from a technical perspective, ignoring the needs and preferences of older adults. This results in strong attitudes and feelings against, and limited adoption of, these technologies. In this chapter, the authors use ethnographic methods to inform the development of solutions taking into account the emotional needs of end-users. They present a three-staged approach by applying it in the domain of personal emergency alarms. First, the authors identify the shortcomings of current emergency alarm systems as perceived by older adults. Then, they develop a prototype that addresses some of the issues identified, focusing on emotional needs. Finally, the authors conduct a trial with the prototype. The results show that considering emotions during system design can improve user experience.

The role of users’ emotions and associated quality goals on appropriation of systems: Two case studies

Article

Jan 2013

In this paper, we examine the role of peoples’ emotions or feelings about a system and the associated system qualities in encouraging adoption and effective use of systems. In two different contexts, we examine the use of a learning management system in an educational setting and a personal emergency alarm system in an aged care setting. This study reveals that technology appropriation – a term used to capture adoption and ongoing use, is driven by different emotions depending on whether users are in the adoption decision-making stage or during actual use. Findings from this study also suggest that social factors influence peoples’ emotions in the decision to adopt a system. However, as people use a system over time, it is the non-functional system qualities, based on personal experiences with the look, feel, functionality and features that trigger positive and negative emotional responses. Our findings therefore propose that these emotional responses should be considered during system design and implementation to encourage appropriation and avoid rejection of systems.

Support mechanisms for early, medium and longer-term use of technologies

Article

Jan 2010

In this paper we examine the support mechanisms that encourage and support early, medium and longer-term use of technologies. In two longitudinal studies, we examine use of a Learning Management System and the software application EndNote in an educational setting. Our findings suggest that providing classroom-based training for users may be a good mechanism encouraging adoption and early use. However, in the medium and longer-term, access to a variety of support mechanisms are necessary to encourage and support the appropriation process. Findings from these studies reveal that, in the medium and longer-term, localized oneon- one support, peer-support and availability of advanced training in the form of one-on-one contact with the trainer at critical time periods are key factors in encouraging productive use and avoiding rejection of the technology in the longer-term.

Advances in Conceptual Modeling - Foundations and Applications

Article

Jan 2007

Socially-Oriented Requirements Engineering: Software Engineering Meets Ethnography

Article

Oct 2014

We outline an approach for eliciting, understanding, and representing the cultural aspects of the domestic environment for the purpose of system design. We use agent models as shared artefacts to represent the everyday cultural life of the home. These representations build an understanding between the people that own this culture and the people responsible for technology development. We argue the necessity of knowing about a formal representation of these cultural aspects to inform design decisions and develop technologies that truly satisfy and support the everyday life of families. Our aim is to express socially-oriented requirements for technology. We show the usefulness of this approach on a case study that investigates interactions between grandparents and grandchildren who are geographically separated.

Agent-Based Modelling of Emotional Goals in Digital Media Design Projects

Article

Jan 2014

James Marshall

The authors promote agent-oriented models to identify, represent and evaluate high-level abstractions of digital media design projects. A major aspect is the introduction of emotional goals, in addition to functional goals and quality goals to describe feelings such as having fun, being engaged and feeling cared for. To establish emotional goals, digital media design methods and processes were employed including the development of emotional scripts, user profiles, mood boards and following an iterative participatory design process. This approach proved to be highly successful, not only to represent emotional goals such as fun, tension and empathy, but also to facilitate the ideation, creation and progressive evaluation of projects. The process supports communication between designers, developers and other stakeholders in large multidisciplinary development teams by providing a shared language and common artefact. The process is demonstrated in the development of a Multiplayer Online Role Play Game (MORPG) called Aspergion that promotes respect for people with Asperger's Syndrome.

Requirements Elicitation and Specification Using the Agent Paradigm: The Case Study of an Aircraft Turnaround Simulator

Article

Oct 2014

In this paper, we describe research results arising from a technology transfer exercise on agent-oriented requirements engineering with an industry partner. We introduce two improvements to the state-of-the-art in agent-oriented requirements engineering, designed to mitigate two problems experienced by ourselves and our industry partner: (1) the lack of systematic methods for agent-oriented requirements elicitation and modelling; and (2) the lack of prescribed deliverables in agent-oriented requirements engineering. We discuss the application of our new approach to an aircraft turnaround simulator built in conjunction with our industry partner, and show how agent-oriented models can be derived and used to construct a complete requirements package. We evaluate this by having three independent people design and implement prototypes of the aircraft turnaround simulator, and comparing the three prototypes. Our evaluation indicates that our approach is effective at delivering correct, complete, and consistent requirements that satisfy the stakeholders, and can be used in a repeatable manner to produce designs and implementations. We discuss lessons learnt from applying this approach.

Emotion-led modelling for people-oriented requirements engineering: The case study of emergency systems

Article

July 2015

Tim Miller · Sonja Pedell · Antonio A. Lopez-Lorca · Antonette Mendoza · Alen Keirnan

Emotion-led modelling for people-oriented requirements engineering: the case study of emergency systems

File (1)

Linked Research

Recommended publications

Software Environment for Queueing Network Modelling

Constraints Satisfaction through Recursive Neural Networks with Mixed Penalties: A Case Study

Development of reconfigurable parallel kinematic machines using modular design approach

Multi-objective modeling and optimization for cleaner production processes