Requirements engineering for a pervasive health ... - Semantic Scholar

Requirements Engineering for a Pervasive Health Care System Jens Bæk Jørgensen and Claus Bossen Centre for Pervasive Computing Department of Computer Science, University of Aarhus IT-parken, Aabogade 34, DK-8200 Aarhus N, Denmark E-mail: [email protected], [email protected]

Abstract This paper describes requirements engineering for a new pervasive health care system for hospitals in Denmark. The chosen requirements engineering approach composes iterative prototyping and explicit environment description in terms of workflow modelling. New work processes and their proposed computer support are represented via a combination of prose, formal models, and animation. The representation enables various stakeholders to make interactive investigations of requirements for the system in the context of the envisioned work processes. The paper describes lessons learned from collaboration between users and system developers in engineering the requirements for the new system.

1 Introduction Three years ago, the hospitals in Aarhus, Denmark, initiated the development of a new electronic patient record (EPR) [33]. EPR is a comprehensive health care IT system with a budget of approximately 15 million US dollars. The deployment began in the autumn 2002 and the system will eventually have 8-10,000 users. EPR solves obvious problems occurring with paper-based patient records, e.g., the latter are not always up-to-date, only present in one location at a time, and sometimes even lost. However, EPR, which is accessible only from desktop PCs in the version currently being deployed, also has its drawbacks and induces at least two central problems for its users. The first problem is immobility: In contrast to a paper-based record, an electronic patient record cannot be easily transported. The second problem is time-consuming login and navigation: EPR requires user identification and login to ensure information confidentiality and integrity, and to start using the system for clinical work, a logged-in user must navigate, e.g., to find a specific document for a given patient. The new pervasive health care system (PHCS) [6, 36] is meant to address these problems. PHCS is being envisioned

as an extension of EPR by Aarhus County Hospital, the software company Systematic Software Engineering A/S [38], and the Centre for Pervasive Computing [34] at the University of Aarhus. The basis for PHCS is to recognise firstly that users like nurses and doctors are away from their offices and on the move a lot of the time, and secondly that users are frequently interrupted [3]. In the ideal situation, the users should have access to the IT system wherever they need it, and it should be easy to resume a suspended work process. The aim of PHCS is to ensure smooth access to and use of EPR by supporting the emerging paradigm of pervasive computing (ubiquitous computing) [25]. This paper describes requirements engineering for PHCS. The main approach to requirements engineering for the version of EPR currently being deployed has been to apply use cases [8] as defined in the Unified Modeling Language (UML) [22]. Use cases for EPR were found and described in collaboration between users and system developers via a variety of requirements engineering techniques [18], e.g., observation of existing work processes, user interviews, workshops, and prototyping using cardboard mock-ups. One of the authors of this paper is a computer scientist who participated in requirements engineering for EPR, at that time working as a system developer at one of the software companies developing EPR. The other author is an anthropologist who studied the requirements engineering process while doing ethnographic field work at a department at Aarhus County Hospital. We have proposed to do requirements engineering for PHCS by augmenting the usual use case concept, our experiences with EPR being a main source of inspiration. The goals are firstly to narrow the gap between informal ideas about requirements and the formalisation that eventually and inevitably emerges when the system is implemented, and secondly to spur communication between users and system developers [9, 29]. Iterative prototyping [4], using prototypes in the form of running programs on a computer as a basis to get feedback from users to system developers, would be a feasible starting point to pursue these goals. However, it has been argued

Proceedings of the 11th IEEE International Requirements Engineering Conference 1090-705X/03 $17.00 © 2003 IEEE

for a long time, see, e.g., [16], that making an explicit description of the environment in which the system is to be used is important, and usually a prototype only provides an explicit representation of the system itself. We believe that for pervasive computing, whose main aim is to tightly integrate the system into the environment in terms of the work processes to be supported [31], the argument becomes even more important. Therefore, the requirements engineering approach for PHCS composes iterative prototyping and explicit environment description in terms of workflow modelling [27]. The approach is designated Executable Use Cases (EUCs), signalling the basis in the UML use cases with which the stakeholders of PHCS are already familiar. EUCs combine prose, formal models, and animation to represent new work processes and their proposed computer support. The representation enables various stakeholders to make interactive investigations of the requirements for the system in the context of the envisioned work processes. The paper is structured as follows: Section 2 introduces the EUC approach and Section 3 outlines basic design principles for PHCS. Sections 4 to 6 describe an EUC for the work process medicine administration, which is in focus in this paper. Section 7 discusses lessons learned from constructing and using the EUC. In Section 8, related work is discussed, and the conclusions are drawn in Section 9.

2 Requirements Engineering Approach: Executable Use Cases (EUCs) The requirements engineering approach for PHCS, Executable Use Cases (EUCs), is described in general terms in this section. As indicated by Figure 1, an EUC is structured in three tiers, which are proposed to be constructed and used in an iterative fashion.

Figure 1. EUC approach

EUCs share a number of characteristics with other approaches, see, e.g., [15, 28].

2.1 EUCs: Structure Tier 1, the prose tier, consists of prose descriptions of work processes and their proposed computer support, and is the basis for the first version of the two other tiers. The prose part of a UML use case (which in the use cases for EPR is the main part) may directly constitute tier 1. Tier 2, the formal tier, provides a formal, executable model of the work processes and their proposed computer support. There are different possible choices of modelling languages to be used at tier 2. It may be a suitable programming language or it may be a general, graphical modelling language such as statecharts [13], UML state machines or activity diagrams [22], a dialect of Petri nets [24] (which is used in requirements engineering for PHCS), or special workflow languages as defined, e.g., by the Workflow Management Coalition [39]. These languages differ in a number of ways. In particular, they have different degrees of formality and rigidity, but they all support modelling of states and modelling of actions, and have an execution semantics ensuring that it is relatively well-defined which actions are allowed to happen in any given state, and also well-defined which successor states will be reached if certain actions take place. Tier 3, the animation tier, is an animation interface to tier 2, which represents the work processes and their proposed computer support based on and consistent with tier 2, but using only concepts and terminology that are familiar to and understandable for the users.

2.2 EUCs: Construction and Use Tier 1 should be the result of domain analysis and collaboration between a broad selection of users, system developers, and possibly other stakeholders in the initial pursuit of engineering the requirements for a new system. The creation of tier 2 requires the effort of system developers who are trained in creating formal, executable models in the chosen modelling language. The formal modelling process is facilitated if one or more expert users with some flair for abstract thinking and logics are able to participate, but in general, tier 2 is not the domain of the average user. The creation of tier 3 requires joint efforts by users and system developers to design and implement a fitting animation. Each tier of an EUC is initially based on the tiers below, but an EUC should, as illustrated by Figure 1, be constructed and used in an iterative fashion. In this way, the insights gained through creation of and interaction with a tier can be consolidated in a new and improved version of the EUC.


EUCs are effective means in requirements engineering in conjunction with specification, validation, and elicitation. Specification has a sound foundation because of the formality and unambiguity tier 2. Validation is supported through execution. This is possible at tier 2, but can only be done properly by people who are able to read and understand the formal model. In practice, this often means only the system developers. However, tier 3 enables the users to be actively engaged in validation by investigating the consequences of the current specification, i.e., the new work processes and their proposed computer support, as realised at tier 2. Elicitation is, in the same way as validation, supported through execution. When the users interact with tier 3, they will often encounter questions, experience the EUC to behave in unexpected and maybe unsuited ways, or discover that relevant aspects have not been covered yet. In each such case, it is possible to revisit the formal model at tier 2, or even the prose descriptions at tier 1, in an attempt to find answers to the questions raised at tier 3, and, consequently remodel at tier 2, rewrite at tier 1, or both, to produce an improved version of the EUC.

2.3 EUCs: Properties Tiers 2 and 3 of an EUC augment a UML-style prose tier 1 use case. Tier 2, being a formal model, narrows the gap between informal ideas about requirements and the formalisation that is present in the implementation of the system. Tier 3, being a visualisation in familiar terms, supports communication between users and system developers, by reducing the semantic distance [10] between the formal model at tier 2 and the conception by the users of future work processes and their proposed computer support. The very construction of an EUC is important. The EUC approach insists on creation of three tiers, and it makes translation between the tiers explicit and visible. Creation of tier 1 forces domain analysis to be translated into informal, but explicit, descriptions of new work processes and their proposed computer support. Tier 1 is often highly based on the users’ understanding of their existing work processes [14], and, thus, tier 1 is to a large extent a description of the domain of the users. The creation of tier 2 forces the system developers to interpret, consolidate, and possibly expand the descriptions at tier 1. Tier 2 explicitly represents the system developers’ current interpretation of tier 1, i.e., both of the work processes and of their proposed computer support. This is an important addition compared to a usual prototype, which typically only explicitly represents the computer support and where some kind of role playing with human actors must be conducted to achieve a representation or simulation of the work processes. Because of the consistency between tiers 2 and 3, when the users interact with tier 3, they see the system developers’ interpre-

tation reflected, without having to care or even know about computer scientific concepts like states and actions. Thus, the creation of tier 1 spurs the users and the system developers to communicate to agree on a prose description. The creation of tier 2 spurs the system developers to communicate with the users, because a formal model requires that ambiguities at tier 1 are resolved, and possibly causes some lacks to be discovered that must be covered. Interaction with tier 3 spurs the users to communicate with the system developers when a question arises. In this way, an EUC is a means to detect misunderstandings and misconceptions by confronting the system developers with the users’ understanding of the new work processes and their proposed computer support, and vice versa.

3 The Pervasive Health Care (PHCS): Basic Design Principles

System

Use of personal digital assistants (PDAs) with which nurses and doctors could access EPR over a wireless network is a possible solution to the immobility problem mentioned in the introduction. That approach has been considered, but is not ideal, e.g., because of small PDA screens and because it does not fully address the time-consuming login and navigation problem. PHCS is a more ambitious solution which to a larger extent takes advantage of the possibilities of pervasive computing. Three basic design principles are exploited. The first principle is context-awareness [26]. This means that the system is able to register and react upon certain changes of context. More specifically, nurses, patients, beds, medicine trays, and other items are equipped with radio frequency identity (RFID) tags [37], enabling presence of such items to be detected automatically by involved context-aware computers, e.g., located by the medicine cabinet and by the patient beds. The second principle is that the system is propositional in the sense that it makes qualified propositions, or guesses. Context changes may result in automatic generation of buttons, which appear at the task-bar of computers. Users must explicitly accept a proposition by clicking a button — and implicitly ignore or reject it by not clicking. The presence of a nurse holding a medicine tray for patient P in front of the medicine cabinet is a context that triggers automatic generation of a button Medicine plan:P, because in many cases, the intention of the nurse is now to navigate to the medicine plan for P. If the nurse clicks the button, she is logged in and taken to P’s medicine plan. It is, of course, impossible always to guess the intention of a user from a given context, and without the propositional principle, automatic short-cutting could become a nuisance, because of guesses that would sometimes be wrong. The third principle is that the system is non-intrusive,


i.e., not interfering with or interrupting hospital work processes in an undesired way. Thus, when a nurse approaches a computer, it should react on her presence in such a way that a second nurse, who may currently be working on the computer, is not disturbed or interrupted. The last two principles cooperate to ensure satisfaction of a basic mandatory user requirement: Important hospital work processes have to be executed as conscious and active acts by responsible human personnel, not automatically by a computer. Figure 2 outlines PHCS (with an interface that is simplified and translated into English for the purpose of this paper). The current context of the system is that nurse Jane Brown is engaged in pouring medicine for patient Bob Jones for the giving to take place at 12 a.m. The medicine plan on the display shows which medicine have been prescribed (indicated by ‘Pr’), poured (‘Po’), and given (‘G’) at the current time. In this way, it can be seen that Advil and Tylenol have been poured for the 12 a.m. giving, but Comtrex not yet. Moreover, the medicine tray for another patient, Tom Smith, stands close to the computer, as can be seen from the task-bar buttons.

logged in and a list of those patients of which she is in charge is displayed on the computer. A medicine tray is associated with each patient. When N takes P’s tray nearby the computer, the button Medicine plan:P will appear on the task-bar, and a click will make P’s medicine plan appear on the display. N pours the prescribed medicine into the tray and acknowledges this in PHCS. When N leaves the medicine room, she is automatically logged out. N now takes P’s medicine tray and goes to the ward where P lies in a bed, which is supplied with a context-aware computer. When N approaches, the buttons Login:N, Patient list:N, and Medicine plan:P will appear on the task-bar. If the last button is clicked, the medicine plan for P is displayed. Finally, N gives the medicine tray to P and acknowledges this in PHCS. When N leaves the bed area, she is automatically logged out again. The description given above captures just one specific combination of sub work processes. There are numerous other scenarios to take into account, e.g., medicine may be poured for one or more patients, for only one round of giving, all four regular rounds of a 24 hours period, or for ad hoc giving; a nurse may have to fetch trays left at the wards prior to pouring; a nurse may approach the medicine cabinet without intending to pour medicine, but only to log into EPR or to check an already filled medicine tray; two or more nurses may do medicine administration at the same time. To support a smooth and seamless medicine administration work process, the requirements for PHCS must deal with all these scenarios and many more. Creating detailed prose descriptions of additional scenarios, and keeping track of dependencies and interrelations between various scenarios is difficult, cumbersome, and error-prone. With respect to these issues, a formal model, to be presented in the next section, is a more appropriate representation.

5 Medicine Administration EUC: Formal Tier Figure 2. PHCS: outline

4 Medicine Administration EUC: Prose Tier The work process in focus in this paper is medicine administration, as it is to be supported by PHCS. It involves medicine plans as the one shown in Figure 2. Medicine administration is described below in prose. Assume that nurse N wants to pour medicine into a medicine tray and give it to patient P. First, N goes to the room containing the medicine cabinet (the medicine room). Here is a context-aware computer on which the buttons Login:N and Patient list:N appear on the task-bar when N approaches. If the second button is clicked, N is

At the formal tier of the medicine administration EUC, the language of Coloured Petri Nets (CPN) [17] is used. CPN is a mature and well-proven modelling language suitable for describing the behaviour of large systems with characteristics like concurrency, resource sharing, and synchronisation. CPN is one dialect of the broader category of graphical modelling languages of Petri nets [24], which have a number of well-known relatives, e.g., statecharts [13] and UML state machines and activity diagrams [22]. A CPN model resembles a board game, with rules that define how the game is played. The CPN modeller’s task is to specify an appropriate board and playing pieces (tokens) to reflect the domain being modelled. In this section, a CPN model of the medicine administration work process is presented. At the same time, the sec-


tion is an informal primer to CPN, which allows the reader to understand the medicine administration CPN model in general terms. The primer does not account for all the technicalities of CPN; its purpose is only to provide an overall impression of the most basic concepts of the CPN language. For a more thorough introduction, please refer to [17]. The model is created and executed with the tool Design/CPN [35], which has a graphical part and includes the programming language Standard/ML [21]. A CPN model is structured as a set of modules that have well-defined relations. The medicine administration CPN model consists of 11 modules. An overview of the model in terms of a graph with a node for each module and arcs showing the relationship between the modules is given in Figure 3. Medicine administration

Provide trays

Pour/check trays

Pour/check tray

Find plan/ tray (cabinet)

Pour and acknowledge

Give medicine

Get trays

Give medicine to patients Find plan (bed)

Give and acknowledge

Figure 3. Medicine administration EUC: formal tier overview The graph shows how the work process medicine administration is decomposed in sub work processes — given an arc, the source node work process has the destination node as sub work process. As indicated by Figure 3, the CPN model is a coherent description of many ways to combine the involved sub work processes, i.e., of many different medicine administration scenarios. We will outline the CPN model by focusing on the selected module shown in Figure 4. The module models the pouring and checking of trays and corresponds to the node Pour/check trays in the overview of Figure 3. In the description, we will address the general characteristics discussed for the tier 2 modelling language in Section 2, i.e., describe how to model states and actions, and outline the execution semantics for CPN models. The state of a CPN model is a distribution of tokens on the places. Each place is drawn as an ellipse and has a data type (“colour”), written in italic capital letters, which determines the kinds of tokens the place is allowed to contain. In Figure 4, the nurses are modelled by tokens on the places Ready and By medicine cabinet, which both have data type NURSE. A token on Ready corresponds to a nurse being ready to carry out work, and a token on By medicine cabinet models a nurse who is in the medicine room, e.g., busy pouring medicine. The

Trays by medicine cabinet place is used to keep track of the medicine trays. The medicine cabinet computer is modelled by a token on the Medicine cabinet computer place. In the shown state, the nurses Jane Brown and Mary Green are ready and have no trays. The computer has a blank display and no task-bar buttons nor users, and there are no trays nearby. The actions of a CPN model are represented using transitions, drawn as rectangles. In Figure 4, the transitions correspond to the action of nurses. A transition and a place may be connected by an arc. The actions of a CPN model consist of transitions removing tokens from input places and adding tokens to output places, often referred to as the token game. The tokens removed and added are determined by expressions associated with the arcs, e.g., the expression (nurse,trays) on the arc from the Ready place to the Approach medicine cabinet transition specifies a NURSE token. The execution semantics for CPN models is defined by the concepts of enabling and occurrence. A transition which is ready to remove and add tokens is said to be enabled. The basic condition for enabling is that appropriate tokens are present on the input places. In Figure 4, enabling of the transition Approach medicine cabinet requires that the place Ready contains some NURSE token and the place Medicine cabinet computer some COMPUTER token. Thus, Approach medicine cabinet is enabled in the shown state, and none of the other transitions are. An enabled transition may occur. Occurrence of the Approach medicine cabinet transition models that a nurse changes from being ready to being busy nearby the medicine cabinet. Moreover, at the same time, two buttons are added to the task-bar of the medicine cabinet computer, namely one login button for the nurse and one patient list button for the nurse, as captured by the function addMedicineCabinetButtons used in the arc expression. The possible actions for a nurse who is by the medicine cabinet are modelled by the three transitions Pour/check tray, Enter EPR via login button, and Leave medicine cabinet. The pouring and checking of one single tray is modelled in detail on the sub module Pour/check tray (note the arc going from the node Pour/check trays to the node Pour/check tray in the overview graph of Figure 3). The Enter EPR via login button transition models that a nurse clicks on the login button and makes a general-purpose login to EPR. The Leave medicine cabinet transition models the effect of a nurse leaving: The corresponding token is put back on the Ready place, and the computer token is changed to reflect the new state of the medicine cabinet computer.


(nurse,trays) (compid,display,taskbar,users)

Approach medicine cabinet

(compid,display, addMedicineCabinetButtons nurse taskbar, users)

HS

(nurse,trays)

(JaneBrown,notrays) (MaryGreen,notrays) By medicine cabinet

Ready NURSE

NURSE

Pour/check tray

tray

Trays by medicine cabinet TRAY

(nurse,trays) (nurse,trays) (compid,display,taskbar,users) Enter EPR via login button

(nurse,trays)

[loginAllowed nurse (compid,display, taskbar,users)]

Medicine cabinet COMPUTER computer (compid,display, removeLoginButton nurse taskbar, addUser nurse users)

(1,blank, nobuttons, nousers)

(compid,display,taskbar,users) Leave medicine cabinet (nurse,trays)

if loggedin nurse (compid,display,taskbar,users) then (compid, blank, removeMedicineCabinetButtons nurse taskbar, removeUser nurse users) else (compid, display, removeMedicineCabinetButtons nurse taskbar, users)

Figure 4. Medicine administration EUC: formal tier module example

6 Medicine Administration EUC: Animation Tier The purpose of the animation tier is to provide an interface to the CPN model that is easy to understand for users like nurses and doctors. To be an interface demands that the animation tier must be consistent with the CPN model, i.e., the animation must show the states, actions, and state changes that appear when the CPN model is executed. This is technically straightforward to achieve: The link between the CPN model and the animation is that the transitions of the CPN model are calling drawing functions when they occur. Occurrence of a transition in this way triggers that graphical objects like nurse icons are created, moved, deleted, etc. in the animation. To be easily understandable demands that the visual symbols used in the animation should be familiar for the users and fitting for the purpose of the animation. This is non-trivial: Visualisations are neither self-evident nor neutral [23]. The animation tier of the medicine administration EUC is shown in Figure 5. Like the formal tier, the animation tier is created and executed with the Design/CPN tool, which includes a library for creating animations. The animation runs in three windows. The Department window shows the lay-out of a hospital department with wards, the medicine room, the so-called team room (the nurses’ office), and two bath rooms. The Medicine room window shows the medicine cabinet, pill boxes, tables, medicine trays, and the computer screen (enlarged). The Ward window shows a patient, a bed, a table, and the computer screen. Thus, the Department window gives an overview, and the other

windows zoom in on areas of interest. The animation is interactive in the sense that the animation user is prompted to make choices. In Figure 5, the animation shows a situation where nurse Jane Brown is in the medicine room, shown in the Department window and the Medicine room window, sufficiently close to produce two task-bar buttons at the computer. The animation user must make choices in order to drive the animation further. Specifically, by selecting one of the buttons to the right in the Medicine room window, the animation user can choose to take a tray or leave the medicine room. Also, the animation user can select one of the task-bar buttons at the computer. As examples, if the animation user pushes the Leave medicine cabinet button, it forces the transition with the same name in the tier 2 CPN model (cf. Figure 4) to occur. The result of the occurrence is experienced by the animation user who sees Jane Brown walking away from the medicine cabinet and the removal of the task-bar buttons on the computer screen, which were generated because of Jane Brown’s presence. If the animation user pushes the Take tray button and then selects Bob Jones’ medicine tray, it is moved close to the computer, and a medicine plan button for Bob Jones appears on the taskbar. If this button is pushed, the computer will display a screen like the one shown in Figure 2.

7 Medicine Administration EUC Construction and Use: Lessons Learned The PHCS project started in early 2001. The first activities were domain analysis in the form of ethnographic field


Department

Bath

Ward

Team room

Provide trays

Ward Pour/check trays Give medicine

Ward

Medicine room

Ward

Bath

Medicine room Patient list: Jane Brown

Take tray

Login: Jane Brown

Leave medicine cabinet

Bob Jones

Ward

Figure 5. Medicine administration EUC: animation tier work, and a series of vision workshops with participation of nurses, doctors, computer scientists, and the anthropologist author. An outcome of this analysis was natural language descriptions of work processes and their proposed computer support [7], directly applicable at the prose tier in an EUC. The EUC, as presented in this paper, is the end result of a number of iterations, each version based on feedback on the previous version. The EUC has been subject for discussions in evaluation workshops with participation of nurses from different departments in hospitals in Aarhus, personnel from the involved software company, and the authors. In this section, we present a number of lessons learned from constructing and using the medicine administration EUC.

modelling computers, e.g., the place Medicine cabinet computer shown in Figure 4, must be taken into account.

7.1 Environment Description Needed in Specification

The following are examples of requirements specified by the transitions on the module of Figure 4: (R1) When a nurse approaches the medicine cabinet, the medicine cabinet computer must add a login button and a patient list button for that nurse to the task-bar (transition Approach medicine cabinet). (R2) When a nurse leaves the medicine cabinet, if she is logged in, the medicine cabinet computer must blank off its display, remove the nurse’s login button and patient list button from the task-bar, and log her out (transition Leave medicine cabinet). (R3) When a nurse selects her login button, she must be added as a user of EPR, and the login button must be removed from the task-bar of the computer (transition Enter EPR via login button).

The EUC specifies a number of requirements for PHCS. From the tier 2 CPN model, requirements are precisely specified by the transitions modelling manipulation of the involved computers. Each transition connected to the places

(R3) could be well specified through a usual prototype. However, such a prototype would only explicitly capture the users’ interaction with the system itself, and to properly specify (R1) and (R2), which refer to actions in the environment, some description of the environment is needed.


As made clear from Figure 5, an EUC explicitly puts the requirements into context. A usual prototype only explicitly represents the computer screens shown in the Medicine room and Ward windows.

7.2 Explicit Environment Description Beneficial for Mutual Understanding The EUC’s explicit description of the environment in terms of a new work process on one hand allows users to make a preliminary validation of how fitting a proposed computer support is to a future work process (although the EUC of course is an abstraction that cannot replace later tests in real-world environments; in this case at hospitals). On the other hand, it enables system developers to better understand the work process to be supported. In this way, the explicit environment description is beneficial for the mutual understanding between users and system developers. A concrete misconception that was captured via the EUC is that the work process medicine administration is not as “regular” as the computer scientist author initially thought it should be. The relationship and dependencies between the sub work processes for medicine administration are not straightforward — Figure 3 is not a simple tree-structured graph, but a more complex structure, reflecting that the considered sub work processes are intertwined in everyday clinical work. These ways of working should not be constrained in an unacceptable way by PHCS. As a specific example (cf. Figure 3), it should be possible to interrupt giving of medicine, temporarily go to pouring of medicine, and eventually resume giving. Both giving and pouring involve the use of PHCS to find medicine plans and making acknowledgements, and the system should, e.g., not insist that all fields on a screen pertaining to giving must be filled, before it is possible to go to a screen pertaining to pouring.

7.3 Explicit Environment Description Beneficial for User Involvement Validation and elicitation have been carried out through execution of the EUC. The visual representation using familiar symbols as provided by the animation tier readily allowed nurses to participate in discussions. They could immediately focus on the relevant subject matter, the work process and its computer support, without being concerned with technical, to them irrelevant details concerning the chosen modelling language. The opportunity to investigate a new work process in a trial-and-error fashion was appreciated. In particular, the nurses said that the EUC’s explicit environment description in terms of a new work process made them think of a broad set of requirements issues. Some of the scores of questions and issues raised would also have emerged naturally through use of a usual proto-

type, but many others, as with specification, rely on the presence of an explicit description of the environment. Examples of such questions (Qs) and corresponding answers (As) reflected in the presented version of the EUC are: (Q1) What happens if two nurses both are close to the medicine cabinet computer? (A1) The computer generates login buttons and patient list buttons for both of them. (Q2) What happens when a nurse carrying a number of medicine trays approaches a bed computer? (A2) In addition to a login button and a patient list button for that nurse, only one medicine plan button is generated — a button for the patient associated with that bed. (Q3) Is it possible for one nurse to acknowledge pouring of medicine for a given patient while another nurse at the same time acknowledges giving of medicine for that same patient? (A3) No, that would require a more fine-grained concurrency control exercised over the patient records. Questions like Q1, Q2, and Q3 may imply changes to be made to the EUC, because emergence of a question indicates that the current version does not reflect the work process and its computer support properly. As a concrete example, in an early version of the EUC, the leaving of any nurse from the medicine cabinet resulted in the computer display being blanked off. To be compliant with the nonintrusive basic design principle for PHCS, the leaving of a nurse who is not logged in should of course not disturb another nurse who might be working at the computer, and the EUC had to be changed accordingly. A general comment to the EUC has been that if the animation had been more comprehensive, even more issues would probably have been raised, e.g., if the animation had included visualisation of the work of other kinds of hospital employees than nurses like a doctor carrying out prescription of medicine. Another major factor influencing the quantity of feedback is of course the number of users involved. The EUC approach supports massive user involvement: If interaction with the EUC via the Internet is made possible, thousands of future users have the opportunity to conveniently experiment with new work processes and their proposed computer support, and to provide feedback.

7.4 User Involvement in Formal Modelling Beneficial for Process If the formal tier of an EUC is created in a graphical modelling language, sometimes users can be found who are able to participate in the formal modelling. With respect to the EUC for medicine administration, nurses were involved by providing feedback, but did not participate directly in the creation of the formal tier. However, the anthropologist author, who may be seen as an expert user of PHCS, participated actively in the formal modelling. He is in general unfamiliar with computer scientific


concepts, but has an academic background and is used to abstract thinking and logics. The participation of an expert user was beneficial for the requirements engineering process. It made it possible to make the formal tier a proper description of the considered work process and its proposed computer support, before it was augmented with an animation tier, and subsequently made available to a broad selection of nurses. Thus, user participation at the formal tier eased communication with the system developers, and contributed to make it relatively fast to reach a proper EUC.

8 Related Work A main motivation for the choice of requirements engineering approach for PHCS was to build on top of UML use cases, with which the stakeholders of PHCS were already familiar via EPR. A key observation, done many times before, is that UML use cases have a number of weaknesses and shortcomings, and various remedies have been proposed, see, e.g., [1, 2]. In the EUC approach, focus is on augmenting use cases with notions of execution, formality, and animation. This is not a new idea, and other approaches and case studies are quite similar. As examples of partial instantiations of the three tiers in an EUC, requirements engineering for a light controller [5] fits well into tiers 1 and 2, and requirements analysis for a small communication channel example [20] yields an instance of tiers 2 and 3. At tier 2, [5] uses abstract state machines and [20] labelled transition systems. The choice of tier 2 language is non-trivial, and many aspects must be taken into account, e.g., available tool support and background of the involved system developers. Choosing CPN as tier 2 language has a number of virtues. CPN has a sound, mathematically well-founded execution semantics, is well-proven, and has proper tool support — including support for creating animations of CPN models, which has been used in a number of projects, see, e.g., [19]. Petri nets as a language to describe workflows has been studied intensively, see, e.g., [30], which concludes that Petri nets, and thus CPN, supports most of the constructs needed to properly model workflows. CPN scales well to modelling large systems, which is relevant when constructing EUCs for “dirty”, real-world systems as characterised in, e.g., [12]. CPN offers extensive support for modelling of states, which makes it adequate to describe pervasive, context-aware systems. However, even though we see a number of advantages of using CPN or some other similar Petri nets dialect at tier 2, other researchers and practitioners may well have other opinions and preferences, e.g., [11] advocates UML activity graphs over Petri nets for the modelling of workflows. The limitations of formal specifications as a means of communication in general, and, thus, the need for the EUC

tier 3, are widely recognised, see, e.g., [32].

9 Conclusions In [16], a number of basic tenets for making descriptions in software development, well applicable to requirements engineering, are recalled. One of the tenets can be phrased describe not only the system, describe also the environment. It is said in [16] that this is often neglected. For PHCS we adhered to the tenet: One of the main elements in the EUC requirements engineering approach is to make a description of the environment in which the system is to be used, in terms of a model of the work processes to be supported. When doing requirements engineering for pervasive systems, we believe that the tenet becomes inevitable. A fundamental technique to achieve the main goal of pervasive computing, tight integration of the system into the environment in terms of the work processes to be supported, is contextawareness as we saw it for PHCS. Making a computer react appropriately in a given context is a key to ensure the seamless nature of pervasive systems. With context-awareness, the environment/context itself provides, by sheer existence, input to the computer. Thus, omitting to make a description of the environment of a pervasive system would correspond to omitting to describe input events to a traditional system. Consequently, a comprehensive and precise descriptions of the environment should be made. In particular, the possible context changes affecting the system should be identified. Context changes are often caused by users moving from one location to another, entailing that making a description of the behaviour of users in the environment of the involved computers seems necessary. Therefore, we believe that construction of work process models as done in this paper for PHCS could become an important activity in general when doing requirements engineering for pervasive systems. However, to sustain that conjecture, more experience must be gained and more projects must be carried out. A particular aspect that needs to be addressed further to make the EUC approach attractive in a broader range of industrial projects is the cost-effectiveness: Are the man hours spent on tiers 2 and 3 justified by the benefits obtained? Specifically for the medicine administration EUC, tier 1 was expensive, while tiers 2 and 3 were cheap in comparison. Tier 1 involved a broad selection of stakeholders, resulting in consumption of relatively many man hours. The time consumption at tier 2 benefitted from, e.g., tier 1 being quite thorough before the first version of tier 2 was created, and from a user being able to participate in the formal modelling. The time consumption at tier 3 benefitted from the availability of skilled users, many already trained in communication with software developers through involvement in the EPR project. Other projects take place in different


settings and may have quite different characteristics, and therefore it cannot be assumed in general that tier 1 will be expensive while tiers 2 and 3 will be cheap. In general, we believe that the cost-effectiveness of construction and use of tiers 2 and 3 is comparable to the cost-effectiveness of usual iterative prototyping. In both cases, trade-offs must be made between, e.g., desired detail-level, degree of completeness, and the number of users to involve versus the required investment of time.

References [1] D. Amyot, R. Buhr, T. Gray, and L. Logrippo. Use Case Maps for the Capture and Validation of Distributed Systems Requirements. In RE’99, pages 44–53, Limerick, Ireland, 1999. IEEE. [2] A. Antón, R. Carter, A. Dagnino, J. Dempster, and D. Siege. Deriving Goals from a Use-Case Based Requirements Specification. Requirements Engineering Journal, 6:63–73, 2001. Springer-Verlag. [3] J. Bardram and C. Bossen. Moving to get aHead: Local Mobility and Collaborative Work. In 8th ECSCW, Helsinki, Finland, 2003. Kluwer Academic Publishers. [4] B. Boehm. A Spiral Model of Software Development and Enhancement. Software Engineering Notes, 4(11):22–32, 1986. ACM SIGSOFT. [5] E. Börger, E. Riccobene, and J. Schmid. Capturing Requirements by Abstract State Machines: The Light Control Case Study. Journal of Universal Computer Science, Springer Pub. Co, 6(7):597–620, 2000. [6] H. Christensen and J. Bardram. Supporting Human Activities – Exploring Activity-Centered Computing. In Ubicomp2002, volume 2498 of LNCS, pages 107–116, Gothenborg, Sweden, 2002. Springer-Verlag. [7] H. Christensen, J. Bardram, and S. Dittmer. Theme One: Administration and Documentation of Medicine. Report and Evaluation. TR-3. Technical report, Centre for Pervasive Computing, Aarhus, Denmark, 2001. [8] A. Cockburn. Writing Effective Use Cases. Addison-Wesley, 2000. [9] L. Constantine and L. Lockwood. Software for Use: A Practical Guide to the Models and Methods of Usage-Centered Design. ACM Press, 1999. [10] N. Dulac, T. Viguier, N. Leveson, and M.-A. Storey. On the Use of Visualization in Formal Requirements Specification. In RE’02, pages 71–80, Essen, Germany, 2002. IEEE. [11] R. Eshuis and R. Wieringa. Verification Support for Workflow Design with UML Activity Graphs. In 24th ICSE, pages 166–176, Orlando, Florida, 2002. ACM Press. [12] M. Feather, S. Fickas, A. Finkelstein, and A. van Lamsweerde. Requirements & Specification Exemplars. Automated Software Engineering, Kluwer Pubs., 4(4):419–438, 1997. [13] D. Harel. Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming, 8:231–274, 1987.

[14] P. Haumer, P. Heymans, M. Jarke, and K. Pohl. Bridging the Gap Between Past and Future in RE: A Scenario-Based Approach. In RE’99, pages 66–73, Limerick, Ireland, 1999. IEEE. [15] P. Heymans and E. Dubois. Scenario-Based Techniques for Supporting the Elaboration and the Validation of Formal Requirements. Requirements Engineering Journal, 3(3/4):202–218, 1998. [16] M. Jackson. Some Basic Tenets of Description. Software and Systems Modeling, 1(1):5–9, 2002. Springer-Verlag. [17] L. Kristensen, S. Christensen, and K. Jensen. The Practitioner’s Guide to Coloured Petri Nets. International Journal on Software Tools for Technology Transfer, 2(2):98–132, 1998. [18] S. Lauesen. Software Requirements — Styles and Techniques. Addison-Wesley, 2001. [19] L. Lorentsen, A.-P. Tuovinen, and J. Xu. Modelling of Features and Feature Interactions in Nokia Mobile Phones using Coloured Petri Nets. In 23rd PN, volume 2360 of LNCS, pages 294–313, Adelaide, Australia, 2002. Springer-Verlag. [20] J. Magee, N. Pryce, D. Giannakopoulou, and J. Kramer. Graphical Animation of Behaviour Models. In 22nd ICSE, pages 499–508, Limerick, Ireland, 2000. ACM Press. [21] R. Milner, M. Tofte, R. Harper, and D. MacQueen. The Definition of Standard ML. MIT Press, 1997. [22] OMG Unified Modeling Language Specification, Version 1.4. Object Management Group (OMG); UML Revision Taskforce, 2001. [23] R. Paton and I. Neilson, editors. Visual Representations and Interpretations. Springer-Verlag, 1999. [24] W. Reisig and G. Rozenberg, editors. Lectures on Petri Nets I: Basic Models, volume 1491 of LNCS. Springer-Verlag, 1998. [25] M. Satyanarayanan (Ed.). IEEE Pervasive Computing, 1(1), 2002. [26] M. Satyanarayanan. Challenges in Implementing a ContextAware System. IEEE Pervasive Computing, 1(3):2, 2002. [27] A. Sharp and P. McDermott. Workflow Modeling: Tools for Process Improvement and Application Development. Artech House, 2001. [28] J. Siddiqi, I. Morrey, C. Roast, and M. Ozcan. Towards Quality Requirements via Animated Formal Specifications. Annals of Software Engineering, 3:131–155, 1997. [29] A. Sutcliffe. User-Centred Requirements Engineering: Theory and Practice. Springer-Verlag, 2002. [30] W. van der Aalst and K. van Hee. Workflow Management: Models, Methods, and Systems. MIT Press, 2002. [31] M. Weiser. The Computer for the 21st Century. Scientific American, 265(3):94–104, 1991. [32] M. Zimmerman, K. Lundqvist, and N. Leveson. Investigating the Readability of State-Based Formal Requirements Specification Languages. In 24th ICSE, pages 33–43, Orlando, Florida, 2002. ACM Press. [33] Aarhus Amt Electronic Patient Record. www.epj.aaa.dk. [34] Centre for Pervasive Computing. www.pervasive.dk. [35] Design/CPN. www.daimi.au.dk/designCPN. [36] Pervasive Healthcare. www.healthcare.pervasive.dk. [37] Radio Frequency Identification. www.rfid.org. [38] Systematic Software Engineering A/S. www.systematic.dk. [39] Workflow Management Coalition. www.wfmc.org.
