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.