RE frameworks for usable e-government

In [43] Donzelli and Bresciani present REF (Requirement Engineering Framework) a goal oriented re-quirements development methodology that was adopted within the context of an e-government project.

In REF organisations are modelled as actors, creating an organisational model through a network of ac-tors in which collaboration and conflicts occur. On the other hand, goals define the relationship between such actors. The authors acknowledge that in e-government scenarios there are “very diverse stakehold-ers, with very different skills and backgrounds”. REF is aimed at helping the designer discover, define, refine and reconcile requirements and goals, which are split into soft and hard goals. The introduction of H-Connections (’Hurting’) in the modelling tool allows the designer to identify possible conflicting stakeholder points of view, and therefore allow for reconciliation efforts to be carried out at this stage.

The main aim is to “evolve the analyses only along the most promising alternatives”. An example of an H-Connection is given in [43], between the Employee’s soft-goal ‘Protect-My-Privacy’ and the Head of Unit’s goal ‘Provides-employee’s-Number-of-Documents’. In collaboration with the relevant stakehold-ers this can help the analyst focus on goal refinement through which potential solutions may be found (e.g., specify an average number of documents rather than an explicit value). Before taking a decision, all possible solutions are discussed with the stakeholders involved in this conflict (although further refine-ment iterations may still be required). Based on the i* framework and given the graphical tools provided, the issue of scalability still stands, and thus it makes it difficult to abstract and analyse a portion of the whole scenario at a time.

Seltsikas and Papas [149] propose a RE approach for trans-national government information sys-tems (TN-GIS) that “is particularly sensitive to political pressures and intent, and an approach that can endure extremely extended development timescales” [149]. The authors pose a simple and yet a very important question; are traditional RE theories suitable within a TN-GIS context? They acknowledge that there might “be hundreds and thousands of potential [unrelated] users from twenty-five or more countries” [149]. Action research together with participant observation were used in their highly quali-tative methodology. The Volere requirements development process was applied to gather and synthesise requirements. However the authors argue that Volere does not “provide much detail how requirements can be elicited from stakeholders” [149].

van Velsen et al. [166] introduce a citizen-centric RE process for e-government projects and at the stakeholder identification stage the model is divided into two major groups: ‘Citizens’ and ‘Civil Servants’ as show in Figure2.1.

2.2. The Interface Between RE and HCI 47 Figure 2.1: Citizen-centric RE for e-government projects [166]

Iterative prototyping is suggested in this approach encompassing citizen walkthroughs which will elicit feedback and scope for user requirement redesign. Scenarios are used in order to facilitate discus-sion and feedback between the design team and users. Personas are also introduced in this process in order to cater for the heterogeneous user groups which will be using e-services. Representatives for each persona are invited to participate in the walkthroughs. At the same time the model assumes that there are two major groups of stakeholders: citizens and civil servants. In reality, a large number of heterogeneous citizen groups exist, each with different needs and goals.

The authors reflect upon a number of issues with RE techniques, especially those applied in e-government scenarios:

1. Experts’ interpretation may vary between one and another

2. Specialists with technical knowledge generally take the “upper hand during the process of design-ing the systems” [166]. This might result in systems which do not have a good fit with its highly heterogeneous users, citizens.

3. Since user groups are highly heterogeneous, the risk of neglecting sub-groups exists.

4. A statistically balanced set of representative users should be involved in the design process in order to have the widest view possible.

5. User requirement elicitation is a lengthy process and this needs to be accounted for in the planning process.

6. Technical development should not start before the requirements elicitation process is exhausted.

Doing otherwise might result in re-design activities, if at all possible, or in expensive workarounds if the system has already been implemented up to a certain point.

7. It is hard to understand the return on investment of user-centric services. The only possible aim is to develop systems which are not ‘disliked’ or ‘under-used’.

Rogers et al. [139] argue that most of the literature in RE emphasises the importance of identifying stakeholders, nonetheless “none describes a model or a concrete approach for identifying stakeholders for a specific project” [152]. Quality of knowledge acquisition for systems development highly depends

on the quality of the stakeholder identification process. Volere, a practitioner-centric requirements pro-cess [138] adopts Ian Alexander’s Onion Model [7] for stakeholder discovery (see Section5.5). This ap-proach focuses on the project’s stakeholder sociology which is in turn modelled using a spatial metaphor [7] – a series of concentric circles surrounding the system being developed. Each concentric circle acts as a placeholder for various stakeholder roles (e.g., the wider environment can contain regulators, devel-opers, political beneficiaries, negative stakeholders and so forth). Stakeholders (i.e., humans, entities or other systems) are organised in terms of their distance from the system being developed, determined by the level of influence they have on the product and vice versa. The segregation of stakeholders into roles was also suggested by Sharp, Finklestein and Galal in [152].

The author then focused on system design processes and considered a set of collaborative work-flows that would also make UX consideration an integral part of the primary design task-set. Janowski et al. [79] conclude that the lack of methodologies and models, as well as the lack of cohesion between related projects are two of the major causes of e-government project failure. Measuring success by the actual delivery of products may not necessarily mean that the overall e-government transformational strategy is being met (i.e., project management vs programme management). A cohesive methodology provides a standardised approach across projects affording cumulative knowledge across projects for use in future projects. Whitten and Bentley (cited in [6]) also suggest that methodologies should store knowledge across projects in order to avoid cold start issues in future projects, especially when devel-opment teams change. Based on this it can be argued that a requirements elaboration and system design methodology should not just help the team to plan, manage, execute and control the development of a system, but should also provide mechanisms to monitor and flag any decisions that may have short and long-term implications on UX.

Rahaman and Sasse [131], Beautemant et al. [12] as well as Porter et al. [127] have presented frameworks and techniques to assess the impact of design decisions on ULX, tackling the psychological impact, compliance to imposed security, perceived workload and task completion respectively. Software development methodologies are there to guide the development team to work efficiently, however prod-ucts will finally be used by different categories of end users and it is only logical to conclude that such methodologies should include user-centric techniques, tools and interim deliverables. Personas as well as user stories are often adopted to inform the decision making process. For instance, Seffah et al. [82]

presented UX-P – User Experiences to Pattern – a user-centred design framework based on the use of personas, associated users’ experiences and HCI (mainly UI) patterns (referred to as building blocks in [81]) to create pattern-oriented designs at different levels of abstractions (i.e., site navigation to screen layout). The Persona to Pattern (P2P) Mapper tool is used to help developers pick suitable building blocks (e.g., UI components) based on a scoring system that considers the respective users’ experiences (represented within the persona specification) as well as the context of use. Through this technique and associated tools, the authors have proposed a way by which design, development and usability consid-erations are streamlined. A case study in which UX-P was adopted is presented in [81]. UX-P proposes the adoption of user experiences to inform the selection of UI building blocks to generate an early

con-2.2. The Interface Between RE and HCI 49

ceptual design, but implicitly assumes that such designs will always result in a positive user experience – during and beyond the interaction time and space (i.e., UX and ULX, as defined in this thesis).

Agile methodologies are incorporating user stories (i.e., high-level statements about specific aspects of a system) to tackle specific UX issues as part of the design process, and on this matter Dimmick [42]

states that this can lead to short-sighted design decisions aiming to fix immediate UX issues in specific user stories within the bounds of a specific sprint¹while risking the neglect of larger design questions.

In an e-government context, the bigger picture UX decisions are as important as a design decision at the micro-level. According to Dimmick, certain big design issues “don’t fit neatly into an existing user story or an individual sprint” and so he proposes time-boxed design spikes as part of an agile framework (SCRUM) allowing designers to focus on complex UX issues at specific time bubbles in-between sprints [42]. Design spikes may be used by designers to tackle over-arching design questions that may invalidate, or back-up, the whole development effort. Nonetheless, design spikes depend on the application of user-centred techniques and tools – inheriting their shortcomings (see Section2.2.4).

Unfortunately although personas are considered to be the de facto tool for user-centric design they may not satisfy the bigger picture in terms of designing for interaction in long-lived systems. Grocki and Thomson [66] consider personas to be snapshots of target users’ traits, intentions, needs and behaviours and as rich as they can be they do not follow changes in target users’ real needs and traits over time.

Storyboards, task flows and scenarios are traditional tools used to show time progression, however these tell short-term stories of single or multiple interactions over a short period of time (i.e., systems of transactions). The authors advocate for what they term as “illustrating the full story of engagement”

(i.e., systems of engagement and personal fulfilment) spanning across longer time-frames and multiple channels of interaction – journey modelling. This thesis acknowledges this view and uses it to support the selection of an established yet appropriate requirements development process (see Section5.3).

Van Velsen, et al. [166] provide a list of considerations for the elicitation of user requirements in e-government projects:

1. Heterogeneous user groups: in terms of cultures, skills, political opinions and disabilities. Dif-ferent demographics are also a crucial element.

2. Incidental use: most e-services are rarely used or used sporadically, and thus proper guidance