Applying Contextual Inquiry for Capturing End-Users Behaviour Requirements for Mobile Exhibition Services

Konstantinos G. Fouskas

PhD Researcher

ELTRUN: The E-Business Center
University of the Aegean
31Fostini Street, Chios, Greece
Tel: +3-010 8203663, Fax: +3-010 8203664
kfouskas@aueb.gr

 

Adamantia G. Pateli

PhD Researcher

ELTRUN: The E-Business Center
Athens University of Economics and Business
47A Evelpidon Street, 11362, Athens, Greece
Tel: +3-010 8203663, Fax: +3-010 8203664
pateli@aueb.gr

 

Diomidis D. Spinellis

Assistant Professor

ELTRUN: The E-Business Center
Athens University of Economics and Business
47A Evelpidon Street, 11362, Athens, Greece
Tel: +3-010 8203682, Fax: +3-010 8203664
dds@aueb.gr

 

Heli Virola

Development Manager
ELISA Communications Research Center
PO Box 81 (Satakunnankatu 18 A, 3rd floor), 33211 Tampere, Finland
Tel: +358 50 370 5806, Fax: +368 10 26 28082
 heli.virola@elisa.fi

ABSTRACT

We investigate the use of Contextual Design, and in particular the process of Contextual Inquiry, for designing complex and innovative systems. Contextual Inquiry is an emerging practice used for investigating behavioural requirements of users in their work environment. The advantage of Contextual Design over other requirements elicitation methodologies, such as Requirements Engineering and User Task Analysis, is the focus on observation and in-work interviews for extracting requirements and designing customer-centred systems. Based on that, we have applied and adapted this methodology to the special case of gathering user requirements for a mobile exhibition system. The major part of this paper discusses the experience and results of this research with the purpose of providing background knowledge and guidelines to future implementors of Contextual Inquiry.

Keywords: Contextual Inquiry, Requirements Elicitation, Mobile Services.

1.     Introduction

The development of next generation, 2.5G and 3G, networks has provided a great variety of mobile services able to transfer and store multiple types of data rather than solely voice through wireless channels and devices. The 3G networks will move mobile communications forward from where we are today into the Information Society based on third generation (3G) services that will deliver speech, data, pictures, graphics, video portal services and other high bandwidth information direct to people on the move [16]. Many mobile e-commerce applications became available recently and new ones are being planned and developed [14]. Varshney and Vetter (2001) list some categories of such mobile applications including: financial services, advertising, entertainment, information-oriented services [17]. Nevertheless, the big explosion in the supply of mobile value-added services is anticipated for the next few years, when the progression from 2G towards 2.5G and 3G will manifest itself in gradually richer information content, greater interactivity, and in some new (or greatly enhanced) application features such as location dependence, personalisation, and immediacy. These will enhance the possibilities for developing usable applications and services [3].

Of course, it is expected that not all the provided services will gain acceptance from end-users and will be widely adopted. Instead, those that either address existing needs or can create new needs have a higher chance to dominate. To ensure widespread adoption of their developed services, there is a set of requirements that application developers and service providers should meet. These requirements are technological, business strategic and behavioural [4], [5]. [11].

Technological requirements concern requirements for designing both the physical and logical architecture of the system to be developed. In the case of information systems with increased communication capabilities, technological requirements also refer to the setting of the network infrastructure required for providing the corresponding communication services. Business strategic requirements concern requirements derived from the business model of the value chain or value network players, which illustrates who has the responsibility to coordinate and the power to control, the relationships between the players, how revenues are created and shared among players, and the end-users’ valuation of the added value provided by each player. Finally, there is another set of requirements from the demand-side of the implementation. These requirements relate to the usual behaviour of end-users and may vary across the type of end-users, contexts, and roles. To understand these requirements, analyses of the context-specific behaviour of end-users must be conducted. Capturing behavioural-type requirements constitutes the principal goal of Contextual Inquiry, which was applied in our case and is thoroughly discussed in this paper.

The goal of this paper is to present and discuss the results of theoretical and empirical research efforts on the application of the Contextual Design (CD) methodology in the design of complex systems and applications. Our primary objectives are: a) providing our experience from using this methodology for requirements capturing, and b) justifying why this new methodology is considered more suitable, in comparison to traditional requirements capturing methodologies, for application in the design of innovative mobile commerce and mobile business applications. We do not claim that our research is exhaustive. Indeed, we hope that it will guide further investigations and experiments in using this methodology that may result in gaining more knowledge and experience for applying Contextual Inquiry in the design of future mobile applications.

The paper is organized in six sections. In this Section, we introduce the problem of describing and explaining end-user requirements when designing complex mobile services or mobile services providing a radically new offering to the end-users, such as services for online real-time navigation in a closed environment. In Section 2, we introduce the theoretical background of requirements elicitation and specification of Information Systems. More particularly, we present and discuss two different approaches to requirements elicitation that are widely applied so far. Section 2 ends with the presentation and a brief discussion of the approach we adopted for capturing end-users requirements for innovative mobile services. In Section 3, we introduce the theoretical perspectives followed to study and apply Contextual Inquiry in our case. Section 4 discusses the empirical research in which Contextual Inquiry was applied for end-users requirements capturing. More specifically, it discusses the setting of the research made, and the analyst’s problem in capturing behaviour requirements of the end-users in their work environment. Section 4 ends with presentation of the research results and discussing their importance in the analysis and design of a mobile exhibition application. We conclude and discuss both the results of our theoretical and empirical research efforts.

2.     Research Approaches in Requirements Elicitation

There are three main methodologies to elicit requirements; Requirements Engineering (RE) [13], User and Task Analysis (UTA) [6], and Contextual Design (CD) [1]. The common ground of all these methodologies is that they underline the importance of observing users in action in order to grasp requirements that cannot be articulated by the users.

The term “Requirements Engineering” has come from a systems engineering background. In the commercial systems background, requirements engineering is more or less the same thing as systems analysis, i.e. requirements regarding systems implemented as software, hardware, or by the people involved with the system [13]. Requirements elicitation is the process of discovering the requirements for a system by communicating with customers, system users and others who have a stake in the system development. This process does not just involve asking people what they want; it requires a careful analysis of the organization, the application domain, the business processes of the organization, and how the system is likely to be used. To elicit system requirements, Sommerville and Sawyer (1997) suggest that the system development staff should combine several techniques, such as study of existing documents, interviewing, and observation [13]. Regarding observation, the requirements engineering people highlight the importance of an observation-based approach to discover unconscious actions, which people may not think as important, as well as to spot important social interactions between people involved in the business processes.

The above theory on requirements engineering mainly concerns the pre-design phase of an information system or merely of an application (software). In the last years, a lot of research has been done on the pre-design phase of user interfaces, which is called “user and task analysis” [6]. User and task analysis is the process of learning about ordinary users by observing them in action. It is different from asking them questions in focus groups outside the users’ typical environments and away from their work. It is also different from talking with expert users or managers who may claim to speak for ordinary users but often unknowingly misrepresent them. Only by observing and by probing users for more understanding in the context of their work, can the design team get the information required for designing usable products.

Requirements engineering, user interface design, systems analysis or whatever the term used to describe the activity, the hard underlying problem of all requirements elicitation methodologies is determining how to build products that address real customers need, and thus are usable and useful to them. Contextual Design is a customer-centered process responding to this issue [1]. For customer-centered design to be possible at all, the process needs to include techniques for learning about customers and how they work. This means that the everyday work practice of people has to be discovered. Contextual Design provides explicit steps and deliverables for the front end of design, from initial discovery through system specification. The first step of that process, called Contextual Inquiry, includes understanding the customers; their needs, their desires, their approach to the work. It involves one-on-one interviews with customers, in their workplace while they work on a day-to-day basis. These are followed by interpretation sessions in which everyone can bring their unique perspective to bear on the data. We will describe Contextual Inquiry in detail in Section 3 and will present a real case in which it was applied in Section 4. 

3.     Contextual Inquiry and Design

3.1.       The contextual design method of work

When trying to design an innovative information system many times, one faces a plethora of problems regarding the capturing of user needs. A system is considered successful, when it meets its users needs. In order to do that, you have to hear the voice of the user and get close to him as current managerial philosophy proposes. The problem, according to Leonard and Rayport (1997), is that users’ ability to guide the development of new products and services is limited by their experience and their ability to imagine and describe possible innovations [9]. How can developers identify needs that users themselves may not recognize? How can designers develop ways to meet those needs, if even in the course of extensive market research users never mention their desires because they assume these desires cannot be fulfilled?  In order to answer these questions, a set of techniques was developed based on contextual design.

Contextual Design (CD) is a customer-centered process that supports finding out how people work, so the optimal redesign of work practice can be discovered. It provides help in designing the front-end design from initial discovery to system specifications [1].

The steps of Contextual Design are the following [9]:

1.      Observation: This step includes clarifying who should be observed, who should do the observing and what the observer should be watching.

2.      Capturing Data: The second step includes capturing of the data that is done mainly through visual, auditory and sensory cues with the help of video or photography or other tools and only few data is gathered through responses to questions.

3.      Reflection and Analysis: After gathering data, the team that performed the observation returns to reflect on what they have observed and review the collected material with other colleagues.

4.      Brainstorming for Solutions: This part of the process in a used to transform the observations into visual representations of possible solutions.

5.      Developing prototypes of possible solutions: Although this step is not unique to the methodology, the development of a prototype clarifies the concept of the new product to the development team and stimulates reaction and foster discussion.

As seen, the first step in Contextual Design, in order to elicit appropriate user requirements for a system is observation, a step called Contextual Inquiry.

3.2.       Contextual inquiry for user requirement capturing

As we outline in Section 2, Contextual Inquiry constitutes the first step of the Contextual Design methodology. The core promise of Contextual Inquiry is very simple: go where the customer works, observe the customer as he or she works, and talk to the customer about the work [1]. The concept of Contextual Inquiry includes going to the location of the user’s work and observe the work being held. It is ideal for capturing unarticulated user needs and the application that holds the greatest potential benefit is the observation of current or possible customers encountering problems with the suggested products and services they don’t know can be addressed and may not even recognize as problems [9].

In more detail, the Contextual Inquiry process regarding users requirements capturing includes the following steps [10]:

1.      A small semi-structured interview before the execution of the observation session, in order to get familiar with the user and gain knowledge about his work. The interview should not be extended and the interview should have a discussion form in order to gain reaction of the user.

2.      The next step is the observation session where the interviewer watches the user working. Usually several interviewers watch different users simultaneously and combine the results afterwards as a team.

To conduct Contextual Inquiry, four principles have to be taken into consideration [1]: context, partnership, interpretation, and focus. The context principle suggests going to the user’s workplace and observing him doing the work. This is done under the perspective of gaining a clear picture of the user’s work than an unclear summary. The partnership principle has the user and the interviewer collaborating in order to make the user provide information in a natural, relaxed way and make his work understandable. The results of the inquiry must be interpreted, thus the third principle, interpretation. The best way to achieve this is to do it under the umbrella of a team in order to gain a common view on the findings. Finally, the focus principle defines the point of view the interviewer takes while observing the user work, allowing him to concentrate on relevant aspects.

Contextual Inquiry can reveal hidden work structure, and thus can give trustworthy customer data in order to address the major problems of both IT and commercial organizations [1].

4.     The Real Case: Requirements Elicitation for a Mobile Exhibition Application

4.1.       Description of the Problem

The case in which Contextual Inquiry was applied was the analysis and design of a Mobile Exhibition Application providing a set of services targeted to exhibition organizers, exhibitors, and visitors. The targeted system constitutes the result of a research project called mEXPRESS[1].

The main objective of the mEXPRESS project is to introduce advanced B2C and B2E oriented electronic services through intelligent mobile devices, enabling personalization, location-sensitivity, contextual-awareness and management of interaction, in information-rich and information-dense environments, and more specifically in exhibition shows, with a view to extend to any such environment. To this end, it will develop the necessary infrastructure within the exhibition premises, utilize currently available mobile networks and terminal devices, and provide a supportive mediation platform that will acts as the hub between visitors, exhibitors and exhibition organizers/administrators before, during and after the exhibition.

The following figure illustrates the physical architecture of the mobile system that is under development within mEXPRESS.

Figure 1. Architecture of mEXPRESS system

 

The need for applying Contextual Inquiry was raised from the more rigid demand of designing and providing through the above-mentioned supportive mediation platform mobile services that will have value for their end-users, either because they will solve existing problems or will exploit opportunities for providing further benefits to them (e.g. convenience, personalization, time and load-saving, etc). The difference of this case to other cases concerning requirements specification for an IS was that the end-users requirements constitute implicit, non-verbally stated demands that could mainly derive from careful observation of the way in which end-users accomplish the concerned tasks. For this reason as well as for the reasons discussed in Sections 2 and mainly 3, none of the older approaches and methodologies for requirements specification could provide us with appropriate methods and tools for eliciting requirements for such complex and innovative services. Thus, we were oriented towards a new approach that could provide us with guidelines on how to capture implicit requirements from different types of end-users in the environment in which they gather for interacting and even conducting their transactions.

The aim of the research made was to capture users (organizers, exhibitors, and visitors) requirements for mobile services in the context of an exhibition show. Regarding the research scope, it took place in Greece during the exhibition show “Naval Saloon – Thallassa 2002”, which targeted both business people and individual customers having interest in boats, naval equipment or other navy products. The exhibition show in which the research was run has been selected as being attractive events for a wide audience, which has some sort of awareness of new technologies, or is interested in learning and applying them. In particular, the Greek Naval Saloon – Thallassa 2002 attracts people who may not know a lot about mobile services but are familiar with wireless technologies, such as GPS systems with which boats and fishermen may be equipped.

The principal objectives of this research were to:

·      Identify non-verbally stated requirements for new services that have not been proposed by the research team,

·      Notify changes that have to be made on proposed mobile services so that they address real needs,

·      Measure the value of the proposed services for the end-users and reject those that seem to have little or no value for their target audience.

·      Define the general attitude of end-user towards the system in general and more specifically towards each one of the mobile services that will be offered.

4.2.       Case Setting

In order to use contextual inquiry methodology for user requirements capturing in the case described above, an appropriate action plan had to be created based on contextual inquiry principles and the case setting’s special issues that had to be addressed. Although contextual inquiry is generally used to elicit the need of a single actor or workgroup, this case was focused on capturing the need of a marketplace, where many actors interact and try to accomplish their own business purposes. This means that the elicitation could not be based on observing a single actor, but a number of actors and the interaction between them. As stated in the above section, the information system we are describing is not referring to a single actor but instead we are facing an inter-organizational system. In such situations, it is difficult to identify who participates in the information system and the decision can no longer be taken by a single organization [12]. Problems of resistance to change and motivation to participate in information systems development become qualitatively different when applied between organizations [2]. Thus when try to capture user requirements in such a system applying contextual inquiry in its traditional form might not be adequate. To cover the needs of the specific research, some alterations had to be made:

·          The observation was not focused on a single actor or group, but instead in a variety of actors.

·          Special attention was given to the interaction between the actors and not the actions taken by each actor.

·          The observation was done simultaneously in a variety of actors within the same area (exhibition hall) and thus the observers of actors in many occasions had the opportunity to observe both interacting actors at the same time from two different points of view.

·          The observation was supported by two interviews instead of one which is more common, in order to verify the results of the inquiry.

·          The number of observations that should be done was analogous to the different kind of visitors and exhibitors and the criteria were based on pure qualitative.

The observation was set to take place in a Greek Naval Saloon – Thallassa 2002 organized by one of the consortium participants and referred to both business (B2B) and consumer customers (B2C). The reasons that lead us to choosing this exhibition where the following:

• The exhibition targeted both business partners and individual customers. That means that the sample that was observed and interviewed should be representative in terms of objectives for visiting the exhibition.
• Since the introduction of new technological applications in the naval industry is high (GPS, Sonar, Satellite phones), the participants of the exhibition were more familiar with new technology applications than participants of other exhibitions taking place in the same period.
• The exhibition also hosted a number of parallel events (e.g. seminars), useful for observing the visitors behavior when deciding to attend them.
• The organizer is a member of the consortium and a possible user of the system, meaning that his interest in setting the observation scene was also high.
• The exhibition took place within the time limits suggested by the project.

In order to support the results of the observation, a set of interviews was arranged with each participant observed, in order to verify the results and gather requirements that possibly did not appear during the observation session. The combination of both observation session and interview sessions led in valid and satisfactory results that covered the project needs.

4.3.       The Application of the Contextual-Inquiry Method

The research was applied in two phases. Both phases took place in the exhibition location. The first phase along the whole exhibition area and the second, mainly concerning interviews, in a room within the exhibition area equipped with a camera to record the interview and a computer to present an overview of the system and its services. 

The end-users that participated in the research were a priori informed about it and its purpose. More specifically, exhibitors were informed about the purpose of the study in cooperation with the exhibition organizer and were asked to participate in the research at the beginning of the observation session. Visitors were also informed about the purpose of the study and asked to participate in the research at the beginning of the observation session. In both cases, neither exhibitors nor visitors were affected by the presence of the observer in an unobtrusive way, since the observers were trying to keep a low profile so as not to affect the persons observed.

Phase A included initial interviews with the intended users as well as observation of their behavior in the exhibition area. Phase B included in-depth interviews that aimed at addressing questions rising from observation, verifying its results and identifying users requirements not addressed by the observation. Since many times it is difficult and not suitable to interrupt the user during the observation a number of questions arise from the observation and cannot be addressed. The best method to answer these questions is to contact a post-observation in-depth interview followed by the analysis of the results. More information on the research phases is included in Table 1.

 

The topics covered in both these types of interviews were divided in two sections. The first section included topics on exhibition behavior and interests. The second section included a brief presentation of the project, followed by questions to the interviewee about his opinion for the system and possible services that seemed interesting or useful to him. This was followed by a presentation of the suggested services, and the interviewee was asked to approve, disapprove or suggest changes on the current service. At the end of the interview, the interviewees were asked once again to propose new services, inspired from the services suggested by the research team.

More specifically, the topics covered in these interviews are included in Table 2.

 

 

Research Phases
	Exhibitors	Visitors
Phase A	9 Short Interviews and Observations Duration: 4 hours (Day 1), 3 hours (Day 2), Interviews’ Goal: Define exhibitors’ objectives, the type and content of the information delivered to visitors, the actions they intended to take during the exhibition and their company’s profile and familiarity with technology applications. Observation’s Goal: Observe the actions taken by exhibitors during the exhibition, the overall approach of visitors to selected stands and the interaction developed between exhibitors and visitors. Action: The short interview was followed by an observation session. The observation process was executed twice, during a high peak and a low peak day, resulting a total of 18 observations, in order to be able to examine actions depending on the exhibition traffic.	9 Short Interviews and Observations Duration: 1 hour Interviews’ Goal: Define visitors’ objectives, the intention of visiting the exhibition, the actions they intended to take during the exhibition and their profile and familiarity with technology applications. Observation’s Goal: Search of information for visitors’ navigation and behaviour during the exhibition, observe the actions taken by visitors while in exhibition, such as visiting stands and interacting with the exhibitors, collecting informative material, navigating though the exhibition, attending seminars being held during the exhibition. Action: The short interview was followed by observation in the form of shadowing.
Phase B	9 Post-observation Interviews Duration: 45-60 mins. Goal: Discuss the system propositions as well as questions raised from the observation. Action: The research team contacted the same exhibitors who participated in the first phase for conducting in-depth interviews. The interview concerned discussion on exhibitors’ overall experience of the exhibition and the degree to which they felt that they had achieved their initial business objectives. The proposed system was discussed on a concept level and the interviewees were called to propose ideas for the customization and improvement of the offered services.	8 Post-observation Interviews Duration: 45-60 mins. Goal: Discuss the system propositions as well as questions raised from the observation Action: The research team contacted conducted in-depth interviews with the visitors observed immediately after the observation. The interview concerned discussion on the visitors’ behaviour in the exhibition as well as on the suggested services in order to come up with the optimal proposition based on visitors needs.

Table 1. Phases of Implementing Contextual Inquiry

 

 

Interview Topics
On exhibition behavior and interests	On the system proposition
ü      Objectives of each target group ü      Purpose of visit ü      Expected and actual benefits ü      Possible and actual drawbacks ü      Navigational and behavioural patterns of visitors ü      Organization of events by exhibitors ü      Estimated cost of exhibition stand for exhibitors ü      Interaction between exhibitor and organizer ü      Satisfaction from the presentation of exhibitors ü      Possibilities for communication of information to visitors ü      Interaction between involved target groups and expectations from each participant in terms of: o       Observation of the stand by visitor, points to look at, o       Time spent in the stand area, o       Interaction with the exhibitor, o       Request of information material, o       Level of offered service, o       Number of visitors around the stand area, o       Satisfaction of the visitor after the interaction, o       Meetings held during the exhibition.	ü      Comprehension of its function and possibilities ü      Degree of acceptance for the proposed services ü      Perceived benefits from the system’s use ü      Perceived risks or weaknesses of the proposition ü      Suggestions for improvement and enrichment of services offered ü      Suggestions for new services ü      Suggestions for services that should not be included in the proposition

Table 2. Topics discussed during in-depth interviews

 

The methodology followed and the expected results are illustrated in Figure 2. In Phase A, initial interviews with visitors and exhibitors is conducted, followed by Phase B were visitors and exhibitors are interviewed on both user requirements and acceptance of proposed services. All the data collected gives results regarding acceptance of proposed services, changes to proposed services, services that should be abandoned and new services. The research is followed by two interviews with exhibition organizers and gives input to the system design regarding System Requirements Description and Software requirements Description.

 

Figure 2. Contribution of Research Outcomes to Requirements Specification

 

4.4.       Outcomes and their Importance

The research results can be presented by type of concerned user (visitor, exhibitor, organizer), and include the following useful information for the analysis and design of the concerned mobile exhibition system and its services.

·        Acceptance of proposed services,

·        Changes on proposed services,

·        Services that are not accepted or considered as useful,

·        New services proposed by the user,

The sources of the above results are not the same for each type of user. In particularly, interviews and observation feed the results for the exhibitor and visitor, while the requirements of organizers have resulted from in-depth interviews with them.

It is expected that the research outcome will ultimately contribute to the design of the discussed mobile system based on users requirements and actual needs. This will be done by gathering the behavioural type requirements captured from the research, combining them with business strategic and technological requirements and present them to a unified Requirements Specification Report, which is structured according to the relevant IEEE standards and is composed of the following parts [7], [8].

 

1.      Introduction

1.1   System Purpose

1.2   System Scope

1.3   Definitions, Acronyms and Abbreviations

2.      System Requirements Description

2.1   System Context

2.2   Major System Capabilities

2.3   Major System Constraints

2.4   User Characteristics

2.5   Operational Scenarios

3.      Software Requirements Description

3.1   External Interface Requirements

3.2   Functional Requirements

3.3   Performance Requirements

3.4   Software System Attributes

3.5   Other Requirements

Table 3. Structure of the Requirements Specification Report

The following table illustrates to which sections and in which way the user behavioural requirements that were gathered provide input to the Requirements Specification Report of the mEXPRESS system.

 

Section	Description	Research Contribution
System Requirements Description
Major System Capabilities.	Includes the major capability groupings of the system that is developed.	They will be described through grouping of requirements that have resulted from applying Contextual Inquiry.
Major System Constraints	Describes how the software interoperated inside various constraints, such as hardware limitations, interfaces to other applications, control functions, reliability requirements, criticality of the application, safety and security considerations.	Although the requirements do not directly feed the system constraints, they can provide input to several of these types of constraints, such as a) interfaces to existing applications, discussed in interviews with organizers, b) security concerns, stated by the users, c) criticality of the application, emerging from the general users attitude.
User Characteristics.	Describes general characteristics of the users including educational level, experience, and technical expertise.	Most of the required user characteristics, such as demographics and behaviour data, have been collected in the research.
Operational Scenarios.	Provides descriptive examples of how the system is used by the end-users through a number of use cases and indicative scenarios of use.	Both the design of use cases and the description of scenarios are tightly dependent on the number and type of requirements resulting from the research.
Software Requirements Description
Functional Requirements.	Defines the fundamental actions that must be accomplished by the system’s software.	The functions of the software will be extracted from the grouping of requirements and the services defined in the Major System Capabilities Section.

Table 4. Research’s Contribution to the Requirements Specification Report

5.     Discussion and Conclusions

5.1.       Indicative Results

Contextual inquiry has proved to be a useful tool in the design of the mobile exhibition system, by giving us results that might not be revealed by user requirements capturing methods such as interviews and focus groups. Most customers have a very limited frame of reference, knowing only what they have experienced. They cannot imagine what they don’t know about emergent technologies, new materials and the like [15]. The results indicated eight new services for visitors, two changes to proposed services for visitors, four new services for exhibitors, and three changes to proposed services for exhibitors. Indicatively, we present two new services found by the research, one for visitors and one for exhibitors

• New service for visitors “Ability to compare between competitive products within the exhibition, mainly in terms of technical characteristics and availability, but not in terms of price”.
• New service for exhibitors “A service linking the terminals to additional general information provided by the system regarding currencies, related issues concerning the exhibits the train schedules, the airport arrivals and departures, taxi companies and business travel service and other similar info that interests the exhibitors and visitors”.

In addition to the above results, the research has revealed the most promising services as well as several proposed services that are not considered as useful to the end users, and thus have to be abandoned. Moreover, the overall acceptance of the system was estimated and issues that should be taken into consideration during the product development and commercial launch were discovered.

5.2.       Limitations and Problems

The experience from using Contextual Inquiry for user requirements elicitation has raised several limitations and problems that are discussed hereinafter.

·      Difficulty in ensuring user participation. The observation that consists the most essential part of this methodology can be done in two ways: a) Observation of the general behaviour of users in their environment, b) Shadowing, that is watching the behaviour and the processes accomplished by a sample of users. While the second way of conducting observation can provide more trustful results, and thus is considered more effective, it has several difficulties in implementation. The principal one emerges from the users’ frequent reluctance to be watched while they work and mainly while they interact with other parties. As a result, it is quite difficult to find people willing to participate in the research.

·      Special requirements in Human Resources. The research team that applies the Contextual Inquiry practice has to be composed of people of diverse specialty, such as psychologists, software developers, and managers. As the most obvious consequences of the demand in special and diverse human resources are considered the need for great preparation period till the required professionals are gathered and the high cost for implementation. 

·      Need for ad-hoc tools. The theory framework of Contextual Inquiry does not provide ready-to-use tools or even guidelines on how to create tools to be used during the observation and interviews [1]. Therefore, the research team has to develop ad-hoc tools that are considered appropriate for the specific case.

·      Limited possibility for automation. Contextual Inquiry has the limitations of every explanatory research approach. It is mainly based on the ability of explaining what is observed not on the ability of observing as many users as possible. Since the process is highly dependent on the individual interpretative capabilities of the research people, meaning that it is based on human factors, it cannot be easily automated with the use of a technology application.

5.3.       Guidelines for Future Implementation

Apart from benefits, problems and limitations, the implementation of Contextual Inquiry for the design of a mobile exhibition system has provided the team with useful knowledge and experience on how to use this methodology in future cases. This knowledge and experience is expressed through a number of guidelines targeted to any organization or individual wishing to apply the same methodology in the future.

The implementations of this methodology requires developing ad-hoc tools in order to record what is observed and guide the discussion during the interviews. The team has to pay special attention to the preparation of these tools, so that they capture all the information that is required for meeting the objectives of the research. Otherwise, the team runs the risk of loosing a lot of useful information, while being distracted from other events that occur simultaneously. Since the importance of the tools is very important in guiding the process and collecting the required data, the team should spend a rather long time in their development. Moreover, future implementers of the methodology are advised to test their tools in a test environment before their formal use. Such a test can provide useful feedback for changing and adapting the tools to the ad-hoc requirements.

Some special guidelines refer to the case in which Contextual Inquiry is used for requirements elicitation in complex and innovative systems, such as the mEXPRESS system. In this case, the research team is advised to develop a conceptual model of the system and more specifically of its services and present it to users, in order to motivate discussion and brainstorming on the number, type and quality of services offered. A conceptual model can be in the form of application scenarios that are illustrated through a paper or a mock-up demo. Last, but not least important, is the need for applying the methodology to more than one site, and, if possible, to sites which can meet the need for diversity of users regarding their characteristics and behaviour.  

5.4.       Further Work

The research made so far has provided the analysts of the project with requirements for services provided from the system. The immediate future plan includes testing these requirements in another site, that means a different country, possibly in Finland, and another type of exhibition, a Mobile Exhibition show, in order to test the results of the research but also gather new ones. Applying the same methodology and more specifically the same method of work and tools in a different environment will be a chance for discovering the impact of the environment as parameter in Contextual Inquiry implementation.

Contextual Inquiry constitutes the first step of Contextual Design. Subsequent steps in this methodology include [1]: work modeling (representing people’s work in diagrams), consolidation (pulling individual diagrams together to see the work of all customers), work redesign (creating a corporate response to customers’ issues), user environment design (structuring the system work model to fit the work), mock-up and test with customers (testing ideas with users through paper prototypes), and last putting into practice (tailoring contextual design to the organization concerned). Further work involves executing the Contextual Design methodology step-by-step, thus passing from all its phases, in order to develop the final product, the mobile exhibition system.

6.     References

1.           Beyer, H. and Holtzblatt, K. Contextual Design: Defining Customer Centered Systems, San Francisco, Morgan Kaufmann Publishers, (1998).

2.           Cavaye A. Participation in the development of inter-organizational systems involving users outside the organization. Journal of Information Technology, 10(3), (1995), 135-147.

3.           Durlacher Research Ltd. UMTS Report, (2001) [available online from: www.durlacher.com].

4.           Frambach, R.T. An integrated model of organizational adoption and diffusion of innovations. uropean Journal of Marketing, 27, (1993), 22-41.

5.           Frambach, R.T., Barkema, H.G., Nooteboom, B. and Wedel, M. Adoption of a service innovation in the business market: an empirical test of supply-side variables. Journal of Business Research, 41, (1998), 161-174.   

6.           Hackos, J. T. and Redish, J. C. User and Task Analysis for Interface Design, New York, John Wiley & Sons, (1998).

7.           IEEE Standards Software Engineering, 1999 Edition, Volume One: Customer and Terminology Standards, The Institute of Electrical and Electronics Engineers, Inc., IEEE Std 1233-1998, IEEE Guide for Developing System Requirements Specification, (1999).

8.           IEEE Standards Software Engineering, 1999 Edition, Volume Four: Resource and Technique Standards, The Institute of Electrical and Electronics Engineers, Inc., IEEE Std 830-1998 (Revision of IEEE Std 830-1993), IEEE Recommended Practice for Software Requirements Specifications (1999).

9.           Leonard, D. and Rayport, J. Spark Innovation Through Empathic Design. Harvard Business Review, (November-December 1997), 102-113.

10.        Nikkanen, M. User-centered research and design methods and their application in the product development process, MSc Thesis, University of Helsinki, (2001) [available online from: http://www.helsinki.fi/~mnikkane/lisuri/methodology.pdf].

11.        Pedersen, P. E. An adoption framework for mobile commerce, In the Proceedings of the 1^st IFIP Conference of E-Commerce, October 3-5, Zurich, Switzerland (2001).

12.        Pouloudi A., and Whitley E. A. Stakeholder identification in inter-organization systems: gaining insights for drug use management systems. European Journal of Information Systems, 6, (1997), 1-14.

13.        Sommerville, I. and Sawyer, P. Requirements Engineering: A good practice guide, Chichester, John-Wiley & Sons, (1997).

14.        Tarasewich, P., Nickerson, R. C., Warkentin, M. Issues in Mobile Commerce. Communications of the Association for Information Systems, 8, (2002), 41-64.

15.        Ulwick, A. Turn customer input into innovation. Harvard Business Review, January 2002, (2002), 5-11.

16.        UMTS Forum. 3G Portal Study - A Reference Handbook for Portal Operators, Developers and the Mobile Industry, November 2001, (2001) [available online from: http://www.umts-forum.org/reports.html].

17.        Varshney, U. and Vetter, R. A Framework for the Emerging Mobile Commerce Applications, in R.H. Sprague, Jr. (ed.) In the Proceedings of the 34^th Hawaii International Conference on System Sciences, Piscataway, New Jersey (2001).