SCENARIO-BASED REQUIREMENTS ELICITATION IN

A PAIN-TELETREATMENT APPLICATION

I. Widya, R. G. A. Bults

University of Twente, Centre for Telematics and Information Technology

Remote Monitoring & Treatment Group, The Netherlands

M. H. A. Huis in ’t Veld, M. M. R. Vollenbroek-Hutten

Roessingh Research and Development, The Netherlands

Keywords: Requirements engineering, Requirements elicitation, Telemedicine, Trial design, Goal-oriented, Task

analysis.

Abstract: This paper proposes a way to elicit requirements in the domain of eHealth, in particular telemedicine

treatment, that is in alignment with the evidence based working practice in medicine. In collaboration with

ICT developers, medical professionals co-shape the intended system, which has to support the telemedicine

application. These professionals develop a scenario and provide feedback to the subsequent requirements

elicitation process which is based on the developed scenario. We propose a mix of methods and techniques

to elicit requirements holistically to achieve the previously mentioned alignment. The requirements

elicitation applies basically a top-down scenario based approach, however complemented with additional

methods to overcome the inherently incompleteness of scenarios. In the proposed approach, we for example

analyze treatment tasks and their goals that are not only identified or inferred from the scenario but also

from the treatment protocol defined in an associated treatment trial design. This paper only addresses the

early phase of requirements engineering, later phases, which require refinements of associated use cases, are

beyond the scope of this paper.

1 INTRODUCTION

The early stages of the development of a software

based system are considered crucial to a successful

design (Yu, 1997). Requirements wished by users or

involved stakeholders of the system to be designed

have to be elicited, analyzed, negotiated, specified

and evaluated in these stages. The engineering

activities on requirements for e-Health application

supporting systems in general, and telemedicine

treatment supporting systems in particular, are

challenging research topics which deserve more

attention.

Design of a telemedicine application supporting

system is a complex multidisciplinary effort

involving medical professionals and Information,

Communication and Technology (ICT) developers.

Evidence based medicine (Sackett and Rosenberg,

1995) requires the collection of medical treatment

evidences, each one of which typically is acquired in

stages. One of these stages includes the design of

trials and the trialling of the proposed treatment

protocol on humans. Trial results will then become

evidence for practitioners to enable evidence based

treatment of their patients in the post trial phase.

Trial design (Meinert, 1986) defines the proposed

treatment protocol and the setting of the trial, for

example the trial inclusion and exclusion criteria,

which in turn define certain characteristics of

participating patients like age, gender and

disabilities. These trial design components are

therefore important for requirements elicitation.

Accordingly, ICT developers have to hook into the

trial design to improve requirements elicitation. On

the other hand, medical professionals who design

trials (i.e. trial designers) need ICT based systems to

enable teletreatment in accordance with the

proposed treatment protocol. This intertwinement

requires close multidisciplinary collaboration

between the experts of the two domains.

406

Widya I., M. R. Vollenbroek-Hutten M., H. A. Huis in ’t Veld M. and G. A. Bults R. (2009).

SCENARIO-BASED REQUIREMENTS ELICITATION IN A PAIN-TELETREATMENT APPLICATION.

In Proceedings of the 4th International Conference on Software and Data Technologies, pages 406-413

DOI: 10.5220/0002287404060413

 SciTePress

This paper discusses how to elicit requirements

for a telemedicine application supporting system in a

multidisciplinary collaboration setting, in which

medical professionals co-shape the system to be

designed. It only addresses the early phase of

requirements engineering, later phases which for

example address requirements on detailed look and

feel of screen windows human computer interfaces

are beyond the scope of this paper. In particular, this

paper describes the requirements elicitation in a

work-related neck-shoulder pain teletreatment trial.

The requirements elicitation basically applies a

top down development approach in which a scenario

plays an essential role as a common universe of

discourse to bridge the collaboration gap between

the trial designers (i.e. medical professionals) and

the ICT developers (see also Cysneiros (2002), Go

and Carroll (2004), and Van Helvert and Fowler

(2003)). Since scenarios are inherently incomplete

and a holistic solution is necessary in evidence based

medicine, other methods have been used to

complement our scenario based requirements

elicitation process. We investigate constraints

imposed by identified stakeholders of the trial, who

are not necessarily users of the intended system. ICT

developers study parts of the trial design and also

cross disciplinary literature on pain treatment.

Furthermore, we analyze the objectives of the

treatment tasks and activities, which are not only

identified or inferred from the scenario but also from

the trial design. This is in line with the way of

working in medicine and if viewed from the

mentioned analysis perspective we apply a goal

oriented requirements elicitation approach (cf. Letier

and Lamsweerde (2004), Mylopoulos et al. (1991)

and Yu (1997).

Moreover, our approach applies a mix of

methods and techniques known in the area of

requirements engineering or the medical domain.

The considered added value of this work is therefore

more on the application and the combination of the

methods and techniques in a way in accordance with

the working practices in medicine. Such alignment

with medical working practices is considered one of

the success factor conditions for usable telemedicine

systems (Wootton et al., 2006).

This paper is organized as follows. The next

section describes the teletreatment application.

Thereafter, we discuss the scenario based

requirements elicitation approach and the elicitation

results. Section 4 discusses some of the lessons

learned and in the last section we present the

conclusion of the work.

2 TREATMENT APPLICATION

This paper addresses a work-related neck-shoulder

pain teletreatment application of the European eTEN

project MyoTel (Myofeedback-based Teletreatment

service) (MyoTel, 2009). This project investigates

the feasibility of deployment of a myofeedback

based teletreatment service that enables patients with

neck-shoulder complaints to receive personalized

remotely supervised treatment during their daily

activities at their place of work. It validates the

teletreatment service in four European countries.

The MyoTel service uses clinical data, in

particular surface-ElectroMyoGraphy (s-EMG) that

represents the trapezius muscle activity. Measures of

muscle activation and relaxation patterns are fed

back to the patient and also presented to a remote

treating myofeedback therapist. This service

provides three feedback loops to enable control of

patient’s muscle activation and relaxation patterns

(Figure 1):

• a micro-loop provides local tactile feedback in

the form of vibration from a body-worn device

to indicate insufficient muscle relaxation results

averaged over a moving time window,

• a meso-loop provides visual feedback on a PDA

screen to indicate near real time muscle

activation performance of the left and the right

trapezius muscles, and

• a macro-loop provides supervised feedback

from a remote therapist during planned

consultation sessions.

The MyoTel telemedicine system consists of the

following: 1) a Body Area Network (BAN)

consisting of body-worn s-EMG sensors and

vibrating actuator and a gateway PDA with wireless

public network access, 2) a MyoTel m-Health portal,

3) a Terminal of a therapist, and 4) a hybrid data

Communication Infrastructure consisting of public

and private wireless networks, the internet and

optionally an intranet.

Figure 1: MyoTel neck-shoulder pain teletreatment system.

SCENARIO-BASED REQUIREMENTS ELICITATION IN A PAIN-TELETREATMENT APPLICATION

407

3 ELICITATION APPROACH

As mentioned earlier our elicitation approach uses a

mix of methods and techniques known in the

literature in the area of requirements engineering or

medical trial design. In this section, we describe and

justify how we combine them to elicit requirements

in the domain of telemedicine.

In a multidisciplinary collaboration, trial

designers and ICT developers firstly develop a

scenario which reflects the treatment protocol

proposed in the trial design. Based on this scenario,

the requirements for the intended system will be

elicited. As discussed earlier, this elicitation process

is complemented with a stakeholder analysis and

also a task and task objective analysis. To improve

the process, ICT developers study pain treatment

literature and parts of the trial design.

During the elicitation process, the ICT

developers conduct several e-mail exchanges and

(semi) structured interviews with the trial designers.

Group discussions in a participatory design setting,

for example conducted during plenary project

meetings, are in our case used for feedback on the

scenario in development and feedback on identified

(and prioritized) requirements. The elicitation, which

depends on feedback of the trial designers who are

myofeedback treatment professionals, uses tables,

textual descriptions, and window screen mock-ups to

specify the requirements. Analyzed and prioritized

requirements in each iteration cycle of the early

phase requirements elicitation are checked by the

trial designers to validate the derived telemedicine

system functionality with respect to their

expectation. During these interviews and group

discussions the trial designers, who are also treating

therapists, therefore validate the requirements.

3.1 Scenario

Different definitions, scopes and objectives of

scenarios are given in the literature. In this paper, we

adopt the definition of Van Helvert & Fowler

(2003): “a scenario is defined as a concrete

description of an activity that the users engage in

when performing specific tasks, a description that is

sufficiently detailed so that design implications can

be inferred or reasoned about”.

In accordance with Go & Carroll (2004) but

slightly adapted here, scenarios can be categorized

as follows:

• Year in the life scenario: typically used in the

area of strategic planning;

• Day in the life scenario: which illustrates user’s

daily activity, for example, in the setting of the

envisioned application of the system to be

designed;

• Activity in the life scenario: which describes the

use of the system to be designed. These

scenarios are also called use-cases, which

specify user’s interactions with the intended

system.

Benyon & Macaulay (2002) categorize scenarios

amongst others into user-centred perspective PACT

and designer-centred perspective FICS scenarios.

PACT stands for People, Activity, Context and

Technology, for example related to the users using a

technology in their daily activity within a certain

context. FICS stands for Function and events,

Interactions and usability issues, Content and

structure, Style and aesthetics, for example related to

system use.

In the MyoTel project, we develop a day in the

life scenario of a patient but combined with

corresponding activities of the treating therapist

(Figure 1). The purpose is to present the end-to-end

interrelations of the treatment activities of the two

actors that to some extent reflect the teletreatment

protocol.

The development of the scenario is moreover

iterative. First, the trial designers specify a day in the

life scenario in terms of PACT. In the setting of a

participatory design, the ICT developers provide

feedback by proposing FICS extensions to the

scenario. As owner of the scenario the trial designers

provide an updated scenario, eventually yielding a

mixed form day in the life scenario containing

PACT elements combined to some extent with FICS

elements. The benefits of this approach are that

• the scenario preserves its role as an embodiment

of (part of) the treatment protocol and it also

preserves the way of working in pain treatment

as defined by the trial designers;

• ICT developers understand the implication of

the scenario in respect of the required system

support functionality. This is also confirmed by

the trial designers who incorporate those FICS

feedback in the scenario and thereby implicitly

agreeing with the interpretation of the ICT

developers.

In this way, the scenario acts as a common universe

of discourse yielded by the discussed handshake

protocol. This scenario therefore bridges the

multidisciplinary collaboration gap between the trial

designers and the ICT developers.

The developed scenario is shown below.

ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies

408

MyoTel Scenario. Lisa is 35 years old. She is

working at a large administrative company and

predominantly performs computer work. She suffers

from neck-shoulder pain which is, to Lisa’s opinion

related to the computerwork she performs because

during holidays the complaints reduce. Because of

this, she was allowed to have a new treatment

approach; the MyoTel myofeedback treatment

service. By means of the MyoTel service subjects

are taught to relax their neck-shoulder muscles (so-

called trapezius muscle). During her daily work,

Lisa carries her Myotel BAN with her. The BAN

consists of a garment, in which dry surface

electrodes are incorporated, which continuously

measure the muscle tension of her trapezius muscle.

The garment can be worn under the clothes. The

garment is connected to a processing and feedback

unit which vibrates when an insufficient amount of

muscle relaxation is measured. The vibration of this

unit provides feedback on results (sufficient or not

sufficient relaxation). Because of this vibration, Lisa

knows her muscle relaxation has been insufficient

for a while. In order to stop the vibrating signal, Lisa

has to relax her trapezius muscle for instance by

means of the relaxation exercises she has learnt from

her myofeedback therapist. She is able to check her

muscle relaxation patterns (parameters: Root Mean

Squares (RMS) and Relative Rest Time (RRT)) for

both her right and left side of her trapezius muscle

live on the visual display of the PDA within the

BAN. This visual information is considered to be

very important as it provides Lisa more detailed

information about her performance, compared to the

vibration of the processing unit. The PDA also

automatically sends the measured EMG or the

derived muscle relaxation pattern data via a safe

wireless communication infrastructure to a secured

MyoTel portal which is accessible for remote

consultation purposes. Lisa receives four weeks of

treatment during which she wears the MyoTel BAN

and notes her activities and pain intensity in a diary

on the MyoTel portal. Weekly counseling sessions

of approximately 30 minutes with the myofeedback

therapist take place. At the start of the MyoTel

treatment, Lisa and the Myotel therapist meet in vivo

(face-to-face). During this so-called introduction

session (in vivo), the myofeedback therapist gives

instructions about the MyoTel system and explains

the principles and course of remotely supervised

myofeedback treatment. Lisa can read all the

instructions in the manual which is provided along

with the MyoTel equipment. In addition, the

therapist ensures that Lisa’s work station comply

with the ergonomic guidelines and uses a checklist

for the main work times, work tasks, working hours,

workload, and work style. On the visual display of

the PDA the therapist views the muscle activation

patterns to check whether the garment which is worn

by Lisa for the first time is properly adapted to her

anatomy. Thereafter, at least three weekly remote

counseling sessions take place (by telephone) in

which Lisa is taught about personal work style in

relation to muscle tension and beginning techniques

to manage actual stressors at work and at home that

may affect her musculoskeletal health. Prior to the

remote counseling session (conducted by telephone),

the therapist prepares the consultation. This means

the therapist logs in on the web-based Myotel portal,

selects Lisa from the patient list, and zooms in/out

on the (historical) muscle activation patterns of the

data available. The therapists seeks for differences in

left and right side of the trapezius muscle, tries to

find patterns in muscle relaxation over the day

and/or week, identifies tasks which accompany

elevated levels of muscle activation of the trapezius

etcetera. In addition, screenshots of deviating or

remarkable muscle activation patterns can be send to

Lisa for more detailed feedback and discussion.

After four weeks of treatment, Lisa visits the

myofeedback therapist (in vivo) for the final

counseling session and to collect the myofeedback

equipment. After four weeks of treatment the pain

intensity in the neck-shoulder has been reduced and

Lisa is able to recognize symptoms of insufficient

levels of muscle relaxation even in the absence of

the service.

Refinements of the scenario towards use cases

which specify detailed actor’s interactions with the

intended system, for example by incorporating

detailed FICS elements, are beyond the scope of this

early phase requirements elicitation paper.

3.2 Complementary Elicitation Inputs

To augment the elicitation process which is based on

the developed scenario, other elicitation process

inputs have been used.

3.2.1 Cross Disciplinary Study

ICT developers investigate literature on pain

treatment and partially study trial design. The

benefits of such study for these ICT developers are

for example:

• understand medical vocabulary better; this is a

necessity in a collaboration with trial designers

who co-shape the intended system (see for

similar experience also in Cysneiros (2002));

SCENARIO-BASED REQUIREMENTS ELICITATION IN A PAIN-TELETREATMENT APPLICATION

409

• get a better understanding in the clinical case,

including the treatment protocol, to enable

alternative solutions (cf. Cysneiros (2002)). The

inclusion and exclusion criteria e.g. provide the

characteristics of patients that are useful for the

design of the human machine interfaces;

• get a better insight in the required quality of the

clinical data. This helps the estimation of the

required Quality of Service of data transport

channels.

3.2.2 Stakeholder Analysis

Telemedicine typically requires holistic solutions.

Demands or constraints imposed by the many

different telemedicine stakeholders have to be taken

into account in case that the teletreatment protocol

has to be medically approved or deployed in large

scale. For example, treatment protocols have to

conform to medical regulations such as the

regulations and guidelines of the governments, the

Medical EThical Committees (METCs) or the

specific association of the specialty.

In our case, the METCs in the four European

countries have to approve the trial design. To

anticipate to their demands, the trial design includes

patient data privacy and security aspects, because

regulatory stakeholders typically do not participate

in the participatory design where requirements

elicitation takes place. In medicine therefore, we

often deal with stakeholders who are not users of the

intended system. We identify and analyze the

interest of these stakeholders, thereby augmenting

the requirements elicitation process which is based

on the scenario.

A special MyoTel stakeholder is the European

eTEN Programme Commission who sponsors the

trial (Section 2). This stakeholder constrains the

system software adaptation, because the eTEN

programme only grants minor software adaptation.

Consequently, this stakeholder reduces the set of

elicited requirements to those that are feasible for

implementations, not only from a cost/benefit

perspective but also from a software development

effort perspective.

Due to the scope of the project, i.e. collecting

medical evidence by trials, the identified

stakeholders are the relevant ones for preparation

and running the trials. Other stakeholders, for

example, relevant for large scale roll out of the neck-

shoulder pain treatment service are not considered in

this requirements elicitation process.

Stakeholders that have been identified or inferred

from the scenario or the trial design are: the users

stakeholder (i.e. representing both the patients and

therapists), the telemedicine system provider, the

communication system provider who provides the

wired or wireless data transport connections, the

MyoTel Centre of Excellence (CoE) who hosts the

trial, the employer of the patient who provides the

computing and internet access facility, the METC

and to some extent the project sponsor.

3.2.3 Role of Goals

We adopt the scenario definition of Van Helvert &

Fowler (2003), because scenarios described in terms

of tasks and activities are in accordance with

working practices in medicine. We analyze and

decompose the treatment tasks or activities,

including their objectives (i.e. goals), to collect or

infer requirements. Objectives of the treatment

protocol (e.g. specified in the trial design),

corresponding tasks and the associated activities

(e.g. identified or inferred from the scenario) play an

important role in inferring new requirements or in

identifying alternative requirements. Our approach is

therefore goal-oriented (Letier and Lamsweerde,

2004; Mylopoulos et al., 1991; Yu, 1997) and

accordingly, we decompose goals of treatment tasks

in a similar but informal way as in the previously

referred papers (

Figure 2).

Example. A therapist who supervises the training of

a patient strictly (a task), needs amongst others to

check the training discipline of the patient (a

subtask, which goal is e.g. represented by

SupervisedCompliance in Figure 2). Figure 2

presents a partial goal model expressed using the

notation discussed in Letier and Lamsweerde (2004).

The goal of managing the training compliance of a

patient is represented by PatientCompliance. This

goal can be achieved if amongst others

SupervisedCompliance is achieved. The figure also

shows that the preparation of consultation material

(whose goal is represented by ConsultationMaterial)

is achieved when the Activity Relaxation Patterns

(ARPs) of the patient is analyzed and annotated. For

this, a minimum set of measured data (mARPset)

has to be available. The arrow with multiple tails in

Figure 2 symbolizes an AND-refinement of the goal

at the head of the arrow by the goals at the tails of

the arrow (Letier and Lamsweerde, 2004), see also

(Mylopoulos et al., 1991). In the goal model

furthermore, the therapist may retrieve the patient’s

activity relaxation pattern data (PatientARPs) by

operationally logging in onto the MyoTel portal

(RoleBasedLogin), listing and fetching the patient’s

files that contain the RMS and RRT of the measured

ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies

410

right and left shoulders s-EMG signals (which goals

are represented by ListPatientARPs and

CollectARPs, respectively; see also “tha_10” and

“tha 23” in Table 1).

ConsultationMaterial

mARPset Analysis&AnnotationsOfARPset

(private)PatientARPs

RoleBasedLogin ListPatientARPs Col lectARPs

PatientCom

liance

Super visedCompliance

…

Figure 2: Consultation Material Preparation Goal Model.

3.2.4 Requirements Elicitation Results

A close inspection of the trial design and scenario

yields the following treatment objectives:

• strictly supervised training based treatment to

reduce neck-shoulder pain: from the perspective

of educational science, the intended system has

to facilitate remote collection and processing of

training material, which are Root Mean Squares

(RMS) and Relative Rest Time (RRT) of

patient’s left and right shoulder’s s-EMGs and

the three feedback mode (Section 2). Learning

objective of this training is that the patient is

able to recognize symptoms of insufficient

muscle relaxation (see e.g. the last sentence in

the scenario). A therapist supervises the training

strictly, meaning that the therapist needs to

check training compliance regularly and at

arbitrary but convenient moments for the

therapist. This moreover ensures that measured

data collected in amounts and at quality needed

for data analysis.

• assessment of the ICT and the diary based

treatment: an objective which originates from

the trial design.

Actors are users of the intended system; each of

them has specific responsibility and represents an

identified stakeholder. Actors that can be identified

from the scenario, in particular the PACT elements,

are the patients and the therapists. A close inspection

of the trial design and the stakeholder analysis

additionally identifies two system administrator

actors. One of them represents the CoE trial

programme owners of the participating institutes and

has the responsibility to organize the trial and to

administrate logistic, privacy and security aspects

(as required by the METC of the CoE country). The

other represents the telemedicine system provider

stakeholder and has the responsibility to initialize

the setting of the intended system, e.g. to register the

CoE system administrators and to set-up the MyoTel

m-Health portal (Figure 1).

Table 1: Example of Actor, Task, Activity and Priority.

Actors Tasks, Activity & (Priority)

myofeedback

therapist

Supervised tele-treatment task:

tha_10 activity: password protected

myofeedback therapist; (need to

have);

tha_11 activity: list patient’s list and

selects a patient; (need to have);

…

tha_12 activity: view selected patient

data with the options to zoom in/out,

scroll (or provide start and end

date/time) to view, view the

differences between left and right

muscle activation and relaxation

patterns. Zoom values are e.g. ... ;

(need to have);

…

tha_23 activity: check the training

discipline of patients by checking the

data on the MyoTel portal any time (cf.

tha_11); (need to have);

Functional needs that have to be supported by the

intended system can be identified from the PACT

activities of identified actors. From these functions,

in turn, requirements can be derived. If the scenario

contains FICS elements, the interactions induce the

requirements more straightforwardly. Table 1

illustrates some of the elicited requirements for the

intended system.

From the elicited requirements, ICT services that

are able to support the teletreatment tasks, or

associated activities, can be identified and

dimensioned (cf. Van Helvert and Fowler (2003)),

for example, internet data transport services to bring

measured RMS or RRT data to the therapist for

analysis, web services to register patients or

therapists and role based login services to control

data access to ensure privacy and security of data.

4 OBSERVATION & DISCUSSION

Requirements elicitation in telemedicine is a

challenging research topic because to some extent it

has to be in alignment with the evidence based way

of working in medicine. An approach which

combines a holistic and a detailed in depth way of

SCENARIO-BASED REQUIREMENTS ELICITATION IN A PAIN-TELETREATMENT APPLICATION

411

requirements elicitation is needed. In this work, we

make use of a scenario and parts of the trial design

in combination with a task and goal analysis and

also a stakeholders’ analysis taken from a business

model perspective. This perspective has led us to the

sponsoring stakeholder, which imposes additional

constraints on the permitted software development

effort. This stakeholder would have been missed if

we had not considered the set of service provider,

technology provider, organisational including

regulatory and financial stakeholders. We also view

treatment training as an educational science

workform, which has a well defined structure in

respect of objectives, roles, tasks and input/output

resources in the planning, doing and evaluating

phases of training. For example, patient’s learning

goals and needed learning material can therefore be

made explicit. We consider this way of combining

methods and techniques fruitful and expect that it

also is typical for requirements elicitation in the

domain of (diagnostic-treatment) telemedicine.

Requirements elicitation in telemedicine

moreover requires an intensive collaboration

between trial designers and ICT developers, for

example to make topics of discussions explicit and

mutually understandable. Thereby, the ICT

developers need a good level of understanding of the

medical vocabulary. Mutual understanding can also

be improved by applying a handshake mechanism

(i.e. protocol) during information exchange between

trial designers and ICT developers in the iteration to

strive for a common universe of discourse. In the

discussed scenario based requirements elicitation

process, the trial designers took the lead in the

development of the scenario, which acts as the

common universe of discourse in the collaboration.

Thereafter, the ICT developers took the lead in the

requirements elicitation process which is based on

the developed and to some extent commonly

understood scenario. In this way, intentions or

objectives can be preserved better because the right

experts manage the development.

Despite our effort to address requirements

elicitation thoroughly in a multidisciplinary

collaboration, we observe a limitation. Lack of cross

disciplinary knowledge and homonyms of terms

have caused misinterpretations. In the developed

scenario, the terms “feedback on results” and

feedback on performance were not recognized by the

ICT developers during the requirements elicitation

process as specific concepts known in the area of

augmented feedback strategies. Feedback on

performance (also called Knowledge of Performance

(KP)) is in some cases better than feedback on

results (Knowledge of Results (KR)). Although the

developed system in this perspective happens to

work correctly, the ICT developers have not

identified a requirement which explicitly excludes

solutions that do not make sense, for example in

which the ICT support for tactile KR feedback is

more complex, therefore more sensitive to resource

failures, than the support for visual KP feedback.

5 CONCLUSIONS

This paper presents a scenario based approach to

elicit requirements in the domain of telemedicine

that is in alignment with the evidence based working

practices in medicine. Such an alignment is

considered one of the success factor conditions for a

usable medical system.

The scenario is developed in a multidisciplinary

collaboration between medical professionals and

ICT developers. Medical professionals take first the

lead in the scenario development to ensure

conformity to the treatment protocol and to preserve

treatment objectives when the actor-activity oriented

scenario is iterated and extended with actor-system

interactions. Then, the ICT developers take the lead

in the subsequent requirements elicitation process.

Besides scenarios, the elicitation approach makes

also use of the trial design, a stakeholder’s analysis

and a task and goal analysis to complement the

incompleteness of scenarios. The mix of methods

and techniques known in the area of requirements

engineering and trial design is considered the

contribution of this paper.

The discussed requirements elicitation addresses

the early phase of requirements engineering, later

phases are considered future work for which

scenarios as discussed in this paper have to be

refined to use cases to detail further the actor-system

interactions.

A challenging future research topic is to

investigate requirements engineering for more

complex treatment protocols which involve several

professional caregivers who jointly manage the

disease of patients, for example the treatment

management of Chronic Obstructive Pulmonary

Diseases (COPD).

ACKNOWLEDGEMENTS

This work has been sponsored by the EU under the

eTEN programme in project MyoTel – 046230.

ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies

412

REFERENCES

Benyon, D. and Macaulay, C., 2002. “Scenarios and the

HCI-SE design problem”, Interacting with Computers,

14, pp. 397-405;

Cysneiros, L.M., 2002. “Requirements Engineering in the

Health Care Domain”, in Proc. of the IEEE Joint Int.

Conf. on Requirements Engineering (RE’02);

Go, K. and Carroll, J.M., 2004. “The Blind Men and the

Elephant: Views of Scenario-Based System Design”,

Interactions, pp. 45 – 53;

Letier, E. and Lamsweerde, A. van, 2004. “Reasoning

about Partial Goal Satisfaction for Requirements and

Design Engineering”, SIGSOFT’04/FSE-12, Newport

Beach, CA, Oct. 31 – Nov. 6, 2004;

Meinert, C.L., 1986. “Clinical Trial: Design, Conduct and

Analysis”, Oxford University Press, New York;

Mylopoulos, J., Chung, L. and Yu, E., 1991. “From

Object-Oriented to Goal-Oriented Requirements

Analysis”, Communications of the ACM, 42, 1, Jan.

1991, pp. 31-37;

MyoTel, “MYOfeedback based TELetreatment Service”,

EU/eTEN programme - 046230,

http://www.myotel.eu, visited Jun. 2009;

Sackett, D.L., and Rosenberg, W.M.C., 1995. “The need

for evidence-based medicine”, Journal of the Royal

Society of Medicine, 88, pp. 620-624;

Van Helvert, J. and Fowler, C., 2003. “Scenario-based

User Needs Analysis”, Chimera Working Paper 2003-

02, Colchester, University of Essex;

Yu, E., 1997. “Towards Modelling and Reasoning Support

for Early-Phase Requirements Engineering”, in

Proceedings of the 3rd IEEE Int. Symp. on

Requirements Engineering (Washington D.C., USA,

Jan. 6-8, 1997), RE'97, pp. 226-235;

Wootton, R., Craig, J., Patterson, V., 2006. “Introduction

to Telemedicine”, the Royal Society of Medicine

Press.

SCENARIO-BASED REQUIREMENTS ELICITATION IN A PAIN-TELETREATMENT APPLICATION

413