Proceedings of IFIP 17th World Computer Congress, Montreal, Canada, 25-30 August 2002, p133-148. Kluwer Academic Publishers.

User requirements analysis
A review of supporting methods
Martin Maguire
Research School in Ergonomics and Human Factors Loughborough University, UK m.c.maguire@lboro.ac.uk

Nigel Bevan
Serco Usability Services, UK nbevan@usability.serco.com

Abstract:

Understanding user requirements is an integral part of information systems design and is critical to the success of interactive systems. However specifying these requirements is not so simple to achieve. This paper describes general methods to support user requirements analysis that can be adapted to a range of situations. Some brief case studies are described to illustrate how these methods have been applied in practice. user requirements, user-centred design, usability methods

Key words:

1.

INTRODUCTION

Understanding user requirements is an integral part of information systems design and is critical to the success of interactive systems. It is now widely understood that successful systems and products begin with an understanding of the needs and requirements of the users. As specified in the ISO 13407 standard (ISO, 1999), user-centred design begins with a thorough understanding of the needs and requirements of the users. The benefits can include increased productivity, enhanced quality of work, reductions in support and training costs, and improved user satisfaction. Requirements analysis is not a simple process. Particular problems faced by the analyst are: • addressing complex organisational situations with many stakeholders • users and designers thinking along traditional lines, reflecting the current system and processes, rather than being innovative • users not knowing in advance what they want from the future system (Olphert & Damodaran, 2002)

2 •

M. Maguire and N. Bevan

rapid development cycles, reducing the time available for user needs analysis • representing user requirements in an appropriate form. This paper considers how these problems can be addressed by selecting appropriate methods to support the process of user requirements generation and validation. It describes each method briefly and shows how it contributes to the requirements process. The basis for the application of different user requirements methods is a simple process as shown in Figure 1 below encompassing 4 elements:

Information gathering

User needs identification

Envisioning and evaluation

Requirements specification

Figure 1: General process for user requirements analysis

The four stages, and methods used to support the stages, are described in the next sections, followed by a summary table highlighting the advantages and disadvantages of each technique.

2.

INFORMATION GATHERING

The first step in user requirements analysis is to gather background information about the users and stakeholders and the processes that currently take place. The following methods may be adopted: Stakeholder analysis identifies all the users and stakeholders who may influence or be impacted by the system. This helps ensure that the needs of all those involved are taken into account. If required, the system is tested by them. User groups may include end users, supervisors, installers, and maintainers. Other stakeholders include recipients of output from the system, marketing staff, purchasers and support staff (Taylor, 1990). Stakeholder analysis identifies, for each user and stakeholder group, their main roles, responsibilities and task goals in relation to the system. One of the main issues is how to trade-off the competing needs of different stakeholder groups in the new system (see 4.5 Allocation of function and user cost-benefit analysis).

User requirements analysis

3

Secondary market research involves researching published sources such as research reports, census data, demographic information, that throw light upon the range of possible user markets. Websites representing special groups of users such as that for the Royal National Institute for the Blind (www.rnib.org.uk/digital) give information about the nature of the user population they represent (Mander & Smith, 2002). Context of use analysis is used when a system or product is developed. The quality of a system, including usability, accessibility and social acceptability factors, depends on having a very good understanding of the context of use of the system. For example, a bank machine (ATM) will be much more usable if it is designed for use at night as well as during the day, in bright sunlight as well as normal light, and by people in wheelchairs as well as those able to stand. Similarly in an office environment, there are many characteristics that can impinge on the usability of a new software product e.g. user workload, support available, or interruptions. Capturing contextual information is therefore important in helping to specify user requirements. In order to gather contextual information, stakeholders attend a facilitated meeting, called a Context Meeting. Here a questionnaire is completed to capture the characteristics of the users, their tasks and operating environment (see main headings in Table 1 below).
User group • System skills and experience. • Task knowledge. • Training. • Qualifications. • Language skills. • Age & gender. • Physical and cognitive capabilities. • Attitudes and motivations. Physical environment • Auditory environment. • Thermal environment. • Visual environment. • Vibration. • Space and furniture. • User posture. • Health hazards. • Protective clothing & equipment. • • • • • • • • • • • • • • • •
Technical environment Tasks • Hardware. Task list. • Software. Goal. • Network. Output. • Reference materials. Steps. • Other equipment. Frequency. Importance. Duration. Dependencies. Organisational environment Work practices. Assistance. Interruptions. Management & communications structure. Computer use policy. Organisational aims. Industrial relations. Job characteristics.

Table 1. Context of use factors

Context of use analysis was one of the outcomes of the ESPRIT HUFIT project and developed further in the ESPRIT MUSiC project (Bevan and Macleod, 1994). Context of use analysis within usability activities are also reviewed in Maguire (2001c).

4

M. Maguire and N. Bevan

Task analysis involves the study of what a user is required to do in terms of actions and/or cognitive processes to achieve a task. A detailed task analysis can be conducted to understand the current system, the information flows within it, the problems for people, and opportunities that indicate user needs. There are many variations of task analysis and notations for recording task activities. One of the most widely used is hierarchical task analysis, where high level tasks are de-composed into more detailed components and sequences. Another method creates a flow chart showing the sequence of human activities and the associated inputs and outputs (Ericsson 2001). Kirwan & Ainsworth (1992) provide a guide to the different task analysis methods, while Hackos & Redish (1998) explain some of the simpler methods for user interface design. Rich pictures can help stakeholders map, explore and understand a complex problem space and thereby help to identify hidden requirements (Checkland, 1981). The technique involves creating a series of sketches to show how people and systems relate to each other in an organisation. They may show peoples’ roles, power structures, communications and reporting mechanisms. Drawing simple figures of people with thought and speech bubbles linked to them can show particular problem areas in the current environment that may lead to new user requirements. Field study and observational methods involve an investigator viewing users as they work and taking notes of the activity that takes place. Observation may be either direct, where the investigator is actually present during the task, or indirect, where the task is recorded on videotape by the analysis team and viewed at a later time. The observer tries to be unobtrusive during the session and only poses questions if clarification is needed. Obtaining the co-operation of users is vital so the interpersonal skills of the observer are important. For further information see Preece et al. (1994). Diary keeping provides a record of user behaviour over a period of time. They require the participant to record activities they are engaged in throughout a normal day that may lead to the identification of user requirements for a new system or product. Diaries require careful design and prompting if they are to be employed properly be participants. Video recording can be used to capture human processes in a stakeholder’s workplace or other location. The results can then be revised for the purpose of understanding more about the work and generating relevant questions relevant to user needs. Video can also be a useful supplement to other method e.g. to demonstrate new system concepts to users during user/stakeholder discussion groups.

3.

USER NEEDS IDENTIFICATION

Once user data has been collected, user needs can start to be identified. A number of methods exist for identifying such needs.

User requirements analysis

5

User surveys involve administering a set of written questions to a sample population of users. Surveys can help determine the needs of users, current work practices and attitudes to new system ideas. Surveys are normally composed of a mix of 'closed' questions with fixed responses and 'open' questions, where the respondents are free to answer as they wish. This method is useful for obtaining quantitative as well as some qualitative data from a large number of users about the problems of existing tasks or the current system. For further information see Preece et al. (1994). Focus groups bring together a cross-section of stakeholders in a discussion group format. This method is useful for requirements elicitation and can help to identify issues that need to be tackled. The general idea is that each participant can act to stimulate ideas in the other people present, and that by a process of discussion, the collective view becomes established which is greater than the individual parts. For further information see Bruseberg & McDonagh-Philp (2001). Interviewing is a commonly used technique where users, stakeholders and domain experts are questioned to gain information about their needs or requirements in relation to the new system. Interviews are usually semistructured based on a series of fixed questions with scope for the user to expand on their responses. They can also be used as part of task analysis. For further information see Preece et al. (1994) and Macaulay (1996). Interviews on a customer site by representatives from the system development team can be very informative. Seeing the environment also gives a vivid mental picture of how users are working with the existing system and how the new system can support them (Mander and Smith, 2002). Scenarios and use cases give detailed realistic examples of how users may carry out their tasks in a specified context with the future system. The primary aim of scenario building is to provide examples of future use as an aid to understanding and clarifying user requirements and to provide a basis for later usability testing. Scenarios can help identify usability targets and likely task completion times. The method also promotes developer buy-in and encourages a human-centred design approach. Scenarios of use are sometimes called ‘use cases’, although the term is also used by software engineers to refer to the use of functions. In a related method called personas, a caricature is created with a name, personality and picture, to represent each of the most important user groups. Potential design solutions can then be evaluated against the needs of a particular persona and the tasks they are expected to perform. Personas are used by innovative design groups to stimulate creativity rather than refine a design solution (Cooper 1999). Future workshops are a way to help users and designers ‘break out’ from a current situations and thinking. Essentially they involve gathering

6

M. Maguire and N. Bevan

participants and posing questions such as: ‘Where do you want to be 10 years from now’. Once participants have agreed a suitable goal, they then seek to establish a process by which it can be achieved. Another variation is to define new technological developments, discuss when they might be attainable and what implications this might have for the user organisation. Evaluating an existing or competitor system can provide valuable information about the extent to which current systems meet user needs and can identify potential usability problems to avoid in the new system. Useful features identified in a competitor system can also be fed into the design process as potential user requirements. Measures of effectiveness, efficiency and satisfaction can be used as a baseline for the new system. To obtain accurate measures a controlled user test should be used, but valuable information can still be obtained from less formal methods of testing.

4.

ENVISIONING AND EVALUATION

Once an initial set of user requirements has been developed, it is important to develop a prototype to illustrate them. User feedback can then be obtained on the prototype to validate and refine the user requirements. Potential techniques are described in this section Brainstorm sessions bring together a set of design and task experts to inspire each other in the creative, idea generation phase of the problem solving process. They are used to generate new ideas by freeing the mind to accept any idea that is suggested, thus allowing freedom for creativity. The method has been widely used the early phases of design. The results of a brainstorming session are, it is hoped, a set of good ideas and a general feel for the solution area to meet user needs. Card sorting is a technique for uncovering the hierarchical structure in a set of concepts by asking users to group items written on a set of cards. This is often used, for instance, to work out the organisation of a website. Users would be given cards with the names of the intended web pages on the site and asked to group the cards into related categories. After gathering the groupings from several users, designers can typically spot clear structures across many users. Statistical analysis can uncover the best groupings from the data where it is not clear by inspection. IBM (2002) is an example of an analysis programme. Affinity diagramming is a related technique that can be used for organising the structure of a new system, and allows participants to work as a group. Designers or users write down items such as potential screens or functions on sticky notes and then organise the notes by grouping them, to uncover the structure and relationships in a domain. Affinity diagrams are often a good next step after a brainstorming session. See Beyer & Holtzblatt (1998) for more information.

User requirements analysis

7

Storyboards, also termed "Presentation Scenarios", are sequences of images that show the relationship between user actions or inputs and system outputs. A typical storyboard will contain a number of images depicting features such as menus, dialogue boxes and windows. Storyboard sequences provide a platform for exploring and refining user requirements options via a static representation of the future system by showing them to potential users and members of a design team (Andriole, 1989). Prototyping is where designers create paper or software-based simulations of user interface elements (menus, buttons, icons, windows, dialogue sequences, etc.) in a static or dynamic way. When a paper prototype has been prepared, a member of the design team sits before a user and 'plays the computer' by moving the paper and card interface elements around in response to the user's actions. The difficulties encountered by the user and user comments, are recorded by an observer. Software prototypes provide a greater level of realism than is normally possible with simple paper mockups. Here, the aim is to create a rapid prototype that is used to establish an acceptable design for the user but is then thrown away prior to full implementation. Some design processes are based on a rapid application development (RAD) approach. Here a small group of designers and users work intensively on a prototype, making frequent changes in response to user comment. The prototype evolves into the full system. Hall (2001) discusses the merits and cost-benefits of varying fidelity levels of prototypes. Allocation of function is an important element for many systems. As ISO 13407 (1999) states in clause 7.3.2, allocation of function is "the division of system tasks into those performed by humans and those performed by technology" to specify a clear system boundary. A range of options is established to identify the optimal division of labour, to provide job satisfaction and efficient operation of the whole work process. User costbenefit analysis can then be carried out to determine how acceptable each user group will find the new arrangement. The use of task allocation charts and cost-benefit analysis is most useful for systems that affect whole work processes rather than single user, single task products. They also provide the opportunity to rethink the system design or user roles to provide a more acceptable solution for all groups. A process for performing a user costbenefit analysis is described by Eason (1988). Design guidelines and standards are referred to by designers and HCI specialists for guidance on ergonomic issues associated with the system being developed. The ISO 9241 standard (ISO, 1997) covers many aspects of hardware and software user-interface design, and contains a widely agreed body of software ergonomics advice. See Bevan (2001) for more information on ISO standards. Style guides embody good practice in interface design. Following a style guide will increase the consistency between screens and can reduce the development time. For a GUI (graphic user interface) an operating

8

M. Maguire and N. Bevan

system style guide should be followed to implement good practice and to provide consistency. For websites, design guidelines are evolving but good web design principles are gradually being established (Nielsen, 2000). Nicolle and Abascal (2001) discuss issues and present guidelines to make systems accessible by people with disabilities. Parallel design sessions involve a few small groups of designers working independently, to generate a range of diverse solutions. The aim is to develop and evaluate different system designs before choosing a solution (possibly drawing from several solutions) as a basis for the implemented system

5.

REQUIREMENTS SPECIFICATION

General guidance on specifying user and organisational requirements and objectives is provided in ISO 13407. The following should be documented within the specification: identification of the range of relevant users and other stakeholders, a clear statement of design goals, the requirements with an indication their priority levels, measurable benchmarks against which the emerging design can be tested, evidence of acceptance of the requirements by the stakeholders, acknowledgement of statutory or legislative requirements, e.g. for health and safety. It is also important to manage changing requirements as the system develops. The following sections describe techniques and methods to support user and organisational requirements specification. Task/function mapping specifies the system functions that each user will require for the different tasks that they perform. By showing the relationship between the tasks and the corresponding functional requirements linked in matrix form, trade-offs can be made between different functions, or to add and remove functions depending on their value for supporting specific tasks. It is also useful for multi-user systems to ensure that the tasks of each user type are supported. Requirements categorisation User requirements: It is important to establish and document the user requirements so that they lead into the process of designing the system itself. User requirements will include summary descriptions of the tasks that the system will support and the functions that will be provided to support them. Usability requirements: It is also necessary to describe the detailed usability requirements in order to set objectives for the design team, and help prioritise usability work. Generally agreed usability goals to define are: effectiveness: the degree of success with which users achieve their task goals: efficiency: the time it takes to complete tasks; and satisfaction: user comfort and acceptability; see ISO 9241, part 11 ‘Guidance on Usability’ (ISO, 1997). These are most easily derived from the evaluation of an existing system. Other more detailed usability issues provide more specific design objectives e.g. understandability, learnability, supportiveness, flexibility and

User requirements analysis

9

attractiveness. Having established usability requirements, it is then necessary to translate the requirements into a specification (specification = requirement + measure). ISO 9126-4 (ISO, 2002) provides a framework for specifying measurable requirements (see also section 6.3). Organisational requirements: A third element is to specify the organisational requirements for the user-system complex, i.e. those that come out of a system being placed into a social context. An understanding of organisational requirements will help to create systems that can support the management structure of the organisation and communications within it, as well as group and collaborative working. Defining and grouping the tasks in an appropriate way will help to create motivating and satisfying jobs, ideally allowing users autonomy, flexibility, provision of good feedback on their performance and the opportunity to develop their skills and careers. Statutory or legislative requirements may also be classed as organisational requirements. The information needed to specify user, usability and organisational requirements will be drawn from the context of use and user needs activities described in previous sections. Maguire (1998) and Roberston & Roberston (1999) provide frameworks for user requirements specification. Prioritisation of user requirements is important so that development resources can be directed appropriately. The DSDM development method uses ‘time boxes’ where the functions and features in each phase of a system’s release are defined by the resources available. This helps control the risks in system development, and allows the customer to redirect future effort to meet the user’s needs more closely. Criteria setting relates to the need for criteria to help decide whether the user requirements have been achieved. This can be done by an inspection team or by user testing, where a representative user sample performs typical tasks with the system and the performance scores and attitude ratings help decide if the system can be accepted. Defining acceptance criteria in advance can be achieved by performing pre-tests on the existing system or on a competitor system, to specify criteria that the new system must be at least as good as these current systems.

10

M. Maguire and N. Bevan

6.

COMPARISON SUMMARY

Table 2 below presents the advantages and disadvantages of each method presented in this paper to assist in method selection.
Method
Stakeholder analysis Secondary market research Context of use analysis

Benefits
Ensures that all relevant stakeholders are considered. Low cost and provides good overview of potential market. Provides framework for documenting all factors that may affect the usability of the product. Defines and models tasks that can highlight user needs directly. Allows complex user environments to be mapped out and potential requirements to be identified Allows viewing of what users actually do in context and may discover unnoticed processes. Allows user to record activities throughout the day.

Drawbacks
Information may be too general or out of date. May be lengthy process. Not all headings applicable to project. Could be shortcircuited for smaller systems. May be over-formal for simple tasks or open-ended tasks. Pictures may highlight indicative factors but may lack sufficient detail. Time consuming to perform. User commentary and analyst observation may disturb tasks. Users may forget to complete diaries or summarise activities at the end. Analyst reminders may be annoying. Time consuming to perform. Requires users to explain activities post-observation. Does not capture in depth comments and may not permit follow-up. Recruitment effort to assemble groups. Dominant participants may influence group disproportionately.

2. INFORMATION GATHERING

Task Analysis

Rich pictures

Field study and observational methods Diary keeping

Video recording

Captures real current activities without the intrusiveness of direct observation.

3. USER NEEDS IDENTIFICATION User surveys Relatively quick method of determining preferences of large user groups and allows for statistical analysis. Focus groups Allows analyst to rapidly obtain a wide variety of user views and possibly a consensus.

Table 2. Comparison of user requirements methods

User requirements analysis

11

3. USER NEEDS IDENTIFICATION continued Interviewing Interviews allow for quick elicitation of ideas and concepts. Customer visits brings user context to life. Effective way of thinking about future system use in context. Personas can bring user needs to life. Way of thinking creatively. Effective means of identifying current problems, possible new features and acceptance criteria. Blank page approach allowing for rapid elicitation and innovative thinking. Effective means of organising structure of a system e.g. a website. Demonstrates software interactions and possibly user context simply and early in the development cycle. Quick to build and refine. Allows early detection of usability issues in response to user feedback Identifies task concerns for the whole work process. Helps define fulfilling jobs and reduces risk of dissatisfied staff. Draws upon established knowledge to assist design. Produces range of design ideas and solutions. Can pick best from each. Need to negotiate access and to combine range of possibly differing opinions from different users. Scenarios may raise expectations too much. Personas may over simplify user population. Results may seem too ambitious for current needs. May lead to including too many new functions or make system too similar to a competitor’s. Doesn’t cover detailed design aspects. Needs way to combine results if performed by individuals or groups separately. Lacks interactive quality of prototyping.

Scenarios, use cases and personas

Future workshops Existing system/ competitor analysis

4. ENVISIONING & EVALUATING Brainstorming

Card sorting and affinity diagrams Storyboards

Prototyping

Allocation of function and cost benefit analysis

Design guidelines and standards Parallel design

Paper prototypes do not support evaluation of fine details. Throwaway software prototypes do but are time consuming to build. Needs good overview of whole system. Many allocation options can cause confusion. Cost benefits sometimes hard to estimate. May be too general or constrain design. Requires certain amount of organisation to assemble design teams.

Table 2. Comparison of user requirements methods (continued)

12

M. Maguire and N. Bevan

5. REQUIREMENTS SPECIFICATION Task/function mapping Way of selecting functions that are relevant to specific tasks. May be a way to avoid including too many functions. Effective way to categorise user requirements. Covers user and organisational levels. Ensures that effort is put into the most important aspects of the system. Way to determine if developed system has met the user requirements. Knowing when task definitions sufficient. Make include tasks to justify unnecessary functions. May be hard to decide which user requirements fall into which categories. Poor management of user expectations may results in disappointed users. Not easily to define suitable criteria. Extensive testing of achievement may be resource intensive.

User. usability and organisational requirements Prioritisation

Criteria setting

Table 2. Comparison of user requirements methods (continued)

7.

CASE STUDIES

This section describes a series of case studies to show how the methods described in this paper support user requirements development. Normally a mix of methods and techniques is needed. Development of intranet site. A study was carried out by HUSAT (Maguire & Hirst, 2001b) to evaluate and redesign an intranet site for a police service in the UK. Human Factors consultants performed the study working with a police officer who was project manager for intranet development, and a civilian co-ordinator with a knowledge of police procedures and human factors. Semi-structured interviews were performed with users and stakeholders covering: needs and aspirations regarding the intranet, how well the current system meets those needs, and possible improvements that could be made. Interviewees were given access to the intranet site so they could demonstrate their comments. They included a constable, sergeant, inspector, senior officers and non-police admin staff. Following the user and stakeholder interviews, an expert review of the intranet pages was performed to establish the strengths and weaknesses of the current service. General recommendations for change were made following the expert evaluation. These were discussed with police representatives and different options for concept designs were proposed using storyboards and screen prototypes. These methods matched the requirement to create and discuss rapid prototypes within the design team. Having developed the design concept, several options for the graphic design for the site were produced as software prototypes to demonstrate both look and feel. A final design for the home page and secondary level content pages was then produced with web

User requirements analysis

13

templates to allow the police service to install the new pages and maintain them in the future. The project showed how a combination of methods can produce an acceptable new system design within a relatively short time (3 months). Expert evaluation of training opportunities. An evaluation was carried out by HUSAT (Maguire & Hirst, 2001a) which provided information about business-related courses to SME's (Small and Medium Enterprises). This was part of a programme of work to develop user requirements for a web-based elearning service or 'virtual campus'. An evaluation was performed by two Human Factors experts who spent time reviewing each of the main parts of the system from their own experience, a knowledge of typical tasks and usability principles. When providing comments on the system the aim was not to improve the current system but to identify features and implications for the new system. Inputs, from a usability perspective, were made to the user specification of the new virtual campus system. These included elements such as: the inclusion of functions to cover course providers as well as users (as this stakeholder had not previously been considered); suggestion for a mechanism to enter, modify and delete course information and course modules; and provision of typical scenarios of use by the users to make sure that the supplier and customer have the same 'vision' of the system. The project demonstrated how expert evaluation of a current system can provide useful feedback into the requirements specification for the new system. Interviews to assess future requirements for financial services. Interviews were carried out by HUSAT with family groups to study their management of home finances (Maguire, 1999). Context of use information was gathered, supported by photographs taken of rooms where financial tasks were carried out. The interviews were held as a series of focus group sessions within each household to discuss how and where they performed financial tasks, how they would like to receive services in future and through which devices, e.g. TV, PC, or other domestic appliance. The sessions were videotaped and areas and devices in the home were photographed. The study showed where household devices were located and where family members performed current financial tasks. This provided a basis for identifying innovative ways to deliver future financial services to the home. Survey to establish user needs for a climate change system. The EC IST EuroClim project (http://euroclim.nr.no) aims to develop an advanced climate monitoring and prediction system for Europe. Climate related data will be stored in digital form collected from a network of sites across Europe. The system will produce raster maps and datasets for scientists and public users showing changes in snow on land, glaciers, sea ice, and general climate trends. To understand the diversity of user requirements for data precision, metadata and data formats, a user needs survey was carried out with climate

14

M. Maguire and N. Bevan

professionals and public users across Europe. Much effort was required to analyse all the different needs and to summarise them in a form that the design team could assimilate. User needs for data quality varied between users. Therefore charts were produced to show what proportion of users in the survey would be satisfied by different components of data quality i.e. resolution, accuracy and delivery delay. For a specialist system such as EuroClim, it is important to be able to trace the requirements back to the organisations that specified them so that clarification of user needs can be obtained. Based on the information gathered from the survey, a user interface mock-up is being developed to demonstrate the system concept and to ‘prototype’ the user requirements before the system specification is firmed up and development begins. User centred design at IAI. Serco worked with IAI LAHAV to evaluate the benefits of applying user-centred methods on a typical project. The user centred design techniques recommended by TRUMP (Bevan et al, 2000) were selected to be simple to plan and apply, and easy to learn by development teams. 1. Stakeholder meeting and context of use workshop The stakeholder meeting identifies and agrees on the role of usability, the usability goals, and how these relate to the business objectives and success criteria for the system. The context workshop collects detailed information about the intended users, their tasks, and the technical and environmental constraints. Both events each last for about half a day. 2. Scenarios of use A half day workshop to document examples of how users are expected carry out key tasks in a specified contexts, to provide an input to design and a basis for subsequent usability testing. 3. Evaluate an existing system Evaluation of an earlier version or competitor system to identify usability problems and obtain measures of usability as an input to usability requirements. 4. Usability requirements A half-day workshop to establish usability requirements for the user groups and tasks identified in the context of use analysis and in the scenarios. 5. Paper prototyping Evaluation by users of quick low fidelity prototypes to clarify requirements and enable draft interaction designs and screen designs to be rapidly simulated and tested. 6. Style guide Identify, document and adhere to industry, corporate or project conventions for screen and page design. 7. Evaluation of machine prototypes Informal usability testing with 3-5 representative users carrying out key tasks to provide rapid feedback. 8. Usability testing Formal usability testing with 8 representatives of a user group carrying out key tasks to identify any remaining usability problems and evaluate whether usability objectives have been achieved. IAI concluded that most of the techniques are very intuitive to understand, implement and facilitate. Practicing these techniques in the early stages of

User requirements analysis

15

design and development ensures less design mistakes later on. All participants and developers thought that most of the techniques were worthwhile and helped in developing a better and more usable system. The techniques were assessed as cost effective and inexpensive to apply.

8.

CONCLUSION

To ensure a successful outcome, the design team must satisfy the needs and wants of the user when the development is complete. To achieve this, user needs should not only be elicited by techniques such as surveys, focus groups, interviews etc., but they should also be reflected back to users via simulations in order to prototype the user requirements. The requirements will of course then evolve as the system develops and more formal user evaluation takes place.

9.

REFERENCES

Andriole, S. J. (1989), Storyboard prototyping: a new approach to user requirements analysis, QED Information Sciences, Inc. Bevan N (2001) International Standards for HCI and Usability. International Journal of Human-Computer Studies, 55, 4. Bevan, N, Bogomolni, I, & Ryan, N (2000) Cost-effective user centred design, www.usability.serco.com/trump Bevan, N. & Macleod, M (1994) Usability measurement in context. Behaviour and Information Technology, 13, 132-145 Beyer, H. & Holtzblatt, K. (1998), Contextual design: defining customer-centered systems, Morgan Kaufmann Publishers. Bruseberg, A. & McDonagh-Philp, D. (2001), New product development by eliciting user experience and aspirations, International Journal of Human-Computer Studies, 55(4), 435-452. Checkland, P. (1981), Systems thinking, systems practice, Wiley. Cooper, A. (1999), The inmates are running the asylum: why high tech products drive us crazy and how to restore the sanity, Sams publishing. Eason, K.D. (1988), Information technology and organisational change, Taylor and Francis. Ericsson Infocom Consultants AB and Linköping University (2001), The Delta method. www.deltamethod.net/ Hackos, J. & Redish, J. (1998), User and task analysis for interface design, Wiley. Hall, R.R. (2001), Prototyping for usability of new technology, International Journal of Human-Computer Studies, 55, 4, 485-502. IBM (2002), EZSort http://www-3.ibm.com/ibm/easy/eou_ext.nsf/Publish/410 ISO (1997), ISO 9241: Ergonomics requirements for office work with visual display terminals (VDTs), 17parts, International Standards Organisation. ISO (1999), ISO 13407: Human-centred design processes for interactive systems, International Standards Organisation.

16

M. Maguire and N. Bevan

ISO (2002), ISO/IEC 9126-4: Software engineering – software product quality – Part 4: Quality in Use Metrics, International Standards Organisation. Kirwan, B. & Ainsworth, L.K. (eds.) (1992), A guide to task analysis, Taylor and Francis. Macaulay, L.A. (1996), Requirements engineering, Springer Verlag Series on Applied Computing. Maguire, M.C. (1998), User-centred requirements handbook. EC Telematics Applications Programme, Project TE 2010 RESPECT (Requirements Engineering and Specification in Telematics), WP4 Deliverable D4.2, version 3.3, May. http:www.lboro.ac.uk/research/husat/respect/rp2.html Maguire, M.C. (1999), NCR Knowledge Lab. Report on study of the management of domestic finances by family groups, 7 May, RSEHF (formerly HUSAT), Loughborough University, Loughborough, UK. Maguire, M.C. & Hirst, S.J. (2001a), Usability evaluation of the LINK project TIGS website and feedback on OVC specification. HUSAT Consultancy Limited, 2 March 2001. RSEHF (formerly HUSAT), Loughborough University, Loughborough, UK. Maguire, M.C. & Hirst, S.J. (2001b), Metropolitan Police Service redesign of corporate intranet pages. HUSAT Consultancy Limited, 26 March 2001. RSEHF (formerly HUSAT), Loughborough University, Loughborough, UK. Maguire, M.C. (2001c), Context of use within usability activities, International Journal of Human-Computer Studies, 55(4), 453-484. Mander, R. & Smith, B. (2002), Web usability for dummies, New York: Hungry Minds. Nielsen, J. (2000), Designing web usability: The practice of simplicity, New Riders Publishing. Nicolle, C. & Abascal, J. (eds.) (2001), Inclusive design guidelines for HCI, Taylor & Francis. Olphert, C.W. & Damodaran, L. (2002), Getting what you want, or wanting what you get? - beyond user centred design, Proceedings of the Third International Conference on Design and Emotion, Loughborough, UK, 1-3 July 2002. Preece, J., Rogers, Y., Sharp, H., Benyon, D., Holland, S. & Carey, T. (1994), Human-computer interaction. Addison-Wesley. Robertson, S. & Roberston, T. (1999), Mastering the requirements process, AddisonWesley and ACM Press. Taylor, B. (1990), The HUFIT planning, analysis and specification toolset, In D. Diaper, G. Cockton, D. Gilmore & B. Shackel, (eds.), Human-Computer Interaction - INTERACT'90, 371-376. Amsterdam: North-Holland.