10.2: Establishing Requirements for a mobile learning system
Helen Sharp, Josie Taylor, Diane Evans and Debra Haley, The Open University
Background
MOBIlearn was a large, multinational European-funded research and development project that explored new ways to use mobile environments to meet the needs of learners, working by themselves and with others. The aim of the project was to develop a new m-learning architecture for a pedagogically-sound mobile learning environment, and to evaluate an instantiation of that architecture using existing technologies. A user-centred approach was taken to the project, based on socio- cognitive engineering (Sharples et al, 2002) and embedded in ISO 13407. The project team consisted of representatives from more than 15 organisations from seven European countries plus one Middle Eastern country. Establishing the requirements for such a project was a complex task, involving many methods and notations. The project produced several documents and results; some of these are available at http://www.mobilearn.org. Publications specifically related to mobile learning are available at http://iet.open.ac.uk/pp/j.taylor/. This case study draws only on work from the user requirements and evaluation workpackage to explore the use of scenarios throughout the project and the use of the Volere shell and template (Robertson and Robertson, 2006) to document the requirements. The next section introduces the three strands used as learning domains throughout the project. Section 3 describes the use of scenarios throughout the project and Section 4 discusses the use of Volere shells and the technology to support them. In Section 5 we conclude by making some observations about our experiences.
The Three Strands
The project chose three learning domains to drive the research, each of which represents a distinct learning situation. These are: the Museum strand, the MBA strand and the Health strand. Data gathering for establishing requirements was conducted by a different project partner, each strand used different data gathering techniques, and each produced its own set of requirements which needed to be rationalised. The three strands and their respective data gathering techniques are outlined below.
Museum strand
This strand typifies informal learning and concerns visitors to a museum. Museums
are the mechanism through which we research, interpret and present our insights into
the natural and cultural worlds. They represent our belief systems concerning cultural
inter-relationships, our relationship with the environment and of our place in the
Universe.
Wireless technology is becoming a part of the museum experience. In an effort to
bring art and science to life for a new generation of technically sophisticated patrons,
an increasing number of museums are experimenting with advanced mobile
technologies to make museum going more interactive, more educational - and more
fun.
Newly emerging portable device and wireless network technologies have the potential
to significantly enhance the experience of a visit to a museum. On the exhibit floor,
visitors carrying wirelessly connected devices can be given opportunities for
exploration, sharing, explanations, context, background, analytical tools, and
suggestions for related experiences. In addition, conventional desktop and Internet
technologies can help extend the visit: in advance, through activities that orient
visitors, and afterward, through opportunities to reflect and explore related ideas.
Figure 1 Potential users trying an early prototype at the Uffizi Gallery
These visitors are varied, ranging from children on school outings to adults with a passion for art. These learners may have been forced to go by a teacher or spouse, or they may be eager to experience as much as possible themselves. Their motivations might range from learning just enough to pass the test, to seeking enrichment and enlightenment.
The Museum strand gathered data initially through questionnaires with visitors and
museum staff, then ran field trials with prototypes once they were available.
Business strand
The second strand represents formal learning and serves business students, both novice first year students and MBA (Master of Business Administration) students. The MBA students are usually highly motivated, extremely busy, and want value for their time and money. Novices may be less demanding and need more support initially, including help in getting around the campus and meeting other students. MOBIlearn addressed both of these student types by providing an Orientation Game for the novices and a collaborative support system for the MBA students.
The Orientation Game involves inducting undergraduate students on their entry into the university and supports ad hoc, situation based, serendipitous learning. The advantage of a game context is that the learning is condensed in a comparatively short and intensive period of time. This allows us to observe requirements and effects more clearly than if it is embedded in normal student life. Furthermore, it is assumed that playing games is an interesting learning approach with its own value - after all, gaming is such a fundamental learning style that it is embedded in the human (and animal) genes. The game could be undertaken by executive MBAs; however because of limited field access we chose to use Bachelor students new to the University. This scenario shows the power of ambient learning intelligence in location-based services. The second case study, the Case Study Scenario, was tested with "real" executive MBAs of the University of Zurich. The Case Study Scenario involves executive MBA students following their studies as they work professionally at the same time and covers a teacher-oriented perspective on modern learning. We chose the form of a case study because it is the typical learning form of an MBA. Furthermore it allows us to link the student's business experiences with the material of the case study. The students have to collaborate with other students and members of their own company. This scenario shows the power of ambient learning intelligence in different learning locations
The MBA strand observed and interviewed students and educators to discover requirements. The requirements ranged from making and sharing annotations of PowerPoint slides to remote control of a classroom projector.
Health strand
The health strand is an example of learning on the job. Initially, we considered several different themes for the Health strand, e.g. general well-being, telematics in support of specialist care, and cancer support. It was not practical to address all of these areas and so the health strand looked at the need for periodic training and updating of skills for first aid workers. First aiders need occasional reinforcement because some time may elapse between their initial training and an event requiring a specific piece of knowledge.
There are various information sources targeted at first aid (e.g. http://www.muslimtents.com/zakihassan/md.htm) which could be accessed by users in a real emergency. Whilst such sites are not envisaged in the MOBIlearn project as a substitute for proper training or advice from a qualified medical practitioner, it would clearly be useful for users to browse such information so that they would be prepared if there were no other options available to them. For example, mountain bikers might like to have acquainted themselves with how to react to a possible broken limb (e.g. don't try to move the victim) which may occur in an isolated location before they leave.
Interactive multimedia medical courseware products have been developed by others for first aid training. User-friendliness, consistency and monitoring of information update are believed to be key issues for market uptake. Using a Web/CD product, citizens will be able to train themselves at a basic level in emergency medicine, in addition to more traditional approaches.
The Health strand employed Future Technology Workshops (FTWs) (Vavoula et al, 2002) with first aiders in a University setting.
3. Establishing Requirements
MOBIlearn used a variety of techniques to gather data during the requirements activity. This information fed the generation and refinement of scenarios that were used to inform envisionment, design and evaluation. The process was very iterative and these scenarios were, in turn, mined for requirements.
Figure 2 below illustrates the overall process, with the experts creating the first set of scenarios which in turn generated the first early requirements for the system. The data gathering exercises with users validated these requirements, produced new ones, and helped to define acceptance criteria.
Figure 2 The relationship between scenarios and requirements
As requirements were identified, they were captured using Volere shells (Robertson and Robertson, 2006) and through a requirements management database they were made available for all partners to view and comment upon.
Each of the strands produced a set of requirements, and many of these overlapped. Furthermore, each of the techniques was deployed by different researchers from various backgrounds, none of whom had used the Volere shell before. They had differing views of what requirements should look like. So requirements sometimes sounded like goals, e.g., "support the learner in everyday situations" but did not specify what the mobile system should do to fulfil this requirement.
So one of the challenges the team faced was to rationalise the requirements and identify generic requirements. To do this, use case diagrams were developed from the scenarios and were used to compare the requirements emerging from the different data gathering activities. We don't explore the role of use case diagrams in this case study, but the generic use case model that was developed in this way is shown in Figure 3.
Once a reconciled specification could be developed this was handed to the technical partners to implement the relevant services.
Figure 3 Generic Use Case Model
3.1 Data gathering
Maiden and Rugg (1996) recommend the use of a range of Requirements Engineering (RE) elicitation techniques. They claim scenario analysis, prototyping, and RAD are the best techniques for new systems. MOBIlearn used the first two of these techniques in addition to questionnaires, observation, interviews, and FTWs. However, due to variations in the user populations, in the environments in which the research took place, and time constraints, it was not possible to run all techniques for each scenario strand.
3.1.1 The Museum Strand
The museum strand used questionnaires to gather data from prospective visitors to the Uffizi Gallery in Florence. One interesting result from the questionnaires, although not specific to learning, indicates a desire to be able to make and pay for reservations from a mobile device rather than the current system of waiting in line for hours. Considering that we were going to create a mobile system in a museum, we started with the following information:
1. Users. The system users are a diverse group, covering a large range of ages,
levels of scientific sophistication and familiarity with computers and handheld
devices. We wanted to provide personalization and user control of the
information and services through customization at the levels of an individual
or a group. The system also needed to support communication between
visitors.
2. Content delivery. The system needed to support both synchronous delivery of
content to handheld device at the exhibit and asynchronous delivery for users
who may not want to absorb a large amount of information on the spot but
prefer to 'bookmark' interesting artifacts and browse the web pages later.
3. Practical considerations. There are issues as to how users can carry and use
any handheld devices, and how well the devices will survive in a somewhat
hostile environment. The physical environment is noisy and bustling. Many of
the exhibits involve whole-body physical action (e.g. spinning around on
turntables or chasing balls across the exhibit area) and/or manipulation using
both hands.
4. Initial Requirements. Initial requirements to create an appropriate mobile-
learning system for museum experiences were:
a. Personal profile,
b. Virtual contextualized maps,
c. Useful information,
d. Simple and complex queries search,
e. Customized information according to users' preferences in terms of
interaction modalities, delivery media, and personal interests in
specific topics;
f. Allow groups visiting the museum to stay in contact with each other
remotely while maximizing each member's museum experience;
g. Control traffic flow for the museum administrator;
h. Display or exchange content;
i. Linguistic and contextualized supporting services;
j. Possibility to make notes and comments at every moment of the
museum visit and on each painting seen.
Two types of questionnaire were created to capture user requirements; firstly from the point of view of the tourists and secondly from the point of view of the museum's director.
The questionnaire developed for visitors is available online at http://www.mobilearn.org/results/questionnaire/questionnaire.htm. Six hundred people were interviewed directly at the Florence Museums and around the Castles of the Duchy of Parma and Piacenza, and some filled in the questionnaire on-line. A summary of the results is in Appendix 1. These results were used to develop further scenarios, and requirements identified in this process were documented in Volere shells. 3.1.2 The MBA Strand We identified two main user profiles for the MBA strand: firstly executive MBAs as the main target group and secondarily undergraduates. Teachers are also important stakeholders, as are administrators, policy makers and employers. The following tables illustrate the user characteristics of the main two groups:
In preparatory interviews for this study, both representatives of the Zurich Executive MBA and from industry showed an interest in including support for alumni into the MBA strand. Such support would include mobile access to knowledge sources after an e-MBA student has finished his or her formal course of study. The access has to be provided as a service specifically tailored to the current situation of the alumni and to the capability of the mobile device. The alumni's situation includes context variables such as his or her knowledge background and his or her organization's training objectives. Knowledge sources include learning content and access to knowledgeable persons.
For the first sub-strand scenario, the Orientation Game, prototype devices were developed and used in order to observe the users' behaviour with such a system. For the second sub-strand scenario, observational studies of students in class, and their use of technology were conducted.
3.1.3 The Health Strand
On closer inspection, the Health strand posed unexpected problems. A major issue of concern to MOBIlearn in the health strand is that in these scenarios, participants may be emotionally involved in the topic in a way which may not apply to the same extent in other application domains. Learners in the health strand will have the additional burden of having to discern appropriate advice, authoritative information and reliable sources in situations where they may be worried, possibly distressed, and possibly seeking reassurance rather than hard information - or even seeking to avoid confronting the reality of the situation they are in, leading them to accept advice which is sub-optimal but which they may find more comfortable. Conversely, there is also the problem of normally healthy patients believing themselves to be at death's door because they believe they exhibit every symptom in the medical dictionary! Drawing on external information sources for first aid, the following initial requirements were identified.
1. Users. As with the Museum scenario strand, the system users are a diverse group, covering a large range of ages, levels of scientific sophistication and familiarity with computers and handheld devices. It will be important that users can annotate content, and create their own 'patient record' associated with the aspects of health that interest them, and perhaps create records for others (e.g. parents for their children). Users must also be able to communicate with other groups or individuals who share the interest.
2. Content delivery. The system will need both synchronous and asynchronous delivery of content to the user depending on the kinds of queries the user inputs. For example, much medical information needs to be read carefully and absorbed over a period of time. Thus, users would need to be able to download material for later perusal. However, checking out the calorie count of a meal, or obtaining information whilst running (e.g. heart-rate) would need synchronous delivery.
3. Practical considerations. The devices will need to be easily carried, or clipped to clothing if the user is engaged in a sporting activity using other monitors. The screen displays for this kind of use would also need to be simple enough to access whilst engaged in activity.
4. Initial Requirements. Initial requirements to create an appropriate mobile learning system for health were:
a. Personal profiles
b. Useful information and support for interpreting certain kinds of
information
c. Possibilities for communication with an expert
d. Access to emergency services
e. Customized information according to users' preferences in terms of
interaction modalities, delivery media, and personal interests in
specific topics;
f. Simple and complex queries search,
g. Allow groups and individuals to stay in contact with each other
remotely in real time
h. Display or exchange content with members of the group
i. Possibilities to make note and comments on content or
communications
j. Access to monitoring methods either through such systems as the Body
Area Network, or linking through other means using mobile devices
k. Access to scientific data regarding food science, sport science, health
levels of exercise, optimal heart rate etc.
l. Lightweight devices
m. Long battery life
n. Some form of global positioning in cases where users may be isolated
(e.g. in the case of sports and fitness training).
The main data gathering technique used in the Health Strand was Future Technology Workshops (FTWs), which were run with first aiders in a University environment. The Future Technology Workshops (FTWs) approach focuses on analysing current user activities and tools whilst at the same time envisioning the future integration of technology and activities. In practice, the FTW method involves the organisation of practical workshops in which targeted users or representative user groups are encouraged to explore and explicate both current and future activities and tools involved in their operational context.
Two FTW workshops involving first-aiders in a University setting were organised during which users were encouraged to interact with various types of "low-tech" and "hi-tech" artefacts to produce models of an envisioned future system for use in first- aid activities. Following this modelling, participants gave presentations of produced models so as to commentate on the operational functions and interface features of produced models.
During the two FTW workshops data was recorded using the following:-
• Video recording of practical modelling activities using video camera
This included the audio capture of pre-modelling discussions, thereafter audio
presentations of produced models involving role-play.
• Audio recording of group discussions whilst modelling
Audio recording machines and tapes were used to capture verbal discussions of
participants whilst they produced models and gave presentations.
• Handwritten notes
Observations were made by assistants monitoring user interactions during
workshop activities. Assistants prepared handwritten notes on various aspects of their observation and interpretation of user behaviour and comments whilst
producing models.
• A minidisk audio recording
A minidisk captured computer compatible audio recording of verbal discussions of participants whilst producing models and when giving presentations. After each workshop, the recordings were transcribed for analysis. A colour coding mechanisms was used to identify operational functions and interface features of envisioned tools and future activities. The definition and use of the term 'tool' in this analytical process was informed and grounded in MOBIlearn about human activities and pedagogy i.e. activity theory. In this respect, the activity theoretical notion of 'tools' embodies both physical tools used to perform human activities, for example a pencil for writing, a fork for eating or a bandage for stopping bleeding on an injury. In addition to this, activity theory recognises the conceptual aspects of tools through their mental mediating capacities, therefore a tool can also be defined as a plan, a formula or operational steps e.g. the first-aid ABC routine for assessing an injured person and context of the incident.
An extract from the requirements identified as a result of the FTWs is in Appendix 2.
3.2 Using Scenarios
MOBIlearn partners generated and drew upon scenarios for each of the strands
described above throughout their activities. Scenarios were initially used to simply
envision the future system in order to inform design, but as the project progressed, the
role of the scenarios grew to encompass
(i) relating system design and implementation to pedagogy by providing a
common frame of reference for developers and pedagogic experts;
(ii) through a process of refinement, defining the evaluation strategy for the
user trials; and
(iii) allowing us to keep the user at the heart of the development project.
Thus, scenarios provided a coherent focus for technical, pedagogic and user-centred
partners and helped to resolve the difficulty identified by Taylor (2004) of how to
bring together the relatively high level issues of pedagogic evaluation and the more
technical user-centred system evaluation.
We began to use scenarios in the project to fulfill a dual function. The first was to assist in the process of 'envisionment' (Carroll, 1995) of the mobile learning environment. An example of these initial scenarios is shown in Figure 4. The second was to begin considering basic requirements to enable us to progress towards data gathering with users that will provide us with user requirements in the user-centred context (see the initial requirements lists in Section 3.1 above).
The first phase of our activity was to invite all members of the consortium to contribute scenarios, primarily for the purposes of envisionment, but we also wanted to scrutinise the scenarios to see which might be suitable for development towards the evaluation user trials. Twenty-seven scenarios were submitted, 3 within the Health strand, 9 within the MBA strand, 11 within the Museum strand and 4 outside of these categories.
We next examined these scenarios to identify the basic requirements for mobile learning, and to pull out the common elements across all three strands. For example, from the list of initial requirements in 3.1.1 and 3.1.3 above, common requirements for the Museum strand and the Health strand were the need for personal profile, communication, and simple and complex queries (among others). This gave us a general top-down view of the essential elements of a future mobile learning environment, as identified by informed experts.
Figure 4 An 'envisionment' Health scenario
Unfortunately, all of the Health scenarios generated at this time had several disadvantages, and Figure 4 illustrates this well. Firstly, it raises important social issues - for example, the ethical question as to whether diagnosis should be made at a distance like this on an unknown patient. Ascertaining the level of shock, for instance, might be hard, or establishing whether there are any possible confounding factors for the diagnosis which wouldn't be evident from a transmitted picture of a hand. Secondly, it deals with an emergency situation (which is not easily replicable) and involves a range of services which do not currently exist. Thirdly, no learning takes place within the scenario, and since we were building a pedagogically sound mobile learning environment, this was a drawback.
Another suggestion was a scenario in which first aid advice is provided on a personal digital assistant (PDA), which raised worrying visions of a first-aider trying to perform CPR whilst fiddling with the PDA to access the next screen of information. To overcome this, in the Health strand, we focused on training scenarios such as the one in Figure 5.
Figure 5 An example scenario from the Health strand
Whilst this scenario was satisfactory from the point of view of the pedagogic experts, it was still not sufficiently detailed for either the technical team or the evaluation team - it was too high level, and there was a great deal of room for conjecture as to what the actual system might be to support the activities described. This produced a slight impasse in the design process because the pedagogic experts and evaluation experts felt they couldn't be much more specific, whilst the technical teams felt that they didn't have enough information to proceed. The piece of the jigsaw that was missing, however, was the relationship between activities of the participants and the expected activity of the system.
It was important, therefore, that the links between services and requirements, and between requirements and testing / evaluation were identified by the decomposition activities carried out as part of the final test instantiation, and in this process, further documentation was required which mapped from scenario activity, through sub- activities to system services and the expected system response (see Figure 6).
Figure 6 Extract from scenario description matching participant activities with system services
The method of successive refinement we used for these scenarios has much in common with the approach to scenario development described by Cugini et al (1999). We would, in effect, move from the high-level descriptions through to fully specified scenarios, and eventually arrive at a level of description close to a scripted scenario. As the level of detail became more specified, the technical team would be able to comment on the technical feasibility. We defined our own terminology as follows:
• Agreed scenarios are a set of scenarios which project members agree to work with intensively. These capture the expertise of partners with experience of teaching and learning. Because the scenarios provide a context, pedagogic considerations can be developed, and are embedded into the envisaged user activities of the scenarios from an early stage.• Test scenarios developed from the agreed scenarios go into more detail, specifying even more details of context, content and tasks.
• Instantiated scenarios locate the activities in a real place (e.g. the Uffizi Museum in Florence, Italy). These scenarios provide the structure of the user trials.
Figure 5 represents an example 'agreed' scenario, in that the partners all agreed to work with it. It also represents a 'test' scenario in that it was feasible to refine it for use within the user trials context. Not all 'agreed' scenarios were also 'test' scenarios as some of them could not be instantiated. Figure 6 represents an extract of an example 'test' scenario.
The scenario development process took place collaboratively between the relevant teams. In this case, between system developers; pedagogic and domain experts; and requirements and evaluation leaders (see Figure 7).
Figure 7 The scenario development process
This allowed work to progress in parallel - whilst the pedagogic and evaluation teams could discuss what tasks the learners would be engaged in, the system developers were able to identify some system requirements, and begin organising their approach to implementation of the system. This breaks the deadlock of no-one being able to move because they are waiting for output from other teams.
4. Documenting requirements using Volere
The project used Volere shells to document the requirements it identified (see Figure 8). The team developed a database to capture the evolving requirements, and to allow all project partners around the world to view and edit them. Using the Volere shell had a number of advantages (Sharp et al, 2003):
1. As all requirements were documented using this format we had consistent
information for each requirement together with traceability information to
track where the requirement originated, and where it appears in later
documentation such as UML diagrams.
2. Having requirements documented in a consistent manner facilitated the
identification of common requirements across scenario strands.
3. The format is clear and simple to follow.
4. The format encourages the originator of a requirement to study the detail of
the requirement (description), to justify it (rationale) and to consider how it
relates to other requirements (dependencies/conflicts).
5. Completing the 'Fit Criterion' field requires the originator to think about how
the requirement can be tested or evaluated. This fed directly into our
evaluation activities and supported the work there.
6. Volere shells were stored in a database for easy search and retrieval. As the
number of requirements grew, the database was updated.
Figure 8 The Volere shell used to document requirements
4.1 Adapting the shell
Although the shells appear to be straightforward, the time commitment required to complete the shell is not negligible, and our researchers frequently found it difficult and time consuming. If we were to convince them to persist with the requirements activities, we needed to adapt the shell to suit the purposes of the project, and to encourage people to use it. In response to user feedback, we added two extra fields to the database template for the shell: status and title. The status field allows researchers to look at requirements in various states of completion, e.g., all requirements in the process of being refined. The title gives a short description that is useful for quick review of all the requirements. These simple additions helped enormously to locate particular requirements.
The database, with this front end, enabled our partners across Europe to inspect the
requirements so far, and to create or modify entries as and when they were able to
work on them. In principle, the idea was that this would prevent a bottleneck, as all
partners who asked for access could have it, and it supported the idea of distributing
responsibility for requirements across all members of the project. Furthermore, the
requirements contributed became a common resource that all could inspect, so discussions could take place around specific requirements and their development. It
was hoped that this would make the task of refining initial attempts easier.
4.2 Adapting the template
The initial version of the database was based on the Volere template's 27 types of requirements (see Figure 9). We found that it was straightforward to store a requirement and assign one of the 27 Volere categories. In addition, we found that some categories fitted our needs well. For example some first-aiders wanted a feature that would immobilise an injured person. Inventing such a technology is not part of the mandate of the project, but we did not want to lose track of any requirement and so used the 'waiting room' category for this kind of requirement. However the stakeholders did not find this categorisation system helpful for retrieval. About 66% of our requirements were in one category - functional and data requirements - and the 27 categories did not provide useful search keys. We therefore split functional and data requirements into separate sub-categories, but this change did not make enough of a difference because there were still about 64% of the requirements in the single category of functional requirements. This led us to attempt to sub-categorise functional requirements as a means to improve the organisational structure of the requirements database. However this attempt revealed how difficult categorisation is.
Although we tried several categorisation approaches, we found that the most appropriate solution for our users was to allow flexible, non-static, and ad-hoc categorisations (Haley et al, 2004). Users with appropriate permission were given permission to add a new categorisation criterion at any time. Thus, the database could be modified easily to reflect new perspectives, decisions, information, and experience.
For example, at the beginning of the process we set up categories using the criteria of Strands (health, MBA, and museum) and of Work Packages (e.g., learning content, mobile media delivery, context awareness). After more experience, we discovered a need to find all requirements pertaining to a particular service. Later, partners found that looking at requirements based on Work Package did not suit their needs because a particular Work Package had members from different countries as well as different organisations. Partners could then add a new criterion, location, to the database. The disadvantage to this method is the need to add an additional piece of data to every requirement when a new categorisation scheme is adopted. Mitigating this disadvantage is that, with a well designed database, the process of adding data is straightforward even if time consuming.
This simple idea of providing the ability to modify the categorisation criteria of the requirements database enabled it to meet the needs of the many different project members throughout the life of the project. It also illustrates how such a flexible resource can support the dialectic between requirements and implementation, each influencing the other as time progresses.
5. Some example requirements
A project of this size generates a large number of requirements. Many of them are implemented on widely available PDAs, i.e. they are not specific to the goal of learning, and are commonly available, e.g. requirements concerned with connectivity, context-awareness, physical properties and context of use. The requirements workpackage attempted to identify requirements more specific to mobile learning. The following examples illustrate requirements from each of the strands, and the modifications to the Volere shell and the categorisation system (called classification below) discussed above. Note that some of these examples include use case numbers. We have not focused on the role of use cases in this case study, but these were generated to help rationalise requirements and to bridge the gap between scenarios and implemented services. Note also that, particularly in Figures 12 and 13, the number of different classification categories assigned to each requirement.
Figure 10 Example requirement from the Health Strand expressed in our modified Volere shell (as displayed from the database)
Figure 11 Example requirement from the MBA Strand expressed in our modified Volere shell (as displayed from the database)
Figure 12 Example requirement from the Museum Strand expressed in our modified Volere shell (as displayed from the database)
Figure 13 Example requirement common to two Strands expressed in our modified Volere shell (as displayed from the database)
Concluding remarks
This case study has explained
• How scenarios may be used throughout the project to bridge the gap between
user-centred and pedagogical concerns expressed by domain experts,
requirements as gathered from user-centred data gathering sessions, and
technical design issues.
• That it is important to keep the focus of the scenarios on relevant aspects of
the domain so that the requirements will be appropriate (e.g. in the first aid
scenarios it was decided to target training rather than emergency events).
• That the Volere shell and template may be modified to suit project-specific
circumstances, and should not be regarded as a rigid structure
• Some issues faced by members of a large multi-stakeholder project aiming to
develop technology of the future. For example, that different stakeholders
have different expectations and needs from a set of requirements; that different
stakeholders have different views of what a requirement should look like; that
it is easy for futuristic scenarios to become unrealistic and unhelpful.
Acknowledgements
We would like to thank all members of WorkPackage 2 of MOBILearn for allowing us to produce this case study. In particular, Paul Crowther, Dirk Frohberg, Elena Murelli, Daisy Mwanza, Luis Palacios and Giasemi Vavoula.
References
Carroll J.M. (Ed), 1995, Scenario-Based Design, John Wiley and Sons
Cugini, J., Damianos, L., Hirschman, L., Kozierok, R., Kurtz, J., Laskowski, S., and
Scholtz, Jean (1999) 'Methodology for Evaluation of Collaborative Systems' The
Evaluation Working Group, The DARPA Intelligent Collaboration and Vizualisation
Program.
Haley, D., Nuseibeh, B., Sharp, H., Taylor, J. (2004) 'The Conundrum of Categorising
Requirements: Managing Requirements for Learning on the Move' proceedings of
RE'04, pp.309-314, Kyoto, Japan, 6-10 September 2004, IEEE Computer Society
Press, ISBN 0-7695-2174-6.
Maiden, N. and Rugg, G. (1996) 'ACRE: A Framework for Acquisition of
Requirements', IEE Software Engineering Journal, 183-192, May.
Robertson, S. and Robertson, J. (2006) Mastering the Requirements Process, 2nd edn.
Addison-Wesley, Boston.
Sharp, H., Josie Taylor, Andreas Löber, Dirk Frohberg, Daisy Mwanza, and Elena
Murelli (2003) 'Establishing user requirements for a mobile learning environment', in
Proceedings of Eurescom Summit 2003, Heidelberg, 29 Sept to 1 Oct.
Taylor, J (2004). 'A task-centred approach to evaluating a mobile learning
environment for pedagogic soundness', in Attewell J and Savill-Smith C (eds)
Learning with mobile devices. Learning and Skills Development Agency ,167 -171
Vavoula, G., Sharples, M., & Rudman, P. D. "Developing the 'Future Technology
Workshop' Method," In M. Bekker, P. Markopoulos, & M. Kersten-Tsikalkina (eds.),
Proceedings of Interaction Design and Children. Eindhoven, The Netherlands, 2002
Appendix 1: Results from the Museum strand questionnaire
The results are in three sections: personal data, services before entering the museum, and services once inside the museum.
1. Personal Data
Of the people interviewed, 54% were male and 46% were female. From these first
results it is possible to state that:
• The interviewed tourists are part of a relatively young public (31% between 18
and 25 years old -23% between 25 and 30);
• They visit museums and castles 2 or 3 times a year in their spare time or
during holidays;
• Almost of all of them (91%) have a mobile phone and 55% of those have a
Nokia;
• Few people (15%) have a palmtop.
2. Services Accessible before entering the museum
Interviewees were asked to indicate, according to their personal opinion, the degree of
importance from 1 (not important) to 5 (very important) of the function and services
offered through the use of mobile technology (mobile phones/palm held computers) in
visiting museums.
The results of this first part of the questionnaire are satisfying: the tourists find the services proposed that are accessible BEFORE entering the museum very interesting and useful. In particular, 58% rated "booking the tickets in advance" as 4 or 5, 55% rated "receiving information about the museum opening times and any related changes" as 4 or 5 and 55% rated "viewing the shortest route to reach the destination" as 4 or 5.
The services proposed are appreciated by tourists because they see the possibility to find their way around an unknown town and they would like to avoid any type of inconvenience (changes in the timetables) especially during their holidays or a week- end.
3. Services Accessible during the visit at the museum For this second part, the results analysis highlighted the following issues:
• The services: "Viewing museum plan", "Planning the visit according to
personal interest and requirements" and "Reaching the area of interest as
quickly as possible" made a good impression on tourists. 49% rated the
museum plan as 4 or 5 in importance, 53% rated planning the visit as 4 or 5 in
importance, and 48% rated reaching the area as 4 or 5 in importance. Note the
fact that several people expressed doubts about the transferability onto PDA or
mobile phones of a plan of the museum as mobile devices screens are small
and maps are usually large.
• Opinions are positive about "viewing a catalogue of works by a particular
artist" (47% rated 4 or 5) and "understanding the artist's techniques" (53% rated 4 or 5). Few people want or have time to make notes or comments during
their visit except for those that visit museums for work or for study purposes;
• Opinions are very positive on the use of an audio guide (32% of the persons
interviewed gave a mark of 4 and 32% gave 5) as it is considered a good
alternative to the traditional guide especially for those that usually make the
visit alone.
• From a general point of view, it is possible to say that the tourists interviewed
expressed positive opinions and interests on the use of mobile technologies
and their applications inside museums.
Appendix 2: Results from the Health strand FTWs
R1: Support Communication
Communication for First Aiders is important in a number of contexts:
• To pass information to others (notify health and safety about safety hazards,
orally describe location/features, ambulance and emergency services)
• To consult with/get information from others (emergency services provide
diagnostic information, OHP staff)
• To (asynchronously or synchronously) contact fellow First Aiders to exchange
experiences
• To call for help (security for ambulance, First Aider or emergency staff)
• To trace colleagues (trace paramedics or nearest emergency centre)
To aid communication, the system should support:
• Automatic transmitting of information (e.g. transmit location to paramedics)
• Automatic locating and contacting (ambulance services)
• Audio and video communication - enable exchange of audio and visual
information (e.g. First Aider describes injury and transmits image)
In terms of technical requirements for the communication system, the following were
mentioned:
• Microphone and speakers
• Video
• Wireless audio communication
• Synchronous and asynchronous means of communication
• Location awareness
R2: Provide Diagnostic Tools
A toolkit that would assist the First Aider in assessing the situation and making a
diagnosis should be part of the system. Such a kit should include tools/sensors for:
• Assessing safety of the area around the incident
• Providing First Aider with step-by-step instructions in producing a
diagnosis/administering First Aid
• Testing vital signs during an emergency
• Monitoring blood pressure
• Checking airways for blockages
• X-ray injuries/photographs of injuries
• Monitoring heart function
• Stabilizing/immobilizing patient
• Checking oxygen levels
• Sensing body temperature
• Detecting fluid
• Providing First Aider with step-by-step instructions in following ABC
procedure in conjunction with diagnostic functioning
• Checking pupil dilution
The diagnostic toolkit needs to be
• Portable, and therefore lightweight
• Applicable on victim's body to take readings
• Automatically activated (e.g. when lifted up)
• Taking continuous readings to assess patient as situation progresses
• Location aware
R3: Provide On-line First Aid Manual
The system needs to provide an on-line First Aid Manual that is easily accessible and
searchable
R4: Provide means for capturing and sharing experiences among First Aiders
The system needs to provide the user (First Aider) with a diary-like facility to capture their First Aid experiences for future personal use as well as for future exchange with fellow First Aiders. The system should incorporate a central database of personal experiences that all First Aiders can access as needed. The information in the diary could also be used in producing reports.
R5: Provide means for maintaining First Aid kit
The system should be monitoring the First Aid supplies and aid the user (First Aider) in replenishing the First Aid kit.
R6: Assist the user/First Aider to maintain practical skills
The system should provide the user with practice exercises and tools like 'Tip of the Day' that aid in revising and maintaining their practical skills.
R7: Non-functional and technical requirements
The following non-functional and technical requirements can be extrapolated:
• Need for wearable and flexible (hardware) technology
• Central database
• Immobiliser (?)
• Abide by First Aid standards and procedures
• Lightweight, mobile system
• Incorporate sensors/scanners
• Incorporate video/image capturing and transmitting
• Operate on identification/password
• Incorporate alarm