Towards Human-centric Model-driven Software Engineering

John Grundy

, Hourieh Khalajzadeh

and Jennifer Mcintosh

Faculty of Information Technology, Monash University, Clayton, Victoria, Australia

Keywords:

Model-driven Engineering, Human-centric Software Engineering, Human Factors.

Abstract:

Many current software systems suffer from a lack of consideration of the human differences between end

users. This includes age, gender, language, culture, emotions, personality, education, physical and mental

challenges, and so on. We describe our work looking to consider these characteristics by incorporation of

human centric-issues throughout the model-driven engineering process lifecycle. We propose the use of the

co-creational ”living lab” model to better collect human-centric issues in the software requirements. We

focus on modelling these human-centric factors using domain-speciﬁc visual languages, themselves human-

centric modelling artefacts. We describe work to incorporate these human-centric issues into model-driven

engineering design models, and to support both code generation and run-time adaptation to different user

human factors. We discuss continuous evaluation of such human-centric issues in the produced software and

feedback of user reported defects to requirements and model reﬁnement.

1 INTRODUCTION

Modern software systems are extremely complex,

currently hand-crafted artefacts, which leads them

to be extremely brittle and error prone in practice.

We continually hear about issues with security and

data breaches (due to poorly captured and imple-

mented policies and enforcement); massive cost over-

runs and project slippage (due to poor estimation

and badly captured software requirements); hard-to-

deploy, hard-to-maintain, slow, clunky and even dan-

gerous solutions (due to incorrect technology choice,

usage or deployment); and hard-to-use software that

does not meet the users’ needs and causing frustra-

tion (due to poor understanding of user needs and

poor design) (Curumsing et al., 2019; Prikladnicki

et al., 2013; Yusop et al., 2016). This leads to huge

economic cost, inefﬁciencies, not ﬁt-for-purpose so-

lutions, and dangerous and potentially lifethreatening

situations. Software is designed and built primarily to

solve human needs. Many of these problems can be

traced to a lack of understanding and incorporation

of human-centric issues during the software engineer-

ing process (Hartzel, 2003; Miller et al., 2015; Stock

et al., 2008; Wirtz et al., 2009; Smith, 1998).

https://orcid.org/0000-0003-4928-7076

https://orcid.org/0000-0001-9958-0102

https://orcid.org/0000-0002-6655-0940

2 MOTIVATING EXAMPLE

2.1 Smart Home

Consider a representative example - a ”smart home”

aimed at providing ageing people with technology-

based support for physical and mental challenges so

they are able to stay in their own home longer and

feel safe and secure (Curumsing et al., 2019; Grundy

et al., 2018). To develop a solution, the software

team must deeply understand technologies like sen-

sors, data capture and analysis, communication with

hospital systems, and software development methods

and tools. However, they must also deeply under-

stand and appreciate the human aspects of their stake-

holders: ageing people, their families and friends,

and clinicians/community workers. These include

the Technology Proﬁciency and Acceptance of age-

ing people – likely to be much older than the soft-

ware designers. The development of ”Smart homes”

technology should factor in the Emotional – both pos-

itive and negative – reactions to the smart home e.g.

daily interaction is potentially positive but being mon-

itored potentially negative. The Accessibility of the

solutions for people with e.g. physical tremors, poor

eyesight, wheel-chair bound, and cognitive decline.

Within this, personality differences may be very im-

portant e.g. those wanting ﬂexible dialogue compared

to those needing directive dialogue with the system.

Grundy, J., Khalajzadeh, H. and Mcintosh, J.

Towards Human-centric Model-driven Software Engineering.

DOI: 10.5220/0009806002290238

In Proceedings of the 15th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2020), pages 229-238

ISBN: 978-989-758-421-3

229

Figure 1: Incorporating ”Human-centric” software issues into Model-Driven Software Engineering.

The Usability of the software for a group of people

with varied needs e.g. incorporating the use of voice

or gestures or modiﬁed smart phone interface.

The ageing population is diverse and therefore

smart home technology must accommodate for the

different Ages, Genders, Cultures and Languages of

users including appropriate use of text, colours, sym-

bols. This is particularly important as one quarter of

the elderly in Australia are non-native English speak-

ers and the majority women, but by far the major-

ity of software developers are 20-something year old

English-speaking men. Within this, personality dif-

ferences may be very important e.g. those wanting

ﬂexible dialogue compared to those needing direc-

tive dialogue with the system. Failure to incorporate

human-centric issues into the development of Smart

Home software has the potential to result in a home

that is unsuitable for who it is designed to help, by in-

troducing confusing, possibly unsettling and invasive,

and even potentially dangerous technology.

2.2 Key Challenges

Current software engineering approaches ignore

many of these human-centric issues or address them

in piece-meal, ad-hoc ways (Prikladnicki et al., 2013;

Curumsing et al., 2019; Hartzel, 2003; Wirtz et al.,

2009; Ameller et al., 2010). For example, key aspects

of Model-Driven Software Engineering (MDSE) are

outlined in Figure 1. In MDSE, user requirements for

the software are captured and represented by a vari-

ety of abstract requirements models (a). These are

then reﬁned to detailed design models (b) to describe

the software solution. These design models are then

transformed by a set of generators into software code

However, currently almost no human-centric issues

are captured, reasoned about or used when produc-

ing or testing this software (Miller et al., 2015; Yusop

et al., 2016).

2.3 Generating More Human-centric

Software

We need to fully integrate these human-centric issues

into model-driven software development. In order to

do this, we aim to carry out the following steps:

1. Use a co-creational, agile Living Lab-based

approach, enabling software teams to capture

and reason about under-represented, under-used,

under-supported yet critical human-centric re-

quirements of target software;

2. Develop a new set of human-centric requirements

modelling languages, enabling software engineers

to effectively model diverse human-centric is-

sues, along with new approaches for obtaining and

extracting such human-centric software require-

ments from a wide variety of sources e.g. Word,

PDF, natural language, videos, sketches,...;

3. Augment conventional model-driven engineering

design models with human-centric requirements

for use during MDSE, along with techniques to

verify the completeness, correctness and consis-

tency of these models, and proactively check them

against best practice models and principles;

4. Develop new techniques to incorporate these

human-centric issues in design models into

MDSE-based software code generators, enabling

target software to dynamically adapt to differing

user needs at run-time; and

5. Use these human-centric requirements dur-

ing software testing to support human-centric

requirements-based testing of software systems,

along with techniques to receive feedback from

users on human factors-related defects in their

software solutions.

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

230

Figure 2: A clinician-oriented Domain-speciﬁc Visual Language for care plan modelling and using Model-driven Engineering

to generate an eHealth app.

3 BACKGROUND

Model-Driven Software Engineering (MDSE) cap-

tures high-level models about software requirements

i.e. what users need their software to do. MDSE then

reﬁnes these models to detailed designs about how

the software solution is organised, composed and its

appearance. Model transformation then turns these

models into software code. This is in contrast with

most current software development methods which

use informal and imprecise models, hand-translation

into code via error-prone, and time-consuming low-

level hand-coding. Advantages of MDSE-based ap-

proaches include capture of formal models of a soft-

ware system at high levels of abstraction, being able

to formally reason about these high-level models and

more quickly locate errors, and being able to generate

lower-level software artefacts, such as code, without

overheads and errors of traditional hand-translating

informal models.

However, most MSDE approaches use generic re-

quirements and design languages e.g. the Uniﬁed

Modelling Language (UML) and extensions (Fon-

toura et al., 2000; Kent, 2002). These have the dis-

advantages of being overly complex and very difﬁcult

to use by non-software engineering domain experts

(Hutchinson et al., 2011). Domain-speciﬁc Visual

Languages (DSVLs) provide a more accessible ap-

proach to presenting complex models for domain ex-

perts (Sprinkle and Karsai, 2004). DSVLs use one or

more visual metaphors, typically derived from the do-

main experts, to represent the model(s). They enable

domain experts to understand and even create and

use the models directly, rather than rely on software

engineers. These DSVLs are then used to generate

software code and conﬁguration artefacts to realise

a software solution via MDSE approaches. This ap-

proach provides higher abstractions and productivity,

improves target software quality, provides for repeata-

bility, and supports systematic reuse of best practices

(Sprinkle and Karsai, 2004; Hutchinson et al., 2011;

Kent, 2002; Schmidt, 2006).

There are many DSVLs for MDSE tools (Sprinkle

and Karsai, 2004; Li et al., 2014; Ali et al., 2013).

A representative example is shown in Figure 2: (a) a

custom DSVL designed for clinicians is being used to

model a new patient care plan for diabetes and obe-

sity management. Then (b) a model transformer takes

the care plan and generates a mobile app to assist

the patient to implement their plan (Khambati et al.,

2008). This is a major improvement on developing

software using conventional techniques. However, the

approach fails to model or incorporate into the mobile

app a range of critical human-centric issues, result-

ing in its failure in practice. Patient-speciﬁc, human-

centric needs are not captured e.g. technology accep-

tance and emotional reactions e.g. some patients react

negatively to the remote monitoring approach used.

Some users are not English speakers. Colours and

care plan model language used in the app are confus-

ing for many older users. Users with eye-sight limi-

tations ﬁnd the app too hard to see and too ﬁddly to

interact with. The app can not adapt to different con-

texts of use or preferences of the users e.g. it can not

Towards Human-centric Model-driven Software Engineering

231

use their smart home sensors or each patient’s particu-

lar mobile app dialogue preferences. The app displays

Euro-centric terminology about well-being, therefore,

putting off some users from following their care plan.

We need to incorporate these human-centric issues

into MDE (Ameller et al., 2010).

There has been recent interest in the human-

centric issues of complex software and how to bet-

ter support these during software development. Agile

methods, design thinking and living lab approaches

all try and incorporate a human element both in elicit-

ing software requirements and in involving end users

of software in the development process (Dyb

a and

Dingsøyr, 2008; Hyysalo and Hakkarainen, 2014;

Mummah et al., 2016). However, none capture

human-centric issues in any systematic way and

therefore the software fails to address several critical

aspects of the human users. Some new approaches

have tried to capture limited human-centric software

issues. Emotional aspects of software usage include

identifying the emotional reactions of users e.g. when

engaging with health and ﬁtness apps or for gaming.

Work has been done modelling these Emotional Re-

quirements and applying them to challenging eHealth

domains (Miller et al., 2015; Curumsing et al., 2019).

Figure 3 shows a representative example using an

emotion-oriented requirements DSVL to design bet-

ter smart homes (Grundy et al., 2018). Here a con-

ventional goal-based DSVL (1) has been augmented

with a set of ”emotional goal” elements (2) speciﬁc

to different users (3). Human characteristics like age,

gender, culture and language can dramatically impact

aspects of software, especially in the user interface

presented by the software and the dialogue had with

the user (Hartzel, 2003; Stock et al., 2008; Wirtz

et al., 2009). Limited support for the capture of some

of these has been developed. Another example is

a multi-lingual requirements tool providing require-

ments modelling in English and Bahasa Malaysia, in-

cluding supporting linguistic and some cultural differ-

ences between users (Kamalrudin et al., 2017).

Usability and usability testing has long been stud-

ied in Human Computer Interaction (HCI) research

and practice. However, usability defect reporting is

very under-researched in the context of software en-

gineering (Yusop et al., 2016). Similarly, a lot of

work has been done on accessibility in HCI e.g. sight,

hearing or cognitively impaired (Stock et al., 2008;

Wirtz et al., 2009), and health IT e.g. mental health

challenges when using mobile apps (Donker et al.,

2013). However, little has been done to evaluate the

extent to which physical and mental challenges are

properly addressed in engineering software develop-

ment, and is also poorly supported in practice. Per-

sonality, team climate and organisational issues relat-

ing to people have been heavily researched in Man-

agement, Information Systems, and the personality

of programmers and testers in software development

(Pikkarainen et al., 2008; Soomro et al., 2016). How-

ever, little attention has been paid to how to go about

supporting differing personality, team climate or or-

ganisational or user culture in software, nor to capture

requirements relating to these human-centric issues.

Traditional software requirements and design models

have very limited (or no) ability to capture these sorts

of human-centric software issues, and approaches are

ad-hoc, inconsistent, and incomplete.

There are no modelling principles, DSVL-based

model design principles, nor widely applicable, prac-

tical modelling tools to capture human-centric soft-

ware issues at requirements or design levels. While

a DSVL provides a more human-centric engineer-

ing approach, it fails to capture and support the key

human-centric issues in the target software itself.

Current MDSE tools, while providing signiﬁcant soft-

ware engineering beneﬁts do not support modelling

and using these critical human-centric issues. Cur-

rent software engineering processes lack consistent,

coherent ways to address these increasingly important

human-centric software issues and thus they are often

very incompletely supported or in fact are usually ig-

nored.

4 APPROACH

We aim to employ several innovative approaches

to (i) systematically capture and model a wide

range of human-centric software requirements and

develop a novel integrated taxonomy and formal

model for these; (ii) promote a wide range of

human-centric requirements for ﬁrst-class considera-

tion during software engineering by applying princi-

ples for modelling and reasoning about these human-

centric requirements using DSVLs; (iii) support a

wide range human-centric requirements in model-

driven engineering during software generation and

run-time reconﬁguration via MDSE techniques; and

(iv) systematically use human-centric requirements

for requirements-based software testing and reporting

human-centric software defects. This will improve

model-driven software engineering by placing cru-

cially important, but to date often forgotten, human-

centric aspects of software as ﬁrst-class considera-

tions in model-driven software engineering. The crit-

ical importance of this is really only just becoming

recognised, due to the increasing breadth of uses of IT

in society and the increasing recognition that under-

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

232

Figure 3: A Human-centric, Emotion-oriented Domain-speciﬁc Visual Language.

standing and incorporating the very diverse needs of

our very diverse software end users is essential. Key

features of this approach include:

• Use of the Living Lab concept’s design think-

ing, agile, co-creation and continuous feedback

mechanisms. These will be used to provide a

MDSE approach in which human-centric require-

ments can be effectively and efﬁciently captured,

treated as priorities by the software team, users

can quickly report defective software violating

these human-centric requirements, and the soft-

ware team can work effectively with these end

users to co-design changes.

• A set of principles for domain-speciﬁc visual

modelling languages will be developed that en-

able software engineers to capture a wide range

of human-centric aspects of software: including

user’s age, gender, cultural preferences, language

needs, emotional needs, personality and cognitive

characteristics, and accessibility constraints, both

physical and mental. These and other human end

user characteristics are essential to prioritise dur-

ing both software development and software de-

ployment to ensure a useful and usable end prod-

uct results for a broad range of end users.

• These principles will be used to design a range

of novel DSVLs that fully support the capture of

many of the important human-centric aspects and

model them as the critical requirements issues that

they are.

• Augmented models that ensure these modelled

human-centric properties are preserved for use at

design-time to ensure that MDSE-based solutions

take them into account appropriately when gener-

ating software applications.

• We will develop a new framework for human-

centric, requirements-based testing of software

that can verify whether the constructed software

systems meet these critical human-centric require-

ments.

Figure 4: Overall approach.

5 RESEARCH ACTIVITIES

Figure 4 illustrates the new human-centric, model-

driven software engineering approach we aim to pro-

duce. We have identiﬁed a set of key approaches

that are needed to achieve this vision. An Agile Liv-

ing Lab approach will be used to colocate the soft-

ware team and target end users (Grundy et al., 2018).

This will provide a co-creational environment to elicit

human-centric requirements, model and capture with

Towards Human-centric Model-driven Software Engineering

233

human-centric DSVLs, and receive continuous feed-

back from users.

A set of DSVL tools will be used to capture and

model the human-centric requirements, validate them

against design principles and best practice modelling

patterns, and translate them to extended design-level

models. A set of MDSE generators will generate soft-

ware applications – code, conﬁgurations, etc. Unlike

existing generators, these will take into account vari-

ations of end-users as speciﬁed in the human-centric

requirements, producing either multiple versions of

the target software applications and/or reconﬁgurable

applications that adapt to each end user’s differing

human-centric needs.

A combination of human-centric requirements

testing and continuous defect feedback will be fed

to the development team. By leveraging the Living

Lab concept, this will enable both faster feedback

and defect correction, but also better evolution and

modelling of the human-centric requirements over

time. Lessons will be fed into the improvement of the

DSVL tools, best practice patterns and MDSE gener-

ators. We have identiﬁed a set of necessary research

activities to achieve this outcome, summarised below.

5.1 A Human-centric Agile Living Lab

Human-centric requirements have to be elicited from

target end users (or stakeholders), captured (or mod-

elled) using our DVSL-based tools, used by extended

MDSE solutions to generate software, and then the

software tested and user feedback accepted and ac-

tioned to correct requirements and design model prob-

lems.

A new approach is needed to effectively support

the software team in achieving this, and propose in-

vestigating the Living Lab co-creation concept that

has become popular in digital health software devel-

opment (Hyysalo and Hakkarainen, 2014; Grundy

et al., 2018). We are establishing this lab with a

domain-speciﬁc focus with partner companies and

target end users and the software team co-located

as in Agile customer-in-team approaches (Dyb

a and

Dingsøyr, 2008; Pikkarainen et al., 2008). Target end

users and developers closely collaborate to elicit, cap-

ture, test, use and reﬁne the human-centric software

requirements. The DSVL modelling tools, MDSE

generators and testing tools all need to support col-

laborative capture, discussion and reﬁnement of the

human-centric requirements for this to be most ef-

fective. We plan to do this by extending our cur-

rent work on developing digital health technologies

(Grundy et al., 2018), human-centric software engi-

neering processes in software teams, including per-

sonality and team climate (Salleh et al., 2018), and

collaborative DSVL-based modelling tools (Grundy

et al., 2013).

To the best of our knowledge, no taxonomy of

human-centric software requirements or even infor-

mal deﬁnition exists at this time. We are working on

developing a new, rich taxonomy of human-centric re-

quirements for software systems. The taxonomy will

include different human-centric concepts relating to

computer software, and will draw on other disciplines

including HCI, usability, psychology, and others to

build the conceptual model, and provide detailed re-

lationships and trade-offs between different human-

centric requirements.

We are applying this to a number of represen-

tative requirements examples to test and reﬁne it,

and use the outcomes to inform the development of

DSVLs, DSVL tools and MDSE solutions in other

activities. This is critical research as it will provide

software engineers a set of principles and concep-

tual model to model and reason about these kinds of

requirements. We are conducting a detailed analy-

sis of several representative real-world software ap-

plications from eHealth apps, smart homes, commu-

nity service apps, educational apps, and other heavily

human-centric requirements critical domains.

From these we are developing a framework and

model for prioritising human-centric software issues.

This will characterise complex trade-offs and other

relationships between different human-centric issues

that make supporting one issue problematic for other

issues, similar to the Cognitive Dimensions frame-

work (Green and Petre, 1996). We will use focus

groups with end users and developers to reﬁne and

validate our taxonomy. The taxonomy will be tested

on real-world example requirements to gain feedback

from both developers and end users to demonstrate its

effectiveness. We are drawing on our extensive pre-

vious work developing taxonomies for design critics

(Ali et al., 2013), emotion-oriented requirements (Cu-

rumsing et al., 2019), usability defects (Yusop et al.,

2016), and team climate (Soomro et al., 2016).

5.2 Human-centric Requirements

Engineering

While DSVLs have been an active research area for

at least 20 years, remarkably few principles exist for

design and evaluation of effective DSVLs (Moody,

2009). We are developing a set of new design prin-

ciples and associated DSVL evaluation approaches

to provide more rigorous principles and design steps

for speciﬁcally human-centric DSVL development.

This will require us to identify for the range of a

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

234

human-centric software requirements and design is-

sues identiﬁed in the taxonomy built, how we can

model these, use appropriate visual metaphors to rep-

resent the models, how we can support interaction

with the visual models, and how we can reason about

the suitability of these visual models in terms of us-

ability and effectiveness. We are drawing upon the

work on DSVL design tools to achieve this (Grundy

et al., 2013; Li et al., 2014; Ali et al., 2013), as well

as work on ’Physics’ of Notations (Moody, 2009) and

Cognitive Dimensions (Green and Petre, 1996) to de-

velop these DSVL design principles for modelling

human-centric software issues.

We are developing a range of new and augmented

DSVLs to model a wide variety of human-centric is-

sues at the requirements level for software systems.

Some of these DSVLs extend existing requirements

modelling languages – in successively more princi-

pled ways than currently – e.g. goal-directed re-

quirements languages such as i*, use cases and es-

sential use cases, target user personas, user stories,

etc. However, others may provide wholly novel re-

quirements modelling techniques and diagrams that

are then linked to other requirements models. We

envisage novel requirements capture for things like

identifying cultural, age, accessibility and personal-

ity aspects of target end users. Where multiple target

end users for the same software application have dif-

fering human-centric requirements, multiple or com-

posite models may be necessary. We are building

on a wide range of DSVLs, including for design

tools, requirements, reporting, business processes,

surveys, performance testing, and many others (Ali

et al., 2013; Grundy et al., 2013; Kamalrudin et al.,

2017) as well as digital health software (Grundy et al.,

2018) and work on modelling usability defects and

emotional and multi-lingual requirements (Curums-

ing et al., 2019).

Software requirements need to be elicited from

end users and these are typically held in a variety

of documents and can be obtained in a variety of

ways. We will work - in the context of the Living

Lab - to develop new tools to extract human-centric

requirements from diverse sources, including Power-

point, Word, Excel, PDF, audio transcripts, images

and video. A number of works have addressed differ-

ent parts of this problem, including extracting require-

ments using light weight and heavy weight natural

language processing (Ali et al., 2010; Lee and Xue,

1999). However, none have speciﬁcally addressed

the extraction of a wide range of human-centric re-

quirements. We will develop, trial and reﬁne a set

of extraction tools leveraging existing approaches but

focused on human-centric requirements capture and

representation using our DSVLs, within our living lab

approach, and leveraging our human-centric require-

ments taxonomy. These tools will also be reﬁned as

these other related activities are reﬁned and extended,

and applying these tools to representative real-world

requirements artefacts will help us to test and ex-

tend the outputs of these other tasks. We will de-

velop leading-edge tools for extracting requirements

for goal-directed and multi-lingual models (Lee and

Xue, 1999; Kamalrudin et al., 2017), and require-

ments checking and improvement (Ali et al., 2010).

5.3 Using Human-centric Issues in

Model Driven Engineering

MDSE tools typically use Uniﬁed Modelling Lan-

guage (UML) or similar design models. Even those

using their own design models need to reﬁne higher-

level abstract requirements models into lower-level

architectural, software design, interface, database and

other models. We will explore different ways to ef-

fectively extend design-level models to capture nec-

essary design-level human-centric properties, derived

from higher level human-centric requirements-level

properties (Ameller et al., 2010). For example, we

want to capture design alternatives to achieve an ap-

plication user interface for a target end user who has

sight-impairment, prefers a gesture-based sensor in-

terface to using a Smart phone, has limited mobility,

and is quite ”neurotic” about device feedback.

We will evaluate the different modelling solutions

via our living lab with both software engineers and

end users, in terms of needed design information and

preserving critical human-centred end user needs re-

spectively. Even partial successful outcomes here will

be immediately of interest and applicable for software

teams. We will extend design models with aspects

(Mouheb et al., 2009), goal-use case model integra-

tion (Lee and Xue, 1999), and goal-models extended

with emotions (Curumsing et al., 2019; Grundy et al.,

2018). Just because we add human-centric issues to

our requirements and design models does not mean

they may be correct or even appropriate. We will de-

velop a set of proactive tool support systems to ad-

vise software engineers of errors or potentially incor-

rect/unintended issues with their models (Ali et al.,

2013; Robbins and Redmiles, 1998). This will en-

able the DSVL toolsets for human-centric require-

ments and design models to provide proactive feed-

back to modellers. To enable these design critics

we will develop a range of ”human-centric require-

ments and design patterns”. These will provide best-

practice approaches to modelling complex require-

ments and design models mixed with human-centric

Towards Human-centric Model-driven Software Engineering

235

issues. These features will be added to successive

iterations of our prototype tools from above. This

work will build on our approaches to develop DSVL

design critics (Ali et al., 2013) and DSVL-based re-

quirements and design pattern modelling tools (Ka-

malrudin et al., 2011).

Once we have some quality design-level human-

centric issues in models (incremental outcomes from

the above activities), we can use these in model-

driven engineering code and conﬁguration generators.

Results from this work will be fed back to extending

the taxonomy and human-centric design principles.

This will involve adding generators that consume

design level models augmented with human-centric

properties and synthesizing software applications that

use these appropriately. For example, we might gen-

erate a gesture-based, passive-voice feedback solution

for the target user from the example above. How-

ever, we might instead generate several interfaces for

the same software feature, and at run-time conﬁgure

the software either with pre-deployment knowledge,

end user input, or even modify it while in use based

on end user feedback. Thus for example a part of

the software for our smart home example could adapt

to different end users’ current and changing needs

(e.g. age, culture, emerging physical and mental chal-

lenges, personality etc).

This work will be done incrementally, focusing on

single issues ﬁrst then looking at successively more

complex combinations, adding support to the proto-

type tools and repeatedly trialling the tools. We will

work on adding human-centric issues to MDSE code

generators (Ameller et al., 2010), generating adap-

tive user interfaces (Lavie and Meyer, 2010), adaptive

run-time software (Mohamed Almorsy, 2014), and

DSVL-based MDSE solutions (Sprinkle and Karsai,

2004).

5.4 Using Human-centric Requirements

in Testing, Defect Reporting and

Continuous Feedback

Here we will address critically important issues of

(i) testing whether the resultant software generated

from our augmented MDSE actually meets the re-

quirements speciﬁed; (ii) providing a feedback mech-

anism for end users to report defects in the software

speciﬁcally relating to human-centric issues; and (iii)

providing a feedback mechanism from software de-

velopers to users about changes made relating to their

personal human-centric issues. We are developing

a human-centric requirements-based testing frame-

work, techniques and tools. These enable human-

centric issues to be used in acceptance tests to im-

prove validation of software against these require-

ments. We will also develop new human-centric de-

fect reporting mechanisms and developer review and

notiﬁcation mechanisms. These will support continu-

ous defect reporting, correction, and feedback via the

living lab and remotely. Even partial outcomes would

be of immediate beneﬁt to the software engineering

research and practice communities. This work is ex-

tending research on software tester practices and us-

ability defect reporting (Yusop et al., 2016; Garousi

and Zhi, 2013) and requirements-based testing (Ka-

malrudin et al., 2017).

5.5 Trials on Industry-scale Examples

We will trial our approach with real industry practi-

tioners and organisations for whom human-centric is-

sues are critical. Our approach is particularly suit-

able on applications with end users with challeng-

ing human-centric issues, such as physical or men-

tal disability, English as second language, cognitive

decline, very young or old, and needing software to

adapt to their changing personal or contextual usage

needs. Planned target application domains include

digital health apps for community members, commu-

nity educational apps, government service and trans-

port apps and websites, and smart home and smart

building management software.

6 CONCLUSION AND

PERSPECTIVES

We have proposed a new approach to incorporating

and supporting a wide range of human-centric issues

into model-driven software development. We are set-

ting up a co-creational, agile living lab in which to

collaborative elicit user requirements, capture in aug-

mented models, generate multiple solutions, and en-

able requirements-based testing and feedback. We are

developing a new taxonomy of human-centric issues

and then incorporating these into requirements and

design modelling languages and tools. We are using

these augmented models in model-driven engineering

to generate multiple versions of software to support

diverse end user needs, or support run-time adaptation

of the generated code to these needs. We are support-

ing iterative user feedback to proactively incorporate

human-centric issues into models and re-generating

and re-deploying solutions.

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

236

ACKNOWLEDGEMENTS

Support from ARC Discovery Project DP170101932

and ARC Laureate Program FL190100035 is grate-

fully acknowledged.

REFERENCES

Ali, N. M., Hosking, J., and Grundy, J. (2013). A tax-

onomy and mapping of computer-based critiquing

tools. IEEE Transactions on Software Engineering,

39(11):1494–1520.

Ali, R., Dalpiaz, F., and Giorgini, P. (2010). A goal-based

framework for contextual requirements modeling and

analysis. Requirements Engineering, 15(4):439–458.

Ameller, D., Franch, X., and Cabot, J. (2010). Dealing with

non-functional requirements in model-driven develop-

ment. In 2010 18th IEEE international requirements

engineering conference, pages 189–198. IEEE.

Curumsing, M. K., Fernando, N., Abdelrazek, M., Vasa,

R., Mouzakis, K., and Grundy, J. (2019). Emotion-

oriented requirements engineering: A case study in

developing a smart home system for the elderly. Jour-

nal of Systems and Software, 147:215 – 229.

Donker, T., Petrie, K., Proudfoot, J., Clarke, J., Birch, M.,

and Christensen, H. (2013). Smartphones for smarter

delivery of mental health programs: a systematic re-

view. J Med Internet Res, 15(11).

Dyb

a, T. and Dingsøyr, T. (2008). Empirical studies of agile

software development: A systematic review. Informa-

tion and Software Technology, 50(9):833 – 859.

Fontoura, M., Pree, W., and Rumpe, B. (2000). The Uml

Proﬁle for Framework Architectures. Addison-Wesley

Longman Publishing Co., Inc., USA.

Garousi, V. and Zhi, J. (2013). A survey of software testing

practices in canada. Journal of Systems and Software,

86(5):1354–1376.

Green, T. R. G. and Petre, M. (1996). Usability analysis

of visual programming environments: a ’cognitive di-

mensions’ framework. Journal of Visual Languages

& Computing, 7(2):131–174.

Grundy, J., Mouzakis, K., Vasa, R., Cain, A., Curumsing,

M., Abdelrazek, M., and Fernando, N. (2018). Sup-

porting diverse challenges of ageing with digital en-

hanced living solutions. In Global Telehealth Confer-

ence 2017, pages 75–90. IOS Press.

Grundy, J. C., Hosking, J., Li, K. N., Ali, N. M., Huh,

J., and Li, R. L. (2013). Generating domain-speciﬁc

visual language tools from abstract visual speciﬁca-

tions. IEEE Transactions on Software Engineering,

39(4):487–515.

Hartzel, K. (2003). How self-efﬁcacy and gender issues

affect software adoption and use. Communications of

the ACM, 46(9):167–171.

Hutchinson, J., Whittle, J., Rounceﬁeld, M., and Kristof-

fersen, S. (2011). Empirical assessment of mde in in-

dustry. In Proceedings of the 33rd international con-

ference on software engineering, pages 471–480.

Hyysalo, S. and Hakkarainen, L. (2014). What difference

does a living lab make? comparing two health tech-

nology innovation projects. CoDesign, 10(3-4):191–

208.

Kamalrudin, M., Hosking, J., and Grundy, J. (2011). Im-

proving requirements quality using essential use case

interaction patterns. In 2011 33rd International Con-

ference on Software Engineering (ICSE), pages 531–

540. IEEE.

Kamalrudin, M., Hosking, J., and Grundy, J. (2017). Mara-

maaic: tool support for consistency management and

validation of requirements. Automated software engi-

neering, 24(1):1–45.

Kent, S. (2002). Model driven engineering. In Inter-

national Conference on Integrated Formal Methods,

pages 286–298. Springer.

Khambati, A., Grundy, J., Warren, J., and Hosking, J.

(2008). Model-driven development of mobile personal

health care applications. In 2008 23rd IEEE/ACM In-

ternational Conference on Automated Software Engi-

neering, pages 467–470. IEEE.

Lavie, T. and Meyer, J. (2010). Beneﬁts and costs of adap-

tive user interfaces. International Journal of Human-

Computer Studies, 68(8):508–524.

Lee, J. and Xue, N.-L. (1999). Analyzing user requirements

by use cases: A goal-driven approach. IEEE software,

16(4):92–101.

Li, L., Grundy, J., and Hosking, J. (2014). A visual lan-

guage and environment for enterprise system mod-

elling and automation. Journal of Visual Languages

& Computing, 25(4):253–277.

Miller, T., Pedell, S., Lopez-Lorca, A. A., Mendoza, A.,

Sterling, L., and Keirnan, A. (2015). Emotion-led

modelling for people-oriented requirements engineer-

ing: the case study of emergency systems. Journal of

Systems and Software, 105:54–71.

Mohamed Almorsy, John Grundy, A. S. I. (2014). Adapt-

able, model-driven security engineering for saas

cloud-based applications. Automated software engi-

neering, 21(2):187–224.

Moody, D. (2009). The ”physics” of notations: toward a sci-

entiﬁc basis for constructing visual notations in soft-

ware engineering. IEEE Transactions on software en-

gineering, 35(6):756–779.

Mouheb, D., Talhi, C., Lima, V., Debbabi, M., Wang, L.,

and Pourzandi, M. (2009). Weaving security aspects

into uml 2.0 design models. In Proceedings of the 13th

workshop on Aspect-oriented modeling, pages 7–12.

Mummah, S. A., Robinson, T. N., King, A. C., Gardner,

C. D., and Sutton, S. (2016). Ideas (integrate, de-

sign, assess, and share): a framework and toolkit of

strategies for the development of more effective digi-

tal interventions to change health behavior. Journal of

medical Internet research, 18(12):e317.

Pikkarainen, M., Haikara, J., Salo, O., Abrahamsson, P.,

and Still, J. (2008). The impact of agile practices on

communication in software development. Empirical

Software Engineering, 13(3):303–337.

Prikladnicki, R., Dittrich, Y., Sharp, H., De Souza, C.,

Cataldo, M., and Hoda, R. (2013). Cooperative and

Towards Human-centric Model-driven Software Engineering

237

human aspects of software engineering: Chase 2013.

SIGSOFT Softw. Eng. Notes, 38(5):34–37.

Robbins, J. E. and Redmiles, D. F. (1998). Software

architecture critics in the argo design environment.

Knowledge-Based Systems, 11(1):47–60.

Salleh, N., Hoda, R., Su, M. T., Kanij, T., and Grundy,

J. (2018). Recruitment, engagement and feedback

in empirical software engineering studies in indus-

trial contexts. Information and software technology,

98:161–172.

Schmidt, D. C. (2006). Model-driven engineer-

ing. COMPUTER-IEEE COMPUTER SOCIETY-,

39(2):25.

Smith, J. (1998). The Book. The publishing company, Lon-

don, 2nd edition.

Soomro, A. B., Salleh, N., Mendes, E., Grundy, J., Burch,

G., and Nordin, A. (2016). The effect of software en-

gineers’ personality traits on team climate and perfor-

mance: A systematic literature review. Information

and Software Technology, 73:52–65.

Sprinkle, J. and Karsai, G. (2004). A domain-speciﬁc vi-

sual language for domain model evolution. Journal of

Visual Languages & Computing, 15(3-4):291–307.

Stock, S. E., Davies, D. K., Wehmeyer, M. L., and Palmer,

S. B. (2008). Evaluation of cognitively accessi-

ble software to increase independent access to cell-

phone technology for people with intellectual dis-

ability. Journal of Intellectual Disability Research,

52(12):1155–1164.

Wirtz, S., Jakobs, E.-M., and Zieﬂe, M. (2009). Age-

speciﬁc usability issues of software interfaces. In Pro-

ceedings of the IEA, volume 17.

Yusop, N. S. M., Grundy, J., and Vasa, R. (2016). Re-

porting usability defects: A systematic literature re-

view. IEEE Transactions on Software Engineering,

43(9):848–867.

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

238