Table of Contents
Revision History
1. Introduction
2. Issues with Preliminary Definition Given
2.1 Domain, Stakeholder, Functional and Non-Functional Objectives – Issues
2.1.1 Memory Lapses
2.1.2 Pill Management
2.1.3 Graphical Complexity
2.1.4 Technological Hindrance
2.1.5 Data Privacy
2.2 Software System Functional Requirements – Issues
2.2.1 Pill Alarm Images
2.2.2 Pill Lookup
2.3 Software System Non-Functional Requirements – Issues
2.3.1 Interface
2.3.2 Separation of Environment
3. WRS
3.1 W - World
3.1.1 Problem
3.1.2 Goal
3.1.3 Improved Understanding
3.2 RS - Requirements Specifications
3.2.1 Use-Cases
3.2.2 Future Functional Requirements
3.2.3 Implemented Functional Requirements
3.2.4 Class Diagram
3.2.5 Sequence Diagram
3.2.6 Activity Diagram
3.2.7 Non-Functional Requirements
4. Preliminary Prototype and User Manual
4.1 Prototype Mockup
4.2 User Manual
5. Traceability
6. Application Superiority
References
Appendix
Index
Creeping Rates

Outline
Name Date
10/1/12
Rough Interim Phase I WRS 10/3/12
Final Interim Phase I WRS
Updated Phase I WRS
Rough Final Phase I WRS
10/4/12
10/8/12
10/18/12
Final Final Phase I WRS
Updated Phase II WRS
10/18/12
10/22/12
Rough Interim Phase II WRS 11/11/12
Final Interim Phase II WRS
Updated Phase II WRS
Rough Final Phase II WRS
11/13/12
11/19/12
11/30/12
Reason For Changes
More details added
Edited and revised
Final of phase I has begun
More details added
Edited and revised
Phase II has begun
More details added
Edited and revised
Final of phase II has begun
More details added
Edited and revised
2.2
3.0
3.1
3.2
4.0
4.1
1.0
Version
1.1
1.2
2.0
2.1
Final Final Phase II WRS 12/4/12 No Changes 4.2
We will develop a smartphone application to help schedule what pills an elderly end-user needs to take and when. The application allows quick and efficient setup of a pill schedule to tell users when medications must be taken.
2.1 Domain, Stakeholder, Functional and Non-Functional Objectives - Issues
2.1.1 Memory Lapses
The elderly user may suffer from loss of memory, and can forget to use or how to use their pill schedule. Use of the application must not be dependent on a consistent memory.
2.1.1.1 Pill Entry
Users may not remember what pills they had entered previously
Options:
■ Information entered is saved so that the user does not need to remember what they had entered previously.
■ Users must write down or have someone else remember what they had entered previously.
A user should not have to remember what information they had entered previously into the application. The application will save any pill information entered by the user.
2.1.1.2 Pill Taking

Users may not remember to check their phone when they should take a scheduled pill.
Options:
■ A pill alarm will be activated whenever a pill is scheduled to be taken.
■ Users should set an alarm clock to remind them to check the application for pills to take.
A pill alarm should be implemented into the pill scheduling application and set during pill entry. This ensures that the users are correctly reminded to take their pills based on their pill entries. Errors may occur if a user had to set a different alarm clock reminder multiple times a day.
2.1.2 Pill Management
An elderly user may have problems managing multiple complex medications using the application.
Options:
■ A separate pill entry will be created for each medication, and relevant information about the medication will be stored along with the pill entry.
■ A single list of pills and their information will be stored in the application.
It is inefficient and overly complicated to store all the pills for a pill schedule in a single list. Each pill added should be a separate entry in the application to ensure simplicity and ease of understanding.
2.1.3 Graphical Complexity
Users may not be able to see small or complex graphics clearly on a smartphone screen. This may lead to confusion or misinterpretation of application functions.
Options:
■ The application interface should use large and simple graphics to clearly convey functions.
■ The application should describe complex graphics in a separate section to be used as a reference guide.
Describing complex graphics in a reference unnecessarily complicates the use of the application. Large, simple graphics offer a feasible solution to the issue while preserving usability and aesthetics.
2.1.4 Technological Hindrance
Users may not be technically inclined enough to easily use the application

2.1.4.1 Access
Users may not know how to download and install the smartphone application
Options:
■ The application should be available download through the already existing Google Play Store, and is automatically installed after downloading.
■ The application should be available to download by visiting a website URL on the smartphone, and must be installed manually.
Making the application available on the Google Play Store makes it easier to download and install. The Google Play Store is included with all
Android smartphones, so this further expands availability. This also allows developers to focus on feature implementation instead of ease of download and installation.
2.1.4.2 Navigation
Users may not be familiar with Android development standards, or how to navigate a complex Android application.
Options:
■ Use simple, large buttons that clearly communicate how to navigate and use the application
■ Include additional documentation inside the application detailing how to navigate a complex application interface
Navigation should be easy and pleasing to the eyes, so large, simple buttons with easy to understand functions should be implemented.
Additional documentation is not necessary, and a complex interface could prolong implementation.
2.1.5 Data Privacy
Users may be vulnerable to other people using their smartphone and accessing sensitive medication information.
Options:
■ The pill scheduling and pill taking functions of the application should be separate and sensitive information should be protected with a password if the user requests it
■ Users should implement a lock screen on their smartphone to prevent unauthorized access to sensitive pill information

We should not assume that a user will have a lock screen on their smartphone, especially if the user is not technically inclined enough to set up a lock screen.
We can feasibly implement separate environments for the pill scheduling and pill taking functions of the application.
2.2 Software System Functional Requirements - Issues
2.2.1 Pill Alarm Images
When there are multiple pill images on an alarm, we need an efficient way of representing the pills without overcrowding the interface
Options:
■ Use scrollable pill images and allow the end-user to confirm each pill individually.
■ Use a single pill image which must be confirmed before the next pill image is shown.
The most feasible option is to use individual pill images which must be confirmed one at a time. This increases the simplicity and easy to use aspect of the product and reduces possible confusion of missing one of the pills.
2.2.2 Pill Lookup
There should be a way for someone to look up a pill that may not have a bottle to identify it.
Options:
■ A pill lookup feature will link with an online pill database where a user could search for pill colors, codes, and shapes.
■ A large pill reference listing could be included in the default pill database including possibly outdated pill information.
The most feasible thing to do is to link to an online pill database through the application. This reduces development time in looking up and adding a large amount of pills for reference, and reduces the overall size of the application.
2.3 Software System Non-Functional Requirements - Issues
2.3.1 Interface
The interface needs to be easy to read and understand. A user should not have to go through a complicated process to learn how to use the system.
Options:
■ Large text and a simple interface.
■ A “simple” version of the application and a “complex” version of the application to support different users of different skill levels.

Using large text and a simple interface is the more feasible option in order to ensure readability and an easy understanding of the system. It would significantly increase development time if two separate versions of the applications had to be implemented.
2.3.2 Separation of Environment
There needs to be a separate environment for a user entering pill information, and a user interacting with alarms and viewing the weekly calendar.
Options:
■ Develop separate applications for those interacting with alarms and those interacting with the scheduler.
■ Include a “Settings” section for users to enter pill information, and have the weekly pill calenda r on a separate screen. Allow users to “lock” the advanced pill scheduling features to prevent accidental changes to the schedule.
It is more feasible to “lock” advanced features like pill scheduling once the schedule has been entered instead of developing separate applications. This reduces overhead and development time when we start to implement the system.
3.1 W - World
3.1.1 Problem
It is important for those needing daily medication to take it regularly and correctly, but this doesn’t always happen. Those taking the medication may have trouble remembering to take the pills they need, or it can be complicated for them to manage multiple medications. Because medications may be missed or forgotten, the health of those taking the pills can be at risk.
3.1.2 Goal
We will develop an application aimed at reducing the complexity of remembering and maintaining a pill schedule. Once set, a pill schedule in our system will keep track of a wealth of information related to the medications and only require the end-user to confirm that they took the pills entered in the schedule.
3.1.3 Improved Understanding
For desired functionality, our PAL system shall take into consideration memory impairments of the elderly when using the application. Information entered into the application should be saved for later reference, and an alarm should activate when a pill needs to be taken. Each pill reminder shall be entered and should be saved separately. The interface shall include simple and easy to see graphics, as well as large buttons to clearly communicate application functionality. The

application shall also be easy to download using the Google Play Store and should offer privacy in the form of password protection.
3.2 RS - Requirements Specifications
3.2.1 Use-Cases Diagram
Figure 1: Use Case Diagram
These are the main use cases we have prepared for our product. They are deconstructed into individual requirements below.
3.2.2 Future Functional Requirements
Due to the time constrained deadline of December 4th, not every feature will be able to be implemented in the first release of the application. Those features that will not be included in this first release, but still plan to be included in future releases are listed below.
3.2.2.1 Paired App
There will be a “Pro” version of our application that will consist of an additional paired application to be used by a caretaker (in a hospital or nursing home). The caretaker’s application could keep track of multiple p atients’ application and give notifications when help was requested.
However, due to the time constraints we have decided that we will not be able to implement this feature during Phase II. While useful, it is not an essential requirement and as such will have to be implemented in future phases. Below are the various features the Paired Application is intended to perform.

3.2.2.1.1 When a user can’t find the required pill
● Input: A user chooses the option on the alarm screen that they “can’t find the pill” twice, once for initial confirmation on the alarm screen, once for final confirmation on a subsequent screen.
● Output: A paired app notification, text message notification, email, or automated phone call is activated to let an outside entity know a pill was not taken because the user couldn’t find it.
When an alarm is activated and a user chooses the option on the alarm screen that they “can’t find the pill” and they confirm this selection, a notification will be sent (via a paired app notification, text message, email, or automated phone call) to let an outside entity know the pill was not taken because the user couldn’t find it.
Note: this could require an internet connection.
3.2.2.1.2 When a user ran out of the required pill
● Input: A user chooses the option on the alarm screen that they “ran out of the pill” twice, once for initial confirmation on the alarm screen, once for final confirmation on a subsequent screen.
● Output: A paired app notification, text message notification, email, or automated phone call is activated to let an outside entity know a pill was not taken because the user ran out of it. An automatic refill request is made to an associated pharmacy.
When an alarm is activated and a user chooses the option on the alarm screen that they “ran out of the pill” and they confirm this selection, a notification will be sent (via a paired app notification, text message, email, or automated phone call) to let an outside entity know the pill was not taken because the user couldn’t find it.
If the application is setup with prescription refill information and a pharmacy location, the prescription refill request is processed automatically for pickup at the pharmacy via an available internet connection.
If internet access is limited, the application can queue notifications that require internet connectivity, such as sending an email or notifying a paired app. If the user is interacting with the application through a tablet without a dedicated data connection, the user must eventually gain internet access to send pill notifications.

3.2.2.2 Feedback
In future releases, we will implement feedback for a caretaker to be notified when a pill has been consumed.
● Input: A user confirms that they took the pill using the system interface twice, once for initial confirmation on the alarm screen, once for final confirmation on a subsequent screen.
● Output: A paired app notification, text message notification, email, or automated phone call is activated to let an outside entity know a pill has been taken and not missed.
When an alarm is activated and a user confirms twice that they took the pill associated with the alarm, a notification will be sent (via a paired app notification, text message, email, or automated phone call) confirming that the user took the associated pill.
3.2.2.3 Backup Data
The option to save the data from the application to a backup location will be added in future releases.
● Input: A user clicks the “Backup” button in the “Security Options” section of the application.
● Output: A file containing the user’s application data is saved locally to the phone and may be exported.
When the user wants to save their pill and schedule information, they may backup their data to a local file that is stored on the phone and may be exported to an external server or device for safekeeping and restorative purposes.
3.2.2.4 Accessibility Features
After several e-mail correspondences, we were able to set up a meeting with Kerry Tate at the Student AccessAbility Department on the 4th of
December. She liked the features implemented so far for the first release of the application, especially the simplicity of design and clarity of content.
She said she was excited about the features we planned to implement for future releases of the application.
She suggested a few features to consider including in future releases of the application including alarm vibration, text-to-speech readouts of alarm text, as well as pill nicknames to identify medication in addition to actual pill names (for example: "the big blue pill" as a nickname for heart medication).
She also said that our application could feasibly widen its scope of users to include children wanting to handle their medications independently,

people with a low level of reading comprehension, people with English as their second language, EMT's and physicians that want to access medications of their patients, people recovering from head injuries, as well as social workers preparing patients for outpatient treatment.
She mentioned that we could widen our scope regarding items added to the customizable schedule. She suggested that we could allow elderly users to take pictures and write descriptions of other items they use daily that aren't medications. For example, an elderly user or a caretaker could take a picture of their hearing aid and include it's location in an entry to be stored by the application. When the elderly user wanted to find their hearing aid, they could open our application and see where it was located.
She urged us to present our application to the Baylor Rehabilitation
Hospital in Dallas, because she believes our application could generate a lot of interest in the industry. She also suggested we try to apply for grants or research opportunities related to our application.
The meeting with Kerry Tate was extremely informative and generated many new ideas for future application features. Although the features discussed at the meeting will not be implemented for the first release of the application, they will be considered for future releases.
3.2.2.5 Security
As new features are added, more security will be needed. We will add a locking feature to lock the medical information portion of the application so that only approved persons can access it.
● Input: Password and User ID
● Output: Access to secure areas of the Application
3.2.2.6 Alarm Ringtone and Vibration
The alarm will be customizable to change the alarm sound or vibration in future releases.
● Input: Custom alarm ringtone and vibration selection
● Output: Custom alarm ringtone and vibration activated when a pill alarm is activated
3.2.3.6 Alarm Service
The alarm service will be able to activate custom pill alarms automatically in future releases.
● Input: Pill information from the customizable schedule, including time to take a pill.

● Output: An audible alarm is activated for a pill is scheduled to be taken.
The current application release can manually activate the alarm screen, but automatic activation using the alarm service is not implemented. An alarm should be activated whenever a pill has been scheduled to be taken.
3.2.2.7 Pill Schedule
A weekly view of pills to take will be displayed on the home screen in future releases.
● Input: Pill picture, time to take the pill, and pill name (from information entered by the user)
● Output: Pill picture, time to take the pill, and pill name will be shown on their appropriate days in a weekly calendar view on the home screen
3.2.3 Implemented Functional Requirements
These are the features that are included in the first release of the application.
3.2.3.1 Create Pill Entry
The Create Pill Entry use case has three parts. The user shall be able to specify the pill name, color, location, and dosage information, as well as provide instructions on what the pill should be taken with. There will also be an option for a picture to be taken of the pill.
Specific pill color, location, and dosage information:
● Input: Pill name, color, location, and dosage information is added by the user to the associated pill.
● Output: Pill name, color, location, and dosage associated with a pill are displayed when an associated alarm screen is activated.
There shall be options to add specific pill information, like name, color, location, and dosage to the schedule that will be shown whenever an alarm associated with a pill is activated.
Instructions on what to take pills with:
● Input: Instructions about how to take the pills correctly (with food, water, etc.) are added by the user to the associated pill.
● Output: Instructions associated with a pill are displayed when an associated alarm is activated.

There shall be options to add specific instructions on how to take a certain pill to the schedule that will be shown whenever an alarm associated with a pill is activated.
Take a Picture of the Pill:
● Input: Picture of the pill is taken at time of creation of pill (or added later)
● Output: Pill picture is displayed when an associated alarm screen is activated.
There shall be an option to take a picture of the specific pill to make identification and location of a pill at the time of the alarm even easier.
3.2.3.2 Pill Schedule
Customizable schedule for multiple kinds of pills:
● Input: When a pill needs to be taken, and what kind of pill needs to be taken, as entered by the user.
● Output: The time a pill needs to be taken and what kind of pill needs to be taken, along with any other associated pill information, shall be displayed when an associated alarm is activated.
A user shall be able to enter multiple pills into the schedule to be taken at multiple times during the day or week.
3.2.3.3 Alarm
Audible alarms that let end-users know when to take their medications.
● Input: Pill information from the customizable schedule
● Output: An audible alarm is manually activated for a pill
The alarm should display the information about a pill entered by the user into the pill schedule.
The current application release can manually activate the alarm screen, but automatic activation using the alarm service is not implemented. For more information about the alarm in future releases, please refer to section 3.2.2 (Future Functional Requirements).
3.2.3.4 Pill Lookup
Pill lookup for pills without bottles
● Input: Information about an unknown pill (name, color, shape, numbers).
● Output: Online search results that most closely match the unknown pill information.

When a pill doesn’t have a bottle, or information about it is missing, a user shall be able to look up a pill based on its name, color, shape, and numbers on the pill. The application shall connect to an online pill database so users can easily identify outdated or unknown medication.
An internet connection is required to use the pill lookup feature.
3.2.3.5 Tutorial
Brief guide to the application
● Input: A user clicks the “About” button on the home screen.
● Output: A tutorial describes the application interface and usage.
When a user wants more information about the application, they can click the “About” button on the home screen to be directed to a simple and clear guide on how to navigate and use the application’s features.

3.2.4 Class Diagram
Figure 2: Class Diagram
This diagram represents associations and dependencies between classes. The solid lines represent the associations between classes, while the dotted lines represent realization
(implementation). The circle represents Interface, and the boxes represent classes.

3.2.5 Sequence Diagram
Figure 3: Sequence Diagram
The sequence diagram shows how the PAL application works internally by calling methods to other classes in order to carry out functions.

3.2.6 Activity Diagram
Figure 4: Activity Diagram
The “Check Alarm” subactivity checks if a pill alarm should be activated, and activates the alarm screen if a pill should be taken. For a more detailed view of what each screen does, please refer to the User Manual (section 4.2).

3.2.7 Non-Functional Requirements
Figure 5: Availability, Compatibility and Affordability NFR Framework Model
3.2.7.1 Availability, Compatibility and Affordability
Availability
Our system needs to be widely available and easily accessible.
■ We will develop it on the Android platform and release it in the Google
Play store.
■ An internet connection is not required to use the main features of the application like pill scheduling and alarms, so the application is available without a live connection.
Compatibility
The system we are developing needs to be compatible with multiple device types.
■ The application will be compatible with both smartphones and tablets.
Affordability
The application we develop must be affordable in order to prevent people who could greatly benefit from the application from refusing to use it based on how expensive it is.
■ We will moderately price the application.

Figure 6: Usability and Aesthetics NFR Framework Model
3.2.7.2 Usability and Aesthetics
Usability
The system interface must be easy to understand and use, and must require a minimum learning curve for a user to navigate the application.
■ All essential application services (view schedule, alarm and confirmations, tutorial) are 0-2 clicks away from the main screen.
■ Advanced services (set schedule, lock application, pill lookup) are 1-3 clicks away from the main screen under “Settings”.
Aesthetics
The system interface must be simple and easy to read for all users.
■ Large fonts and buttons will be used.

Figure 7: Separate Environments NFR Framework Model
3.2.7.3 Separate Environments
These nonfunctional requirements are based on features that will be implemented in future releases of the application. As they are not in the current version, they are marked as denied. For more details, please refer to Future
Functional Requirements (section 3.2.2)
Separate Environments
The advanced pill scheduling part of the application must be separate from the weekly calendar view and alarm functions of the application.
■ We will include a “locking” feature which will prevent accidental changes to the schedule once it is entered.
■ A password will be set by the user for the locking feature
■ Granularity of control will be implemented by a set of locking options

4.1 Prototype Mockup
The prototype screenshots are shown below:

4.2 User Manual
4.2.1 Implemented
The following list includes all screens and features implemented in the current application release:
Home Screen
When you open the application, you will see the Home Screen (Figure 8). The current date, the PAL logo, and two buttons labeled About and Settings are on the home screen.
About
When you tap About , the phone’s internet browser will be opened and you can download a short tutorial about how to use the application.
Settings

When you tap Settings , you will see a screen with a variety of advanced options
(Figure 9). These options include Add A Pill , Change Schedule , Pill Lookup , and Contacts . If you want to return to the Home Screen , tap the Home Screen button.
Add A Pill
When you tap Add A Pill on the Settings screen, you will see a screen with options to add a pill to your pill schedule (Figure 10). You can take a picture of the pill, specify pill name, what time to take the pill, instructions on how to take the pill, and other pill information (including pill location, dosage, and color). If you want to return to the Home Screen , tap the Home Screen button.
Change Schedule
When you tap Change Schedule on the Settings screen, you will see a screen with a list of pills from your pill schedule (Figure 11). When you select a pill to edit, you will see a screen similar to the screen shown on the Add A Pill screen.
You may then edit the pill information and save it. If you want to return to the
Home Screen , tap the Home Screen button.
Pill Lookup
When you tap Pill Lookup on the Settings screen, a pill lookup website will launch in your device’s internet browser. You may enter pill information into the website’s search to look up a pill.
Alarm Screen
When the alarm is manually activated (by tapping the PAL logo), the Alarm
Screen is activated (Figure 12). The alarm screen shows the pill name, current alarm time, a picture of the pill, instructions on how to take the pill, and the location of the pill. To turn off the alarm, you must tap the I took this.
, Can’t find it!
, or the I’m out! button. When the I took this.
button is tapped, you will be asked if you are sure you have taken the pill by a Confirmation Screen . If you confirm the decision (by selecting “Yes”), the confirmed pill will be removed from the alarm screen, and any remaining pills to be taken at the current time will be displayed. If you cancel the confirmation (by selecting “No”), you will be returned to the alarm screen.
Confirmation Screen
When the I took this.
button is tapped on the Alarm Screen , the Confirmation
Screen will be shown (Figure 13). The Confirmation Screen will ask you to confirm the I took this. button decision you made on the Alarm Screen . You may tap the Yes or No buttons to confirm or cancel your previous button decision.
4.2.2 Not Implemented

As seen in Section 3.2.2, there are many features that will be added in future releases of the application. While they are not yet implemented, the following is an idea of what they will look like and what they will accomplish in addition to the implemented features.
Home Screen
The home screen lists the weekly pill schedule, as well as what pills you have scheduled to take today.
Security Options
When you tap Security Options , you will see a screen with option buttons labeled Backup Data , Set Password , and Locking Options . If you want to return to the Home Screen , tap the Home Screen button.
Backup Data
When you tap Backup Data , you will be prompted to choose the location where you would like your data to be backed up to on your device. When you choose a location, the data will be saved to that location on your device. If you want to return to the Home Screen , tap the Home Screen button.
Set Password
When you tap Set Password , you will be prompted to enter and confirm a password to lock the application with. After specifying a password and confirming it, you will be required to enter the password whenever you try to access sections of the application specified in the Locking Options section. If a password is already specified, you will be notified with the message: “There is already a password set. Go to Locking Options to change your settings”. If you want to return to the Home Screen , tap the Home Screen button.
Locking Options
When you tap Locking Options , you will see a screen with checkboxes labeled
Password Active , Lock Home Screen , and Lock Settings . The Password
Active checkbox specifies if a password is currently set for the application. The
Lock Home Screen checkbox specifies if the Home Screen requires a password to access. The Lock Settings checkbox specifies if the Settings screen requires a password to access. By default, Password Active is not checked, Lock Home Screen is not checked, and Lock Settings is checked. If you want to return to the Home Screen , tap the Home Screen button.
Alarm Screen
The alarm service will automatically activate an alarm associated with a pill that needs to be taken at the current time. The alarm will be activated for a maximum of 10 minutes. If the alarm is not turned off within 10 minutes, the pill(s) that the alarm is associated with will be marked as “Not taken” on the weekly calendar on the Home Screen , and the application will return to the Home Screen . If the

Can’t find it! button is selected and confirmed, an automatic notification will be sent to a contact specified previously in the application options. If the I’m out! button is selected and confirmed, and automatic refill request will be made to a pharmacy specified previously in the application options, and an automatic notification will be sent to a contact specified previously in the application options.
For our application, our goal is to guarantee both forward and backwards traceability. For this phase of the project, the traceability is between our domain problems, user requirements, system requirements, design specifications, and coding components.
ID Description Forward
Traceability
Backwards
Traceability
P1 Problems remembering to take medication.
P2 Problems managing multiple mediations.
P3 Problems seeing small graphics on screen.
U1, U2
U1
U4
Meeting 2
Meeting 2
Meeting 3
P4 Problems using complicated technology. U3, U4
P5 Problems with others finding out their medical information U5
ID Description Forward
Traceability
Meeting 3
Meeting 3
Backwards
Traceability
S1, S3, S4 P2 U1 Create pill entry for each medication that stores relevant information
U2 Be alerted when a pill should be taken
U3 Availability
U4 Usability and Aesthetics
S1, S2
S10
P1
P4
S7, S8, S9 P3, P4
S5, S6 P5 U5 Separate Environments/Security
ID Description
S1 Customizable schedule for multiple medications
S2 Alarms that let notify when to take medication
S3 Pill information includes name, color, dosage, location, picture, and instructions on what to take the pill with
S4 Pill lookup for pills without bottles
S5 Backup functionality
S6 Password options
S7 Tutorial
Forward
Traceability
Backwards
Traceability
D1, D3, D4 U1, U2
D4, D7
D3
U2
U1
D5
D6
D6
D9
U1
U5
U5
U4

S8
S9
System must be easy to navigate
System interface must be simple and easy to use.
S1, S2
D1, D2, D3,
D4, D5, D6,
D7, D8, D9
S10 Release the application in the Google Play store for free. Released in
Google Play store for free
ID Description
(all are screens of the application)
D1 Home
U4
U4
U3
Forward
Traceability
C6, C7
Backwards
Traceability
S1, S8, S9
D2 Settings
D3 Add a Pill
D4 Change Schedule
D5 Pill Lookup
D6 Security Options
D7 Alarm
D8 Confirmation
D9 About
ID Description
C5
C2
C4, C8
C10
[Future
Release]
C4
C3, C4
C1
S8, S9
S1, S3, S9
S1, S2, S9
S4, S9
S5, S6, S9
S2, S9
S9
S7, S9
C1 AboutActivity.class
C2 AddPill.class
C3 AlarmMain.class
C4 AlarmService.class
C5 GeneralSettings.class
C6 MainActivity.class
C7 Receiver.class
C8 ListPills.class
Forward
Traceability
Tutorial
Add Pill Screen
Alarm Screen
Manual Alarm
Functionality
Settings Screen D2
Home Screen D1
Running in
Background
D1
Schedule Screen D4
Backwards
Traceability
D9
D3
D7, D8
D4, D7, D8
C9 PalDB.class
C10 Pill database webpage link
Saving Data D6
Link to Pill Lookup D5
For our application, we focus on a specific user group: the elderly. We concentrate on usability and functionality issues that directly affect this user group, and do not sacrifice quality of the application for a larger scope. Some groups implementing similar features to ours have stated

that they aim their application at a large range of users, including vastly different ages and different comfort levels with technology. We feel that even if they were to implement all of the same features that we have, they would suffer from deterioration in the overall quality of the application because of their wide scope. Our team believes that large differences in the users an application is aimed at will result in many people not getting what they want or need out of the application. Elderly users may need larger text and buttons in order for them to be comfortable using an application. Those who are not that technologically savvy will feel alienated by an application that is too complex for them. On the other hand younger users may want more content on the screen at once, and those comfortable with technology will crave more complexity in the application. Teams that make their scope of users too large are unlikely to please everyone. Since our application is focused on a specific user group, we feel that we will be able to make the majority of our users very satisfied with our application. We can efficiently design an application to accommodate our user group very well, instead of trying to cater to interests that may be vastly different.
Similarly, some teams decided to design an application with a suite of features in different categories of aid. While they may be able to implement all of their planned features, they will likely not have the time or resources to implement all of the features with a high amount of quality. It is more plausible that they will do many things OK, instead of doing one thing very well. We believe that by focusing our attention on an application to solve a specific problem we will be able to efficiently alleviate health risks related to pill management.
Finally, we chose to address the problem of pill management because of its health implications.
There are many people who have a complex, confusing pill schedule. And they may not always be able to execute their schedule correctly due to time constraints, lack of organization, or a failing memory. When someone doesn’t take a pill that they need in order to maintain good health, they are putting themselves at risk of harm or death. We felt that the health of the elderly was the most important issue for us to tackle with our application.
References http://www.utdallas.edu/~chung/CS4351/syllabus.htm
Compatibility: The system we are developing needs to be compatible with multiple device types.
Availability: Our system needs to be widely available and easily accessible.
Affordability: The application we develop must be affordable in order to prevent people who could greatly benefit from the application from refusing to use it based on how expensive it is.
Usability: The system interface must be easy to understand and use, and must require a minimum learning curve for a user to navigate the application.
Aesthetics: The system interface must be simple and easy to read for all users.
Separate Environments: The advanced pill scheduling part of the application must be separate from the weekly calendar view and alarm functions of the application.

Creeping Rates
We anticipated a creeping rate of 62.5%, because we were prepared to accommodate changes to five out of eight of our functional requirements. We decided this by dividing our functional requirements into two categories: critical and noncritical. Critical application features are required in order for the application to function correctly. Noncritical application features enhance the application’s scope and usefulness, but are not required for functionality.
The critical (those required for the application to function) features included:
● Custom pill schedule: Needed to manage multiple medications.
● Pill alarm: Needed to remind the user about multiple medications.
● Pill name, color, location, and dosage information: Needed to inform the user about how to identify multiple medications.
The non-critical (those that enhance the application but are not necessary for functionality) features included:
● Instructions on how to take the pills: Redundant information that is also on the pill bottles.
● Feedback services: Additional information provided to and from an outside entity, but not a required function for the critical features of managing and maintaining a pill schedule.
● Pill lookup: Useful for identifying unknown pills, but most pills will already have a bottle, and pill lookup does not directly relate to the critical features.
● Security: Prevents accidental or intentional changes to a set schedule, but not a requirement to satisfy the critical features.
● Tutorial: Helps users find their way around the application, but not needed for the critical features to work.
For the first release of the PAL application we were able to implement most of the non-critical features except for Feedback and Security features (See section 3.2.2 for more detailed information).
We were not able to fully implement the pill alarm critical feature. In the current release, the alarm screen for a pill may be activated manually, but the alarm service does not activate the alarm screen automatically when an associated pill needs to be taken. Time constraints were the main cause of this.
Consequently, we were able to achieve an actual creeping rate of 37.5% because we were able to substantially implement five out of eight features while accommodating changes to three out of eight features. Even though we could not fully implement the automatic pill alarm, we still achieved a better creeping rate than our original estimate of 62.5%.