Requirements Engineering is, as its name suggests, the engineering discipline of establishing user requirements and specifying software systems. There are many definitions of Requirements Engineering (Zave, 1995); however, they all share the idea that requirements involves finding out what people want from a computer system, and understanding what their needs mean in terms of design. Requirements Engineering is closely related to software engineering, which focuses more on the process of designing the system that users want. Perhaps the most concise summary comes from Barry Boehm: requirements are "designing the right thing" as opposed to software engineering’s "designing the thing right" (Boehm, 1981). Nuseibeh and Easterbrook (2000) give a more comprehensive definition as "software systems requirements engineering (RE) is the process of discovering that purpose, by identifying stakeholders and their needs, and documenting these in a form that is amenable to analysis, communication, and subsequent implementation".
Requirements Engineering shares many concepts, techniques and concerns with Human Computer Interaction (HCI) especially user-centred design, participatory design and interaction design. However, it differs from HCI in its view of the scope of design; for example, socio-technical design is rarely mentioned in Requirements Engineering (although see Sutcliffe et al.(2005) for an exception), where the organisational and people part of a system is an explicit target of requirements and design. The other difference lies in the HCI focus on design per se and interaction design where user requirements are seen as part of the process of a design exploration, prototyping and evaluation dialogue with the user, rather than as the more linear requirements "specify-design-implement" process favoured in the Requirements Engineering community. However, Requirements Engineering certainly espouses iterative design, prototyping and evaluation (usually validation in requirements terminology). Furthermore, there has been a growing realisation that requirements cannot be specified without doing some design, which had led to the emergence of "architecture requirements". In this chapter I will explore the commonalities and differences between Human Computer Interaction and Requirements Engineering to reflect on how the two communities tackle what is essentially the same problem: building a system based on software that satisfies people’s needs.
The chapter is structured in six subsequent sections. In the next section, 1, the Requirements Engineering process is described. This is followed in section 2 by a review of scenario-based approaches which illustrate the convergence between Requirements Engineering and HCI. Section 3 deals with models and representations in the two disciplines, then section 4 returns to a process theme to assess the differences between HCI and Requirements Engineering approaches to development. Section 5 reviews how knowledge is reused in the requirements and design process, leading to a brief discussion of the prospects for convergence between HCI and Requirements Engineering.
13.1 Requirements Engineering Activities and Process
13.1.1 Scoping
Requirements frequently start with a vague statement of intent. The first problem is to establish the boundary of investigation and, inter alia, the scope of the intended system. Unfortunately, this is rarely an easy process as clients often don’t know exactly what they want, and knowledge about the intended system is vague. Scoping tends to be an iterative activity as the boundaries become clearer with increasing understanding of the domain shared by all the stakeholders. However, the process is poorly understood and little research has directly addressed this difficult problem.
Take for example a system to help epidemiologists with their research, which was the brief for the ADVISES project (Thew et al., 2009; Sutcliffe et al., 2011). The stakeholders might include public health analysts with interests in epidemiology as well as medical researchers. The range of possible decision-support tools could include data collection, data preparation, statistical analysis, visualisations, graphs, maps, as well a groupworking support for collaborative discussion of results. The systems owner and scope were not clear since the project was initiated as part of the UK Government supported e-science research programme, with users who were academic researchers in epidemiology, and who also collaborated with public health analysts who worked in local hospitals.
For general scoping, enterprise modelling (Kirikova & Bubenko, 1994) provides a way of describing the business context to discover requirements in the large (i.e. goals, aims, policies), but little process guidance is offered. Workshops in the KJ brainstorming method, named after its inventor Jiro Kawakita, and Rapid Applications Development (DSDM Consortium, 1995) are the current state of the art; they advocate use of lists and informal maps of the problem space, although these methods also offer little systematic guidance. More detailed scoping has been researched by Jackson and Zave (1993), who propose techniques for establishing the system boundary by examination of the intended system’s obligations in responding to real-world events, although this does not help bounding investigations which start from general statements of users’ intentions.
Scoping is best achieved by discussion with all the stakeholders and by documenting the high-level system goals as terms of reference. Writing down the scope tends to focus users’ attention on where the boundaries of the system investigation should lie, and helps to identify at least an initial scope for the system.
13.1.2 Fact gathering
For the most part, the techniques for this activity have been borrowed from systems analysis, e.g. interviews, observation, questionnaires, text and document analysis (Gause & Weinberg, 1989). Techniques from knowledge acquisition, such as repertory grids and protocol analysis, have been employed, but there have been no systematic investigations into the merits of different fact-capture techniques, apart from a preliminary study by Maiden and Rugg (1994). An interesting emergent area is the use of ethnographic and associated observational methods (Goguen & Linde, 1993; Luff et al., 1993); however, these have failed so far to deliver explicit guidance for fact capture or analysis, leading software engineers to propose their own quick and dirty approaches (Hughes et al., 1995).
13.1.3 Analysis
Analysis and modelling generally follow top-down approaches, concentrating on goal decomposition. Analysis is often driven by 5 ‘W’ questions:
What is the system purpose (goals)?
What objects are involved?
Where is the system located?
When should things happen?
Why is the system necessary (goals or problems it intends to solve)?
In an example of the common approach, Potts et al.(1994, 1995) provide a means of goal-related analysis which uses scenarios to discover obstacles, or potential problems caused by external agents that the system has to deal with. From obstacles, goals for maintaining, avoiding and repairing situations can be elaborated. Other goal decomposition methods follow a taxonomic approach and attempt to analyse goals in the context of domain models (Sutcliffe & Maiden, 1993). For problem analysis, soft systems methodology (Checkland, 1981) gives a means of informal modelling and an analytic approach to discovering problem-oriented requirements. Informal diagrams and sketches, which may be referred to as domain models or rich pictures (Checkland 1981) are used to document the analysis as it progresses. A domain model for the ADVISES project is illustrated in Figure 1.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.1: Domain model for the ADVISES project, as an informal diagram showing stakeholders and organisations involved
The organisations involved appear in rectangles as secondary stakeholders, i.e. people who have an interest in the system output, but are not the primary hands-on users who are shown in circles. Primary stakeholders were public health analysts in Primary Care Trusts (local units of organisation in the UK National Health Service) and academic health informatics researchers who collectively formed the NIHBI unit (North West Institute of Bio-Health Informatics).
Rationale-based techniques are also appropriate for analysis and modelling. These structure analysis in hierarchies of graphs linking goals with potential solutions and supporting arguments; see gIBIS (Conklin & Begeman, 1988) and QOC (MacLean et al., 1991).
13.1.4 Modelling
This activity consumes the output from analysis, structures facts and represents them in a notation. Requirements Engineering has borrowed techniques for this activity from structured system development methods and conceptual modelling. Informal modelling notations, such as data flow diagrams and entity relationship diagrams, have been widely used. Many formal approaches to modelling have been imported from software engineering (Goguen & Linde, 1993; Van Lamsweerde, 2009; Van Lamsweerde et al., 1995) although the effectiveness of these techniques has yet to be demonstrated in industrial practice. Analysis and modelling are frequently interleaved to elaborate the requirements as understanding of the problem domain increases through the act of representation.
Some examples of modelling notations are shown in Figures 2-4. The entity relationship diagram in Figure 2 shows entities and their functional relationships (has, prices, etc.) which support data modelling and ultimately database design.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.2: Entity relationship diagram; entities are shown as rectangles, relationships as connecting lines
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.3: Data flow diagram: rectangles in this notation are processes, ovals are external agents and arrows show the directions of the flow of information between processes
Data flow diagrams model the processing aspects of a system, and complement the "data view" model of entity relationship diagrams.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.4: i* diagram, also known as GRN (goal requirements notation)
Circles represent agents, ovals are goals, cloud-like shapes denote "soft goals" or quality criteria, rectangles are resources, and the relationships with D annotation are dependencies. Tasks which achieve goals have been omitted to simplify the diagram.
The i* diagram in Figure 4 illustrates the relationships between the stakeholders, major goals and non-functional requirements (soft goals in i* terminology) in the ADVISES application. Dependencies between agents and goals are marked with Dsymbols on the arcs.
13.1.5 Validation
This key activity in Requirements Engineering, in spite of being extensively researched, is still problematic. Validation implies getting users to understand the implications of a requirements specification and then agree, i.e. validate, that it accurately reflects their wishes. The current state of the art is walkthrough techniques in which semi-formal specifications such as data flow diagrams are critiqued in a workshop of designers and users. Walkthroughs have the merit of early validation on specifications, whereas prototypes are probably more powerful as users react more strongly to an actual working system. Unfortunately prototypes still incur construction costs, and poorly organised use of prototyping can be detrimental (Attwood et al., 1995). However, prototypes in combination with techniques for gathering and evaluating user feedback can be highly effective (Gould, 1987). Overall, the process of validation is poorly understood and explanation is an important yet often neglected component. Some research into explaining complex requirements has demonstrated that a combination of visualisation, examples and simulation is necessary (Carroll et al., 1994; Maiden & Sutcliffe, 1994). Scenario-based representations and animated simulations help users see the implications of system behaviour and thereby improve validation (Johnson et al., 1992); furthermore, early prototypes with scenarios are a powerful means of eliciting validation feedback (Sutcliffe, 1995). The inquiry cycle technique of Potts et al.(1994) approaches validation by comparing scripts of imagined real-world behaviour against the required behaviour in a specification. Validation is still poorly understood and further research is necessary to discover how explanation, representation and users’ understanding of system specifications interact.
In ADVISES, requirements validation was an iterative process of showing users different designs initially as storyboards, and later as mock-ups and prototypes. This facilitated discussion with users about just what they wanted, and also helped the Requirements Engineering team learn more about the users’ work. Presenting people with designs rarely fails to elicit useful feedback, and this approach is central to user-centred design.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.5 A-B: Illustrations of the ADVISES storyboards used in validation sessions with users
A video demonstration of the ADVISES prototype can be found in the supplementary material or at: http://www.youtube.com/watch?v=8EfSM9KG3Dg
Figure 5 shows two configurations of the ADVISES paper prototype designed to support exploration of epidemiological data. (A) shows a map of a fictitious city split up according to Primary Care Trust boundaries, including an apparent hotspot in one area shown by shading to indicate that the mean for this area falls at the extremes of the distribution. (B) shows the same map but now split into smaller sub-areas accompanied by a histogram-like plot for those areas. Acetate transparencies are used as overlays so different options can be presented in an interactive sequence, while post-it notes are used to record ideas and feedback suggestions during validation sessions. Users are encouraged to draw on the paper prototypes to illustrate their own design ideas. Figure 6 illustrates an interactive requirements validation session where post-it notes profile a means of sharing ideas among all the participants.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.6: Users discussing ideas on post-it notes during a requirements validation session
13.1.6 Trade-off Analysis
Requirements frequently cannot be satisfied by a specification. Non-functional requirements fall into this category; although the design can accommodate them to some degree, a complete solution is not feasible. Requirements are often held by different stakeholders who may have conflicting views, hence trade-off analysis is an essential activity for comparing, prioritising and deciding between different requirements or design options. Ranked lists or matrix-based techniques using decision tables are helpful for this analysis. The modelling techniques proposed by Chung (1993) and Yu (1993) for mapping relationships and dependencies between goals, tasks, actors and soft goals (alias non-functional requirements), contains some guidance for trade-off analysis. Their method and support tool facilitate tracing influences between goals and non-functional requirements (NFRs) as well as giving active guidance about potential clashes between different types of NFR (e.g. security may militate against ease of use). This work is a significant advance in handling trade-offs. In spite of this, few tools or methods exist to help the requirements engineer, although House of Quality (Hauser and Clausing, 1988) techniques have been imported into RE and some tool support is available (Jacobs and Kethers, 1994). More complex approaches such as multi-criteria decision making (Fenton, 1995) do not seem to have been considered in RE.
An example of trade-off analysis in ADVISES is shown in Table 1. Two sets of requirements were gathered, one from the academic researchers and the other from the public health analysts. The relationship between the requirements and different quality criteria or NFRs, such as accuracy, privacy, etc., are shown in the table.
Goals | Medical | Health | Non-functional requirements | ||
Accuracy | Security | ||||
Plot data on maps | ✓ | ✓✓ | ++ | ||
Show hotspots on maps | - | ✓✓✓ | ++ | ||
Provide simple statistics | ✓ | ✓✓ | + | ||
Annotate maps | - | ✓✓✓ | + | ||
Check data errors | ✓✓ | ✓ | ++ | + | |
Provide advanced statistics | ✓✓✓ | - | ++ | ||
Prevent analysis errors | ✓✓✓ | -- | ++ | ||
Encrypt data | ✓✓ | - | ++ | ||
Integrate maps and charts | ✓✓ | - | + | + | |
Table 13.1: The dependencies between requirements goals and quality criteria for two stakeholder views in ADVISES. Ticks show the prioritisation of the goals for each group of stakeholders, - are neutral, -- shows disapproval or a goal conflict, while + implies associations between goals and NFRs
Decision tables, trees and flowcharts are other representations which can facilitate negotiation and trade-off analysis by making the space of options clear and helping stakeholders to see their priorities from the perspective of others.
13.1.7 Negotiation
The social dimension of Requirements Engineering is poorly understood. This activity subsumes many others, e.g. analysis, trade-off and modelling, but the essence lies in discussion, explanation and negotiation of conflicting requirements. The negotiation issues in ADVISES are illustrated in Table 1. Clearly the two groups of stakeholders have different priorities with only a few goals in common (data errors, maps and simple statistics). If stakeholder goals do not conflict, then all goals might be included in the design, although this can increase complexity. However, when goals conflict, as was the case in the "prevent analysis errors" goal, negotiation has to reconcile the conflicting views. Health analysts perceived this goal as a slight on their professional integrity; however, when the positive effects of this function on improving the accuracy of results was explained, they accepted this requirement. The modelling work of Chung (1993) contributes to negotiation by creating a shared artefact through which influences and design alternatives can be discussed. This is effected by creating a strategic dependency model to map out relationships between goals, tasks, actors, etc., followed by a strategic rationale model which illustrates potential system solutions for the requirements with arguments for and against them. Unfortunately, these models provide no active guidance for agreeing requirements, although Boehm et al. (1994) suggest some heuristics for structuring successful negotiation of requirements. Stakeholder analysis methods in co-operative requirements capture (Macaulay, 1993) help to structure the composition of workshops with different stakeholders and provide a framework for considering requirements from different viewpoints. Guidance for managing Requirements Engineering meetings, and handling negotiation and conflict resolution, is hard to find. Social science research on meetings describes roles, desiderata for leadership and managing consensus in groups (Viller et al., 1994); however, this research has not been applied in Requirements Engineering.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.7: Different groups of users may have conflicting requirements which are negotiated in workshops facilitated by the designers
It helps to have experts in the negotiation process facilitate discussion in a relaxed setting to reduce tensions and possible conflicts among stakeholders, as shown Figure 7.
The Requirements Engineering activities are placed into a generic process map in the following section to illustrate a typical route.
13.1.8 Process Map of Requirements Engineering
Requirements Engineering follows different routes and mixes of activities; for instance, requirements might start as problems with a current system, or as examples of products which users want. Procurement-based Requirements Engineering to select products is beyond the scope of this chapter (see Maiden & Ncube, 1998 for COTS-based Requirements Engineering), so only the most common, goal-oriented, pathway will be explained. Requirements are initiated by senior managers and company executives as policies, aims, objectives and other high-level statements of intent. This route, illustrated in Figure 8, necessitates considerable scoping activity as requirements start with vaguely expressed intentions and users’ wish lists. The process borrows from business analysis, such as Set policy objectives (1) and Analyse and model business (2). Policy can be analysed within the business context by enterprise models. Non-Requirements Engineering activities which are pertinent to policy analysis include business modelling, value-chain analysis (Porter, 1980), competitive advantage theories and business process re-engineering (Davenport, 1993). Business analysis techniques such as business process analysis, concept maps (Eden, 1988), and critical success factors (Rockart & Short, 1991) are also applicable at this stage; however, proposing a detailed methodology is beyond the remit of Requirements Engineering. The key problem is to model the business to discover opportunities for developing computer systems to enhance competitive advantage. Although some suggestions can be found in value-chain models e.g. (Porter, 1980), and case histories of inter-organisational system design (Holland, 1995), this area is poorly understood. The methods and approaches in the business analysis community are still largely a matter of intuition, so regrettably only limited guidance can be gleaned from this source.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.8: Goal-oriented pathway for Requirements Engineering
Top-down decomposition is the normal approach whereby policy-level intentions are successively decomposed into goals. Objectives from management are combined with facts, information and goals from users gathered in the Elicit requirements (3) step via interviews, focus groups, workshops, etc. These form the inputs for Analyse requirements (4) in which preliminary information, usually in the form of lists and notes, is organised as connections between facts are made. For example, relationships are added progressively as the context of the policy is understood in terms of what has to be done to achieve it (goals) and the implications for people (actors) and their organisations (organisation unit, objects, etc.). Analyse requirements is interleaved with Model requirements and domain (5) as analysis produces models that document facts and their associations. For example, modelling goals in the context of how they impact on tasks and the organisation is vital not only to elaborate the meaning of informal statements of intent but also to enable assessment of the impact of change (Chung, 1993; Yu, 1993). Goals have to be refined as linguistic statements of intent until the stage when the desired state of the system can be described, when formalisation may be possible (Dardenne et al., 1993). Hypertext tools can help to represent informal goal hierarchies (Pohl, 1996), as can standard conceptual models, e.g. data flow diagrams, but there is little advice or process guidance for goal-related requirements analysis. Chung (1993) and Yu (1993) provide representations of goals in context models showing dependencies between goals (both functional and non-functional), actors and tasks, with some guidelines for goal decomposition and modelling. Modelling is an essential precursor for the Validate requirements stage (6) in this route, as goals can not be easily understood without contextual detail about how they may be achieved and their relationship to agents and processes. Validate requirements is usually interleaved with Negotiate requirements (7) as discussion among stakeholders and designers leads to requirements being agreed or rejected, and conflicts between stakeholders being resolved. Stages 4-7 in the process form an iterative loop as requirements are rarely specified correctly first time; instead, requirements emerge through iterations of analysis, modelling, validation and negotiation. The policy route converges with other Requirements Engineering pathways for common activities of trade-off analysis and negotiation, both of which are important for goal-oriented Requirements Engineering. Once goals are decomposed to the stage where the desired state of the system can be described, at least informally, the first-cut decisions on use of technology can be made. Some goals become functional requirements, while others have implications for management alone (e.g. decisions about resources, organisation, and human activity).
Having described Requirements Engineering activities, the next section reviews scenario-based approaches which form the common ground between the Requirements Engineering and HCI.
13.2 Scenario-based Design: Common Ground between HCI and RE
HCI and the parent discipline of Requirements Engineering, Software Engineering (SE), are both design disciplines that aim to develop software systems. Their close relationship has been subject to considerable debate although unfortunately little constructive synthesis. Requirements Engineering may be regarded as the front end of Software Engineering since it focuses on requirements and process phases prior to implementation, although the boundary between Requirements Engineering and Software Engineering is becoming increasingly blurred. HCI, in contrast, covers the whole design process. The boundary with Software Engineering depends on the focus of the two disciplines. Software Engineering’s core concern is software, so people and systems in the socio-technical sense are minor concerns; whereas HCI focuses on people and the user interface as well as on the design of the wider socio-technical system, at the expense of software architecture. The common ground between Requirements Engineering and HCI lies in shared processes and representations, advocated in different flavours as user-centred design, scenario-based design, iterative development and agile methods.
Both HCI and Requirements Engineering use scenarios as a motivation for design, although the form and function in each field differs. Unfortunately, the term "scenario" has been abused in the literature and a large number of definitions exist (see Rolland et al., 1998). Indeed, much of the scenario literature, especially in the Software Engineering tradition (Kaindl, 1995), is in fact describing event-sequence traces through state transition models. In object-oriented design it becomes difficult to distinguish between use cases, alternative paths through use cases, and scenarios, which are just another path through a use case (Cockburn, 2001; Graham, 1996; Jacobson et al., 1992). Scenarios have several roles in design, from a "cognitive prosthesis" stimulating the designer’s imagination to narratives of system use and problems from which requirements emerge (Carroll, 2002).
In Requirements Engineering, scenarios are generally seen as inputs to modelling and are closely related to use cases and requirements elicitation, constituting the early phase of RUP (Rational Unified Process). In contrast, HCI places less emphasis on the link from scenarios to modelling; instead, scenarios and other techniques such as personas stimulate thought in the design process (Carroll, 2002). Scenarios can be related to personas which amplify narrative experiences by describing typical users. Indeed, some propose scenarios that are deliberately exceptional to provoke constructive thought (Djajadiningrat et al., 2000).Scenarios are arguably the starting point for all modelling and design; however, modelling has fallen out of favour in HCI, and task models are rarely mentioned as components of the design process. In Requirements Engineering and Software Engineering, modelling is still a mainstream activity and this illustrates a key divergence between the disciplines. See Figure 2.
One productive juxtaposition of scenarios and models is to use scenarios as test data to validate design models. This approach has been actively researched in the Inquiry Cycle (Potts, 1999), which recommended using scenarios as specific contexts to test the utility and acceptability of system output. By questioning the relevance of system output to a set of stakeholders and their tasks described in a scenario, the analyst can discover obstacles to achieving system requirements. Input events can be derived from scenarios to test validation routines and other functional requirements. This approach has been refined into a formal process for discovering the achievability of system goals with respect to a set of environmental states, taken from scenarios (Van Lamsweerde & Letier, 2000).
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.9: Use of scenarios in different phases of the Requirements Engineering-Software Engineering process
To illustrate with some examples from the ADVISES e-science system, the initial vision scenario describes how medical researchers might work in the future:
Epidemiologists view data sets from different parts of the UK displayed on maps and different charts. They can ask questions about the data using limited natural language and simple controls like sliders so they can immediately see the results of different analyses on their data in different areas of the country. When they have found interesting results they can add notes and send the results to colleagues in other research teams.
Vision scenarios set the scene for the development project before any prototype exists so they focus on the intended outcomes.
Usage scenarios, in contrast, paint a more detailed picture of how the system will operate and are frequently accompanied by storyboards and prototypes to illustrate the design:
Iain wants to see if there is any link between asthma and obesity in young school children in different areas of greater Manchester. He loads data sets for the incidence of asthma and obesity in different areas. Map displays show that most areas have little association, apart from two local districts where both high levels of obesity and asthma are shown by colour coding in the map. He checks that this is an accurate result by applying an area density correction statistic and then running a correlation analysis.This shows a significant result. However, diet and poor exercise are more common causes of childhood obesity so Iain loads the location of sports facilities on the map and finds that both asthma-obesity hotspots also have few sports facilities. His investigation continues.
Later in the development cycle, context and use scenarios describe system use but with expectations of how the system output may be used, including test probes for use in validation and evaluation sessions, e.g.
You are a public health analyst for the Greater Heaton PCT. You are interested in looking at BMI in year 6 (age 11 years) children in your area. Make a new map based on the Middle Layer Super Output Areas, and using your first data set. Load the younger children data sets and inspect the map display, using sliders to change the view of results using the age, gender and other variables provided. See if you can spot any general patterns when you look at maps for males only, females only and both together.
You have noticed a hotspot in one region of your Reception Class map which appears to have higher levels of obesity. Load the younger children data sets and inspect the map display, using sliders to change the view of results using the age, gender and other variables provided. Investigate whether or not this looks like a genuine hotspot.
HCI uses scenarios in a similar manner in usability evaluation, although the role of scenarios is not articulated so clearly. Nevertheless, task or test scripts in evaluation methods (Monk & Wright, 1993; Sutcliffe, 2000a) are scenarios. Carroll also recognised the validation role for scenarios in the task-artefact cycle in which an implemented artefact is evaluated, leading to design improvements and, by a process of claims analysis, to new HCI knowledge. Carroll has articulated several different roles for scenarios in the design process including as envisionment for design exploration, requirements elicitation and validation (Carroll, 1995). Other roles are usage scenarios, which illustrate problems; initiating or visioning scenarios, which stimulate design of a new artefact; and projected use scenarios, which describe future use of an artefact that has been designed (Sutcliffe & Carroll, 1998).
13.3 Models and Design Representations
Models are a central concern in Requirements Engineering as representations of the system and to support reasoning in the requirements process. The most popular models in Requirements Engineering are use cases, which are shared with commercial systems development and Software Engineering; see Figure 10.
Use Case Number | EM3 |
Name: | Viewing the name of a map region |
Description: | Basic theme map has been created |
Primary actor: | Epidemiologist |
Pre-condition: | User has successfully created a theme map, divided into geographic regions |
Trigger: | Map has been created, user is ready to explore map |
Basic flow: | Selection of a region, viewing of name |
Alternate flows: | Error handling – name cannot be displayed for the selected region
|
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.10: Use case context diagram and lower-level use case specified in an action sequence template
More specific to Requirements Engineering is the i* family of models which records agents, goals, tasks and resources connected by dependency and means-ends relationships, as illustrated in Figures 4 and11.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.11: i* strategic dependency model, showing agents (circles), goals or high-level functional requirements (rounded rectangles), resources, (rectangles) and soft goals or non-functional requirements (clouds)
Goal models and goal-oriented analysis are also key influences in Requirements Engineering (GORE: see Potts, 1999). Goal hierarchies represent the decomposition of user needs with relationships showing interactions between them such as support, inhibit or hinder. Goal models share a common heritage with task models, although task models record not only intent, but also the operational sequence in which a task will be carried out. Task models (e.g. HTA: Annett, 1996; TAKD: Diaper & Johnson, 1989) link goal-decomposition hierarchies with action sequence descriptions at lower levels of detail. Both goal and task models use a hierarchical notation, as illustrated in Figure 12.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.12: Library goal model with upper-level goals being decomposed into lower-level sub-goals. Task models in HCI follow a similar pattern
Dependency relationships, denoted by the D symbol on an arc, signify an association such as a goal depends on an agent to realise it or a goal depends on a resource for its achievement. Means-end relationships record how goals will be delivered by tasks, agents and resources. Goals belong to users and are equivalent to requirements. In i* a distinction is made between hard goals which will become functional requirements to be implemented by software programs; and soft goals (NFRs) which are quality requirements such as usability, safety, cost or accuracy.
SE extends Requirements Engineering models to provide different views of the software system, such as the data process structure in class diagrams, behaviour in activity sequence diagrams, or event sequences in state transition diagrams.
Task models provide an abstract view of the real world with a set of semantics motivated by the modelling goal. In a similar manner, class diagrams in Software Engineering represent the abstract inheritance structure of system objects, whereas state transition diagrams represent activity-oriented specification. Task models fit within the modelling genre that represents intent (goals) and activity (procedures or action sequences). Task modelling has been extended to cover data-oriented views via domain knowledge structures in TKS (Task Knowledge Structures: Johnson et al., 1988), and have been adapted to the object-oriented paradigm in MAD (Methode Analytique et Description: Rodriquez & Scapin, 1997). A prime role of task models has been to represent the problem space when reasoning about functional allocation. Although the functional allocation literature acknowledges the need for task analysis, it rarely represents task models explicitly (see Dearden et al., 2000). Instead, scenarios may be used to motivate functional allocation decisions, within task-related frameworks such as IDAS (Information, Decision, Action, Supervision: Wright et al., 2000). However, task models can be used to partition activity during functional allocation (Sutcliffe, 1997; Vicente, 2000), and this remains one of their major roles.
One criticism of task analysis is that it does not capture the richness of interaction that occurs in the real world compared with scenario narratives that concentrate on contextual description (e.g. Kuutti, 1995; Kyng, 1995). However, task models have been extended to describe information requirements implied in tasks (Sutcliffe, 1997), and the role of work artefacts in ecological interface design (Vicente, 2000). Another omission is the lack of explicit representation of communication between agents engaged in collaborative tasks, although this is partially specified in GTA (Van Der Veer et al., 1996) and is dealt with more explicitly in coupling analysis, which provides a discourse analysis framework that can be incorporated into a task workload analysis (Sutcliffe, 2000b, 2002b). Finally, task models may be criticised for not representing the relationships between agents, activity and organisational structures, although these concepts are described in socio-technical system design frameworks such as ORDIT (Eason et al., 1996); while more comprehensive modelling languages can be found in Requirements Engineering such as i* that analyses the dependencies between agents, tasks, goals and resources (Mylopoulos et al., 1999; Yu, 1993).
Task analysis as a method or notation has not been readily adopted in practice (Bellotti, 1988; Diaper, 1999) apart from the human factors safety engineering community (e.g. Hierarchical Task Analysis: Annett, 1996). Furthermore, modelling has fallen out of favour in HCI where lightweight representations such as hierarchy diagrams for information architecture and design sketches, wireframes and storyboards have become the norm.
A shared genre of representations has been Design Rationale which has been adopted by both HCI and Requirements Engineering to record design decisions and present alternative design solutions for debate. In Requirements Engineering the gIBIS (Conklin & Begeman, 1988) notation has been adopted to represent user goals as issues, mapped to design alternatives (requirements) with arguments. QOC (MacLean & McKerlie, 1995), the HCI version, follows a similar format with Questions as design issues, Options for design alternative, and Criteria to select trade-offs between designs; see Figure 13.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.13: Design Rationale Diagram showing the gIBIS-Requirements Engineering variant
The design issues illustrated in Figure 13 comes from a case study of requirements analysis for a safety-critical fire-management system on container ships. Heat sensors detected fire, then the issue was how to notify the crew. The diagram shows three design alternatives, linked to trade-off criteria. The top option proposes an audio alarm which does broadcast the alarm throughout the ship but does not give vital information on the location of the fire. The middle option of a visual alarm on a panel display is reliable but more localised, while the third option of using visual diagrams of the ship and highlighting the location of the fire provides better information. Design rationale diagrams allow users to see the trade-offs between different requirements as design options; however, QOC has been difficult to introduce into new communities of practice (MacLean & McKerlie, 1995), and similar problems have been encountered with the gIBIS (Conklin & Begeman, 1988) version of design rationale (Buckingham Shum, 1996; Sutcliffe & Ryan, 1997).
13.4 Design Process in Requirements Engineering and Human-Computer Interaction
One of the key differences between Requirements Engineering and HCI lies in process. Requirements Engineering is a systematic engineering discipline, so techniques and a systematic process are favoured. While Requirements Engineering has no standard methods, such as RUP in SE, Requirements Engineering nevertheless follows a process and applies a set of techniques to elicit, analyse, specify and validate requirements, for example the Volere method (Robertson & Robertson, 2002). In Software Engineering the nature of process guidance can vary from the substantial, as in RUP, to lightweight agile methods (Beck, 1999), which are similar to scenario-based design.
In HCI, development proceeds by user-centred design where iterative cycles of design exploration and user evaluation gradually refine the design to converge on a solution acceptable to users’ needs. No formal procedures for checking or testing the design are adopted. In contrast, Requirements Engineering places more emphasis on automated checking of specifications, often referred to as model checking. This involves automated checking of software specifications to ensure that the program code will eventually operate correctly and reliably. One of the most influential formal approaches to Requirements Engineering is the KAOS method and associated tools (Van Lamsweerde, 2009). KAOS follows the Requirements Engineering mainstream with a goal-oriented approach but takes specification further as goals are refined to lower-level detail expressing states that the system should achieve, maintain or avoid. Model checkers then validate whether the goals can be achieved by the specified procedures. KAOS supports Requirements Engineering with tools, so constraints, assumptions and barriers to goals, called obstacles, can be assessed; for instance, what assumptions are necessary for a particular goal to be achieved? This just gives the gist of what KAOS and its support tools GRAIL can do; in reality it is more complex, with a temporal logic that also enables reasoning about when goals can be achieved. However, KAOS and all formal Software Engineering approaches do assume that considerable detail is known about the specification and the system environment. This is a key point of divergence with HCI, which conceptualises development as a more dynamic process where knowledge is partial.HCI used to have an interest in formal analysis but this has waned over the years, although it is still active (Thimbleby, 2007) with similar interests in model checking.
13.5 Design Advice and Knowledge Reuse
Both HCI and Requirements Engineering reuse knowledge, although in different ways. In Requirements Engineering, product-line requirements are the main approach to reuse, in which requirements are associated with a set of related designs in a particular application domain. Product lines are variations on a theme, common in engineering sectors; for example, automotive industry software for engine control and braking systems. Requirements can be categorised as common core requirements shared by many applications and variation points: requirements which change between different design versions. Requirements Engineering has adopted methods from the wider field of software reuse which creates hierarchy diagrams of features, showing points in the feature decomposition where tailoring may occur. In Requirements Engineering, processes have been researched for managing product-line requirements to plan releases and to prioritise variations and versions. (Finkelstein et al., 2008).
Requirements reuse has received less attention, although some generalised requirements have been proposed in studies of aero engine controllers (Lam et al., 1997); and, at a more abstract level, a library of reusable, generic requirements was associated with abstract problem models (Sutcliffe,2002a). These abstract models are distant relatives of more detailed and domain-specific product lines, so reuse is intended to provide tools for thought during the requirement process rather than specifications which can be customised. In Requirements Engineering the most abstract reuse model is Problem Frames (Jackson, 2001), which describes high-level requirements in terms of dependencies between software processes and their external environment. Four problem frames describe monitoring and controlling devices (required behaviour), responding to external commands (commanded behaviour), editing and updating states (workpieces) and general transformations. Abstract problem models provide more detail with 11 families of problems including transactions, hiring, monitoring control, logistics and tracking.
HCI places considerable emphasis on reuse of knowledge. Copious quantities of guidelines have been produced (ISO1997, 1998) with principles and heuristics as a more general expression of design advice (Benyon & Macaulay, 2002). The task-artefact cycle, illustrated in Figure 14 (Carroll, 2000), promotes reuse via artefacts which are design examples that can be organised in families similar to product lines (Sutcliffe, 2000b), although artefacts tend to be motivated by interaction design concerns rather than by functionality, as in product-line requirements. Artefacts are associated with claims which encapsulate design trade-offs as upsides and downsides in a similar manner to design rationale. Claims are also associated with scenarios of use to anchor the design advice in a realistic setting.
Author/Copyright holder: Unknown (pending investigation). Copyright terms and licence: Unknown (pending investigation). See section "Exceptions" in the copyright terms below.
Figure 13.14: Task-artefact cycle for creating reusable knowledge in HCI
The upsides and downsides in claims present usability arguments as trade-offs in psychologically based design rationale. Claims are generated by implementing a design, evaluating the usability of the implemented artefact, then extracting the claim and iteratively improving the design. The artefact becomes an example that instantiates the claim, while the claim and links to theory provide justification about why the claim should deliver usability, with supplementary information on dependencies and design trade-offs. See Figure 15.
Claim ID: | Colour-coded Telegraphic Display |
Author: | Singley, M.K.; Carroll, J.M. |
Artifact: | MoleHill tutor - Goalposter tool |
Description: | A colour-coded telegraphic display of goals |
Upside: | Provides persistent feedback on the correctness of actions, as well as access to further information |
Downside: | Learners must learn the display’s feature-language and controls |
Scenario: | The presentation of individual goals in the window is telegraphic, several words at most. However, the learner can expand any of the telegraphic goals (through a menu selection) to display a fuller explanation of why the goal is worthwhile pursuing or not. Thus the system provides both shorthand feedback on correctness and access to further help. |
Figure 13.15: Example of a claim (after Carroll et al., 1992)
Claims offer more targeted delivery of HCI knowledge than do guidelines, by virtue of the task-artefact cycle that provides a context. Claims have a domain-specific anchor in the artefact context; however, they can be linked to generic problem models to give a wider context for reuse (Sutcliffe & Carroll, 1998; Sutcliffe, 2002a); for example, human factors problems are associated with monitoring tasks or transaction processing for hiring/loans, sales, and logistics/distribution, etc. Furthermore, claims can be associated with interaction patterns to relate HCI knowledge to Software Engineering use cases.
-- Purchase Process --
Problem
Users want to purchase an already selected product
Solution
Present users with the purchase steps
[Example from www.bn.com]
Use when
The site allows purchasing of goods, typically an E-commerce Site but it can also be a site that happens to sell products as well such as a Museum Site. A purchase can also be part of larger tasks such as a Booking.
How
In order to purchase the products in the cart they need to select the checkout action. The checkout is a five step Purchase Process with the following tasks:
Identify the client
Select shipping address and special options
Select payment method
See overview of the entire order
Confirm and place order
Receive confirmation by email
The users can abort the checkout procedure at any step. When users retry the checkout later, they start again at the first task. Consider a Wizard to guide the user through these tasks while minimizing the number of web pages used. However, a wizard is not always needed for just a purchase. Often sites ask for details that are not strictly necessary to process the order. In many cases, all of the order information may easily fit on one page and hence eliminating the need for a wizard.
Minimize navigation and non-relevant page elements
Since purchasing is a task that requires quite some focus, the standard page layout during the purchase process has to be simplified. Sub-navigation and contextual elements should not be shown. All distracting elements should be removed.
User Login
Many sites require users to Login as the first step of the process. While this is convenient for returning customers because all their personal data can be re-used, it is not very nice for new users. New customers should be allowed to purchase items without creating an account. At the end of a purchase, users can be asked to Registration. Registration can then be made very simple because all the basic data has already been captured during the purchase process, only the username and password still needs to be selected.
Confirmation by email
It is important to "give" the users something that is easily accessible after the browser has been closed. An email with the information about the purchase is like a "receipt" for users. It should contain an order number, list of items in the order, all amount, shipping address, payment information, date of placing order. It should also contain help for users how to track they order, cancel it, or request assistance.
Why
First time customers or infrequent customers are best helped with a Wizard that allows the user to complete the purchase in small steps. Returning customers usually use the same shipping address and same credit-card. Therefore the process can be more efficiently done in only one overview screen with a "purchase" button.
Figure 13.16: Example of an HCI pattern for design of e-commerce purchase interaction
This view of claims is similar to patterns which are shared by both disciplines. Patterns record reusable design advice with an example of its use, a motivating scenario, description of the contents for application,and forces: essentially trade-offs of advantages and disadvantages. In HCI, patterns tend to focus on user interface problems and designs (Tidwell, 2005), while Software Engineering patterns range from low-level software solutions (Gamma et al., 1995) to higher-level processes and designs (Coplein, 1996). Patterns recommend that design advice is presented in the context of a motivating problem, and with an example of its application (Borchers, 2001). Although patterns do have a clause that indicates the range of problems the design advice can be applied to, this scoping is ad hoc. Advocates of patterns propose relationships between individual patterns constructed into a hypertext-like pattern network or language (Alexander et al., 1977) to set the context. Unfortunately, pattern languages are also ad hoc and tend to be incomplete.
An example of an HCI pattern from the van Welie collection (www.welie.com) is illustrated in abbreviated form in Figure 16.
The pattern describes the problem context that it applies to and is then gives a solution with examples. Links are given to related patterns and some pattern formats add Forces to give arguments about the advantages and disadvantages of using the pattern.
13.6 Conclusions and Future Directions
HCI and RE hold many common views about the design process. Both disciplines advocate iterative design cycles with testing and evaluation, although the degree of user-centredness varies. One topic neglected by both disciplines is deciding the automation boundary. This has been researched in human factors where methods and heuristics for functional allocation decide which process should be fully automated, manually operated or shared human-computer cooperation (Wright et al., 2000; Sutcliffe, 2002c). However, in Requirements Engineering this issue is rarely addressed and mainstream HCI assumes that a user interface boundary emerges from the process of design exploration.
While HCI has become less method-oriented with time, Requirements Engineering has maintained a more systematic engineering approach. Methods, guidelines, principles and models are rarely used explicitly by expert designers (Guindon & Curtis, 1988). Scenario-based design is the closest that HCI comes to a systematic method, although the approach may be regarded as tools for thought rather than step-by-step guidance. Scenarios, as Carroll suggests, support the design process at runtime as probes to test assumptions and stimulate creation. Scenarios can stimulate thought, but knowledge can only be reused effectively in a generalised form as claims, principles and guidelines.
HCI has expanded its focus from goal-oriented office work-style applications to user experience in entertainment and product design (Hassenzahl, 2010; Sutcliffe, 2009), with the role of emotion and feelings being recognised as important requirements for successful interactive systems (Norman, 2004). Requirements Engineering, in contrast, has barely acknowledged that goal-oriented applications exist apart from the occasional treatment of emotional requirements (Callele et al., 2006) and values (Thew et al., 2008). Requirements Engineering needs to expand its endeavour to encompass user-experience requirements and value-based design (Cockton, 2009).
On the other hand, HCI can benefit from Requirements Engineering by rediscovering past research into systematic specification where these concerns are paramount in safety-critical applications. Techniques for obstacle analysis (Van Lamsweerde, 2009) and reasoning about assumptions and user preferences (Jureta et al., 2008) could be usefully incorporated into HCI.
Finally, both disciplines need to recognise the changing nature of software as applicationsbecome more intelligent, self-aware and adaptable. In Requirements Engineering, requirements for intelligent applications are still research agendas (Sawyer et al., 2010), while in HCI intelligent user interfaces are present in recommenders and attentional user interfaces as well as occupying the IUI conference series in their own right. However, requirements and human-centric design of intelligent and socially networked software are future challenges for both disciplines.
13.7 Where to learn more
13.7.1 Textbooks
The most comprehensive text book is Van Lamsweerde (2009), Requirements engineering: From system goals to UML models to software specifications. Chichester: Wiley.
Lamsweerde, Axel van (2009): Requirements Engineering: From System Goals to UML Models to Software Specifications. Wiley
13.7.2 Journals and Conference Series
The main journal of the discipline isRequirements Engineering (Springer). Proceedings of the IEEE International Conference on Requirements Engineering are available from 2002 onwards; before 2002 there were two separate conferences: the IEEE Symposium of Requirements Engineering, and the International Conference on Requirements Engineering.
13.7.3 Requirements Engineering
13.7.3.1 RE - IEEE International Conference on Requirements Engineering
20082007200620052004200320022001200019991998199719961995
See also IEEE Software, Information and Software Technology, Journal of Information Technology.
13.7.4 IEEE Software Magazine
13.7.5 Information and Software Technology
13.7.6 Journal of Information Technology
2006
13.7.7 Internet
The Requirements Engineering Specialist Group (of the British Computer Society, www.resg.org.uk/) provides a comprehensive listing of RE resources, tools and a bibliography;the group publishes a Newsletter listing events with reviews and informal articles.
13.7.8 Related Fields
The journals Human Computer Interaction, Software Engineering, Proceedings of the International Conference on Software Engineering (ICSE) and the IEEE Transactions on Software Engineering publish RE-related articles. See Proceedings of the Participatory Design Conferences for a Scandiavian view of the RE process.
13.7.9 IEEE Transactions on Software Engineering
13.7.10 Human Computer Interaction
13.7.10.1 PDC - International Conference on Participatory Design
13.8 References
Alexander, Christopher, Ishikawa, Sara and Silverstein, Murray (1977): A Pattern Language. Oxford University Press
Beck, Kent (1999): Extreme Programming Explained: Embrace Change. Reading, MA, Addison-Wesley Publishing
Bellotti, Victoria (1988): Implications of Current Design Practice for the Use of HCI Techniques. In: Jones, Dylan M. and Winder, R. (eds.) Proceedings of the Fourth Conference of the British Computer Society Human Computer Interaction Specialist Group - People and Computers IV August 5-9, 1988, University of Manchester, UK. pp. 13-34
Benyon, David and Macaulay, Catriona (2002): Scenarios and the HCI-SE design problem. In Interacting with Computers, 14 (4) pp. 397-405
Boehm, Barry W. (1981a): Software Engineering Economics. Prentice Hall
Boehm, Barry W (1981b): Software Engineering Economics. In IEEE Transactions on Software Engineering, 16 (1) pp. 4-21
Boehm, Barry, Bose, Prasanta, Horowitz, Ellis and Lee, Ming-June (1994): Software requirements as negotiated win conditions. In Proceedings of IEEE International Conference on Requirements Engineering, pp. 74-83
Borchers, Jan O. (2001): A Pattern Approach to Interaction Design. John Wiley and Sons
Borchers, Jan O. (2000): A Pattern Approach to Interaction Design. In: Proceedings of DIS00: Designing Interactive Systems: Processes, Practices, Methods, & Techniques 2000. pp. 369-378
Bubenko, Janis A. and Kirikova, Marite (1994). Enterprise Modelling: Improving the Quality of Requirements Specifications.
Callele, David, Neufeld, Eric and Schneider, Kevin (2006): Emotional Requirements in Video Games. In: 14th IEEE International Conference on Requirements Engineering RE 2006 11-15 September, 2006, Minneapolis/St.Paul, Minnesota, USA. pp. 292-295
Carroll, John M. (2002): Making use is more than a matter of task analysis. In Interacting with Computers, 14 (5) pp. 619-627
Carroll, John M. (2000): Making Use: Scenario-Based Design of Human-Computer Interactions. MIT Press
Carroll, John M. (ed.) (1995): Scenario-Based Design: Envisioning Work and Technology in System Development.John Wiley and Sons
Carroll, John M., Singley, Mark K. and Rosson, Mary Beth (1992): Integrating Theory Development with Design Evaluation. In Behaviour and Information Technology, 11 (5) pp. 247-255
Carroll, John M., Alpert, Sherman R., Karat, John, Deusen, Mary S. Van and Rosson, Mary Beth (1994): Raison d'Etre: capturing design history and rationale in mutimedia narratives. In: Plaisant, Catherine (ed.) Conference on Human Factors in Computing Systems, CHI 1994, Boston, Massachusetts, USA, April 24-28, 1994, Conference Companion 1994. p. 213
Checkland, Peter (1981): Systems Thinking, Systems Practice: Includes a 30-Year Retrospective. Wiley
Cockburn, Alistair (2000): Writing Effective Use Cases. Addison-Wesley Professional
Cockton, Gilbert (2009): Getting there: six meta-principles and interaction design. In: Proceedings of ACM CHI 2009 Conference on Human Factors in Computing Systems 2009. pp. 2223-2232
Conklin, Jeff and Begeman, Michael L. (1988): gIBIS: A Hypertext Tool for Exploratory Policy Discussion. In: Greif, Irene (ed.) Proceedings of the 1988 ACM conference on Computer-supported cooperative work September 26 - 28, 1988, Portland, Oregon, United States. pp. 140-152
Conklin, Jeff and Begeman, Michael L. (1988a): gIBIS: A Hypertext Tool for Exploratory Policy Discussion. In ACM Transactions on Information Systems, 6 (4) pp. 303-331
Dardenne, Anne, Lamsweerde, Axel van and Fickas, Stephen (1993): Goal-directed requirements acquisition. InScience of Computer Programming, 20 (1) pp. 3-50
Davenport, Thomas H. (1992): Process Innovation: Reengineering Work Through Information Technology. Harvard Business Press
Dearden, Andy, Harrison, Michael and Wright, Peter C. (2000): Allocation of Function: Scenarios, Context and the Economics of Effort. In International Journal of Human-Computer Studies, 52 (2) pp. 289-318
Diaper, Dan (2001): Task analysis for knowledge descriptions (TAKD): a requiem for a method. In Behaviour and Information Technology, 20 (3) pp. 199-212
Diaper, Dan and Johnson, Peter (1989): Task analysis for knowledge descriptions: Theory and application in training. In: Long, John and Whitefield, A. (eds.). "Cognitive Ergonomics and Human-Computer Interaction (Cambridge Series on Human-Computer Interaction)". Cambridge University Press
Djajadiningrat, J. P., Gaver, William W. and Fres, J. W. (2000): Interaction Relabelling and Extreme Characters: Methods for Exploring Aesthetic Interactions. In: Proceedings of DIS00: Designing Interactive Systems: Processes, Practices, Methods, & Techniques 2000. pp. 66-71
Eason, K. D., Harker, S. D. P. and Olphert, C. W. (1996): Representing socio-technical systems options in the development of new forms of work organisation. In European Journal of Work and Organisational Psychology,
Eden, Colin (1988): Cognitive mapping. In European Journal of Operational Research, 36 (1) pp. 1-13
Fenton, Norman E. (1995): The role of measurement in software safety assessment. In: 12th Annual CSR/ENCRESS Conference on Software Safety Case 13 Sept, 1995, Bruges, Belgium.
Finkelstein, Anthony, Harman, Mark, Mansouri, S. Afshin, Ren, Jian and Zhang, Yuanyuan (2008): "Fairness Analysis" in Requirements Assignments. In: Proceedings of the 2008 16th IEEE International Requirements Engineering Conference 2008. pp. 115-124
Gamma, Erich, Helm, Richard, Johnson, Ralph and Vlissides, John (1995): Design Patterns: Elements of reusable object-oriented software. Addison-Wesley Publishing
Gause, Donald C. and Weinberg, Gerald M. (1989): Exploring Requirements: Quality Before Design. Dorset House Publishing Company, Incorporated
Goguen, Joseph A. and Linde, Charlotte (1993): Techniques for requirements elicitation. In 1993 Proceedings of the IEEE International Symposium on Requirements Engineering, pp. 152-164
Gould, John D. (1987): How to Design Usable Systems. In: Bullinger, Hans-Jorg and Shackel, Brian (eds.)INTERACT 87 - 2nd IFIP International Conference on Human-Computer Interaction September 1-4, 1987, Stuttgart, Germany. pp. xxxv-xli
Graham, Ian M. (1996): Task scripts, use cases and scenarios in object oriented analysis. In Object Oriented Systems, 3 pp. 123-142
Graham, Ian (): Task scripts, use cases and scenarios in objectoriented analysis. In: Object-Oriented Systems .
Guindon, Raymonde and Curtis, Bill (1988): Control of Cognitive Processes During Software Design: What Tools Are Needed?. In: Soloway, Elliot, Frye, Douglas and Sheppard, Sylvia B. (eds.) Proceedings of the ACM CHI 88 Human Factors in Computing Systems Conference June 15-19, 1988, Washington, DC, USA. pp. 263-268
Hassenzahl, Marc (2010): Experience Design: Technology for All the Right Reasons. Morgan and Claypool Publishers
Hauser, John R. and Clausing, Don (1988): The House of Quality. In Harvard Business Review, 66 (3) pp. 63-73
Holland, Christopher P. (1995): Cooperative supply chain management: the impact of interorganizational information systems. In Journal of Strategic Information Systems, 4 (2) pp. 117-133
Hughes, John A., O'Brien, Jon, Rodden, Tom, Rouncefield, Mark and Sommerville, Ian (1995): Presenting ethnography in the requirements process. In: Second IEEE International Symposium on Requirements Engineering 1995 March 27 - 29, 1995, York, England. pp. 27-39
Jackson, Michael (2000): Problem Frames: Analysing & Structuring Software Development Problems. Addison-Wesley Professional
Jackson, Michael (2001): Problem Frames: Analysing & Structuring Software Development Problems. Addison-Wesley Professional
Jackson, Michael and Zave, Pamela (1993): Domain Descriptions. In RE, pp. 56-64
Jacobson, Ivar, Christerson, Magnus, Jonsson, Patrik and Övergaard, Gunnar (1992): Object-oriented software engineering: A use-case driven approach. Reading, MA, Addison-Wesley Publishing
Johnson, Peter, Johnson, Hilary, Waddington, Ray and Shouls, Alan (1988): Task-Related Knowledge Structures: Analysis, Modelling and Application. In: Jones, Dylan M. and Winder, R. (eds.) Proceedings of the Fourth Conference of the British Computer Society Human Computer Interaction Specialist Group - People and Computers IV August 5-9, 1988, University of Manchester, UK. pp. 35-62
Johnson, W. Lewis, Feather, Martin S. and Harris, David R. (1992): Representation and Presentation of Requirements Knowledge. In IEEE Trans. Software Eng., 18 (10) pp. 853-869
Jureta, Ivan, Mylopoulos, John and Faulkner, Stéphane (2008): Revisiting the Core Ontology and Problem in Requirements Engineering. In: 16th IEEE International Requirements Engineering Conference RE 2008 8-12 September, 2008, Barcelona, Catalunya, Spain. pp. 71-80
Kaindl, Hermann (1995): An integration of scenarios with their purposes in task modeling. In: Proceedings of the 1st conference on Designing interactive systems processes, practices, methods, and techniques 1995. pp. 227-235
Kethers, Stefanie and Jacobs, Stephan (1994): Improving Communication and Decision Making within Quality Function Deployment. In: First International Conference on Concurrent Engineering, Research, and Application1994.
Kuuti, Kari (1995): Workprocess: Scenarios as a preliminary vocabulary. In: Carroll, John M. (ed.). "Scenario-Based Design: Envisioning Work and Technology in System Development". John Wiley and Sonspp. 19-36
Kyng, Morten (1995): Creating contexts for design. In: Carroll, John M. (ed.). "Scenario-Based Design: Envisioning Work and Technology in System Development". John Wiley and Sonspp. 85-108
Lam, W., McDermid, John A. and Vickers, Andrew (1997b): Ten Steps Towards Systematic Requirements Reuse. InRequir. Eng., 2 (2) pp. 102-113
Lam, W., McDermid, John A. and Vickers, Andrew (1997): Ten Steps Towards Systematic Requirements Reuse. In:3rd IEEE International Symposium on Requirements Engineering RE97 January 5-8, 1997, Annapolis, MD, USA. pp. 6-15
Lamsweerde, Axel van (2009): Requirements Engineering: From System Goals to UML Models to Software Specifications. Wiley
Lamsweerde, Axel van and Letier, Emmanuel (2000): Handling Obstacles in Goal-Oriented Requirements Engineering. In IEEE Trans. Software Eng., 26 (10) pp. 978-1005
Lamsweerde, Axel van, Darimont, R. and Massonet, P. (1995): Goal-directed elaboration of requirements for a meeting scheduler: problems and lessons learnt. In RE, pp. 194-203
Luff, Paul, Jirotka, Marina, Heath, Christian C. and Greatbatch, David (1993): Tasks and social interaction: the relevance of naturalistic analyses of conduct for requirements engineering. In: Proceedings of IEEE International Symposium on Requirements Engineering 1993 1993, San Diego, CA , USA . pp. 187-190
Macaulay, L. (1993): Requirements capture as a cooperative activity. In: Proceedings of IEEE International Symposium on Requirements Engineering 1993 1993, San Diego, CA , USA . pp. 174-181
MacLean, Allan, Young, Richard M., Bellotti, Victoria and Moran, Thomas P. (1991): Questions, Options, and Criteria: Elements of Design Space Analysis. In Human-Computer Interaction, 6 (3) pp. 201-250
Maiden, N. A. M. and Ncube, C. (1998): Acquiring requirements for Commercial Off-The-Shelf package selection. InIEEE Software, 15 (2) pp. 46-56
Maiden, N. A. M. and Rugg, G. (1994): Knowledge acquisition techniques for requirements engineering. In:Proceedings of the Workshop on Requirements Elicitation for System Specification 12-14 July, 1994, Keele, University of Keele.
Maiden, N. A. M. and Sutcliffe, Alistair G. (1994): Requirements critiquing using domain abstractions. In:Requirements Engineering 1994 - Proceedings of the First International Conference on Requirements Engineering 1994, Colorado Springs, CO , USA. pp. 184-193
Monk, Andrew, Wright, Peter, Haber, Jeanne and Davenport, Lora (1993): Improving Your Human-Computer Interface: A Practical Technique (Bcs Practitioner). Prentice Hall
Mylopoulos, John, Chung, Lawrence and Nixon, Brian (1992): Representing and using nonfunctional requirements: a process-oriented approach. In IEEE Transactions on Software Engineering, 18 (6) pp. 483-497
Mylopoulos, John, Chung, Lawrence and Yu, Eric S. K. (1999): From Object-Oriented to Goal-Oriented Requirements Analysis. In Communications of the ACM, 42 (1) pp. 31-37
Norman, Donald A. (2004): Emotional Design: Why We Love (Or Hate) Everyday Things. Basic Books
Nuseibeh, Bashar and Easterbrook, Steve M. (2000): Requirements engineering: a roadmap. In: ICSE - Future of SE Track 2000 2000. pp. 35-46
Pohl, Klaus (1996): Process-Centered Requirements Engineering (Advanced Software Development Series).Research Studies Press
Porter, Michael E. (1980): Competitive Strategy: Techniques for Analyzing Industries and Competitors. Free Press
Potts, Colin (1999): ScenIC: A Strategy for Inquiry-Driven Requirements Determination. In: 4th IEEE International Symposium on Requirements Engineering RE 99 7-11 June, 1999, Limerick, Ireland. pp. 58-65
Potts, Colin, Takahashi, K. and Anton, A. I. (1994): Inquiry-based requirements analysis. In IEEE Software, 11 (2) pp. 21-32
Potts, Colin, Takahashi, Kenji, Smith, Jeffrey D. and Ota, Kenji (1995): An evaluation of inquiry-based requirements analysis for an Internet service. 1995. pp. 172-180
Robertson, Suzanne and Robertson, James (1999): Mastering the Requirements Process. Addison-Wesley Professional
Rockart, J. F. and Short, J. E. (1991): The networked organisation and the management of interdependence. In:Morton, Michael S. Scott (ed.). "The Corporation of the 1990s: Information Technology and Organizational Transformation". Oxford University Press, USA
Rodden, Tom (1999): Human factors in requirements engineering: - A survey of human sciences literature relevant to the improvement of dependable systems development processes. In Interacting with Computers, 11 (6) pp. 665-698
Rodriguez, F. Gamboa and Scapin, D. L. (1997): Editing MAD* task description for specifying interfaces, at both semantic and presentation level. In: Design, specification and verification of interactive systems 1997 1997.
Rolland, C., Achour, C. Ben, Cauvet, C., Ralyté, J., Sutcliffe, Alistair G., Maiden, N., Jarke, M., Haumer, P., Pohl, Klaus, Dubois, E. and Heymans, P. (1998): A proposal for a scenario classification framework. In Requirements Engineering, 3 (1) pp. 23-47
Sawyer, Peter, Bencomo, Nelly, Whittle, Jon, Letier, Emmanuel and Finkelstein, Anthony (2010): Requirements-Aware Systems: A Research Agenda for RE for Self-adaptive Systems. In: RE 2010, 18th IEEE International Requirements Engineering Conference, Sydney, New South Wales, Australia, September 27 - October 1, 20102010. pp. 95-103
Shum, S. Buckingham (1996): Analyzing the usability of a design rationale notation. In: Moran, Thomas P. andCarroll, John M. (eds.). "Design Rationale: Concepts, Techniques, and Use (Computers, Cognition, and Work Series)". CRC Press
Stapleton, Jennifer and Constable, Peter (1997): DSDM: Dynamic Systems Development Method: The Method in Practice. Addison-Wesley Professional
Sutcliffe, Alistair G. (2002c): The Domain Theory: Patterns for Knowledge and Software Reuse. CRC Press
Sutcliffe, Alistair G. (1997): Task-Related Information Analysis. In International Journal of Human-Computer Studies, 47 (2) pp. 223-257
Sutcliffe, Alistair G. (1995): Requirements Rationales: Integrating Approaches to Requirement Analysis. In:Proceedings of DIS95: Designing Interactive Systems: Processes, Practices, Methods, & Techniques 1995. pp. 33-42
Sutcliffe, Alistair G. (2000): Bridging the communications gap: developing a Lingua Franca for software developers and users. In: Actes du XVIIIe Congres 2000 2000, Toulouse, France. pp. 13-32
Sutcliffe, Aiistair (2009): Designing for User Engagement: Aesthetic and Attractive User Interfaces. In Synthesis Lectures on HumanCentered Informatics, 2 (1) pp. 1-55
Sutcliffe, Alistair G. (2002): Modelling collaboration in loosely coupled inter-organisational relationships. In: Systems engineering for business process change 2002. pp. 347-366
Sutcliffe, Alistair G. (2000a): On the Effective Use and Reuse of HCI Knowledge. In ACM Transactions on Computer-Human Interaction, 7 (2) pp. 197-221
Sutcliffe, Alistair G. (2002a): User-Centred Requirements Engineering. Springer
Sutcliffe, Alistair G. and Carroll, John M. (1998): Generalizing Claims and Reuse of HCI Knowledge. In: Johnson, Hilary, Nigay, Laurence and Roast, C. R. (eds.) Proceedings of the Thirteenth Conference of the British Computer Society Human Computer Interaction Specialist Group - People and Computers XIII August 1-4, 1998, Sheffield, UK. pp. 159-176
Sutcliffe, Alistair G. and Ryan, Michele (1997): Assessing the usability and efficiency of Design Rationale. In: Howard, Steve, Hammond, Judy and Lindgaard, Gitte (eds.) Human-Computer Interaction, INTERACT 97, IFIP TC13 Interantional Conference on Human-Computer Interaction, 14th-18th July 1997, Sydney, Australia 1997. pp. 148-155
Sutcliffe, Alistair G., Fickas, Stephen and Sohlberg, McKay Moore (2005): Personal and Contextual Requirements Engineering. In: 13th IEEE International Conference on Requirements Engineering RE 2005 29 August - 2 September, 2005, Paris, France. pp. 19-30
Thew, Sarah, Sutcliffe, Alistair G., Bruijn, Oscar de, McNaught, John, Procter, Rob, Venters, Colin and Buchan, Iain (2008): Experience in e-Science Requirements Engineering. In: 16th IEEE International Requirements Engineering Conference RE 2008 8-12 September, 2008, Barcelona, Catalunya, Spain. pp. 277-282
Thew, Sarah, Sutcliffe, Alistair G., Procter, Rob, Bruijn, Oscar de, McNaught, John, Venters, Colin C. and Buchan, Iain (2009): Requirements Engineering for E-science: Experiences in Epidemiology. In IEEE Software, 26 (1) pp. 80-87
Thimbleby, Harold (2007): Press On: Principles of Interaction Programming. The MIT Press
Tidwell, Jenifer (2005): Designing Interfaces: Patterns for Effective Interaction Design. O'Reilly and Associates
Veer, Gerrit C Van Der, Lenting, Bert F and Bergevoet, Bas A J (1996): GTA : Groupware Task Analysis - Modeling Complexity. In Acta Psychologica, 91 (3) pp. 297-322
Vicente, Kim J. (2000): HCI in the Global Knowledge-Based Economy: Designing to Support Worker Adaptation. In ACM Transactions on Computer-Human Interaction, 7 (2) pp. 263-280
Viller, Stephen, Bowers, John and Rodden, Tom (1999): Human Factors in Requirements Engineering: A Survey of Human Sciences Literature Relevant to the Improvement of Dependable Systems Development Processes. InInteracting with Computers, 11 (6) pp. 665-698
Wright, Peter C., Dearden, Andy and Fields, Bob (2000): Function Allocation: A Perspective from Studies of Work Practice. In International Journal of Human-Computer Studies, 52 (2) pp. 335-355
Yu, E.S.K. (1993): Modeling organizations for information systems requirements engineering. In 1993 Proceedings of the IEEE International Symposium on Requirements Engineering, pp. 34-41
Zave, Pamela (1995): Classification of research efforts in requirements engineering. In: Second IEEE International Symposium on Requirements Engineering 1995 March 27 - 29, 1995, York, England. pp. 214-216
