Wearable technology and improved processing of streaming data have contributed to the advancement of the Internet of Things (IoT) and its applications such as smart living and working environments. The development of use-cases for such solutions continue to evolve and are supported by research into security, privacy and UX, which are all seen as central to developing appropriate and acceptable solutions. Development of IoT systems may also follow best-practice engineering principles (model-driven development and testing, formal methods etc.) to ensure they will meet all requirements and perform as expected in (often) uncontrolled environments. We argue, however, that there are two key concepts that are still overlooked. We de ne these as `Data Sovereignty Management' (DSM) and `Quality of Life' measurements (QoL). In this paper we present examples of how and why DSM and QoL should be considered central within the development of IoT systems, and propose that software engineering methods be extended to include these.
The increase in the availability of cheap, lightweight sensors and wearable
technology, alongside the development of smarter processing methods using edge and
fog computing, has helped to move Internet of Things (IoT) solutions into the
mainstream [
The development of such solutions leads to research questions based around
key considerations such as privacy and security of data collection [
There are, of course, other considerations which we need to take into account
when developing these `smart' environments. One of these is understanding the
e ect that living in a smart environment has on the people who inhabit them.
This is di erent from UX and usability considerations as it needs to take into
account the long-term e ects of reduced autonomy (due to being forced into a
routine that is deemed safe by the system) or constant monitoring in peoples'
everyday lives. While this may be studied as a part of traditional HCI
evaluation studies (e.g. [
Alongside these direct e ects of living in a smart environment there is also
the consideration of data, and more speci cally data ownership. IoT solutions
based around the monitoring of individuals or groups of inhabitants generate
large amounts of data which is both heterogenous and, in many cases, constantly
streaming (big data) much of which can be considered personal data. Initiatives
such as the EU General Data protection Regulation (GDPR) [
In this paper we contend that both the engineering principles we use to design and develop IoT systems and smart environments, as well as the evaluation and testing techniques we use to ensure they are usable and error-free, must be able to include these more detailed considerations of the e ect on a user's quality of life (QoL) as well as data sovereignty management (DSM) principles. We de ne QoL to include not just the everyday experience of using (or living within) the technologies, but the longer term implications on users' way of life from the use of technology in this way as well as the management and ownership of data collected by such technologies. DSM a ects the complete life-cycle of data from sensing, communication, pattern analysis to long-term storage and access.
We will argue in Section 3 that both software engineering methods and modeldriven development techniques are lacking consideration for user quality of life as well as data sovereignty management.
In order to demonstrate how these problems may manifest we provide two real-world examples of IoT solutions which highlight the issues identi ed, and then suggest an approach to begin to address this.
Since 2014 the Hakituri project1 has been investigating solutions based around
the use of wearable technology for workers in hazardous environments. The initial
aims of the project were to identify appropriate data that could be gathered
from workers in-situ that could be analysed and used to identify fatigue. This
was done with the goal of helping with accident prevention in high-risk work
environments, such as forestry [
In the initial stages of the project a wide variety of personal and contextual data types were considered and/or experimented with, for example: worker activity levels based on step counts, role, heart-rate, heart-rate variability (HRV); worker well-being based on hydration, sleep patterns; contextual factors such as ambient temperature; humidity; terrain type.
It was clear early on that while the workers who participated in our studies were keen to be involved in research that may have potentially life-saving bene ts, they were also uncomfortable with the nature of some of the data being collected and how it might be used. For example, if a wearable solution identies a worker as being fatigued and his boss is noti ed what is the result? Is the worker given time to rest before continuing with his work, or sent home for the rest of the day and not paid? These started to create ethical questions around the type of data collection we wanted to do which related to the intended use of the data vs. its actual use (worker safety vs. management tool). It also led us to reconsider the use of o -the-shelf wearable solutions due to lack of data ownership associated with such tools.
The issues around data collection in this project are further complicated by the fact that a large proportion of the workers in the target industry are Maori. This means that, as we collect large amounts of data (numerous workers on a daily basis), we are creating a large personal dataset, and therefore our DSM needs to include the principles of indigenous data sovereignty [11{13].
From these we identify our rst problem statement: How can we ensure that data collected in IoT solutions is always treated in accordance with the system requirements and the end-user wishes?
Our proposed solution to this is that data must be treated as a rst-class citizen in all parts of the development process. This means that at the requirements stage we must identify and describe all aspects relating to: what data is collected, how will it be used in all parts of the system, how/where is it stored, who owns the data, who has access to the data etc. Then as we begin to develop our system, we must continue to include DSM in whatever engineering process we follow. So if we are using a model-based development process the models must include the DSM and enable us to reason about it (e.g., to ensure the requirements are met) in the same way that we reason about functional behaviour and user interaction. Testing and evaluation methods must also be extended
to similarly include the DSM and ensure that the developed solution correctly manages the data in accordance with the requirements.
Including the data as a component in our software models will help to ensure that we can reason about it within our development process. However, we also need to consider DSM as a component with our human centred approaches. That is, not only do we need to nd ways of gathering requirements about the data from the stakeholders, but also ensure that our usability testing includes this aspect. For example, we must ensure that if the user requirements are that they should be able to specify di erent parts of the data and who has access to these (in our forestry context this may be the supervisors of work teams or family members who can see some, but not all, of the data) then we should provide usable methods for users to de ne this personalisation. DSM, therefore, includes both determining how the data should be managed as well as all aspects of controlling that management both within the system and by the users. 2.2
An increasingly common use-case proposed for smart-home environments is a
supportive environment for the elderly which enables them to continue to live in
their own home safely, see [
What is typically missing from explorations about how to satisfactorily develop such systems is an understanding of the impact on the quality of life of those who are living in the environment. In 2015 the Super ux lab created the \Uninvited Guests" short video2 for the ThingTank project3 which explored the tensions between embedded technology designed to assist an elderly man living alone and his desire for autonomy in his daily life. This has become part of an ongoing dialogue which seeks to understand the real implications and impacts of these smart environments on those who inhabit them. However, this has not yet translated into any systematic development and evaluation methods which allow us to understand such quality of life metrics during the development lifecycle.
While usability and UX can consider the user's interactions with the system, and to some extent how it makes them feel during that interaction, it does not capture the longer term implications of having technology incorporated into our
everyday lives. A small example of this can be seen in the way tness trackers
are use. A study by Endeavour Partners found that a third of U.S. consumers
who purchased a particular brand of tness tracker stopped using it entirely
within six months [
This leads to our second problem statement:
How can we measure the impact of IoT solutions on the quality of life of end
users to ensure that the solutions we propose and build are not just usable but
also acceptable?
This goes beyond traditional UX measures and requires us to nd tangible ways
of both measuring, and including the measurements of, QoL into all stages of a
development process. This requires the development of an evaluation framework
that can be used to predict the outcome of envisaged scenarios, as well as measure
them during traditional user evaluation. We also need to be able to measure
the potential impact of subversion (alongside traditional problems such as loss
of connectivity, data corruption etc.) that may occur with data collection to
understand the trustworthiness of the data before using it (e.g., following the
approach described in [
The QoL and DSM we have described are not distinct, but rather interconnected. If the users' quality of life is negatively a ected by living within a smart environment they may act to subvert the system or avoid using it, which then has an impact on the quality of data being collected and ultimately the utility of the system. Similarly if it is not transparent to users how their rights and interests in the collected data are being managed and protected this may directly a ect how they feel about the system and impact their quality of life.
If we consider state-of-the-art software engineering methods, and in particular model-driven development techniques, two dimensions are currently missing. The rst is a reliable method for measuring and evaluating quality of life impact (QoL), the second is a way of recording data management processes as a rst class citizen in the model-driven engineering process. While we recognise both of these concepts as important, the problem of developing engineering practices that address these concerns during development, testing and evaluation has not yet been addressed.
Furthermore, while IoT technology is often considered as if it were providing solitary solutions, most smart living environments will be a combination of technology solutions, thus further complicating issues of long term impact on QoL and increased complexity of DSM.
The answer to the discussed problems will be to ensure that both QoL metrics and DSM are included as rst-class citizens in robust software engineering processes. In this way they can be reasoned about along with all other parts of the systems being developed.