=Paper=
{{Paper
|id=None
|storemode=property
|title=Intangible Trust Requirements - How to Fill the Requirements Trust “Gap”?
|pdfUrl=https://ceur-ws.org/Vol-656/paper3.pdf
|volume=Vol-656
|dblpUrl=https://dblp.org/rec/conf/iused/FrenchH10
}}
==Intangible Trust Requirements - How to Fill the Requirements Trust “Gap”?==
https://ceur-ws.org/Vol-656/paper3.pdf
Intangible Trust Requirements - How to Fill the
Requirements Trust "Gap"?
Tim French Wei Huang
Department of Computer Science & Technology Department of Computer Science & Technology
University of Bedfordshire University of Bedfordshire
Park Square Campus, Luton LU1 3JU, UK. Park Square Campus, Luton LU1 3JU, UK.
Tim.french@beds.ac.uk Wei.Huang@beds.ac.uk
ABSTRACT Finally, the strength of Va- is greater than the strength of
Previous research efforts have been expended in terms of Va+. Essentially, his view of trust is of a trust relationship
the capture and subsequent instantiation of "soft" trust in which events are linked to other events, each of which
requirements that relate to HCI usability concerns or in has beneficial or non-beneficial paths. For a trust
relation to "hard" tangible security requirements that relationship to occur, the harmful path is more significant
primarily relate to security assurance and security protocols. than the beneficial path. Risk is an essential property of the
Little direct focus has been paid to managing intangible environment within which a choice of paths occurs.
trust related requirements per se. This 'gap' is perhaps most
evident in the public B2C (Business to Consumer) E- The notion that trust building between individuals takes
Systems we all use on a daily basis. Some speculative place within information spaces that are both potentially
suggestions are made as to how to fill the 'gap'. Visual card risky to the participants and where incomplete information
sorting is suggested as a suitable evaluative tool; whilst is available to the human actors has been widely accepted
deontic logic trust norms and UML extended notation are and developed by many subsequent researchers [4]. Within
the suggested (methodologically invariant) means by which this information space the notion of expectation is central to
software development teams can perhaps more fully capture many writers. For example, Gambetta [5] provides us with
hence visualize intangible trust requirements. a rich and potentially computationally useful definition that
encapsulates the notion of trust as expectation: ‘Trust (or
Author Keywords symmetrically, distrust) is a particular level of subjective
Intangible trust requirements; visual card-sorts; deontic probability with which an agent assesses that another agent
norms; or group of agents will perform a particular action, both
before he can monitor such action (or independently or his
ACM Classification Keywords capacity ever to be able to monitor it) and in a context in
H5.m. Information interfaces and presentation (e.g., HCI): which it affects his own action’. This idea of trust as an
Miscellaneous. expectation (either rational or affective or a mixture of
both) is a closely related concept to that of confidence
INTRODUCTION levels. Confidence can be defined as a conscious or
The extant trust related research literature is vast and highly unconscious act or mental state involving the placing
diverse. A full literature review of intangible trust in B2C e- confidence in something or someone. The idea that this
service contexts lies outside the scope of this exploratory confidence level can be formalized, hence measured is
paper. The interested reader is directed to both [1] and [2] developed by Marsh in his highly influential PhD thesis [6].
for a comprehensive literature review. One of the Human actors often invest their trust in a particular object
difficulties is that the notion of trust is closely related to of trust. This object may be another human agent or some
other concepts such as reliance, competence, artifact (such as a B2C Web-site). Indeed, within our
trustworthiness and credibility. Deutsch [3] was one of the intended scope of enquiry a company web-site acts as a
first modern writers to seek to build a formal model of trust. central focal point within an information space (cyberspace)
He defined trust in terms of an individual confronted with within which actors can choose either to follow "selfish
an ambiguous path. Further, the path may lead to either an self-interested" paths or act in the interests of others
event leading to a beneficial outcome (Va+) to that ("benevolent" paths). With the notion of an object of trust in
individual or to an event perceived as being harmful (Va-). mind, researchers have attempted to explore and develop
This individual perceives that the occurrence of Va+ or Va- the notion of trust as credibility, both within off-line and
is dependent on the behaviour of another human agent. on-line contexts [2]. Kim et al., [2] have variously
identified the sub-components of the credibility of an object promise for the future [13]. The main advantage is that a
of trust as comprising: honesty, expertise, predictability and cognitive "map" can be created from early (even paper
reputation. Research appears to indicate that credibility is based) web-site visual designs that reflects both the tacit
driven by the behavioural predictability of a trusted object, and semi-tacit knowledge of site users. This "map" can aid
for example a web-site [2]. Indeed, many researchers, such in probing customer perceptions of UX, including affective
as those of [7], define trust as comprising the dimensions of and rational trust responses to various visual design
trustworthiness and expertise. These dimensions are closely features. Card-sorting can also be used to validate early
related to the notion of credibility. Many have stressed the paper-based prototype designs as well as later in the release
importance of trust building over time (i.e. the temporal cycle so as to probe "live" or pre-release user trust site
dimension of trust). Thus the concept of trust as reputation perceptions.
has been developed by those seeking to quantify and
The final site design is however, ultimately only the product
measure high-level organisational trustworthiness in
of earlier application of methods, tools and requirements
businesses and organizations, and most recently in Virtual
gathering activities. Indeed, we go on to argue below that
Organisations [8]. Trust is not only dependant on our past
there is an intangible requirements 'gap' within existing
experiences but also on an expectation of reliability and
methodologies. That is, capture of intangible requirements
confidence in future events too. These aspects have been
is often implicit and does not always form an integral part
incorporated into various formal and informal models of
of the normative team design process that ultimately leads
trust building in relation to specific methodologies, such as
to a given trusted or distrusted UX.
agile [9-10]. An important aspect of trust building is the
degree to which affective vs. rational components are
A METHODOLOGICAL TRUST 'GAP'?
involved. It is clear from the literature that the affective
The familiar software development lifecycle methods used
component has been relatively under researched in
in industry such as agile approaches, XP (Extreme
comparison to the rational cognitive dimension [1].
Programming), RAD (Rapid Applications Development)
and indeed the typical waterfall models all tackle the issue
TRUST and UX
of requirements in different ways. Agile emphasises face-
Hassenzahl and Tractinsky, [11] deem that UX is
to-face interactions and iterative development within time-
influenced by a user’s internal state (e.g. predispositions,
boxes, in which case it may be expected that some informal
expectations, needs, motivation, affective state), as well as
stakeholder trust expectations may exist during the
by the characteristics of the designed system (e.g.
lifecycle. As a type of agile software development, XP aims
complexity, purpose) as well as by the environmental
to improve responsiveness for requirement changes during
context within which the interaction occurs (e.g.
the software lifecycle and it normally has multiple short
organisational, social and cultural setting, and perceived
development cycles instead of one long one in order to
meaningfulness of the activity). With respect to B2C e-
reduce the cost of changes. Unlike typical waterfall models,
shopping user contexts, reinforcing initial user trust
which can be treated as “plan-driven” or “predictive” so
building expectations is critical if businesses are to leverage
trust is relatively easier to be built up, agile methods, which
full value from their B2C sites. B2C trust building via the
have much in common with XP and RAD, are “adaptive”
HCI (Human Computer Interface) layer has been
and can respond quickly to requirement changes. Thus trust
extensively studied and many of the trust building factors
plays an important role in this kind of “adaptive” method
have been identified. Trust signs, seals, physical address
[9]. The following points seek to summarise and compare a
details, rich media et al., all serve to act as trust builders
number of typical lifecycle methods to see whether, when
both as affective and rational trust drivers. A review of the
and how intangible trust issues are considered:
relevant literature and a summary of trust determinants can
be found in [12]. There is little direct methodological Waterfall: Intangible trust requirements are
support to B2C system developers for intangible trust typically embedded within feasibility study, and
requirements capture. Rather, implicitly such systems are in a requirements catalogue as non-functional
enhanced with respect to trust only much later via requirements explicitly agreed by client and
acceptance testing and usability testing, if at all. Thus, developer;
intangible trust requirements in sharp contrast with tangible
Agile (e.g. XP): Trust is vital at every stage among
security requirements are not typically captured early
developer team members. More specifically, trust
enough within the software development lifecycle.
is tested during the meetings and at the end of
One of us has successfully used visual card sorts in the each and every iteration. Trust is built up due to
context of an SME to improve the UX of their B2C web- its iterative nature and its primary focus upon
site. The method has proven to be useful in revealing to interpersonal trust in the development process.
both developer and end-users semi-tacit trust knowledge. Tested software is generated at the end of every
Card sorts are not of course a new technique but their use in iteration and this helps to build a sense of
the context of validating intangible trust designs of for credibility (if the tested software is working as
instance B2C e-banking is relatively new and may hold scheduled!);
RAD (Rapid Applications Development): Often both rational and affective drivers that in turn serve to
implicit and embedded within evolving software influence technology acceptance levels. The well known
artifact itself (all stages) Trust is most likely to and heavily cited TAM (Technology Acceptance Model) of
emerge as an "issue" via acceptance testing and a type proposed by [2] exemplifies this vision. It is implicit
system walkthroughs once artifact is well refined. within such models, that trust is intimately related to risk;
"Look and feel" of software engenders customers that is to say where there is no risk trust is not relevant.
to engage through the use of branding, metaphor Rather, the higher the risk factors the more reliance needs
and narrative; to be placed by stakeholders on intangible trust
requirements so as to mitigate perceived risk.
Test-driven development (TDD): Not widely
considered? Some signs of confidence / trust build However, it would be a mistake to say that mere security
up when all test cases "pass" (which only may assurance equates to trust per se; rather, intangible
mean that the code meets all the defined/explicit perceptions of trust create the necessary pre-conditions and
requirements. (Trust is perhaps not widely set of constraints within which systems are procured,
considered explicitly here partly because TDD is a developed, and are ultimately released. Thus, trust is acts as
relatively new technique.) a super-set (universe of discourse) within which tangible
security assurance standards are seen to operate. However,
Ideally trust building aspects should be initiated at the very
it is important to note that mere security assurance itself
beginning among all system stakeholders (i.e. at the
(e.g. secure message protocols, cryptographic techniques)
requirements stage) no matter which lifecycle method is
can of themselves never fully meet the intangible trust
used. Trust requirements are important to final users as
concerns of users as part of their UX. For one thing, wider
well as to other stakeholders such as developers, managers,
intangible cultural trust norms differ greatly across and
clients, and system sponsors. Indeed many consider trust
within societies and cultures [12] and thus are highly
amongst Agile teams, tools and techniques for example to
relevant to "shared meanings" across cross-trans/national
be absolutely vital to help generate a credible "win-win"
software development teams working across borders or
specification. Yet as many industry practitioners
with culturally specific B2B partnerships. Although
acknowledge this is rarely the case in practice due to deep
intangible trust perceptions/expectations between business
seated cultural differences as between developers and their
partners or as between developers and clients mediate
clients.
requirements negotiations from the earliest stage of the
It would appear that there is a methodological 'gap' with software development lifecycle, there are two fundamental
respect to intangible trust requirements, particularly with problems that we seek to address:
respect to aspects of UX that encompass hedonic,
a) Firstly, intangible trust requirements are often at least
emotional aspects - not merely trust as rational decision
partially implicit, hence developers and clients may not
making and tangible security. There is a methodological
themselves fully realise its potential impact upon eventual
trust “gap”, particularly at the requirements stage. None of
system acceptance until too late in the development of the
the notations within the UML (Unified Modelling
system. When (due perhaps to disagreements or ambiguity
Language) for example directly support intangible trust
or un-stated sets of trust expectations, i.e. norms and meta-
requirements - aside from generic use-case and domain
norms) such issues may become more explicit, resulting in
models. Rather, the main focus is upon tangible security
a mismatch as between a norm and an agreed set of
and assurance aspects. Methods such as MEASUR [10]
functional requirements. Such matters cannot even be
claim to add value to existing approaches via ontology
realised (hence alterations made) by system developers or
charting by seeking to capture not only semantic entities
their clients before actual release of the system unless
and their relationships but also organisational contexts and
intangible trust is fully and richly articulated (hence made
culture, including normative methods of working, both
fully visible) to all system stakeholders.
formal and informal. This may perhaps serve to reveal
implicit trust aspects within workgroups or indeed trust Candidate solution?: Deontic logic has previously been
expectations concerning the presentation layer of the used to define norms and meta-norms in the context of
system. However, MEASUR is not in fact as yet widely enabling MONA (Portugese Acronym for a norm modeler
used outside academia, despite many years of effort. This for tailorable user-interfaces) [14]. It may be that in the
lack of adoption limits its potential impact and relevance to future the definition of high-level trust specific norms and
addressing the trust gap, despite recent efforts to formalize, meta-norms can (since the natural language version of
align and integrate MEASUR with modern component deontic logic is easily interpretable by clients) be
based design principles [10]. potentially useful in framing intangible trust issues - thus
potentially impacting on the design of a user's UX. A
HOW TO FILL THE TRUST "GAP"? potential advantage of the use of deontic norms is that they
Dyadic trust between an e-service provider and consumer are expressive enough to reflect well known cultural
(trust as a set of expectations as to future behaviour, differences of the wider social world within which the
reliability, service quality et al.,) is typically influenced by system is seen to operate.
b) Secondly, there is a notation gap with respect to CONCLUSION
articulating intangible trust requirements. Within the rich Intangible trust forms an important yet somewhat elusive
and expressive notational vocabulary of the UML, there is part of both UX, and wider technology acceptance. Without
no specific notational support for trust, other than as a trust building (explicit or implicit or both) systems will
natural text narrative to enrich the domain model. Various simply be not adopted or "work around's" will be employed.
notations and formalisms such as state-charts have been Despite the importance of intangible trust building, there
adapted to reflect some aspects of intangible HCI trust appears to be a methodological and notation 'gap'. The
requirements. However these extended or otherwise framing of system design within explicit trust norms may
specially adapted charting methods are not widely used prove to be useful since any methodology could be "front-
outside academia. Formal and mathematical notations ended" by a set of norms that are method and notational
claim to have been used for trust, yet they often only independent of any existing method. The alternative or
actually reflect tangible security paradigms. There has been complementary approach is to leverage an existing notation
some emergent work on the development of trust specific (e.g. the UML) for intangible trust or perhaps (even more
notations and methodologies such as The Shared Meanings speculatively) to seek to influence industry standards and
Design Framework (SMDF) to capture trust requirements methods such that they fully encompass intangible trust
across stakeholder groups. Few if any of these notations requirements. Others have tried to develop their own
are used outside academia. methods yet these are surely doomed to failure unless
industrial developers and their clients feel that the trust gap
Candidate solutions?: Perhaps suitable extensions to the is worth filling (adds real "bottom line" value?) Perhaps at
well known UML notation can be provided to support the present there is a certain cynicism that leads to rapid system
explicit articulation of intangible trust issues (for example release followed by numerous "patches" that seek to paper-
the domain model). As yet, this potential has only been over gaps in requirements. This is both the fault of clients
tentatively explored in relation to intangible trust [15], (too demanding time-scales) and developers. But it is also
though recently approaches such as UMLTrust seek to because of a "gap" in the industry methods and notations
offer support for intangible as well as tangible security currently deployed.
aspects: trust policies, scenarios as well as trust
certification [16]. One alternative path going forward is As wider notions of UX grow it is to be hoped that this
perhaps that one of the many trust specific notations to "gap" will be filled as all stakeholders come to realize the
emerge out of academia will be adopted or otherwise importance but also acknowledge the intractability of trust;
influence industrial practitioners, such as the SULTAN including the fact that we lack models of trust that take into
(Simple Universal Logic-oriented Trust Analysis Notation) account "obvious" cultural differences. Thus, there will be
[17] and associated tool-kit previously developed at UCL. no quick "fix", rather the trust gap reflects deep seated
cultural divide as between system stakeholders,
In our earlier discussions it was apparent that there is no organisational needs and current paradigms.
one methodology that is universally adopted. Rather,
methods are selected by client-developer partnerships Many challenges remain not the least of which is: how to
according to the "best fit" to whatever type of software define intangible trust in the first place. Deciding how and
system is proposed. For this reason we are very hesitant to what to "measure" becomes a central question - particularly
supply any definitive answer to the trust "gap" across every perhaps with respect to the impact of cross-cultural trust
method; but the above suggestions may perhaps at least norms. The extant literature in B2C e-trust has perhaps
prove useful as potential candidate solutions. In any event it tended to place over-relied on methods such as
is our contention that card-sorts have been shown to add questionnaires and under developed ways of probing user
value to the probing of intangible trust perceptions using cognition such as card-sorts. Perhaps in the future, hybrid
B2C sites. Either in relation to early designs or in relation to approaches that seek to triangulate as between
pre- or post release UX intangible trust evaluation. So physiological metrics and cognitive metrics by
whilst various possibilities exist with respect to enriching incorporating neuroscience may add value to evaluating
existing methodological practice, UX trust perceptions can trust as part of UX [1]. This may in turn lead to the
at least be probed empirically, once an artifact has emerged definition of objective physiological trust metrics as well as
from the development team. It would of course be more subjective metrics in relation to the UX.
desirable if as part of whatever methodology is used to If industry is willing to embrace new "blue-sky" techniques
develop artifacts, that intangible trust notational support and sees added value in funding studies in Usability Labs.,
could be agreed upon and more widely adopted. Thus far, as part of their requirements gathering /interface design
whilst various tentative suggestions have been made by validation studies then intangible trust requirements
academia, industrial practice has tended only to support gathering activities could form a normative part of every
tangible security requirements at the expense of intangible software project that has end users irrespective of the actual
trust concerns. choice of methodology. As yet though, too often failure to
address intangible trust perceptions result in lack of
adoption or expensive "fixes" and software re-releases.
To cite one well known UK Public Sector instance: the [9] Hasnain, E, and Hall, T. Investigating the Role of Trust
lengthy adoption of the NHS (National Health Service) GP- in Agile Methods using a Light Weight Systematic
to-hospital "Choose and Book" specialist referral e-booking Literature Review. Procs. 9th International Conference
system has been frequently ascribed as being due to an on Agile Processes in Software Engineering and
initial failure to address stakeholder trust and mistrust Extreme Programming. Limerick, Ireland, Jun 10-14,
issues at an early stage in the system's initial specification. 2008. In: Lecture Notes in Business Information
This initial failure led to not only to an initial lack of Processing, Volume: 9, (2008) 204-207.
adoption by GP's, but was the prime cause of numerous [10] Poernomo, I., and Tsaramiris, G. Ontology Based
subsequent system upgrades over a lengthy eight year time UML2 Architecture Generation. Procs. ICISO, (2010)
scale [18]. 314-321.
REFERENCES [11] Hassenzahl, M, Tractinsky N. (2006). User experience
[1] French, T. Towards an E-Trust Framework: trust as a –a research agenda. Behaviour & Information
semiotic phenomena. PhD Thesis, (2009). Reading Technology, 25 (2), March-April 2006, 91-97.
University, School of Systems Engineering, UK. [12] Wang, Y.D., and Emurian, H.H. An Overview of
[2] Kim, D.J., Ferrin, D.L., Rao, H.R. A trust-based online Trust: concepts, elements and implications.
consumer decision-making model in electronic Computers in Human Behaviour, 21, (2005) 105-125.
commerce: The role of trust, perceived risk, and their [13] French, T., and Opatola, K. A Pilot Investigation of E-
antecedents. Decision Support Systems, 44 (2008) 544– Banking trust perceptions amongst the Yoruba and
564. Igbo of Nigeria. Procs. IWIPS 2010, (2010) 107-116.
[3] Deutsch, M. Trust and suspicion. Journal of Conflict [14] Neris, V.P., and Baranauskas. User Interface Design
Resolution, 2(3) (1958), 265-279. Informed by Affordances and Norms Concepts. Procs.
[4] Corritore, C., Krasher, B., & Wiedenbeck. On-line ICISCO, (2010) 133-140.
trust: concepts, evolving themes, a model. International [15] Oussena, S. and French, T. Integrating the Semiotic
Journal of Human-Computer Studies, 58, (2003) 737- into UML via Enhancing and Cross-validating Use
758. Case with an Enriched Domain Model. International
[5] Gambetta, D. (Ed.) Trust: Making and Breaking Journal of Sociotechnology and Knowledge
Cooperative Relations. (2000) Oxford: Basil Blackwell Development (2010),1,3,15-31.
Publications. [16] Uddin, M., and Zulkernine, M. UMLTRust: Towards
[6] Marsh, S.P. Formalising Trust as a Computational Developing Trust-Aware Software, Procs. of the 2008
Concept. PhD Thesis, (1994). Stirling University, UK. Symposium on Applied Computing,831-836, New-
York, ACM.
[7] Fogg, B.J., Marshall, J., Laraki, O., Osipovitch, A.,
Varma, C., Fang, M., Paul, J.,Rangnekar, A., Shon, J., [17] Grandison, T. Trust management for internet
Swani, P. and Trienen, M. What Makes a Website applications, PhD Thesis, (2002). University of
Credible? : a Report on a Large Quantitative Study. London.
Proc. SIGCHI conference on Human factors in [18] Referral Management: Lessons for Success. King's
Computing Systems, (2001) 61-68. Fund, 2010. ISBN 978-1-85717-600-1
[8] French, T. Collaborative Virtual Organisation Trust
Measurement: Leveraging Corporate Governance
Metrics, Procs. IEEE, i-Society, (2010) 502-509.