Establishing Requirements for a mobile learning system
Helen Sharp, Josie Taylor, Diane Evans and Debra Haley, The Open University
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
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
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
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
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
The Museum strand gathered data initially through questionnaires with visitors and
museum staff, then ran field trials with prototypes once they were available.
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
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.
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
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
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
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
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
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
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
The questionnaire developed for visitors is available online at
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
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
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
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
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
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
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
• 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
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
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
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
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
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)
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.
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.
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
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.
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
• Almost of all of them (91%) have a mobile phone and 55% of those have a
• 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
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-
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
• 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
• 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
• Microphone and speakers
• 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
R4: Provide means for capturing and sharing experiences among First
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