Introduction
Introduction
This document is a collection of approaches and methods (together loosely called practices) for user-based requirements engineering produced by the RESPECT project. We intend this term to mean: eliciting from users what they want, developing with assistance from users a representation of what the system under design should look like, and verifying or confirming with users that this is what will satisfy their needs.
A recent review of software engineering orientated requirements engineering practices by Loucopoulos and Karakostas [6] stresses that requirements engineering still lacks consensus as to what exactly constitutes software requirements engineering as a whole but presents a model in terms of three stages: elicitation, representation, and validation. These terms are likely to be more familiar to the software engineer but it will be seen that they map onto the terms used in the definition of user-based requirements engineering given above. At present there is no commonly accepted interdisciplinary framework which takes account of the wide range of criteria and practices relevant to studies of both software engineering and human-computer interaction [9].
We will argue elsewhere that some of the problems with requirements engineering raised by Loucopoulos and Karakostas can be resolved with reference to a greater focus on the needs of the end user. However, the methods described in section 2 do not deal with important issues such as data modelling [6], and the specification and validation of requirements such as Reliability, and Efficiency [3]. For these, a thorough grounding in software engineering principles and methods has always been, and continues to be essential.
A standard text on information systems design, current throughout the 1980s, writes:
The bottom line to systems work, and in particular the gathering of study facts and their analysis, is to extract from a group of people their knowledge, ideas, and needs [2].
The text advocates a number of ways in which facts may be gathered; but as far as people are concerned, it leans on interviews, surveys, and naturalistic observation (the emphasis on ‘desk research’, ie looking at documents generated by the commissioning company is typical of the period). The extremely concise text by Olle and colleagues, first published at the end of the 1980s and current through the early 1990s [8], views design methodologies as processes that take the design team at least part-way through an intricate information systems methodology framework of which the system design is a part-way product. Olle et al write that "The system design stage consists of preparing a prescriptive statement about an information system..."
and that furthermore
The user acceptor must, in order to fulfil his or her role, be able to judge whether the information system to be built will meet his or her needs.
The role of the user into the lifecycle of such a document is classically viewed as (1) to provide input and (2) to sign off the end result. But as Olle et al write: "the lack of comment (to this process) from users has all too frequently been accepted as approval."
Comment from end users may not achieve its purpose for a number of reasons; chief among them being that the non-technical end user may not understand the notations and language used in a software engineering requirements specification, and be unable to visualise or predict the end result of a development process based on such a specification.
This state of affairs may not matter too much if systems are designed for use in batch mode, where the end users’ interaction with the system is limited or at least well-buffered by specialists (it is useful to remember that it was WW Royce who first proposed the so-called waterfall life cycle model in the batch-computing days of the early 1970s), but as interactive computing became increasingly ubiquitous, and as the level of involvement of the users with the system became increasingly intensive, this mind set became increasingly pernicious. Two issues raise themselves with particular force:
For in addition to the increased amount of interactivity in contemporary information systems, we have to face the fact that such systems are also going to embody, to increasingly greater extents, options for end user originated customisation and fine tuning and may have to cope with data processing demands that cannot be foreseen by the design team or even the user representatives themselves.
Thus requirements engineering is no longer a case of analysing the ‘tasks’ the users will have to ‘complete’ with the software, but of exploring the latent possibilities of the medium and approach being adopted by the development project, and ensuring that these possibilities will be easily available to the user.
Rubin [7] emphasises that it is not enough simply to focus on users. He writes:
In the worst cases, I have seen entire engineering teams trek across several continents on a tour of customer sites, only to return with a myriad of conflicting information documented and filed away on unstructured trip reports. Unfortunately, this volume of information and huge effort served little useful purpose.
The key solution is to collect perhaps less information to start with, but to verify it more frequently. Although the word ‘prototyping’ has by now a specialised technical meaning as in ‘rapid prototyping’, in fact any representation of the system is technically speaking a prototype. This can be anything from a sketch on a back of an A4 pad to a miniature working model. Distinctions are usefully made between ‘horizontal’ and ‘vertical’ prototypes [5], where a ‘horizontal’ prototype is an overview of a large part of the system, and a ‘vertical’ one is a more detailed view of a smaller self-contained segment. T
he essence of true iterative design which is open to feedback from end users is that the team is able, following Rubin, to "shape the product" through a process of design, test, redesign and retest.
Isensee and Rudd [5] summarise studies that claim that 60% to 80% of all system problems can be traced back to inaccurate requirements definitions, so it is not surprising to read that in 1992, 87% of developers from a large US sample reported using some kind of iterative design strategy. So obviously prototyping makes sense, commercially. These authors also review an up-to-date collection of software based tools which may be used in the stages of prototyping where computer representations have become necessary, and the reader is referred to this invaluable resource.
The RESPECT model of user-based requirements engineering is detailed in [7], and is presented in outline here. It is an iterative process with three main stages, described as follows. Each stage may be returned to, but in practice we would expect to see considerable iteration within stages, possibly using a time-boxing principle.
Stage 1 User Context Analysis
This consists of understanding the initial project requirement and performing an analysis of the main user groups, their tasks and working environments. Design constraints and relevant standards to be applied are identified.
Stage 2 Feasibility and Prototyping
This stage is concerned with concept development and representing possible concepts by means of scenarios, paper prototypes, software prototypes etc. This allows users to assimilate each concept easily and to comment on its feasibility. Different concepts are evaluated by comparing their characteristics, by assessing their cost/benefits for different user groups, and by testing them with users. The requirements specification is validated against user experience as it is developed.
Stage 3 User Requirements Synthesis
This stage integrates the user requirements identified in stages 1 and 2, and groups them ready for input into the design phase of system development. The different requirements groups include: concept description, general system characteristics, system functions (based on the tasks that must be performed), user-system interfaces, user support needs, physical and organisational characteristics, usability goals, and the approach for installing the system. A plan for implementing the user requirements is also developed.
For the purpose of the current document, the methods collected are summarised under each of these stages at the start of Part 2.
The following user-centred methods are current in software engineering treatments of user-based requirements work:
These methods are all relevant to the early user context analysis phase of user-based requirements work. However, they do not support in any strong way the feasibility and prototyping phase, nor do they support the important user requirements synthesis phase outlined in the current framework.
A view of how different aspects of requirements (business and market; user; and functional) can be successfully integrated as a spiral process in a realistic commercial environment is given in [4], which describes how users, usability engineers, system engineers, and developers are able to rapidly co-ordinate their efforts to produce a GUI design using an iterative methodology known as the Bridge. Of special interest here is how the Bridge methodology efficiently addresses the integration between the software product’s deep functionality in addition to the GUI ‘look and feel’.
Approaches such as these, as well as STUDIO [1] and GUIDE [10] will become increasingly prevalent as the software industry takes up the opportunities afforded by involving the end users in requirements engineering in order to create quality software products.
There is some confusion in terminology in this area, and the purpose of this section is to present a systematic terminology that the RESPECT project have found useful when dealing with these issues.
Models are generic descriptions of strategies in which development work may be carried out. It has become commonplace to talk of the ‘waterfall’ model of software development, while understanding that this model has many instantiations in different organisations—some instantiations are ‘official’ and some are ‘de facto’. The document by Maguire and Kirakowski emerging from Work Package 5 of the RESPECT project [7] presents a model of the user-based requirements engineering framework.
Approaches are generic in nature: they are simply broad classes of ways of doing things which may be instantiated in dozens of different ways. Thus for instance Wizard of Oz prototyping, or interviews. Approaches are ideas, sometimes quite extensively commented upon and discussed, but these ideas have to be developed and instantiated in order to be of any practical value. Very often, an approach only has practical value when it is instantiated in a particular company methodology.
Methods are ways of doing things, like recipes. Methods should be prescriptive, otherwise they are approaches, as discussed above. Examples of methods are Video Prototyping, or Usability Context Analysis. Methods have the characteristic that they can be employed in a variety of organisational circumstances, and they may have some necessary materials associated with them that can either be copied or purchased from the method developer, or developed anew. However, anybody should be able to apply a well-described method once it has been explained to them.
The reader is referred to [5] for a recent collection of software-based tools that may be pressed into use for prototyping.