Remind Me Application
Team Hedgehog

Revision History…………………………………………………………………………………... 2
1. Introduction……………………………………………………………………………………... 3
1.1 Purpose ……………………………………………………………………………..… 4
1.2 Scope ……………………………………………………………………………….… 5
1.3 Definitions, Acronyms, Abbreviations……………………………………………… 7
1.4 References…………………………………………………………………………… 8
1.5 Overview……………………………………………………………………………… 8
2. Overall Descriptio n…………………………………………………………………………….. 10
2.1 Product Perspect ive…………………………………………………………………. 11
2.2 Product Functions…………………………………………………………………… 13
2.3 User Characteristics…………………………………………………………………. 22
2.4 Constraints…………………………………………………………………………… 22
2.5 Assumptions and Dependencies……………………………………...…………… 24
3. Specific Requirements………………………………………………………………………… 25
3.1 External Inte rfaces……………………………………………………………...…… 26
3.2 Function s……………………………………………………………………………... 26
3.3 Performance Requirements………………………………………………………… 29
1

Version
Initial draft
Date
10/01/2013
Description
Contains Most
Requirements.
Architecture and
Design to be added.
Authors
Tej Gidvani
2

3

1.1 Purpose
The purpose of this Software Requirements Specification is to establish the requirements needed in developing the Remind Me application. This document will cover the information on what this application will do to meet the user’s needs.This document serves as the guide for the developer to know what the system needs to include when it comes to functional and nonfunctional requirements.
1.1.1 User Needs
This application is targeted for an elderly population. It is also targeted to people who take medication. The application is based around reminding people when to take their medicine as well as other functions to aid them in taking their medication. The user needs that were targeted were the need for the user to keep track of how much of each medication is left. The user also wants to be reminded and notified when they need to take their medication. Another concern the user had, was being able to have a caretaker help them refill their medication as well as being able to call them when they need help.
1.1.2 Developer Objective
The developer wants to create a software system that will accomplish all of the user’s goals. The developer wants to develop software that will create a smart home experience. The smart home experience should tie together all the utility systems in the home into one easy to access system. The smart home experience should also be capable of performing automated actions that have been brought up by the user.
4

1.2 Scope
This Document will cover the requirements for creating the Remind Me android Application.
This document will also cover the problems and the audience that the application should cater to.
1.2.1 Deliverables
Remind Me is an android application for mobile devices.
1.2.1.1.1 Users can set caretakers
1.2.1.1.2 Users can add prescriptions
1.2.1.1.3 Users can view their prescriptions.
1.2.1.1.4 Users can keep track of their pill count
1.2.1.1.5 Users can get reminders for taking their medications
1.2.1.1.6 Caretakers can be notified to help the user with medication refills
1.2.1.1.7 The user can call the caretaker in an emergency
1.3 Definitions, Acronyms, Abbreviations
Term
Caretaker
Entry
Definition
The person who is assisting the user with their health care.
A placement of data about a prescription that is placed in the application.
5

1.4 References
1. IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements
Specifications.
IEEE Computer Society, 1998.
2. (2013). Internet Society [Online]. Available: http://www.internetsociety.org/
1.5 Overview
1.5.1 Contents and Organization of the SRS
This Software Requirements Specification contains information that will be considered when designing the smart home experience.
1.5.1.1 Introduction: In this first section, the goals of this project have been stated. The rest of this document will cover various other topics necessary in designing this software system.
1.5.1.2 Overall Description: This section will cover the overall description of the project.
The business goals and concepts will be discussed. All interfaces necessary will be talked about. Constraints to the project will also be discussed. The context of the product will also be defined. The uses of the product will be discussed. All the assumptions that are going into development will also be stated.
1.5.1.3 Specific Requirements: This section will discuss the requirements that affect the design of the software system more directly. The interfaces that the system will interact with will be discussed. The functionality of the software system will be discussed in detail. Performance requirements and constraints on the functions will also be discussed. Any back-end database topics will be discussed to. This
6

section will talk about anything needed in designing and implementing the software system.
1.5.1.4 Appendices: This section has the appendices which contain charts, pictures, tables, and/or graphs.
1.5.1.5 Index: The index contains a list of topics or terms to be noted throughout the document.
7

2.1 Product Perspective
8

In modern times, elder people are living by themselves. Also many people who are independent take medication. Most of these medications need to be taken on schedule. This means that people need to make sure to remember to take their medication on time and in the right dosages. A problem that arises with elder people and people with memory disabilities is that they can forget to take their medication. Some of these people also need help with refilling their medication and they may have a family member or a caretaker that helps them with their health.
2.2 Product Functions
This subsection of the SRS provides a summary of the functions that the software will perform.
2.2.1 Use Cases
1. A user wants to add a new medication
2. A user wants to update a medication entry
3. A user wants to view their entries
4. A user wants to decrement the pill count
5. The user wants to change the settings
6. The user wants to call the caretaker
7. The pill count gets below safe and texts the caretaker
2.3 User Characteristics
The primary users of this application are people who take medication. More specifically the application is targeted toward medication users who are older or have memory problems.
Since the users will probably be older we need to account for usability. Elder people are no as literate with technology so the user interface should be simple.
9

2.4 Constraints
Constraints are conditions that limit the developer’s options for the creation and execution process for the system. The following are the constraints of the system:
2.4.1.1
2.4.1.2
Internet regulation will be from the Internet Society.
OSHA will be used as the health and safety regulation.
2.4.2.1
2.4.2.1
2.4.2.3
Downtime shouldn’t be more than 2 minutes.
Response time to button clicks should be no more than 2 seconds
System process time shouldn’t be any longer than 2 seconds.
2.4.3.1
.
The application will interact with other android facilities such as the alarm, texting and phone calling.
2.5 Assumptions and Dependencies
This subsection of the SRS should list each of the factors that affect the requirements stated in the SRS. These factors are not design constraints on the software but are, rather, any changes to them that can affect the requirements in the SRS.
10

11

3.1 External Interfaces
3.1.1 User Interfaces
The Remind Me Application
3.1.2 Hardware Interfaces
The Remind Me application will interact with an Android phone. It will also be able to text and call any other cellular phone.
3.1.3 Software Interfaces
3.1.3.1 The application interacts with a MySQL Lite back end that stores the data for prescription entries.
3.1.4 Communications Interfaces
The Remind Me application will use the android API for communication with external devices.
This means that the application will text the care taker and call the care taker through the android APIs.
3.2 Functions
3.2.1 New Medication Entry
Inputs: The new entry will need the following information
3.2.1.1 Medication Name
3.2.1.2 Doctor Name
3.2.1.3 Refill Date
3.2.1.4 Pill Count
3.2.1.5 Dosage
3.2.1.6 Time to take the dose
Checks: The screen will check that each field has the proper type of data entered.
Normal Response: The application will create a new entry for the medicine
Abnormal Response: The system does not create the new entry or crashes.
12

Other Requirements: The user will have to know what the information needed is.
3.2.2 Change Settings
Inputs: Patient Name, Caretaker Name, Caretaker Number
Checks: Checks if the input is of valid type
Normal response: The user changes the value of either the patient name, caretaker name, or caretaker number
Abnormal response: Values are not changed and the application crashes
Other Requirements:
If the user wants to delete an entry
3.2.3 Delete an Entry
Input: Use th touch interface to pick the delete option and then click which entry to delete.
Checks: This will check if the entries exist.
Normal Response: The entry will be deleted
Abnormal Response: The entry is not deleted
Other Requirements:
This option will inflate a menu to access the view screen.
From the view screen you will be able to chose which entry to delete.
3.2.4 Update a medication
Inputs: Long click on the entry in the view screen.
Checks: It checks that long click is on an existing entry.
Normal response: It will open an inflated menu to update the entry
Abnormal response: No menu opens.
Other Requirements:
The entry can only update certain values in an entry.
3.2.5 Decrement pill count
Inputs: Button on the view screen
Checks: Check that the pills are there to be decremented and current count is greater than 0.
Normal response: The number of pills decreases appropriately.
Abnormal response: The number of pills does not decrease properly.
Other Requirements:
If the pill count is brought below the threshold then the application will text the caretaker.
3.2.6 Choose a Menu Option
13

Inputs: 4 possible buttons on the main menu screen
Checks: None
Normal response: A menu option is picked and the appropriate screen appears
Abnormal response: The screen does not appear or the application crashes
3.3 Performance Requirements
3.3.1 Response Time
3.3.2 Reliability
3.3.2.1
3.3.2.2
3.3.2.3
3.3.2.4
3.3.3 Workload
3.3.3.1
3.3.4 Scalability
3.3.4.1
3.3.5 Platform
14

3.3.6 Security
3.3.6.1
15