January 2015

Project I

---------------------------------------------------------------------------------------------------------------------------------------------------------------------

The MEDICINE ALERT System Requirements

Specification
---------------------------------------------------------------------------------------------------------------------------------------------------------------------

b
Medicine Alert SystemPage 1

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

“The hardest single part of building a software system is deciding

precisely what to build. No other part of the conceptual work is as
difficult as establishing the detail technical requirements,
including all the interface to people, to machines, and to other
software systems. No part of the work so cripples the resulting
system if done wrong. No other part is more difficult to rectify
later.”

[Brooks, 1987]

Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Medicine Alert SystemPage 2

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Contents

INTRODUCTION................................................................................................................................... 3

GENERAL OVERVIEW................................................................................................................................3
MEDICINE ALERT SYSTEM OVERVIEW.....................................................................................................4
PURPOSE...................................................................................................................................................4
SCOPE.......................................................................................................................................................4
DEFINITIONS, ACRONYMS, AND ABBREVIATIONS..................................................................................4

REFERENCES....................................................................................................................................... 4

DOCUMENT OVERVIEW...........................................................................................................................5
DOCUMENT REVISION HISTORY...............................................................................................................5

TEAM ARCHITECTURE....................................................................................................................... 6

TEAM MEMBERS AND RESPONSIBILITIES................................................................................................6

INFORMAL REQUIREMENT DESCRIPTION.................................................................................. 7

ENTERPRISE REQUIREMENTS...................................................................................................................7
FUNCTIONAL REQUIREMENTS..................................................................................................................8
NONFUNCTIONAL REQUIREMENTS.........................................................................................................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 SystemPage 3

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Introduction
General Overview
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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 SystemPage 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.

Introduction
Medicine Alert System Overview
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Purpose

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.

Scope

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.

Definitions, Acronyms, and Abbreviations

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.

References

[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.

Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Medicine Alert SystemPage 5

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[2] C. J. D. M. (. Kohn LT, "To Err Is Human: Building a Safer Health System," National Academy Press,
1999.
[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] Martin Glinz, "Requirements Engineering".
[12] M. Tool, " https://www.lucidchart.com/," [Online].

Document Overview

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.

Document Revision History

Date Reviser Summary

2/18/2015 Aishu, Ramya, Raj, Created document outline from example submission.
Sruthi

2/22/2015 Aishu, Ramya, Raj, Group meeting. Went over WRS layout and filled in some
Sruthi issues and functional clarification.

3/12/2015 Aishu, Ramya, Raj, Group meeting to update WRS document with material
Sruthi generated in previous meetings. Revision for submission
of phase 1 deliverable.

Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Medicine Alert SystemPage 6

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Team Architecture
Team Members and Responsibilities
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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 Primary Concern

Member
Aishwarya  Elicitation of Enterprise Requirements
Ramya  Elicitation of Functional Requirements
Rajasekar  Elicitation of Non Functional Requirements
Sruthi  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 SystemPage 7

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Informal requirement Description

Enterprise Requirements
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Defining the Full Problem

To elicitenterprise requirements for Medicine Alert System, it’s better to definethe problems
being solved first.Havingmedicine 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.
4. Substantial cost and time savings.

Enterprise Requirements for Medicine Alert System

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 SystemPage 8

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Informal requirement Description

Functional Requirements
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

System Top Level Diagram

Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Medicine Alert SystemPage 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.

1. 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
Storethe 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 SystemPage 10

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

1.2.4 Outputs
The entered details are shown in the menu and pushed into the database and ready for
sending reminders.

2. 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.

3. Send the patient’s medicine intake reports to doctor.

3.1 Create User asDoctor
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 reportsfor 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 SystemPage 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 SystemPage 12

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Informal requirement Description

Nonfunctional Requirements
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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.

Availability
The system should be available 24 hours a day and 7 days a week.

Reliability
The Medicine Alert system should be released after thoroughly tested. System generate alerts when
the battery life for the mobile devicegoes down below to a certain preset value.

Performance
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.

User friendliness
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, quickresponse time, tool tip, configure themes, auto update feature,
and detailed catalog withsearch feature.

Maintainability
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.

Security
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 SystemPage 13

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Issues
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Inconsistency
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.
Redundancy
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.
Ambiguity
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.
Incompleteness
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 includedin 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 SystemPage 14

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Prototype
FR 1.1

Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Medicine Alert SystemPage 15

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

FR 2.1

FR3.1

Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Medicine Alert SystemPage 16

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

FR 3.2

FR 4.1

Project #1: Requirements Elicitation - Initial Understanding Mar. 11 2015

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Medicine Alert SystemPage 17

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Creeping Rate
The requirements and specifications can be changed up to 20% with avariance of +/-5%. This value is
not accurate and is based on thefollowing 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

Why we are the best

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.

Weshall 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

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------