Glossary of Terms

erally treated as add-on features, generally designed for completeness’ sake and to claim that a system is usable and secure. Epstein contrasts this approach to one in which security and usability are “emergent properties of software systems”. This report was the outcome of the first Software And Usable Security Aligned for Good Engineering (SAUSAGE) workshop. This edition of the workshop was sponsored by the National Institute for Standards and Technology (NIST) to promote usability and security actions as fundamental components in “all stages of the software development lifecycle” [124]. A set of recom-mendations was also presented, and two recomrecom-mendations are of particular importance to this thesis: (1) the need to identify and develop methods and tools to support usable security across the various devel-opment activities, including the requirements and design stage and (2) the need to develop a framework for understanding usability and security preferences, and for enabling trade-off analysis among usability and security choices.

2.6 Glossary of Terms

This section provides a glossary of terms and their working definition based on existing literature.

Accessibility Accessible systems are those designed to promote social inclusion, allowing people with disabilities to adopt mainstream technologies through alternative or enhanced interfaces. The objective of accessibility is to allow the majority of users, possibly all, to achieve their goals irrespective of any possible visual, auditory, motor or cognitive disability. Standards and techniques exist to help system designers spec-ify measurable and verifiable accessibility requirements while tools are available to assure compliance. Tim Berners-Lee, director at W3C states that the power of the web is in its universality and access by everyone regardless of disability is an es-sential aspect. When a system is not designed for accessibility then it automatically excludes specific groups of users, or at best makes their lives more difficult. Fur-thermore, accessibility goes further in its social inclusivity goal and W3C include these non-disability related aspects as important considerations for accessible sys-tems: old age, literacy, language barriers, use of older technologies and bandwidth, mobile and resource constrained devices, new and infrequent web users and also limited access to technology in rural areas. For all of these aspects W3C proposes a set of accessibility guidelines for web-based systems [71]. Legal requirements exist for public entities (e.g., federal agencies, government departments) to comply with accessibility guidelines, such as the Section 508 Laws in the US and the Web Accessibility Standards in Canada. Other countries provide guidelines, checklists as well as legal policies to encourage public agencies to ensure accessibility for their electronic services [20]. The International Standards Organisation (ISO) pub-lishes guidance and pointers on software accessibility under ISO9241-171:2008 (Ergonomics of human-system interaction – Part 171: Guidance on software ac-cessibility).

Attitudes vs Behaviour

The term attitudes refers to explicit feedback given by participants on the subject matter (i.e., based on past experiences) which would in turn be processed through qualitative methods. On the other hand behaviour refers to observable and measur-able user activities which would in turn be processed through quantitative methods.

Malheiros [101] observed that what users report (e.g., concerns on privacy) may vary significantly from their actual behaviour (e.g., while transacting online).

Critical design factors

These are elements within a system that may violate both end-user goals and lived experience goals. End-goals (i.e., what a user wants to do) represent user motiva-tion for completing a task (e.g., “save time by paying taxes online”) while lived ex-perience goals (i.e., how a user should feel) are more universal and express feelings generated while interacting with the product (UX) but also feelings that go beyond that interaction (ULX), carrying a knock-on effect on the user’s personal activities beyond that interaction (e.g., making a user feel ‘stupid or uncomfortable’) – result-ing in reduced effectiveness and self-esteem while increasresult-ing resentment towards the system and its provider [38].

Design The stage in the requirements development process within which product use cases for the product-to-be are specified as a series of actions (executed by any active actor(s)) which would eventually lead to the completion of a primary task.

This should be an iterative process, ideally involving empirical exercises to estab-lish the effectiveness of the process or processes being considered. To some extent this complies with the definition of interaction design provided by Rogers et al.

[139] – “designing interactive products to support the way people communicate and interact in their everyday working lives” – however this thesis stops short from specifying visual design aspects such as colour schemes, typography and so forth.

Non-functional requirements specified during the design process should be verifi-able through the use of measurverifi-able fit-criteria – e.g., “users shall be verifi-able to locate the search page in less than 20 seconds 80% of the time”.

Formative UX assessment

Crooks [40] defined formative assessment in education as an activity “intended to promote further improvement in student attainment” and assessment is defined as

“any process that provides information about the thinking, achievement or progress of students”. This principle is applied in this thesis and formative UX assessment is proposed as part of the design and development process to promote systematic and iterative UX improvements starting at the earliest stages of a system’s lifecycle.

Framework Charles Haley, cited by Faily in [52] defines a framework as “a set of milestones in-dicating when artefacts should be produced” without being too prescriptive on the intermediate steps required to produce them. A framework, as a supporting struc-ture, should also recommend or provide optional tools and techniques to help its

2.6. Glossary of Terms 75

adopters be more effective and efficient in the production of deliverables. Such rec-ommendations must however comply with the framework’s underlying philosophy (e.g., building user-centric systems).

Primary task vs Secondary task

Sasse and Fl´echais [144] use the term production tasks to refer to those actions that a user performs to attain a goal or a desired state (e.g., obtain a birth certificate), while supporting tasks are actions that support production tasks but are not es-sential to their completion [144] (e.g., enrolment, identity verification and account activation for use in future interactions). This thesis will use the terms primary tasks and secondary tasks to refer to production and supporting tasks respectively.

In the same paper [144], the authors state that human behaviour is goal driven, and any action that takes the user away from her goal, or that leaves the user to choose between complying with the security requirements imposed by a system or getting the job done, is essentially bad design. Systems must be designed in a way that en-courage the completion of primary tasks in the most effective, efficient and secure way.

Requirements development process

This refers to the entire range of requirements-specific activities; from elicitation to quality assurance as well as requirements management and reuse. Wiegers [173]

defines the requirements development process as a four stage process: starting from the elicitation stage. At this stage the team identifies project milestones and deliv-erables, specifies the project’s scope and vision, identifies stakeholders, product champions, use cases as well as business events and associated responses. Among other techniques Wiegers suggests user observation (within the users’ context) as well as requirements elicitation workshops (with stakeholders) as two important information harvesting techniques. The elicitation stage is followed by the analy-sis stage wherein the elicited information is analysed, requirements are prioritised, grouped, formalised, modelled (visually) and also ranked by the value each re-quirement contributes towards customer satisfaction. Prototypes may also be built during use case design activities. If clarifications are required the process would iterate from the elicitation stage. The specification stage is used to record re-quirements based on an officially accepted template, including each requirement’s initiator and supporting artefacts as well as quality attributes (as guides towards customer satisfaction). Finally, the validation stage acts as the quality gateway wherein requirements are tested and validated for completeness, correctness, fit-ness, consistency (in terminology adopted) and traceability. During this stage, one should make sure that requirements are decorated with acceptance criteria [173]

(at a minimum) and with fit-criteria for more rigorous processes [138]. The entire development process is iterative, and the validation stage may take the project team back to the specification stage (for re-writing), analysis stage (for re-evaluation)

or back to the elicitation stage (for corrections). The logical flow suggested by Wiegers [173] is largely congruent to processes proposed by Axel van Lamsweerde [91] and Suzanne and James Robertson [138].

Saturation – qualitative (codebook) and statistical

This thesis makes use of the concept of saturation to inform the researcher on when an investigation could be safely terminated without jeopardising the study’s output quality. In particular, two types of saturation were used to guide the researcher across the various studies: qualitative saturation (see Section4.1) and statistical saturation (see Section4.3).

Qualitative saturation is the point at which additional qualitative studies would not yield significantly new and useful knowledge. Unlike quantitative studies, the qualitative researcher needs to assess her data as the study progresses in order to determine when to stop, or if necessary, when to extend a study. Guest et al. [67]

provide a number of insights on this matter and the reader is urged to consider their recommendations when embarking on qualitative research. This thesis makes use of qualitative saturation to determine the point at which any additional inter-views (analysed thematically) would not yield significantly new codes, or situations which might affect the ranking of existing codes in the codebook (i.e., the number of times a code is used).

Statistical saturation is the point at which any new input data would not yield any significant improvement on the statistical models being produced (e.g., regression models) [128]. If the change in prediction power (or model parameters) following the injection of new data is negligible, then the collection of further data might not be justifiable (depending on the model’s purpose and domain of use). Saturation is hereby defined as the point at which statistical models do not exhibit significant improvements in prediction with the addition of more data (e.g., an additional 10 participants will not yield more than 2% improvement over predictions generated by the original model). Out-of-sample tests can be used for this purpose whereby updated models are tested against a set of known observations. A score based on residual values (predictions vs actual observations) will help determine by how much the model has improved with the addition of new calibration data – based on the original model’s score (without the new data).

Security friction Beautement et al. [12] define friction as the imbalance between the business pro-cess (user goals) and security behaviour required, including any inherent cogni-tive and physical workload. Friction can cause resentment, and ultimately non-compliance, which can lead to service abandonment.

2.7. Conclusions 77

2.7 Conclusions

This chapter presents evidence of a clear relationship between enrolment-specific design decisions and user adoption, supporting the hypothesis that over-protection has a negative impact on takeup (see Sec-tion2.3). These findings shed more light on the first sub-question (SRQ1) presented in Section1.2.

A review of current practices in e-government service procurement and development (see Section 2.4) reveals that the lowest bidder approach is generally adopted for e-service procurement (or Lowest Prices Technically Acceptable in the US). Bidders are likely to cut costs on UX related activities unless these are specified in a measurable and verifiable way. This has been flagged as a major issue, motivating the rest of the investigation. Transforming experience requirements into a measurable and verifiable form is not trivial, although believed to be necessary. A number of standalone techniques exist that can be used to measure the impact on the users’ lived experience, and tools such as GOMS-KLM can be utilised to assess workload levels associated with specific tasks. Other techniques (e.g., NASA-TLX) have been reviewed in Section2.3.5. The literature reviewed for this thesis has not provided pragmatic indications on how enrolment processes can be designed in such a way that support the service provider’s required level of identity assurance while respecting end-users’ limitations and expectations.

This chapter has also shown that a culture gap exists between usability people and engineers (see Section2.5) and this is further accentuated by the skills gap that exists within e-government project teams in which policy makers are not aware of the importance of UX activities to the success of e-government projects. Usability, HCI and user experience are frequently treated as a non-engineering discipline, or rather, an add-on activity following the ‘real’ software development process – to make an existing system

‘user friendly’. This thesis is mainly driven by the belief that user experience has its roots at the core of the development process, starting at the requirements stage. A badly designed use case will have a negative snowball effect on end users and service providers alike, and no matter how much work is put into the improvement of the user interface (UI), the lived experience (ULX) will not improve.

Several user-centred techniques and tools exist, however more emphasis is required on the devel-opment of efficient and pragmatic practitioner-oriented techniques. These should also abstract complex theory and be encapsulated within usable and production-ready tools to assist in the specification of testable experience requirements for e-government services.

Methodology

This chapter starts by reviewing research methods generally adopted in HCI and requirements engineer-ing (RE). This is then followed by an outline of the methodology used to develop and evaluate the main contributions presented in this thesis.