software requirement specification - bfhstatic.sws.bfh.ch/download/mt-10-01-14-spec.pdf ·...

ICU Scandinavia www.icuscandinavia.com

T-213-01 / V 1 EMS_Software_Requirement_Specification-v1.0.doc of 24

Compare with the valid version before usage of prin ted documents!

Process: Software Requirement Specification

Project: Proof of Concept Study „Elderly Monitoring System“

for the uMove Framework

Number MT-10-01.14

Version: 1.0

Replace document: n/a (first edition)

Template: T-213-01 Software Requirement Specification

Number MT-10-01.14 Class MAS-IT 10-01 Student René Süssmilch,

[email protected], +41 (0) 79 475 85 72 Advisor Pascal Bruegger, PAI Group,

[email protected] +41 (0) 26 300 87 63 Expert Reto Koenig, Software Schule Schweiz, Wankdorffeldstrasse 102

Postfach 325, CH-3000 Bern 22, [email protected], +41 31 84 83 272 Keywords uMove, elder person, monitoring, KUI, kinetic user interface Release

Role Name Title Date / Signature

Author: Süssmilch René Student

Review: Bruegger Pascal Advisor

Release: Koenig Reto Expert

Software Requirement Specification Version 1.0

T-213-01 / V 1 EMS_Software_Requirement_Specification-v1.0.doc

of 24


1 Introduction .................................... ..................................................................................... 4 1.1 Purpose ................................................................................................................................... 4 1.2 Scope ...................................................................................................................................... 4 1.3 Terms & Abbreviations ............................................................................................................ 5 1.4 References .............................................................................................................................. 6 1.5 Requirements Coding .............................................................................................................. 6 1.6 Priority ..................................................................................................................................... 6

2 Overall Description ............................. ................................................................................ 6 2.1 Product Perspective ................................................................................................................ 7 2.2 Product Functions ................................................................................................................... 7 2.3 User Characteristics ................................................................................................................ 8 2.3.1 Elder people ......................................................................................................................... 8 2.3.2 Medical staff ......................................................................................................................... 8 2.3.3 System administrator ........................................................................................................... 8 2.4 Constraints .............................................................................................................................. 8 2.4.1 Regulatory Limitation ........................................................................................................... 8 2.4.2 Safety and Security Considerations ..................................................................................... 8 2.5 Assumptions and Dependencies ............................................................................................. 8 2.6 Apportioning of Requirements ................................................................................................. 8 2.7 System requirements .............................................................................................................. 9 2.7.1 System interfaces ................................................................................................................ 9 2.7.2 User interface ....................................................................................................................... 9 2.7.3 Hardware Interface............................................................................................................... 9 2.7.4 Software interface ................................................................................................................ 9 2.7.5 Communication interface ................................................................................................... 10 2.7.6 Storage limitation ............................................................................................................... 10 2.7.7 Location specific requirements ........................................................................................... 10

3 Specific Software Requirements for server based a pplication .................................... 11 3.1 General ................................................................................................................................. 11 3.1.1 Use Cases ......................................................................................................................... 12 3.2 Set up the system ................................................................................................................. 12 3.3 Check condition of elder person ............................................................................................ 13 3.4 Receive location .................................................................................................................... 14 3.5 Receive situation ................................................................................................................... 14 3.6 Appraise situation .................................................................................................................. 15 3.7 Alarm escalation .................................................................................................................... 15 3.8 Alarming medical staff ........................................................................................................... 16 3.9 Confirm alarm........................................................................................................................ 16

4 Specific Software Requirements for elder person m obile application ........................ 17 4.1 General ................................................................................................................................. 17 4.1.1 Use cases .......................................................................................................................... 18 4.2 Analyze of activity ................................................................................................................. 18



of 24


4.3 Check temperature ................................................................................................................ 18 4.4 Check location ....................................................................................................................... 19 4.5 Send context changes ........................................................................................................... 19 4.6 Alarming ................................................................................................................................ 19 4.7 Usage of the mobile app ....................................................................................................... 19

5 Mobile application for medical staff requirements ........................................................ 20 5.1 General ................................................................................................................................. 20 5.1.1 Use Cases ......................................................................................................................... 20 5.2 Alarming ................................................................................................................................ 20 5.3 Confirm alarm........................................................................................................................ 21 5.4 Change situation ................................................................................................................... 21 5.5 Check location ....................................................................................................................... 21 5.6 Send context changes ........................................................................................................... 22 5.7 Usage of the mobile app ....................................................................................................... 22

6 Documentation ................................... ............................................................................... 22

7 Document history ................................ ............................................................................. 22



of 24


1 Introduction

1.1 Purpose The EMS project focuses on an application which monitors elders or impaired people living alone or in a medical home. The goal is to allow medical staff to be alerted at any time when a monitored person needs special attention or is in a critical situation. The application will inform the contextually more appropriate person (nurses, doctors) about the situation of the patient.

There is a big potential in monitoring people who needs to be monitored. With this system thisthese people could retrieve should received back a bit of autonomy having with the assurance of being observed in case when they come to a dangerous situation. something starts to go wrong.

1.2 Scope The Elder Monitoring System (EMS) will be a proof of concept for the uMove Framework.

The main goal is to develop a system implementing the concept of Kinetic User Interface (KUI) and using uMove middleware.

KUI semantic model

KUI-based systems are intended to integrate the motions of users or objects in physical space where the motions which are recognizedrecognised and processed as meaningful events. The KUI model is a conceptual framework which can help in the design of pervasive systems including mobile applications or server-based systems integrating thea user’s locations, activities and other contexts such as spatio-temporal relations with other users.

uMove

uMove is Java API which implements the concept of KUI. It allows programmers to easily develop systems of observed entities (users, places, rooms, buildings). As shown in figure 1, the entities are objects created and managed in the e-space. There are attached to activity managers which process the data coming from the connected sensors. The entities are observed by the observer object which processes the situation of an entity each time a context changes. The applications are connected on top of the system and get the output of the observer. The advantage of this architecture is that a system is independently evolving (e.g. a medical home) and many specific applications can observe it and take actions when events are detected.

In this project, the entities will be the elders, the medical staff, the medical home with all rooms, the outside environment (e.g. the city).

There will be three parts to do:

server-based application It monitors the physical environment (city) and the building (medical home) and reports the state (motion, location, eventually physiological information) of the elders. It also locates and detects the activitiesy of the medical staff. The goals of the server application are:

Obs1

View1 View2

Activitymng

Relationmng

e-Spacee1

e12e11 e112

e111 e1122e1121

Obs2 Obs3

Senget1

sensor1

Senget3

sensor3

Senget2

sensor2

Motion-aware application

Sen

sor

laye

rE

ntity

laye

rO

bser

vatio

n la

yer

Situa-tionmng

Obs1

View1 View2

Activitymng

Relationmng

e-Spacee1

e12e11 e112

e111 e1122e1121

Obs2 Obs3

Senget1

sensor1

Senget3

sensor3

Senget2

sensor2

Motion-aware application

Sen

sor

laye

rE

ntity

laye

rO

bser

vatio

n la

yer

Situa-tionmng

Fig. 1 – uMove middleware



of 24


1. Tracking of the elders and storage of the current information and contexts.

2. Offer a graphical user interface to:

a. Manage the system (entities and sensors)

b. Monitor the system, using a map showing the location of the users.

3. Notify the medical staff only when an elder needs special attention.

Mobile application for elder people The elder’s mobile application has two main goals:

1. It processes the motion, location and the activity of the person. It detects locally if the person is doing something wrong or is missing something or is in a wrong place. For instance, if the person does something not allowed, he/she will receive a warning on theits mobile devicesmart phone. This application has to be really easy to handle without big technological knowledge of technique..

2. It transmits the elder’s situation to the server application in order to be processeds

Mobile application for medical staff The second application will be for the nursing staffes and provides information or alarm to the medical staff if an intervention is required.

The mobile application will communicate towith the server-based application and transmits the data from the enabled sensors (Bluetooth, gps, …). The communication between the two uMove entities is provided. In this project the focus is setwill be on the processing of the information and the feed back to the monitored person and medical staff.

The output of this project is an advanced prototype of academic use and marks an evaluation milestoneAs output of this project there will be an advanced prototype only. The output will be an evaluation of the uMove API (uMove, coordination, monitoring and mobile monitoring JARs), as it models and implements by implementing a concrete application within a real life context.

1.3 Terms & Abbreviations Term Explanation

uMove

Elder situation Indicates the behavior and location of the elder, can be - Normal - Dangerous - critical

Normal behavior slow movements just in one direction (accelerometer)

Strange behavior Fast movements in different directions (accelerometer) Abbreviation Explanation

KUI Kinetic User Interface

GUI Graphical User Interface

EMS Elder person monitoring system



of 24


API application programming interface

SBA Server based application

MAEP Mobile application for elder person

MAMS Mobile application for medical staff

BT Bluetooth

EP Elder person

MS Medical staff

RSSI Received Signal Strength Indication

1.4 References Ref 1 Project_tasks_-_EMS.doc

Ref 2 Benjamin Hadorn, Coordination Model for Pervasive Computing: A model to create and design applications using a pervasive middleware

Ref 3 Bruegger et al. - Enriching the Design and Prototyping Loop: A set of tools to support the creation of activity-based pervasive applications – journal article

1.5 Requirements Coding There are requirements described within this document. These requirements are listed in tables with a certain coding. The coding scheme is described as follow: SWRS-xxx-yy SWRS is referring to this document (Software Requirement Specification). xxx: is referring to a functional block according to the table below Coding of Requirements yy: is a consecutive number Every requirement is a must requirement. It is not allowed to delete or modify requirements. Requirements which are not applicable anymore have to be marked as N/A in a new line in the description field. It’s not allowed to reuse these numbers again to guarantee the traceability.

1.6 Priority Notation Description 1 Implementation of the Must point (must), basis functionality. 2 Wish point (should). 3 Proposition (can).

2 Overall Description This section of the SWRS describes the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements which are defined in detail in section 3 of this SWRS.



of 24




of 24


2.1 Product Perspective The following figure shows the scopes of the end product:

2.2 Product Functions This project is a proof of concept for the uMove framework which has been developed in a PhD project of the University of Fribourg.

The project covers these main features:

- uMove evaluation: checking the usability of uMove as a middleware, reporting problems and bugs, Proposition of improvement.

- Indoor user tracking:

o Location: based on Bluetooth technology.

o Activity: detection on simple activity pattern (acting normally, acting stressfully, no motion)

- Raising alarms:



of 24


o Sending alarms to the medical staff when critical user situation are detected. The situation are detected with a simple situation manager which triggers 3 types of messages:

� Normal situation

� Potentially dangerous

� Critical

o Proactively informing the monitored elder if something is detected to be wrong.

2.3 User Characteristics The system has to be used by personspeoples of threewo characteristics:

• elder people • medical staff • system administrator

2.3.1 Elder people The elder people have to carry a mobile device with android operating system, but they should almost not have to interact with this device. (Maybe except for , only for chargingloading the accumulator).

2.3.2 Medical staff Medical staff also has also to carry a mobile device with android operation system. The medical staff has to be able to interact more with the application:can interact more with the application for checking the situation of the elders and getting alarms.Changing their status, checking the position of the elder persons, and handling alarms.

2.3.3 System administrator The system administrator has to be able to set up the system, manage the rooms (i.e. that means, changing attributes of a room like Bluetooth ID, room description), manage monitored persons within the uMove (i.e. nurses and elders), set up the alarm distribution and allowed zones.

2.4 Constraints

2.4.1 Regulatory Limitation For this prototype there are no regulatory limitations.

2.4.2 Safety and Security Considerations There are no safety and security considerations needed because ofas this project states is only an advanced prototype and proof of concept for the uMove framework (at least in this phase of the project)

2.5 Assumptions and Dependencies Mobile Operation System Android v2.0 and higher

Server Operation System Windows XP

The uMove Framework v2 developed by Pascal Bruegger must be used for the applications. The communication between the two uMove entities must be provided by the University of Fribourg

2.6 Apportioning of Requirements



of 24


2.7 System requirements Req. ID Req. Types Requirement description Ref. Ref.Det.

SWRS-SYS-01

Functional The application must implement a KUI system

1

2.7.1 System interfaces Req. ID Req. Types Requirement description Ref. Ref.Det.

SWRS-SYS-02 Design Constraint

The System does not interact with other systems. There is only one server based application and one or more mobile applications for elder persons and one or more applications for medical staff

1

2.7.2 User interface

2.7.2.1 Server based application Req. ID Req. Types Requirement description Ref. Ref.Det.

SWRS-SYS-03 Functional The user has the following Interfaces for interacting with the server based EMS application:

- Screen - Keyboard - Mouse

1

2.7.2.2 Mobile application Req. ID Req. Types Requirement description Ref. Ref.Det.

SWRS-SYS-04 Functional The user has the following Interfaces for interacting with the mobile EMS application:

- Touchscreen

1

2.7.3 Hardware Interface Req. ID Req. Types Requirement description Ref. Ref.Det.


The PAI Group of the University of Fribourg must allocate at least one mobile device with Android Operation system

1

2.7.4 Software interface Req. ID Req. Types Requirement descr iption Ref. Ref.Det.


The application must use the uMove library 1

The PAI Group of the University of Freibourg must allocate a running version of uMove v2 and Coordination allowing the communication between server-based and mobile application including documentation and training as soon as possible



of 24


2.7.5 Communication interface The communication between the uMoves entities must be provided by Cthe client so there is no need to specify the communication interface here.

2.7.6 Storage limitation There is no storage limitation for this project

2.7.7 Location specific requirements There are no location specific requirements for this project



of 24


3 Specific Software Requirements for server based a pplication

3.1 General

Entity Tracker

Observer

Viewer

world

building

floor

room

Message

Processor

Situation

manager

GUI

EMS Application

uMove

entity

entityentity

entityentity

entityentity

Figure 1: Overview of the server based application

For the server based application there will be two major parts to be done:

- Setting up the system with uMove library (actor, zones, viewers, situation manager) - Programming the EMS Application (Entity tracker, GUI)

Req. ID Req. Types Requirement description Ref. Priority

SWRS-GEN-01 Functional The application must be as modular as possible in order to be able to change modules without having to rewrite all the codechanging the all codes.

1 1

SWRS-GEN-02 Functional The applications must be clearly implemented and documented/commented in order to be extended and reused in other projects

1 1



of 24


3.1.1 Use Cases

Figure 1: Use cases of the server based application

3.2 Set up the system uMove is designed to findautonomously discover itself new mobile devices with uMove running on it. So, any person carrying a uMove enabled device (elders or and also medical staff) will be founddiscovered and managed automatically by the uMove framework when they will enter the building. In the setup the system administrator is able to modify system attributes. Req. ID Req. Types Requirement description Ref. Priority

SWRS-SUP-01 Functional It must be possible to define different safe locations for every elder person in the system depending on time and date

1 1

SWRS-SUP-02 Functional It must be possible to modify safe locations (position, time, date) for every elder person in the system

1 1



of 24



SWRS-SUP-03 Functional It must be possible to define persons of trust for every elder person

1 1

SWRS-SUP-04 Functional It must be possible to modify persons of trust for every elder person

1 1

SWRS-SUP-05 Functional It must be possible to assign a specified Bluetooth ID to a room

1 1

SWRS-SUP-06 Functional It must be possible to modify the assigned Bluetooth ID to a room

1 1

3.3 Check condition of elder person The SBA must allow the medical staff to check the actual condition of the elder person via the GUI. It should be possible to change the current view from tree view to floor plan view.

Figure 2: Tree view For this advanced prototype the floor plan view will just be static. The prototype has to be able to manage and present multiple floors.but there has to be more than one floor shown in different tabs. As Because of there will be just an indoor location tracking only, the position will be determined by the floor- and room numberjust be floor number and room number.. Req. ID Req. Types Requirement descript ion Ref. Priority

SWRS-CHC-01 Functional It must be possible for medical staff to find the actual location of a defined elder person Position:

- Floor Nobr. - Room Nobr.

1 1

SWRS-CHC-02 Functional In the floor plan view there must be a tab for every floor

1 1

SWRS-CHC-03 Functional In the floor plan view the elder person must be defined as a point in the room including the name Name:

- First name - Last name

1 1



of 24


Req. ID Req. Types Requirement descript ion Ref. Priority

SWRS-CHC-04 Functional In the tree view every floor has to be its own tree like shown in Figure 2: Tree viewFigure 2: Tree view

1 1

SWRS-CHC-05 Functional In the tree view elder person must be defined as an entry containing the name. Name:

- First name - Last name

1 1

SWRS-CHC-06 Functional On clicking on the elder person in the GUI the medical staff must get information about the elder person: Information:

- Actual location - Actual activity - Actual context (temperature) - Actual situation (normal, dangerous,

critical)

1 1

3.4 Receive location The SBA will receive from the mobile applications the actual Bluetooth ID of the room where the sender is. The SBA has to know which BT-ID refers to which room and sends the room ID to the uMove Framework. The receiving of the data is a task of uMove and not one of this advanced prototype. Req. ID Req. Types Requirement description Ref. Priority

SWRS-REL-01 Functional The SBA must translate the received Bluetooth-ID into a room number

1 1

3.5 Receive situation The SBA will receive from the EP mobile application the actual activity and context. The SBA will also receive from the MS mobile application the actual activity of the nurses. The receiving of the data is a task of uMove and not one of this advanced prototype. Received data from EP mobile app:

- Actual activity o Falling down o Strange behavior o Normal behavior o Not moving

- Context o Temperature o Location

Received data from MS mobile app:

- Actual activity o Making bed o With elder

Feldfunktion



of 24


o Eating o Out

3.6 Appraise situation The SBA has to appraise the situation of the elder person by interpreting the received current activity and the contexts. There will be tree different states for the situation:

- Normal - Dangerous - Critical

Situation Situation Activity: normal behavior and temperature between 36°C – 38°C Normal Temperature: below 36°C or above 38°C dangerous Activity: falling down and after 1 minute still not moving critical Activity: falling down after 1 minute strange behavior critical Activity: falling down after 1 minute normal behavior dangerous Activity: strange behavior dangerous Location: outside safe area dangerous Table 1: Situation of certain situations Req. ID Req. Types Requirement description Ref. Priority

SWRS-APS-01 Functional The SBA must decide in which situation - Normal - Dangerous - critical

the elder person is according the Table 1: Situation of certain situationsTable 1: Situation of certain situations

1 1

3.7 Alarm escalation If the SBA appraises the situation as dangerous or critical the SBA must alarm the person of trust. As priority 1 there will be just a simple alarm escalation. If the elder person is in a dangerous or critical situation, the next person of trust with an interruptible situation will get a message on histhe mobile device. As lower priority a more complex alarm escalation will be implemented.there will be a more complex alarm escalation. Req. ID Req. Types Requirement description Ref. Priority

SWRS-ALE-01 Functional If an elder person is in a dangerous or critical situation the SBA must alarm the nearest person of trust with an interrupt able situation.

1 1

SWRS-ALE-02 Functional If an elder person is in a dangerous situation the SBA should warn all persons of trust with an interruptible situation on the same floor.

1 2

Feldfunktion



of 24



SWRS-ALE-03 Functional If an elder person is in a critical situation the SBA should alarm the nearest person of trust with an interruptible situation.

1 2

SWRS-ALE-04 Functional If the person of trust doesn’t confirm the alarm message within 1 minute the SBA can alarm any nearest person of trust.

1 3

SWRS-ALE-05 Functional If the person of trust doesn’t confirm the alarm message within 1 minute the SBA can alarm any nearest person of trust.

1 3

SWRS-ALE-05 Functional The alarming time interval between alarming again can be settable by the system administrator.

1 3

3.8 Alarming medical staff After appraising the situation and checking which medical staff is the nearest, this person of trust must be alarmed. uMove will send automatically send a message to the MS mobile application of the defined person of trust. Req. ID Req. Types Requirement description Ref. Priority

SWRS-ANS-01 Functional The SBA must pop up a window on the screen with an alarm message.

1 1

SWRS-ANS-01 Functional The SBA must send a message with the alarm to the mobile device of the person defined for the chosen escalation scenario.the from alarm escalation defined person of trust mobile device.

1 1

SWRS-ANS-01 Functional In the alarm message there must be included the

- Actual location - Actual activity - Actual context (temperature) - Actual situation (normal, dangerous,

critical) of the elder person which is in a critical or dangerous situation

1 1

3.9 Confirm alarm If the person of trust accepts the alarm and is going to act accordingly, will have a look on the elder person in a dangerous or critical situation, the personhe or she should be able to confirm the alarm message. The confirming is also important for the alarm escalation. Req. ID Req. Types Requirement description Ref. Priority

SWRS-COA-01 Functional The medical staff iscan be able to confirm the alarm via their mobile device

1 3



of 24


4 Specific Software Requirements for elder person m obile application

4.1 General

Observer

Viewer

root

Message

processor

Situation

manager

EMS Application

uMove

accelerometer

Message

processor

Activity

manager

Temp sensorBluetooth interface

entity

entity

senget senget senget

actor

Figure 3: Overview of the elder person mobile appli cation

In this advanced prototype there will be no priority of power management. Req. ID Req. Types Requirement description Ref. Priority

SWRS-GEN-01 Functional The application must be as modular as possible in order to be able to change modules without changing the all codes.having to rewrite all the code

1 1


1 1



of 24


4.1.1 Use cases

Figure 4: Use cases of the elder person mobile appl ication

4.2 Analyze of activity Using the data from the accelerometer the MAEP must evaluate the activity of the elder person. There are just 3 different activities to detect in this advanced prototype:

- Normal behavior - Strange behavior - Fall down


SWRS-ANA-01 Functional The MAEP must be able to read out the accelerometer of the mobile device

1 1

SWRS-ANA-01 Functional The MAEP must be able to interpret the data from the accelerometer and decide it the elder person

- Has a normal behavior - Has a strange behavior - Falls down

1 1

4.3 Check temperature The MAEP has to read out the internal temperature sensor from the mobile device. With this temperature the SBA will analyze the condition of the elder person. The mobile device must be directly connected to the body of the elder person, so the temperature should be about 37°C.



of 24



SWRS-CHT-01 Functional The MAEP must be able to read out the temperature sensor of the mobile device

1 1

4.4 Check location Using the Bluetooth ID the SBA will evaluate the location of the elder person. Every room will get a Bluetooth device with its fix own Bluetooth ID so there will be no problem to allocate the ID to the room number. If there are different location indicators available the MAEP has to choose the right one by measuring and interpreting the Bluetooth RSSI. Req. ID Req. Types Requirement description Ref. Priority

SWRS-CHL-01 Functional The MAEP must be able to receive the Bluetooth IDs of “location indicators”

1 1

SWRS-CHL-02 Functional The MAEP must be able to measure the RSSI of the Bluetooth “location indicators”

1 1

SWRS-CHL-03 Functional The MAEP has to choose the” location indicator” with the strongest RSSI with its ID saved in the SBA database.

1 1

4.5 Send context changes Every context change must be sent to the SBA. uMove Framework will do this, so this is not part of this advanced prototype.

4.6 Alarming The MAEP should alarm the elder person if he/she does something wrong or stands outside authorized location. Req. ID Req. Types Requirement description Ref. Priority

SWRS-ALA-01 Functional The MAEP can alarm the elder person with a sound when he/she is in a dangerous or critical situation

1 3

4.7 Usage of the mobile app The usage of the MAEP must be as easy as possible. It is considered as ideal if The best thing would be, when the only interactions with the mobile device of the elder person would be the just has to start up initial start up and the battery-charging. the mobile device and to charge the battery. uMove will login itself as soon as it detects a smart environment (uMove running on server). Req. ID Req. Types Requirement description Ref. Priority

SWRS-USA-01 Functional The MAEP should start up automatically when the mobile device starts up.

1 2



of 24


5 Mobile application for medical staff requirements

5.1 General In this advanced prototype there will be no priority of power management. Req. ID Req. Types Requirement description Ref. Priority

SWRS-GEN-01 Functional The application must be as modular as possible in order to be able to change modules without changing the all codes.without having to rewrite all the code

1 1


1 1

5.1.1 Use Cases

Figure 5: Use cases of the medical staff mobile app lication

5.2 Alarming The MAMS should alarm the medical staff if an elder person does something wrong or stands outside authorized location. Req. ID Req. Types Requirement description Ref. Priority

SWRS-ALM-01 Functional The MAMS must alarm medical staff by earconwith a sound (Beep) when an elder person is in a dangerous situation

1 1



of 24



SWRS- ALM -02 Functional The MAMS must alarm medical staff with a continuous earconsound (e.g. Beeps) when an elder person is in a critical situation

1 1

SWRS- ALM -03 Functional The MAMS must show the from SBA received information about the elder person

- Location (floor and room number) - Situation - activity

in the screen

1 1

5.3 Confirm alarm If the person of trust intents to act accordingly to the received alarmwill have a look on the elder person in a dangerous or critical situation, the person of trushe or she should be able to confirm that he/she takes care of the situationalarm message. The confirming is also important for the alarm escalation. Req. ID Req. Types Requirement description Ref. Priority

SWRS-CAM-01 Functional The medical staff can be able to confirm the alarm through the mobile app by pressing a confirm button on the touchscreen.

1 3

5.4 Change situation The medical staff can change the actual his activity statussituation. Thise activity statussituation will indicate the SBA if this person will be available for alarm or not. Req. ID Req. Types Requirement description Ref. Priority

SWRS-CSM-01 Functional The medical staff must be able to change the activity statushis situation. Following situationstati will be defined:

- Making bed - With elder person - resting - away

1 1

SWRS-CSM-02 Functional The situationstatus of medical staff can change according to the appointments in the mobile device’s calendar

1 3

5.5 Check location Using the Bluetooth ID the SBA will evaluate the location of the elder person. Every room will get a Bluetooth device with its fix own Bluetooth ID so there will be no problem to allocate the ID to the room number. If there are different location indicators available the MAMS has to choose the right one by measuring and interpreting the Bluetooth RSSI. Req. ID Req. Types Requirement description Ref. Priority

SWRS-CLM-01 Functional The MAMS must be able to receive the Bluetooth IDs of “location indicators”

1 1



of 24



SWRS-CLM-02 Functional The MAMS must be able to measure the RSSI of the Bluetooth “location indicators”

1 1

SWRS-CLM-03 Functional The MAMS has to choose the” location indicator” with the strongest RSSI with its ID saved in the SBA database.

1 1

5.6 Send context changes Every context change must be sent to the SBA. uMove Framework will do this, so this is not part of this advanced prototype.

5.7 Usage of the mobile app The usage of the MAMS must be as easy as possible. The best thing would be, when the elder person just has to start up the mobile device and to charge the batteryThe usage of the MAMS must be as easy as possible. It is considered as ideal if the only interactions with the mobile device of the elder person would be the initial start up and the battery-charging. . uMove will login itself as soon as it detects a smart environment (uMove running on server). Req. ID Req. Types Requirement description Ref. Priority

SWRS-USA-01 Functional The MAEP should start up automatically when the mobile device starts up.

1 2

6 Documentation Req. ID Req. Types Requirement description Ref. Priority

SWRS-DOC-01 Design Constraint

A Design Description must be written for this project All applications must be described using UML and clear diagrams.

1 1

SWRS-DOC-02 Design Constraint

An evaluation of the uMove API (umove, coordination, monitoring and mobile monitoring JARs) must be written containing the following points:

- Usability of uMove (programming point of view)

- Problems and bugs encountered - Proposition of improvement.

1 1

7 Document history Version Date Creator Description of modification

0.1 17.04.2010 René Süssmilch Newly created

0.2 26.04.2010 René Süssmilch Adjusted after review with P. Bruegger

0.3 28.04.2010 René Süssmilch Adjusted after review with P. Bruegger and M. Adam



of 24


1.0 29.04.2010 René Süssmilch

software requirement specification - bfhstatic.sws.bfh.ch/download/mt-10-01-14-spec.pdf ·...

Documents