Classical HCI considerations in RE

Zave [179] defines requirements engineering as the branch of software engineering concerned “with the real-world goals for, functions of, and constraints on software systems. It is also concerned with the relationship of these factors to precise specifications of software behaviour, and to their evolution over time and across software families”.

Karl Wiegers states that requirements engineering is a communication activity and not a purely technical activity [172]. This can be backed up by the fact that if communication barriers exist, and different people have different ideas of what the requirements actually are, problems will surely develop in the early phases of the project. Wiegers also explains that RE is the understanding [by all stakeholders]

of what is intended to be built, before actually building it.

Jackson [77] argues that the term requirements is often used to specify functional requirements and in [78] it is stated that requirements are located in the environment and are to be segregated from the machine or product to be built. Specifications on the other hand are restricted forms of requirements, giving boundaries and rules which are to be adopted in order to implement an effective solution. Jackson divides systems into the environment and the machine, and through this he denotes the importance of formalisation techniques. This is due to the fact that most environments provide haphazard and widely heterogeneous variables, changing from one industry to the other and from organisation to the next. The

goal for the formalisation techniques as described by Jackson is to provide a “faithful approximation of the informal reality” to the customer.

Lamsweerde [88,89] suggests a number of activities which are pertinent to RE, namely; domain analysis, elicitation, negotiation and agreement, specification, analysis of specification, documentation and evolution. These activities are iterative in nature in an effort to elaborate and manage a complete specification for a new system or product. Other authors, such as Goguen and Linde [64] denote that many scientists see RE as the phase in which scientific processes stop and chaos begins. Is there any order in the social world? For this reason, added importance is given to the social context wherein social order may not be readily visible and “obvious”. This soft view of the social context elicits an important aspect of RE; the importance of having proper communication channels between all the stakeholders. On the same lines, Leveson [95] considers RE to pertain to the fields of cognitive psychology, systems theory and human-machine interaction. Her work concludes that it is of greater importance to understand the intention for which the system was or is to be designed [95]. Having set a psychological framework for, and having understood the reason why the system is to be developed, that is, knowing the goals which the system is to help achieve, clears the way for successful translation of the business’ requirements into an operational technological solution.

One of the largest problems of evolutionary and long-term management of requirements is cost.

Boehm and Papaccio [16] state that late corrections in software (already in operation) may cost 50 and up to 200 times more than if such corrections are carried out at the requirements stage. When this state-ment was written (in the 80’s), technology was not as enabling as today’s, while project managestate-ment methodologies which were generally followed discouraged late amendments to the function points cur-rently present and planned within the system. So the 200 times multiplier might be diluted down to a relatively lower figure due to technological and management advancements. Whichever figure that might be the problem persists – late changes will still be a burden, especially in highly competitive markets.

The determinant of success for any task or goal is the degree by which it satisfies the purpose or intention for which it was initially commissioned. Nuseibeh and Easterbrook [118] earmark software systems requirements engineering as the process for identifying this “purpose” (or “intention”). It is suggested that this process should take the form of a documented study including an analysis of all the stakeholders and their needs, while producing artefacts which are fit for analysis, communication (between all parties), and eventually translatable for implementation.

In 2002 at the RE conference held in Essen (Germany), RE was positioned as a “well-recognized practice and research area”. The importance of “skills, processes, methods, techniques and tools” within RE was also given its due importance. Within the same definition, the issue of diversity in terms of application domains was denoted as an underlying challenge which practitioners face on a project-by-project basis.

Axel Van Lamsweerde outlines a number of requirement categories in [90], including:

Functional Requirements Define what the system shall do

Non-Functional Requirements Define constraints and parameters within which functional

require-2.2. The Interface Between RE and HCI 43

ments should be satisfied

Quality Requirements Or quality attributes, adding the level of requirement satisfaction, defining in-tegrity, availability, reliability and privacy amongst others.

Compliance Requirements Define requirement conformance to issues such as regulations, norms and cultures amongst others.

Architectural Requirements Architectural nature of the system, including software component distri-bution and installation requirements.

Development Requirements Requirements related to the way systems are to be developed, including requirements such as re-usability, portability and maintainability amongst others.

Castro, Kolp and Mylopoulos denote that non-functional requirements have not received enough attention, and are “less well understood than other, less critical factors in software development” [30].

Should solution design be based on intentional specifications or on operational ones? Intentions specify the goals of a system, while operational specifications explicitly specify the system operations, their rules and dependencies among others. van Lamsweerde stipulates that the two approaches are complementary [90], in which intentional specifications “leave the operations realizing them implicit” and operational specifications “leave the intentions underlying them implicit”. The approach proposed is called goal operationalisation, in which leaf goals are mapped to operations. Each goal is assigned to a specific agent, whose responsibility is to execute the respective operations under specific conditions in order to achieve such goals. Goal operationalisation is discussed in [90].

Goal oriented requirements engineering techniques such as the i* Framework and KAOS are tech-nically enabling when modelling complex scenarios. The author believes that the complexity in vi-sual representations (even in the simplest forms) produces barriers for successful communication with non-technical stakeholders, thus lessening the effectiveness of any participatory exercise within a non mission-critical e-government context. Alexander, Robertson and Maiden [9] have studied the main fac-tors that influence the selection and adoption of requirements development processes in industry. Their findings corroborate the author’s experience whereby practices in industry vary considerably from the

“elaborate techniques” discussed in academic literature. Furthermore, the authors have also noticed that the government sector suffers from a “combination of apparently rigid procedures, low education and limited use of available process knowledge”. Based on these observations, the author believes that unless guided by capable analysts who are also good communicators, government stakeholders should be han-dled with care – using a simple to follow yet rigorous and controlled requirements development process that adopts intuitive, familiar and possibly non-technical notations, jargon and schematics.

van Lamsweerde [88] argues that “although goal-based reasoning is highly appropriate for require-ments engineering, goals are sometimes hard to elicit. Stakeholders may have difficulties expressing them in abstracto”. Through the groundwork of Jacobson, scenarios were first utilised in human-computer interaction research in the late 1990’s. This has put additional focus on the area. Ivar Jacobson used the term use case instead of type scenario. The derivation of the term use case started much before the 90’s.

Through his work in Ericsson’s AXE system (1967) Jacobson started using scenarios in an informal and sometimes “coarse-grained” manner. There was no formal structure for the usage of use cases or type scenarios; but they simply indicated what the system’s workings were suppose to be.

From a historical perspective, Cockburn [32] outlines the evolution of the term “Use Case”:

1. Anvendningsfall (Swedish for situation of usage) 2. Usage Case (Did not sound good in publications) 3. Use Case (as used today)

There are a number of benefits or advantages pertaining to RE based on scenarios, and Glinz [63]

identifies the following:

1. Taking a user’s viewpoint: This can help validate requirements in terms of adequacy, as they give users a feel of what they will eventually get, in contrast to the classical and more formal techniques such as entity-relationship diagrams or class diagrams, including UML.

2. Partial specifications: Scenarios can provide a decomposition of the system into functions (user-system interaction representing a transaction) through the user’s perspective, whereas such func-tions can be treated separately.

3. Ease of understanding: Avoid the problems pertinent to pure narrative specifications techniques and formal methods, and allows for requirements to be elicited as natural language specifications.

Glinz denotes that the use of user-system interaction descriptions is a natural way for understand-ing and discussunderstand-ing (eventually refinunderstand-ing) requirements [63].

4. Short feedback cycles: Treating each user function, which has been elicited through user consul-tancy, separately will allow for better understanding and faster feedback between the requirements engineers and the users.

5. Basis for system test: Having scenarios which define interaction sequences can serve as a good starting point for system test planning; verifiable test cases can be derived from scenarios.

Jarke and Kurki-Suonio [80] note that scenarios are informal and inexpensive tools that may also provide a “middle-ground abstraction” to encourage team-members from different disciplinary back-grounds to participate in the requirements development process (e.g., offering common back-grounds for HCI practitioners and software engineers) [85]. Furthermore, Maiden and Robertson [100] suggest that sce-narios as well as use cases are effective tools for the elicitation of stakeholder requirements. The informal nature of scenarios tend to “suspended commitment” and thus can be used to encourage experimentation while fuelling innovation [85]. During system design, especially in the development stages, scenar-ios can serve as a handy reference point against which the development team can derive a sequence of events and exceptions which the system or sub-system or a particular function or sub-function has to abide with. From a methodological perspective, Alistair Sutcliffe [161] argues that scenario-based

2.2. The Interface Between RE and HCI 45

design “is the closest that HCI comes to a systematic method”, which unlike methods from software engineering and requirements engineering, is mainly used to support the thought process rather than to offer “step-by-step guidance” [161]. From personal experience it is felt that many stakeholders in the design of new e-government services are non-technical and can be considered as novices with respect to requirements engineering techniques and their deliverables, especially when specialised diagramming notation is used. This view is corroborated by Faily [52] and Hamilton, Pavan and McHale [68].

RESCUE [85] is a scenario based requirements development process that integrates various require-ments elicitation, modelling and management techniques (and best practices) specifically built to specify requirements for complex socio-technical systems. RESCUE has been built specifically for the air traffic control domain, and has been successfully adopted in multiple projects (e.g., DMAN [86] and CORA-2 [85]). The authors argue that traditionally requirement specification techniques have evolved from dis-tinct disciplines tackling domain-specific challenges (e.g., task-analysis from HCI and use cases from software engineering) however when it comes to safety-critical socio-technical systems (e.g., air traffic control) hybrid-processes are needed. RESCUE adopts this approach, combining different techniques to offset one’s deficiencies with another’s strengths [85]. This is obtained by integrating techniques and best-practices from different disciplines that handle different aspects of complex systems (e.g., realtime systems, ergonomics and human-computer interaction) while merging them into a cohesive process of discovery. RESCUE adopts techniques such as human activity modelling, i* models for system goal modelling, use cases, scenario walkthroughs and Volere-inspired activities (i.e., Quality Gateway) and templates (i.e., requirements snow card) for requirements specification, verification and management.

Considering the domain tackled by this thesis (i.e., non-critical public facing e-government services) it was decided to investigate James and Suzanne Robertson’s work on Volere [138]. Here the authors present a requirements development and management framework that proposes simple constructs and techniques while maintaining and encouraging process rigour. On the other hand RESCUE adopts a significant level of formalism especially in the way requirements are elicited and modelled – in line with its application on safety-critical systems. Simplicity is important in the e-service development domain, however this should not be obtained at the expense of rigour. Volere provides this balance, and this has been shown through its extensive use in both the public and private sector [98]. RESCUE may be well suited for safety-critical e-government systems, however this discussion is beyond the scope of this thesis.

Volere adopts scenarios as well as actors (i.e., active and interested), goals and testable requirements through measurable fit-criteria [99]. It is designed in a way that allows analysts to have a full view of what led to a specific requirement, the rationale behind it, related events and business use cases. A change in a specific requirement can be assessed and validated against the related business events, business use cases and product use case(s) – and vice-versa. The Volere process does not enforce strict rules on the system analyst however it proposes a templated set of deliverables (and milestones) together with corresponding methods while allowing the use of different modelling techniques (e.g., UML). Diagramming techniques are left up to the team’s discretion – who can adopt formal techniques such as UML models, BPMN and

flowcharts as well as informal techniques such as rich pictures - as long as the techniques adopted are deemed suitable for the task at hand and understood by all of the primary stakeholders. The process is adaptable to three levels of agility: (1) projects which require a high level of agility (“Rabbit projects”), (2) projects which need as much agility as possible but are constrained by project or organisational circumstances (“Horse projects”) and finally (3) projects involving a large number of stakeholders and requiring formal documentation due to legal or contractual obligations (“Elephant projects”) [138].