Software Requirements Specification (SRS)

fullfattruckΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

81 εμφανίσεις

Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)

Software Requirements Specification (SRS)

Project PMR
-
Droid


Authors:
Joe Heldt, Jong Jang, Michael Keesey, Tom Randall, Kurt Seippel

Customer:
Dr. Betty Cheng

Instructor:
Dr. Betty Cheng


1


Introduction


This Software Requirements Specification document provides an over
view of the
functionality of a

Personal Medical Record (PMR)

designed for the
Motorola D
roid
phone.

This document

will cover the scope, organization, description, constraints,
requir
ements, and the prototype of the

PMR.

1.1

Purpose


The purpose of this document is to describe the functio
nality and specifications of
th
e design of a PMR for the D
roid.

The expected audience of this document is the
faculty

and students

of CSE 435, the developers
,

and other possible user
s

of the
application.

1.2

Scope

The

scope of the PMR is that it will be designed to run on the Droid
. The
user
will be able to store, access and c
omment on their medical records

from their
D
roid
phone. This information will be stored on a central database where doctors will be
able to upload the
ir

most recent medical records. The appli
cation will then be abl
e to
upload

this data
from

the server whenever it needs to be updated.

1.3

Definitions, acronyms, and abbreviations



EMR (Electronic Medical Reco
rd)
-

An electronic copy of the patients’

medical record. All information is provided by your doctor.



PMR (Personal

Medical Record)
-

A copy of the

patient’s EMR stored,
accessed and possibly edited by the patient.



Android
-

The operating system, developed by Google, made to be ran on
cellular phones.

Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)



Droid
-

A smart phone, currently being distributed by Verizon
Wireless,

that
runs the latest version of the Android operating system on it.



GUI

(Graphical User Interface)

-

The part of the application that the user sees
and interacts with.



PC

(Personal Computer)

-

A desktop or laptop running the
Microsoft
windows
operating system.



IP

Address
-

A unique number given to every computer on a network to
differentiate it from other computers.

1.4

Organization


The remaining portions of this document are

broken
down into four

major
sections, followed by references and a po
int
of contact. The first

section will provide
an overall description of the project. The next part will give more detailed
requirements.
Following the requirements, there are

models describing
the
application

and the description/use of the prototype.

2


Over
all Description




This section will provide a high level description of
the

entire application. It will
describe the product perspective, functionality, the characteristics
of an expected user
,
constraints, assumptions and dependencies, and the
ap
portio
ning

of requirements.


2.1

Product Perspective




This product is to
be used specifically for the D
roid phone. This
means there
needs to be

a database with all the EMR’s that
the application

can access. The
interface will be made to
allow consistency
with ot
her Android applications to make
it easier for the user to navigate through.


The PMR system is a part in a larger system that includes EMRs and databases. In
an ideal system, all of the smaller systems would cooperate.


Some constraints include lack of me
mory in the phone, lack of screen size to have
all information shown at once, and lack of wifi or 3G connections.








EMR

Database

PMR

Figure
2.1

Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)

2.2

Product Functions



P
rovides a high
-
level view of the key types of medical
information
.



P
rovides a means to easily navigate to the details of any of the major categories
.



P
rovides access to different typ
es of media for medical records

including:

o

Text
-
based documents

o

Images (CT
-
scans, X
-
rays)

o

Scanned documents

o

Photographs



The user

is
able to
backup

and later

edit

a local copy of the user’s

PMR

on

your
personal computer
.

2.3

User Characteristics






The user should

know how to use the basic functionality of the phone. The user
should be familiar with
navigation and the input of data. There are no other
assumptions since this product can be used by anyone who wants access to their own
medical record.

2.4

Constraints






A user

cannot store large
amounts of data in the phone. The user will have to
access t
he data

directly from the server
.
This software is only for D
roid.

The user
will not be able to run this application on any other platform of the Android
Operating System.


2.5

Assumptions and Dependencies




All hardware specifications will be known

since th
e application

will only

be used
on the D
roid phone
. User interactions with
the application

will come in two forms:

touch screen to navigate, and the keyboard to enter comments under specified
sections.


2.6

App
ortioning of Requirements




One of the things

th
e customer would like implemented in the future is to have a
GUI on a PC that the customer would be able to input information and be able to
upload it on the Droid.


The company providing the PMR would also have a reliable server to hold all of
the data that the Droid phones
would be able to upload
.

Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)


The customer would prefer that there be a biometric access for full functionality
of the Droid device.


3


Specific Requir
ements




Provide a high
-
level view of the key types of medical information
-

We will have a
“front page” where just very basic medical data will be displayed. This
information can be customized by the user as to what will
,

and won’t
,

be
displayed. This pag
e is designed to be us
ed in case of an emergency. If

doctors
would need to quickly
obtain

certain important m
edical data, like blood type or
allergies to certain medications,

they could look at this ma
in page without having
to log in
. For security reason
s

the user can hide
whatever

informati
on they don’t

want someone who to see

on this front page
.




Provide a means to easily navig
ate to the details of any

major categories
-

there is

a tabbed user interface where the major topics will be selectable. Once

a
category is selected, the screen will be refreshed to

a separate page where all
the relevant information will be displayed in an organized fashion.




Provide access to different types of media for medical records, including:

o

Text
-
based documents

o

Images (
CT
-
scans, X
-
rays)

o

Scanned documents

o

Photographs




For each medical procedure, diagnosis, medication prescribed, there
will

be the
following information associated:

o

A healthcare worker complete contact information

o

Date of event

o

Rationale for treatment/medica
tion/diagnosis

o

Follow
-
up activities

o

As appropriate, any research
-
based trials/clinical studies that might be
available

o

As appropriate, any short
-
term or long
-
term side effects

o

As appropriate, any relationship to family history (ancestors and/or
descendant
s).


This information is standard for any information provided by the doctor.
There is sometime more information needed depending on the kind or
medical information being provided, so where necessary there are more
fields to input additional data.




A
means for a patient to record information (e.g., symptoms, context, photographs
of condition
)
-

Sometimes the user will

want to add/edit the information in
the
application
. This is possible for any of the information stored on
the

phone or
Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)

computer. Onc
e

the user

edit
s

something
,

it is flag
ged as “Changed by User” so
the user’s doctor knows that this is no
t information provided by a doctor but by
the patient. These changes
will be synced with the data on the database so
whenever the user

download
s

the la
test version of

the data, the user

will also get
the information that has been changed
.




Be able to backup information
onto
computer
-

At any point the user can connect
the D
roid

phone to a computer, or use the

computer application to download
the
data from

the user’s application
. Once on the computer it provides a safe backup
in
the event that

something happens

to your phone. The PMR on the

phone can
also be updated to the latest version that is

either on the server or on the

Droid.

If
at any point the P
MR on the

D
roid becomes corrupt or lost the user can download
the file on the
i
r

c
omputer and save it back to the

phone.




Security
-

Some

information
is more private than the user
’s personal medical

history. With this in mind, the

system seeks to maintain a
high level of
security
.
The

security measures are separated into two domains: database/server security,
and user authentication.


Database/Server
:



The

data is separated into two groups, according to the sensitivity

of the
data. These groups are
stored on
separate servers, with a firewall in
between them, as well as a firewall protecting the system as a whole. This
multi
-
la
yer firewall approach allows the

most sensitive data, such as test
results and usernames and passwords, to be protected by multiple
fire
walls.






















Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)



























Direct access to
the

databases

will be restricted by IP to the

developers
only. No one els
e will have direct access to the

data.



Commercial anti
-
virus software will be employed on all
servers.



Administrator and developer passwords must be changed every 14 days.



Developers will also use CryptoCard authentication tokens for one
-
use
randomly generated passwords.


User Authentication:



Users, defined as both patients and care providers, will

need to use
username and password authentication to gain access to their data.



User pass
words will require

one or more uppercase letters, one or more
lowercase letters, one or more numerical values, and one or more special
characters (‘@’, ‘$’, ‘%’, etc.)
. No dictionary words will be allowed.



If no activity within the application is registered for a period of ten
minutes, the user will be logged out automatically.


4


Modeling Requirements




To start use of the PMR,
a

doctor

registers the patient and adds t
he patient's
record to his/her

database of patient medical records and the PMR backup
-
server.


A
medical record consists of basic personal information (e.g. name, social security
Fi
gure 3.1

Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)

number, gender, blood type), insurance infor
mation, family history, emergency
contacts and zero or more medical record entries.


A medical record entry consists of
labeled data (e.g. information on medications, vaccinations, test results) and when
applicable links to images (e.g. x
-
rays, CT scans or

hospital record scans)

(Figure
4.1)
.


All non
-
text based data and large files are kept on a server, and links to them
are stored on the Droid device, while all text
-
based data will be stored both on the
server and the Droid.




Both physicians and pat
ients can add or edit entries

(Figure 4.2)
, though any
entry edited by the patient will be flagged as such and will take precedence behind
any physician
-
edited entries.


When editing entries, images can be uploaded to the
server, and a link to the image wi
ll be stored in the applicable entry on the Droid

(Figure 4.3)
.


When displaying an entry, the user can choose

to

download a linked
image from the server

(Figure 4.4)
.


The image could be copied, e
-
mailed or saved
onto disk.


The image will remain in the
Droid's memory until the patient logs off the
PMR.


When the doctor edits or adds entries, he/she can sync the new information to the
server.


When syncing, anything the doctor has written will take higher priority than
the patient
-
edited files. The p
atient information on the Droid would be updated when
displaying the entry if the device is connected to the network.


The patient can also
backup the record by connecting the Droid to a laptop or desktop computer

(Figure
4.5)
.


The record will copy to a
folder (or make one) as an xml document and will
overwrite the previous copy.


If any images are still in memory when syncing, the
patient will have the option of backing those up as well.

State Diagram:


The following diagram (Figure 4.5) illustrates the
behavior of the
"MedicalRecord" object. Initially, after the "AddPatient()" event, the MedicalRecord
data is up to date on the server, although the record itself may still be empty. After a
doctor edits some information in the record, the MedicalRecord mov
es into the "Info
Edited by Doctor" state. This state signifies that the data is inconsistent between the
device and the server. Once the "SyncInfo()" operation is called, the MedicalRecord
moves back to the "Server Data Up to Date" state. The behavior is
similar for when a
patient updates the data, although in this case all the data is flagged as "patient
-
edited" in the database and on the device.

Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)




Fi
gure 4.1

Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)



System












































Physician

Add_Patient

Edit_Info

Login

Patient

Download
Image

Display_Info

Sync_Info

Backup_Info

Get Updated
Info

Extends

Upload

Image

Extends

Fi
gure 4.2

Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)















































R.AddEntry()

NewRecord()

Physician:

Patient:

Medical_Record:

Entry:

BasicInfo:

Laptop

Server

AddPatient()

NewPatient()

MedicalRecord* R

EditInfo(Record R)

R.EditBasicInfo()

R.EditEntry(E)

Entry *E

DisplayInfo(Record R)

ForAll (Entrys E)
R.Display(E)

Login()

UploadImage(Image I)

*I

DownloadImage(*I)

I

Logoff()

R.SyncInfo()

Doctor Sequence Diagram

Figure
4
.3

Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)















































AddEntry()

Physician:

Patient:

Medical_Record:

Entry:

BasicInfo:

Laptop

Server

EditInfo()

EditBasicInfo()

EditEntry(E)

Entry *E

DisplayInfo()

ForAll (Entrys E)
Display(E)

Login()

DownloadImage(Image *I)

I

Logoff()

If (Connected) UpdateLatest()

Record

BackupInfo()

Patient Sequence Diagram

Fi
gure 4.4

Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)

State Diagram for Medical Record


5


Prototype






The prototype of the Droid
application will encompass the basic functions of the
completed application. This will include m
ost of the features on the Droid

itself, and
also on the server. The main functions on the Droid will include downloading a data
file

from the server
, viewing t
he file in specific sections, and editing certain sections
of the data file. The application will also
include

buttons to upload the data files to
both the server and a PC as a backup file. On the server side,
there is also

a template
to input information
that will act as a demo data file. The server will also contain
example pictures and/or medical documents that will be viewable on the phone.


5.1

How to Run Prototype


If you do not have a Droid phone, you can download an emulator to your
computer. Windows, M
ac, and Linux systems are all able to access this emulator. If
you type in the
URL
:
http://developer.android.com/sdk/index.html

into your favorite
browser you are able to download the Android SDK needed to set up your emulator.
There are other links under
the SDK tab on the android development website that will
further assist you in downloading and installing the emulator.
[2]

Source code for this
Fi
gure 4.5

Template based on IEEE Std 830
-
1998 for SRS. Modifications (content and ordering of information) have
been made by Betty H.C. Cheng, Michigan State University (chengb at chengb.cse.msu.
edu)

application will be located on the project website under the Prototype section
(
http://www.cse.msu.edu/~cse435/P
rojects/F09/PMR
-
droid/web/proto.html
).

The last way to view this application in use is to navigate to the prototype folder
on the project website (
http://www.cse.msu.edu/~cse435/Projects/F09/PMR
-
droid/web/proto.html
). There will be

a link to a Mi
crosoft
P
owerPoint

presentation
that will show functionality of the application. We have constructed a library of
screen captures from the emulator. Simply click the touch screen portion of the
emulator to navigate through the functionality.

5.2

Sample Scenarios






A

time that you may need this application is if you are in a car accident. If you are
unconscious and the paramedics arrive on scene they would be able to see
information about you, and would be able to treat you more efficiently en
-
route to the
hospital. T
he paramedics would also be able to tell who to contact, whether it be
physicians or a family member.


6


References


[1]

D. Thakore and S. Biswas, “Routing with Persistent Link Modeling in Intermittently
Connected Wireless Networks,” Proceedings of IEEE
Military Communication, Atlantic
City, October 2005.

[2]

“Download the Android SDK”

Android
Developers

2009

Android
<
http://developer.android.com/sdk/index.html
>


7


Point of Contact

For further information regarding this document and project, please contact
Pro
f. Betty
H.C. Cheng
at Michigan State University (chengb at cse.msu.edu). All materials in this
document have been sanitized for proprietary data. The students and the instructor
gratefully acknowledge the participation of our industrial collaborators.