-Trust is the key concern that underpins social sustainability. In this paper we provide a brief overview of trust from a number of perspectives (from security to customer relationship management), and present our take on trust as an interaction-based phenomenon. Index Terms-trust, sustainability, trust requirements.
Klaus Pohl states that “Requirements engineering is the
process of eliciting individual stakeholder requirements and
needs and developing them into detailed, agreed requirements
documented and specified in such a way that they can serve
as the basis for all other system development activities” [
Sustainability is often defined as the state whereby the
humankind can “meet the needs of the present without
compromising the ability of future generations to satisfy their
own needs” [
In this work we focus on the social dimension of
sustainability, specifically on its trust requirements. As noted by R.
Goodland [
But what exactly is trust? And how does it lower transaction costs? And what requirements do we need to “elicit, document, and agree” so that the resultant software system promotes social sustainability through enhanced trust? These are the kinds of questions that we hope to address in our research. This paper provides the very brief summary of related work on trust (in Section 2), and an overview of our initial thoughts and research direction (in Section 3).
The topic of trust has been studied in many sciences and from many perspectives. We will discuss some of those that we consider relevant to our work below (though we note that other relevant areas, such as group and social psychology are missing here).
Many researchers have examined the notion of trust in
software systems as closely aligned with security or privacy.
Some have focused on security of the system as an artefact,
while others focus on the human aspects of security. For
instance Elahi [
Trust in (customer) relationship management can be divided into two categories: the initial trust and the ongoing trust.
Initial trust involves the willingness to trust the other
party without having a prior experience or knowledge of
its background [
Trust seems to play a crucial role in reducing users’
uncertainty. Damian-Reyes and colleagues suggest that it is one of
the factors that can affect user confidence in a software system
[
Li and colleagues [
Copyright © 2017 for the individual papers by the papers' authors. Copying permitted for private and academic purposes. This volume is published and copyrighted by its editors. or the technology did not substantially affect the trusting beliefs.
The factors that affect trust were studied specifically for the case of new software systems. The authors have grouped these factors into several “trust categories”, which include: • Personality-based trust; • Cognition-based trust (or reputation); • Institutional-based trust (structural assurance); • Information technology, which includes factors such as
security, privacy, and general online experiences; • Social factors, such as national culture; • Diffusion of innovation: as users initially receive some information about an innovation and its advantages and disadvantages, this forms their initial attitude toward the innovation and influences subsequent adoption decisions.
The specific mix and selection of the listed factors for each individual depends on their characteristics (e.g., no prior experience in IT systems for business), and context characteristics (e.g., national culture of the Jordanian context).
As outlined in the previous section, a number of interpretations and factors of trust have been investigated. The present work is focused on operationalising the notion of trust into software requirements in order to inform trusted software systems design. For this we first need to establish the scope of the notion of trust for this work. Drawing on the previous research we observe that: • Trust is a relationship. Although some key characteristics (such as security, an individual’s willingness and aptitude to trust, social conventions, etc.) are essential for the initiation of the relationship, it also requires interaction between the involved entities. • Trust is dynamic. As any relationship that involves humans, a trust relationship is subject to continuous change. The change is driven by feedback from the interaction whose results are evaluated by the participants and, where considered relevant, contribute to building up or eroding the relationship. • Trust is cumulative. While a single result from a specific interaction may not have substantial effect on the trust relationship, repeated similar results are likely to have a defined cumulative effect (e.g., if an employee is late for one of the meetings, (s)he is likely to be excused; but if (s)he is repeatedly late, (s)he is likely to gain an “always late” reputation).
Thus, we suggest that trust is a relationship which will change over time through the evaluation of relevant interactions by the participants in the relationship.
Given the above interpretation of trust, our work aims to (i) elicit (specific and measurable) requirements that enable trustworthy software systems engineering; and (ii) define a trust evaluation model for measuring the current trust level within the given software system and its dynamics.
For this, we must first account for the initial trust relationship between the software system (or system-to-be) and its stakeholders. This will serve as the starting point of the trust relationship. The dynamic model of the relationship evolution and evaluation will then build upon the initial trust.
In light of this, we will work on building a trust model that: 1) Starts from eliciting the end-user requirements which support the socio-technical interactions between users and the system. The first set of such requirements will address the most frequently repeated requirements/services that the users ask for, and that (as per related published work) is considered essential on establishing the trust relationship between the stakeholders and the system. 2) Study how the socio-technical interactions are affected by various environments (e.g., product markets); 3) Study how such interactions are affected by specific stakeholder requirements and constraints (e.g., posed by developers, or the business owners).
In conclusion we would like to underline that some may suggest that trust requirements (possibly implicitly) are already covered in traditional RE, as trust towards a system is gained if the system i) functions as expected, ii) is efficient, iii) is reliable, iv) is usable, and v) is safe and secure. Yet, the key distinction of this work from any previously published RE work on topics that relate to trust is that we underline the need for continuous evolution in a trust model and requirements. All previous work has formulated static requirements, which, though may relate to trust, do not reflect its’ dynamic nature.
This research is partially supported by the EPSRC HoSEM (EP/P031838/1) grant, as well as sponsorship awarded to Ms. Zieni. We also would like to personally thank Riman S. for her continuous moral support.