Medicine Alert System
Page 1
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
---------------------------------------------------------------------------------------------------------------------------------------------------------------------
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 2
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
INTRODUCTION .................................................................................................................................. 3
G ENERAL O VERVIEW .............................................................................................................................. 3
M EDICINE A LERT S YSTEM O VERVIEW ................................................................................................... 4
P URPOSE ................................................................................................................................................. 4
S COPE ..................................................................................................................................................... 4
D EFINITIONS , A CRONYMS , AND A BBREVIATIONS ................................................................................ 4
REFERENCES ...................................................................................................................................... 4
D OCUMENT O VERVIEW ......................................................................................................................... 5
D OCUMENT R EVISION H ISTORY ............................................................................................................. 5
TEAM ARCHITECTURE ..................................................................................................................... 6
T EAM M EMBERS AND R ESPONSIBILITIES .............................................................................................. 6
INFORMAL REQUIREMENT DESCRIPTION ................................................................................. 7
E NTERPRISE R EQUIREMENTS ................................................................................................................ 7
F UNCTIONAL R EQUIREMENTS ................................................................................................................ 8
N ONFUNCTIONAL R EQUIREMENTS ....................................................................................................... 12
ISSUES ................................................................................................................................................. 13
PROTOTYPE ....................................................................................................................................... 14
FR 1.1 ................................................................................................................................................... 14
FR 2.1 ................................................................................................................................................... 15
FR 3.1 ................................................................................................................................................... 15
FR 3.2 ................................................................................................................................................... 16
FR 4.1 ................................................................................................................................................... 16
CREEPING RATE ............................................................................................................................... 17
WHY WE ARE THE BEST ................................................................................................................. 17
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 3
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Mobile computing systems have been increasingly adopted by the healthcare industry. Such systems typically provide greater convenience and better accessibility to both patients and healthcare service providers, often resulting in substantial cost and time savings. With more people owning and using mobile devices, more mobile healthcare applications will be embraced by the general population, especially those perceived to be useful and easy to use [1]. One of the major challenges faced by healthcare providers is poor medication adherence. This problem affected both males and females of all ages.
Many of them are not taking their medications as directed [3]. According to a landmark study on medical errors conducted by the US Institute of Medicine in 1999 [2], medication errors is the most common case among all medical errors. These medication errors incurred significant tolls in terms of patient fatality, medical expenses, productivity losses, and damages to morale and reputation of healthcare professionals. Out-patient medication administration has been identified as the most error prone procedure amidst the entire medication process. They accounted for 25% - 40% of all medication errors and were the main reason for admission of elderly into nursing homes [3].
Most out-patient medication errors were made when patients bought prescribed and over-the-counter
(OTC) medicines from different drug stores and use them at home without little or no guidance.
Common causes of these errors include: (1) irregular medicine in-takes due to the patient's busy or erratic lifestyles, (2) complicated in-take schedules due to the large number of medicines taken by the patient, (3) adverse drug reactions caused by un-reconciled prescriptions obtained from different sources, (4) lack of knowledge about proper use of medicines, (5) lack of consultation with healthcare providers and (6) lack of monitoring mechanisms to keep track of patient's medicine in-take schedules.
As elderly patients are more likely to be afflicted with chronic diseases, they need to take more prescription medicines and poor medication adherence would lead to serious consequences. Some common factors affecting medication adherence have been identified. The patient may be forgetful, or he may find it difficult to manage multiple medications.
There are existing devices that can provide reminder services for medication. The Automated
Pill Dispenser by MedMinder [4] is a rectangular tray with multiple compartments for storing medications for each day over a week. It is equipped with wireless technology and can be programmed to send visual and audio reminder. This tray is very useful in a home environment but is relatively bulky to be carried around by the user to different places. Since many people own mobile devices nowadays, a mobile application installed on a mobile phone can provide the reminder service without requiring additional cost or equipment.
Several mobile applications for medication reminder have been made available [5-9]. These are examples of Android applications that help users to manage their prescriptions and provide reminders.
Typically, this type of applications allows the user to set the time at which the reminder is to be triggered.
The reminder is usually in the form of an audible alarm.
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 4
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
However, none of these applications provides voice reminder in a language/dialect chosen by the user.
This feature is particularly useful for promoting medication adherence among elderly users who are not familiar with the default language, such as English.
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This Med-Alerts project is used to provide guidance and support to memory-loss patients to correctly take their medications. The application helps the user suffering from memory-loss by creating alerts that tell the user when and what medication is to be taken. Since smartphone mobiles are being widely used by general population, the Med-Alert application can provide on the go support for the users.
The Med-Alerts System provides timely alerts to users to notify them of the medicine intake. It has two modes: user-mode and assistive person mode. The system will function differently for the
“medicine in takers” and the family member/assistive person or the doctor. The system will generate reports regarding the medicine intakes, time of intake and will show the complete history of the medical details (including the wrong medicine intake, missed days etc.) at a pre-defined interval when in
“Assistive” mode. Where as in “in takers” mode, it will remind /alert the person to intake medicines for the day and at right time. The system will show the color of the medicine, the look and feel of the medicine and the description of the medicine. It alerts the in taker to have it right now and sign up for the confirmation and snoozes until it receives a confirmation of intake.
User:
The person who is suffering from memory-loss and need assistance for intake of medicines.
Assistive Person:
The person who will be entering the medicine name, dosage, color, description, look and feel and the time of intake.
Doctor:
The person who prescribes the medicine to the user (patient).The doctor can review the medicine reports and can provide consultation accordingly.
[1] S. W. a. L. L. J.H. Wu, "Mobile Computing Acceptance in the Healthcare Industry: A Structural,"
International Journal of Medical Informatics, pp. vol. 76, pp. 66-77, 2007.
[2] C. J. D. M. (. Kohn LT, "To Err Is Human: Building a Safer Health System," National Academy Press, 1999.
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 5
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
[3] W. A. a. S. TM, "Medication Compliance Research," Journal of Applied Research in Clinical and
Experimental T herapeutics, 2003.
[4] A. P. D. MedMinder, "www.medminder.com/products/maya-pill-dispenser," [Online].
[5] 2. P. A. Sartuga Software LLC, "www.pillboxalert.com," [Online].
[6] 2. M. R. Google Androidzoom, "www.androidzoom.com/android_applications/medical/med," [Online].
[7] 2. P. R. Google Shop Android Apps, "play.google.com/store/apps/details?id=com.garland.medmi," [Online].
[8] 2. M. Appbrain, "www.appbrain.com/app/medbuddy/com.rmcomputing.med," [Online].
[9] 2. M. R. W. Appbrain, "www.appbrain.com/app/medication-reminderwidget/," [Online].
[10] IEEE, "IEEE standard 830: Software Requirements Specifications.".
[11] L. Chung, "Requirements Engineering".
[12] M. Tool, " https://www.lucidchart.com/," [Online].
1.
Introduction provides an overview of the entire Medicine Alert system document.
2.
Team architecture describes how our team is divided up and what role each of our team member plays.
3.
Informal requirements description is about three parts: Enterprise Requirements, Functional
Requirements, and Nonfunctional requirements.
Enterprise Requirements
Defining the Full Problem, Enterprise Requirement for Medicine Alert System.
Functional Requirements
Configuring the Medicine Alert, Generate medicine reminder on time, Send the patient’s medicine intake reports to doctor.
Nonfunctional Requirement
Usability, User-Friendly, Reliable, Stable, Secured, Easily Configurable, Backup, Supportability.
4. Issues show the inconsistency, incompleteness, ambiguity, redundancy, etc. The solutions of these problems are also included.
2/18/2015
2/22/2015
Aishu, Ramya, Raj,
Sruthi
Created document outline from example submission.
Aishu, Ramya, Raj,
Sruthi
Group meeting. Went over WRS layout and filled in some issues and functional clarification.
3/12/2015 Aishu, Ramya, Raj,
Sruthi
Group meeting to update WRS document with material generated in previous meetings. Revision for submission of phase 1 deliverable.
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 6
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Our team consists of four people: Aishwarya, Ramya, Rajasekar and Sruthi. The team is divided into three categories, representing people in the User World, System World and Subject World.
Primary concerns and roles played by each team member is listed as follows:
Team
Member
Primary Concern
Aishwarya  Elicitation of Enterprise Requirements
Ramya  Elicitation of Functional Requirements
Rajasekar
Sruthi


Elicitation of Non Functional Requirements
Coming up with Product Perspectives and characteristics


Elicitation of Graphical User Interface and its feasibility
Elicitation of System Implementation and its feasibility


Traceability conducted for the refinement and to operationalize NFR's
To provide a best application:
1.
Trade Off Analysis for system decision making
2.
Survey on ease of use and GUI design with different categories of end-users.
3.
Understand and compare the features of existing Medicine
Reminder Applications.
The overall work is made up of two major activities: Problem Analysis and Product description .
Problem Analysis Step
 Learn about the problem domain




Understand the needs of potential users
Understand all constraints on the solution
Perform trade-offs between constraints
Consider alternatives.
The major source of our information is through observing the activities of how memory loss people forget to intake there medicines and the health hazards faced, reading journal paper for current problems faced by people, and surfing the web for related Medicine Reminders. Functional-oriented problem analysis is used in this Step. Data flow diagrams are sketched when as the problem become well understood.
Product Description Step


Organize ideas
Document SRS


Resolve conflicting views
Extract issues
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 7
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
To elicit enterprise requirements for Medicine Alert System, it’s better to define the problems being solved first.
Having medicine reminder as a mobile computing system we can make significant progress toward solving key problems most healthcare industry are contend with:
1.
Patients; more adherence to medication.
2.
Greater convenience and better accessibility to both patients and healthcare service providers.
3.
Greater help to elderly patients afflicted with memory loss, chronic diseases and having less hearing capability.
Substantial cost and time savings.
Now we are ready to elicit enterprise requirements specifically for Medicine Alert System.
Patients and their Family members:


Available to set reminders - Can I have a timely reminder for medicine intake?
Available of voice reminders – Is it possible to have a voice reminder?


Available theme settings - Can I change the look and feel of the system?
Description of medicine with image is provided - Can I have the details regarding the medicine?
Healthcare Providers:
 Availability of sharing reports - Can I have the report which indicates the adherence of medicine
 intake for my patients?
Available for login page for doctors - Can I have a protection mechanism thus the patients details are
 not known to other people?
Report and medicine details are archived for 3 months -Can I have all my patient’s details and use this application as a database repository to retrieve patient’s information?
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 8
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
System Top Level Diagram
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 9
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Prerequisites:
The mobile device should have a minimum charge to install this application (after the application is installed if the battery life goes less than 15% it alerts the users).
The mobile device should have the internet connection (3G/4G or Wi-Fi) to send medicine intake reports to the doctor.
Configuring the Medicine Alert
1.1
Create User as Assistive Person
1.1.1
Introduction
Assistive person will create a unique login to enter the medicine details which cannot be edited by others.
1.1.2
Inputs
Username and Password
1.1.3
Processing
Store the user information in the database and create a User for the application.
Give him the basic rights to set a medicine reminder and its intern functionalities.
1.1.4
Outputs
Lead user to set a medicine alert.
1.2
Create a medicine alert
1.2.1
Introduction
Assistive person after logging in to the application can set the medicine reminder for the patient.
1.2.2
Inputs
Assistive person can enter:
Name of the medicine
Description about the medicine
Amount (Quantity of intake)
Size (#grams of the tablet, #milliliters to intake when it is a tonic, etc.)
Start Date
End Date
Exact Time to remind
Repeat on what interval
Refill Date of the medicine
Upload an image of the medicine
Patient’s Doctor details (Name and mail id)
Doctor Report’s mail frequency.
Save the information.
Multiple medicine reminders can be entered.
1.2.3
Processing
Then details are entered into the DB and it is set for reminders.
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 10
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.2.4
Outputs
The entered details are shown in the menu and pushed into the database and ready for sending reminders.
Generate medicine reminder on time
2.1.1
Introduction
The system will take the details from the database and generates the reminder to the user to intake medicine and by default is snoozes until the medicine in taker timestamps back.
2.1.2
Inputs
The medicine details will be picked up from the database.
2.1.3
Processing
The system code functions and fetches the display format from the database.
2.1.4
Outputs
The display of reminder with sound having details of
Medicine Image
Medicine Info
Timestamp submission of Taken
On click of the above buttons it reads the information for us.
Send the patient’s medicine intake reports to doctor.
3.1 Create User as Doctor
3.1.1
Introduction
Doctor will create a unique login to view his patient’s details which cannot be viewed by others.
3.1.2
Inputs
Username and Password
3.1.3
Processing
Store the user information in the database and create a User for the application.
Give him the basic rights to view a medicine intake reports for his patient.
3.1.4
Outputs
Allows doctor to view his patient’s report.
3.2
View Particular Patient’s Details
3.2.1
Introduction
A doctor can have multiple Patient’s and on click of the link of the patient’s name he will be able to view the patient’s medicine intake report.
3.2.2
Inputs
The report is retrieved from the Database.
3.2.3
Processing
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 11
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The report is refreshed as the user inputs his time stamp and it is refreshed in the database. Along with this the mail of the patient report reached doctor as per the time frequency set by the user in the initial set up screen.
3.2.4
Outputs
Doctor can view the report as a link in the application and as a PDF file from his mail.
4.
Other Accessory Controls:
4.1.1
Introduction
The users will be able to setup the font size, change their password, change the background theme of the application, set the multilingual functionalities and audio support for English language will be provided.
4.1.2
Inputs
The user can configure the above mentioned functionalities through the Settings menu.
4.1.3
Processing
Look and Feel will take up the values of User’s by replacing the default value.
4.1.4 Outputs
The look and feel of the application is changed as per user’s input.
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 12
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
A good Medicine Alert system should meet the powerful functional requirement. It should also pay attention to its non-fictional requirements. This section describes the quality attributes that the
Medicine Alert software should have.
The system should be available 24 hours a day and 7 days a week.
The Medicine Alert system should be released after thoroughly tested. System generate alerts when the battery life for the mobile device goes down below to a certain preset value.
The system should provide high performance.
1.
The respond time for managing the settings, viewing reports and changing the look and feel should be no more than 2 seconds.
2.
The system should provide battery down alert information to the user as soon as the mobile battery life reaches 15%.
3.
The system should be able to serve 1000 users concurrently.
The system should have a good user interface. The novice user can simply follow the instructions to use the system without special computer technique. This is achieved by options to configure the font size, multilingual, optical zoom, quick response time, tool tip, configure themes, auto update feature, and detailed catalog with search feature.
The system should be easy to maintain by administrators. The system’s database should be backup every week. After certain of time, the system should be added new function, new features so that it can provide user good qualities.
The system should protect itself from external attacks that may be accidental or deliberate such as viruses, unauthorized use of system services, unauthorized use of system services, unauthorized modification of the system or its data. All customers’ account information must be stored in the system’s database. Only the database administrators have direct access to the database for making any change related to the database schema and for maintenance purposes.
Compatibility
It works with previous versions of Android OS.
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 13
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Trade-Off Analysis/ Traceability:
Problem: The patient gets a reminder to in-take a medicine on a time, but the user is not sure whether it is a powder or pill or tonic and how does it looks like.
Goal: The patient should be able to distinguish the type of medicine.
Option 1: We could provide a dropdown stating whether it is a Pill, Powder or Tonic; so that the assistive person can set during the enablement of reminder.
Option 2: We can provide an option to upload an image showing the Pill or tonic or powder; so that the assistive person can upload during the enablement of reminder.
Solution: Option 2
Reason: As the memory loss patient can see how the medicine looks like and get in touch with the medicine as soon as possible without any confusion.
Trade-Off Analysis/ Traceability:
Problem: The “assistive person from the family” and the “doctor” have the same role.
Goal: To create an isolation between different user roles.
Option 1: Change “Doctors” to “assistive person”.
Option 2: Separate mode to be placed for doctor.
Solution: Option 1
Reason: Keep it simple and useful.
Trade-Off Analysis/ Traceability:
Problem: The memory loss patient are uncertain how many tablets are available and when they need to purchase the tablets for in-take.
Goal: To enable the patient to accurately determine the medicine availability.
Option 1: Keep a manual update to hold the details of when they started a bottle of medicine and when they should buy a new one; with a week before the deadline date.
Option 2: Keep an automated update based on the number of pills in a bottle and the patient’s dosage.
Solution: Option 1
Reason: Keep it simple and maintain accuracy.
Trade-Off Analysis/ Traceability:
Problem : The Medicine Alert system need to have interfaces to mailing system, e.g. SMTP (Simple
Mail Transfer Protocol); so, it should be included in the nonfunctional requirements part.
Goal : To establish a communication between the patient and the doctor.
Option 1: Adding interoperability to the nonfunctional requirements.
Option 2: Only using the Medicine Alert system.
Solution: Option 1.
Reason: Right now the mailing system of medicine alert system needs to use the SMTP protocol to finish its task.
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 14
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FR 1.1
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 15
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FR 2.1
FR 3.1
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 16
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FR 3.2
FR 4.1
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Medicine Alert System
Page 17
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
The requirements and specifications can be changed up to 20% with a variance of +/-5%. This value is not accurate and is based on the following criterions: a)
The intensity of change on prototype b)
The time and resource required to implement the change in the provided limited resources. c)
How deviated is the new requirement from the old requirement d)
New changes should support validation and traceability factors
We are taking a unique approach to the HOPE System by dividing functionality across a suite of applications. This allows each piece of functionality to be provided in a more concise manner reducing the difficulty of navigation and increasing the cohesion of functionalities provided. We are also able to more easily divide labor and keep developers on a smaller set of functionality and code to be familiar with.
We shall provide a best application by:
 Doing Trade-Off Analysis for system decision making.
 Survey on ease of use and GUI design with different categories of end-users.
 Understand and compare the features of existing Medicine Reminder Applications.
Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------