Online
Health Monitoring System
Software
Requirements Specification
COP 4331, Fall, 2014
Modification history:
|
Version |
Date |
Who |
Comment |
|
v0.0 |
|
Jon Carelli |
Uploaded Template |
|
v0.1 |
|
Jon Carelli |
Added title details, team contact info, acronym
descriptions, and product assumptions. |
|
v0.2 |
|
Jon Carelli |
Added stakeholders, event table |
|
v0.3 |
|
David Gundler |
Started 3.1,3.3 |
|
v0.4 |
|
Jon Carelli |
Added the Use Case Diagram |
|
v0.5 |
|
Jon Carelli |
Continued work on Event Table. |
|
v0.6 |
|
David Gundler |
Continued work on requirements 3.1 – 3.7 |
|
v0.7 |
|
Jon Carelli |
Cleaned up formatting, changed UCD requirements per
client request, and edited Event Table. |
|
v0.8 |
|
Jon Carelli |
Created Use Case Diagram descriptions and Section
4.0 Supporting Material |
|
v0.8 |
|
Jon Carelli |
Grammar check, finalized requirements 3.1-3.7 |
|
v0.9 |
|
C. N. McCue |
Completed “evaluations” sections |
|
v1.0 |
|
D. Gundler |
Completed “dependency” sections |
|
v2.0 |
|
C. N. McCue |
Modified sections 3.1, 3.2, 3.6, 3.9, Event Table
and Use Case Descriptions |
Team Name: Team 14
Team Members:
·
Jon Carelli - email
- web
page
·
Chris McCue - email - web
page
·
Chris Chaffin - email - web
page
·
Ethan Pitts - email - web
page
·
David Gundler - email
- web
page
·
James Luke - email - web
page
Contents
of this Document
Definition, Acronyms, and Abbreviations
The online health monitoring tool is an environment in
which a patient can keep track of their scheduled medicine doses coupled with
an alert system to their phone or email. The system encourages collaboration
via email or video chat to the patient’s physician and can be helpful for the
physician to keep track of what they have prescribed and to whom. The goal of
the system is to be simple and easy to use in order to make the website
accessible and frequently utilized by patients.
·
RFC 2616.
Hypertext Transfer Protocol -- HTTP/1.1, June 1999. Published by the Internet
Engineering Task Force (http://www.ietf.org/rfc/rfc2616.txt).
Definitions, Acronyms, and
Abbreviations:
- HTML – Hypertext Markup Language, a language to
create a layout for a webpage
- HTTP – Hypertext Transfer Protocol, the protocol used
by web servers and web browsers to communicate
- PHP – A programming language used to create dynamic
websites.
- SMS – Short Message Service, the protocol used in
most cell-phones for the exchange of short messages. This will be used to
notify patients when to take their medicine.
- MySQL – An open source database management program.
This will store user accounts and passwords.
- jQuery – A library for JavaScript
that cuts down on the amount of code needing to be written.
SECTION
2: Product Overview
- The developers assume the users and physician will be using a
modern web browser such as Google Chrome, IE 8+, Firefox
or Opera. We assume the website will be running on a single dedicated
server, and that there is a system admin who has access to that server.
- Client: Dr. Turgut / Gurkan Solmaz gave the idea
for the project and will be acting as client to decide what features will
be implemented.
- Patients: Looking for an easy way to find out when to
take medicine and be notified via SMS.
- Physician: Want an easy tool to keep track of patient’s
medicine intake.
- Developers: Want an efficient system as quickly as
possible.
|
Event Name |
External Stimuli |
External Responses |
Internal data and state |
|
Patient Create Account |
Clicking on “Patient Registration” button on the front page |
Redirects to “New Patient” form |
Creates a new Patient Node in respective database. User login and password are encrypted. Fill with provided information. |
|
Log In Account |
Entering account information in the appropriate area on the front page and pressing the “Log In” button. |
Directs user to “User Page” page. |
Access Patient Node in database. User supplied information is encrypted. Check credentials against those on file. Allows user access to their respective user page. Event manager updates user Calendar. |
|
Physician Create Account |
Clicking on “Physician Registration” button
on the front page |
Redirects to “New Physician” form |
Creates a new Physician Node in respective
database. Physician login and password are encrypted. Fill with provided
information. |
|
Physician Log In |
Clicking the Physician Log In link, then entering information and pressing the “Log In” button. |
Directs user to “Physician Page” page. |
Access Physician Node in database. User supplied information is encrypted. Check credentials against those on file. Allows user access to their respective user page. |
|
Assign Pill Schedule |
Finding patients name using drop down list,
entering medicine name, entering date and time patient must take the
medicine, clicking the ‘Assign Medicine’ button. |
Directs physician to a completed request
page, then auto re-loads the physician page. |
Accesses the patient’s user node in
database and updates medicine list and when it should be taken. Will also
send information to SMS tool and queue based on time to send SMS message. |
|
Add Appointment |
Finding patients name using drop down list,
entering appointment date and time patient must arrive, clicking the ‘Add
Appointment’ button. |
Directs physician to a completed request
page, then auto re-loads the physician page. |
Accesses the patient’s user node in
database and updates appointment list and when it should be taken. |
|
Send Message |
Selecting a patient in a drop down list,
entering a message in the text field and clicking the ‘Send Message’ button. |
Showing a ‘Message Sent’ alert to the user. |
Contacts the message handler with the
Sender ID and Receiver ID, message handler begins process to send message to
the Receiver ID. |
|
Receive Message |
No action needed |
User will see a popup on their page
displaying the message. |
Message Handler finds user ID, runs script
to display message on user’s page. |
|
View Calendar |
Log into patient page |
Calendar will display on the patient page
automatically with when the patient needs to take medicine. |
Calendar updater will run when patient
loads the patient page. Will check patient database for patient medicine
schedule and update accordingly. |
|
Video Chat |
Log into patient page, click ‘Video Chat’
button, redirects to video chat page, can request a video chat with a
physician. |
The physician can choose to accept or not. If
accepted, a video chat box will pop up and automatically connect the patient
and physician. |
None |
Use Case Descriptions:
Register Account:
Prompts the user for a username,
password and email. Creates a user account with the given
information.
Exceptions:
See Functional Requirements 3.1.1
Patient Log In Account:
Prompts the user for a username,
password. Log’s into the Patient Login Page.
Exceptions:
See Functional Requirements 3.1.2
Physician Log In Account:
Prompts the user for a username,
password. Log’s into the Physician Login Page.
Exceptions:
See Functional Requirements 3.1.3
Manage Account:
Allows user to edit phone, name,
email, and video chat credentials.
Exceptions:
Requesting user is not logged in or registered
Enter Name:
Allows the user to edit the name
recorded in the database.
Exceptions:
Invalid name characters or length
Enter Phone Number:
Allows the user to edit the phone
number recorded in the database.
Exceptions:
Invalid characters entered
Enter Email Address:
Allows the user to edit the email
address recorded in the database.
Exceptions:
String is not an email address
Enter Video Chat Credentials:
Allows the user to edit or input
their video chat credentials.
Exceptions:
Invalid credentials.
Send Message:
Allows the Physician to send a
message to a patient
Exceptions:
Message too long
Receive Message:
Allows the Patient to receive a
message.
Exceptions:
None
Message Handler:
Handles the sent message and passes it
along to the patient
Exceptions:
None
Assign Patient Medicine:
Allows the Physician to assign
medicine to an individual patient.
Exceptions:
Medicine name too long
Patient is already taking medicine at that time
Patient is already taking that medicine
Patient Database:
Stores patient information, including
when and what medicine to take.
Exceptions:
None
Calendar Updater:
Checks patient database for newly
added medicine, pushes update to patient Calandar.
Exceptions:
None
View Calendar:
Automatically loads calendar on
patient log in page.
Exceptions:
Patient not logged in.
Request Video Chat
Patient clicks a link that opens
video chat program, and automatically calls the Physician.
Exceptions:
Physician not online
Video Chat
A successful video chat begins
Exceptions:
None
SECTION 3: Specific Requirements
|
No: 1 |
|
Statement: Creating new user Node
in respective database and filling with the needed information. |
|
Source: Creation of a new Account. |
|
Dependency: No. 10 |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: When the program runs successfully, it
creates the user node and fills out the newly created node with the given
data. |
|
Revision History: David Gundler , |
|
No: 2 |
|
Statement: Log patient into
existing account by accepting information in appropriate area on the front page
and comparing it to account information on the Users Node in the database. |
|
Source: Patient login. |
|
Dependency: No. 10 |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: When it runs,
it can successfully compare the information and log in the patient. |
|
Revision History: David Gundler , |
|
No: 3 |
|
Statement: Log patient into
existing account by accepting information in appropriate area on the front
page and comparing it to account information on the Physician Node in the
database. |
|
Source: Physician login. |
|
Dependency: No. 10 |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: When it runs, it
can successfully compare the information and log in the physician. |
|
Revision History: David Gundler , |
|
No: 4 |
|
Statement: Physician must be able
to add patient appointments and assign pills schedules. |
|
Source: Doctor Manager. |
|
Dependency: No. 10; No. 9 |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: See if the Physician
can access and modify the patient’s calendar. |
|
Revision History: David Gundler , |
|
No: 5 |
|
Statement: Patients access to
calendar. |
|
Source: Calendar Viewing. |
|
Dependency: No. 10; No. 8 |
|
Conflicts: None |
|
Supporting Materials:
UML |
|
Evaluation Method: When logged in
as patient, see if a patient can access and view calendar. |
|
Revision History: David Gundler , |
|
No: 6 |
|
Statement: Sending and receiving
messages from Patients and Physician. |
|
Source: Message Handler. |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials:
UML |
|
Evaluation Method: Test the
systems capability to send and receive messages. |
|
Revision History: David Gundler , |
|
No: 7 |
|
Statement: Handling live video
chat between Patients and Physician. |
|
Source: Video Chat |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials:
UML |
|
Evaluation Method: Test the
systems capability to connect to the video chat. |
|
Revision History: David Gundler , |
|
Specific
interface for the Patients. |
|
Source:
Patient interface |
|
Dependency:
None |
|
Conflicts:
None |
|
Supporting
Materials: UML |
|
Evaluation
Method: Testing all the capability of the patient-users interface. |
|
Revision
History: David Gundler , |
|
No: 9 |
|
Specific
interface for the Physician. See
specifications below. |
|
Source:
Patient interface |
|
Dependency:
Node |
|
Conflicts:
None |
|
Supporting
Materials: UML |
|
Evaluation
Method: Testing all the capability of the Physician-users interface. |
|
Revision
History: David Gundler , |
|
Data Specifications for Pill
Scheduling |
||
|
Date
Related |
Control |
|
|
dateStart |
Drop-down lists |
Month 1-12; Day 1-31; current or next year |
|
dateDuration |
Text field |
0-365 days |
|
dateFrequency |
Drop-down list |
Every ____ days (1-10) |
|
|
|
|
|
Time
Related |
|
|
|
timeStart |
Drop-down list |
|
|
timeFrequency |
Drop-down list |
1-10 times/day |
|
timeEnd |
Drop-down list |
|
|
timeInterval |
Drop-down list |
Every ___ hours (1-12) |
|
|
|
|
|
Pill
Related |
|
|
|
pillName |
Text field |
Up to 80 characters |
|
numberPillsToTake |
Drop-down list |
1-10 pills at a time |
|
pillsLeft |
Text field |
0-999 pills |
|
Data Specifications for Appointment
Scheduling |
||
|
Field |
Control |
|
|
appointmentDate |
Drop-down lists |
Month 1-12; Day 1-31; current or next year |
|
appointmentTime |
Drop-down list |
|
|
recurringFrequency |
Drop-down list |
Daily, weekly, bi-weekly, tri-weekly, monthly,
bi-monthly, tri-monthly |
|
endRecurrence |
Drop-down lists |
Month 1-12; Day 1-31; current or next year |
3.3Physical Environment Requirements:
|
No: 10 |
|
Statement: Server that is capable
of holding all necessary data. |
|
Source: Website |
|
Dependency: No. 11 |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Seeing if the
program fits on the server and runs. |
|
Revision History: David Gundler , |
|
No: 11 |
|
Statement: Secure space for Server
that has temperature control, safety from all liquids and air quality
maintained (dust / humidity). |
|
Source: Server Maintenance |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Research into
server location and review uptime and safety precautions. |
|
Revision History: Jon Carelli , |
|
No: 12 |
|
Statement: Device that is capable
of accessing website (computer/smartphone/tablet
etc.). |
|
Source: Website access. |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Taking a device
and see if it can successfully access the site and run. |
|
Revision History: David Gundler , |
|
No: 13 |
|
Statement: Location that has
access to the internet. |
|
Source: Website access. |
|
Dependency: No. 12 |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Checking if environment has hotspot or
Ethernet connection. |
|
Revision History: Jon Carelli, |
3.4
Users and Human Factors Requirements:
|
No: 14 |
|
Statement: Users-Patients must
have basic understanding of web navigation and filling out form documentation for account creation. Must have steps to filling out form
documentation. |
|
Source: Users-Patients. |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Take feedback
from Patients |
|
Revision History: David Gundler , |
|
No: 15 |
|
Statement: Users-Physician must
have understanding of web navigation, documentation, and the ability to edit
calendar information. Documentation of
how to edit and modify calendar information. |
|
Source: Users-Physician. |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Take feedback
from physicians |
|
Revision History: David Gundler , |
|
No: 17 |
|
Statement: Software must maintain control of the
access dependent on the type of user. |
|
Source: Users-Access |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Test different logins for each type of user.
|
|
Revision History: David Gundler , |
3.5
Documentation Requirements:
|
Statement: On-line documentation for the patients for
filling out the form and account editing. |
|
Source:
Users-Patients |
|
Dependency:
None |
|
Conflicts:
None |
|
Supporting
Materials: UML |
|
Evaluation
Method: “Help” button click opens up
online help pdf. |
|
Revision
History: David Gundler , |
|
No: 19 |
|
Statement: On-line documentation for the physician in
account editing and calendar editing. |
|
Source:
Users-Physician |
|
Dependency:
None |
|
Conflicts:
None |
|
Supporting
Materials: UML |
|
Evaluation
Method: “Help” button click opens up
online help pdf. |
|
Revision
History: David Gundler , |
3.6
Data Requirements:
|
Statement: Retaining the data of the user account
information and calendar information.
Must be retained for authentication for accessing one's account and maintaining
all calendar information that will inform the patients of important events. |
|
Source:
Information/Servers |
|
Dependency:
No. 10 |
|
Conflicts:
None |
|
Supporting
Materials: UML |
|
Evaluation
Method: Random quality reports will be compared with user reports. |
|
Revision
History: David Gundler , |
Data protocols for Doctor Manager data
fields:
|
Example Data |
||
|
Date
Related |
User Data
Format |
Actual
Data Format |
|
dateStart |
|
2014:12:03 |
|
dateDuration |
7 days |
7 |
|
dateFrequency |
Every 1 day |
1 |
|
|
|
|
|
Time
Related |
|
|
|
timeStart |
|
|
|
timeFrequency |
3 times/day |
3 |
|
timeEnd |
|
|
|
timeInterval |
N/A |
N/A |
|
|
|
|
|
Pill
Related |
|
|
|
pillName |
Aspirin |
Aspirin |
|
numberPillsToTake |
3 |
3 |
|
pillsLeft |
15 |
15 |
The example data above is converted into the below data
format:
Aspirin 3 15
2014:12:3
2014:12:3
2014:12:3
2014:12:4
2014:12:4
2014:12:4
2014:12:5
2014:12:5
2014:12:5
2014:12:6
2014:12:6
2014:12:6
2014:12:7
2014:12:7
2014:12:7
2014:12:8
2014:12:8
2014:12:8
2014:12:9
2014:12:9
2014:12:9
3.7 Resource Requirements:
|
No: 21 |
|
Statement: Admin to maintain the system. |
|
Source: User-Admin |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Admin to
support monthly reports for accountability purposes. |
|
Revision History: David Gundler , |
|
No: 22 |
|
Statement: Secure space for Server that has
temperature control, safety from all liquids, air quality maintained (dust /
humidity) and constant power reliability. |
|
Source: Server |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Trainer to
check off this item on installation checklist. |
|
Revision History: David Gundler , |
|
No: 23 |
|
Statement: ·
Server
and the following tools and software. ·
HTML
– Hypertext Markup Language, a language to create a layout for a webpage ·
HTTP
– Hypertext Transfer Protocol, the protocol used by web servers and web
browsers to communicate ·
PHP
– A programming language used to create dynamic websites. ·
SMS
– Short Message Service, the protocol used in most cell-phones for the
exchange of short messages. This will be used to notify patients when to take
their medicine. ·
MySQL – An open source database management program. This will
store user accounts and passwords. ·
jQuery – A library for JavaScript
that cuts down on the amount of code needing to be written. |
|
Source: Server |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Application to
show green check for requirements met and red x for unmet. |
|
Revision History: David Gundler , |
3.8 Security Requirements:
|
No: 23 |
|
Statement: Access must be controlled for patients so that patients may only view their
own information. |
|
Source: Security/User-patients |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Attempt to hack
into system. |
|
Revision History: David Gundler , |
|
No: 24 |
|
Statement: Access to all patient files must be totally secure, including
calendar, account information, and medicines. |
|
Source: Security/User-patients |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Attempt to hack
into system. |
|
Revision History: David Gundler , |
|
No: 25 |
|
Statement: Access to the server must be secure
physical or otherwise. |
|
Source: Security/server |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Attempt to hack
into system. |
|
Revision History: David Gundler , |
|
No: 26 |
|
Statement: Patient and Physician usernames and passwords will be encrypted in
the database |
|
Source: Security/user-patients
& user-physician |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Attempt to hack
into system. |
|
Revision History: David Gundler , |
3.9
Quality Assurance Requirements:
Below is a listing of quality
attributes that are relevant to this system:
Safety-
Failure may result in harm or death to the user. Include disclaimers.
Testability-
Important to ensure failure does not occur.
See Test Plan.
Ease-of-use-
User must be able to use system within 5 minutes. Controls shall be similar to current user
interface controls.
Portability-
Must be compatible with the most current web browsers.
Performance-
Storage and retrieval of data must occur within 3 seconds.
Maintainability-
Maintenance testing to be performed twice daily to ensure smooth operation.
|
No: 27 |
|
Statement: Server reliability and availability must be
up 95% of the time and must always be secure. |
|
Source: Server reliability. |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Perform quality
tests for a week gather statistics. |
|
Revision History: David Gundler , |
.
|
No: 28 |
|
Statement: Calendar and messaging must have a
reliability of 99.99%. |
|
Source: Server reliability. |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Test Plan to
include 10,000 test cases. 9, 999 of
these must pass. |
|
Revision History: David Gundler , |
|
No: 29 |
|
Statement: Must have 99.99% reliability to reach the
Physician. |
|
Source: Reliability. |
|
Dependency: None |
|
Conflicts: None |
|
Supporting Materials: UML |
|
Evaluation Method: Test Plan to
include 10,000 test cases. 9, 999 of
these must pass. |
|
Revision History: David Gundler , |
SECTION 4: Supporting Material
- Questions sent to client and clients response in second hand:
Template
created by G. Walton (GWalton@mail.ucf.edu) on
This
page last modified by Chris McCue (christopher.mccue@knights.ucf.edu) on