see the attached question doc

Usability: Gaining a Competitive Edge IFIP World Computer Congress 2002 J. Hammond. T. Gross. J. Wesson (Eds) Published by Kluwer Academic Publishers @IFIP.2002 User Requirements Analysis A Review of Supporting Methods Martin Maguire Research School in Ergonomics and Human Factors Loughborough University. UK [email protected] Nigel Bevan Serco Usability Services. UK [email protected] 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. Key words: user requirements, user-centred design, usability methods 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) 134 Part Two Technical Sessionsn • rapid development cycles, reducing the time available for user needs analysis • representing user requirements in an appropriate fonn.

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 I below encompassing 4 elements: Infonnation gathering ---. User needs identification Envisioning ---. Requirements and evaluation 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 infonnation 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: A Review ojSupporting Methods 135 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.mib.org.ukldigital) 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). Usere.COUD Tasks Technlcal environment · System skills and experience. · Task list. · Hardware . · Task knowledge. · Goal. · Software . · Training. · Output. · Network . · Qualifications . · Steps. · Reference materials . · Language skills. · Frequency . · Other equipmen t. · Age & gender . · Importance. · Physical and cognitive capabilities. · Duration. · Attitudes and motivations. · Dependencies .

Physical environment , Ol'lanisational environment · Auditory environment. · Work practices. · Thermal environment. · Assistance . · Visual environment. · Interruptions. · Vibration . · Management & communications structure. · Space and furniture . · Computer use policy . · User posture . · Organisational aims. · Health hazards . · Industrial relations. · Protective clothing & eQuipment. · lob 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 (200Ic). 136 Part Two Technical Sessionsn 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. User Requirements Analysis: A Review a/Supporting Methods 137 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 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 a1. (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 semi­ structured 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 138 Part Two Technical Sessionsn 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 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 User Requirements Analysis: A Review of Supporting Methods 139 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.

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 mock­ ups. 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 cost­ benefit 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 cost­ benefit analysis is described by Eason (1988).

Design guidelines and standards are referred to by designers and HeI 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 140 Part Two Technical Sessionsn 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 GU! (graphic user interface) an operating 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 II 'Guidance on Usability' (ISO, 1997). User Requirements Analysis: A Review a/Supporting Methods 141 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 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. 142 Part Two Technical Sessionsn 6. COMPARISON SUMMARY Table 2 below presents the advantages and disadvantages of each method presented in this paper to assist in method selection. Method Benefits Drawbacks r . ':;. 2. INFORMATION Stakeholder analysis Ensures that all relevant - stakeholders are considered. Secondary market Low cost and provides good Information may be too research overview of potential market.

general or out of date. Context of use Provides framework for May be lengthy process. Not analysis documenting all factors that all headings applicable to may affect the usability of the project. Could be short- product. circuited for smaller systems. Task Analysis Defines and models tasks that May be over-formal for can highlight user needs simple tasks or open-ended directly .

task s. Rich pictures Allows complex user Pictures may highlight environments to be mapped indicative factors but may out and potential requirements lack sufficient detail.

to be iden tified Field study and Allows viewing of what use rs Time consuming to perform.

observational methods actually do in context and may User commentary and analyst discover unnoticed processes.

observation may disturb tasks.

Diary keeping Allows user to record Users may forget to complete activities throughout the day.

diaries or summarise activities at the end. Analyst reminders may be annoying.

Video recording Cap tures real current activities Time consuming to perform.

without the intrusiveness of Requires users to explain direct observation.

activities post-observation.

3. USER NEEDS IDENTIFICATION User surveys Relatively quick method of Does not capture in depth determining preferences of comments and may not permit large user groups and allows follow-up.

for s ta tistical analysis.

Focus groups Allows analyst to rapidly Recruitment effort to obtain a wide variety of user assemble groups. Dominant views and possibly a participants may innuence consensus. group disproportionately . Table 2. Comparison of user requirements methods User Requirements Analysis: A Review of Supporting Methods 143 3. US ER N EE DS IDENTIFICATION continued Interv iew ing Interviews allow for quick Need to negotiate access and elicitation of ideas and to combine range of possibly concepts. Customer visits differing opinions from brings user context to life. different users.

Sce n a rios, use case s Effective way of thinking Scenarios may raise a nd perso n as about future system use in expectations too much.

context. Personas can bring Personas may over simplify user needs to life. user population.

F utur e wo rks h ops Way of thinking creativel y. Results may seem too ambitious for curren t needs.

Ex istin g sys t em or Effective means of May lead to including too C om p e tit or a n a l ysis identifying current problems, many new functions or make possible new features and system too similar to a acceptance criteria. competi tor's.

4. ENVISIONING & EVALUATING 'F' Br ain sto rm Blank page approach Doesn't cover detailed design allowing for rapid elicitation aspects.

and innovative thinking. Car d orting and Effective means of Needs way to combine results a ffini ty diag r a m s organising structure of a if performed by individuals or system e.g. a website . groups separately.

S t ory boar d s Demonstra tes software Lacks interac tive quality of interactions and possibly user prototyping.

context simply and early in the development cycle.

Pro to ty p in g Quick to build and refine. Paper prototypes do not Allows early detection of support evaluation of fine usability issues in response to details . Throwaway software user feedback prototypes do but arc time consuming 10 build .

A lloc ation of function Iden tifies task concerns for Needs good overview of and User cost ben efit the whole work process . whole system. Many ana lysis Helps definc fulfilling jobs allocation options can cause and reduces risk of confusion. Cost benefits dissatisfied staff. sometimes hard to estimate.

D esig n g uid e lines a nd Draws upon established May be 100 general or s t a ndard s knowledge to assisl design. constrain design. Para llel design Produces range of design Requires certain amount of ideas and solutions. Can pick organisation 10 assemble best from each. design teams. Table 2. Comparison of user requirements methods (continued) 144 Part Two Technical Sessionsn 5. REQUIREMENTS SPECIFICATION , Task/function Way of selecting functions that Knowing when task mapping are relevant to specific tasks.

definitions sufficient. Make May be a way to avoid include tasks to justify including too many functions. unnecessary functions.

User. usability and Effective way to categorise user May be hard to decide which organisational requirements. Covers user and user requirements fall into requirements organisational levels. which categories .

Prioritisation Ensures that effort is put into Poor management of user the most important aspects of expectations may results in the system . disappointed users. Criteria setting Way to determine if developed Not easily to define suitable system has met the user criteria. Extensive testing of requirements .

achievement may be resource i ntensive . 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, 200 I b) 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 templates to allow the police service to install the new pages and maintain them in the future. User Requirements Analysis: A Review a/Supporting Methods 145 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 e­ learning 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 HUSA T 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 video­ taped 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 1ST 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 data sets 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 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 146 Part Two Technical Sessionsn 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 !AI LAHA V to evaluate the benefits of applying user-centred methods on a typical project. The user centred design techniques recommended by TRUMP (Bevan et aI, 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 design and development ensures less design mistakes later on. All participants and developers thought that most of the techniques were User Requirements Analysis: A Review o/Supporting Methods 147 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 Infonnation Sciences, Inc.

Bevan N (2001) International Standards for HC! 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.comltrump 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 Kaufinann 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 Linkoping University (2001), The Delta method. www.deltamethod.netl 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.comlibrnleasy/eou_ext.nsf/Publishl410 /48 Part Two Technical Sessionsn 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.

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.uklresearch/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, SJ. (2001a), Usability evaluation of the LINK project TIGS website and feedback on 0 VC specification. HUSA T 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 intra net pages. HUSA T Consultancy Limited, 26 March 200 I. RSEHF (formerly HUSAT), Loughborough University, Loughborough, UK. Maguire, M.C. (200Ic), 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, 1. (2000), Designing web usability: The practice of simplicity, New Riders Publishing.

Nicolle, C. & Abascal, J. (eds.) (2001), Inclusive design guidelines for HeI, 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, Addison­ Wesley 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