Hope (Helping Our People Easily) Mobile Phone Application System wrs document Phase 2 Final se 4351 Section 001 Team Name: Team Awesome

Version 2.0 11/29/2011

The purpose of this project is to help people that have difficulties with hearing, vision, speech impairment, and memory loss. In the past, devices such as hearing aids have been designed and implemented by Augmentative and Alternative Communications (AAC). However, this technology proves to be costly. Our goal is to provide our customers with an all encompassing solution, thus integrating all these features into a single device. The key to our success lies in the recent advent of mobile devices with their sophisticated software and hardware capabilities. Our project will focus on using the Android platform for smart phones. This system will be implemented on a mobile device which consists of a helpful user interface containing icons, pictures, sounds, speech and text understood universally by smart phone users.

This project in this document is an application for the Android mobile phone system with the goal of helping elderly people with problems in memory or communication. This is specifically targeted at the smart phone audience due to the rising popularity of smart phones, particularly the Android OS. Smart phones allow a broad range of capability, allowing our system to utilize many tools that otherwise may not be available. Additionally, the range of applications available for Android means that the user will not need to purchase additional devices for added functionality; they merely have to add more applications onto their phone.

Android: a mobile phone platform

Assistive person: caretaker or assistant who helps the elderly

Elderly: elderly people who might use the HOPE System to aid with memory and communication needs

HOPE: Help Our People Easily

1.4 References

1. Requirement Engineering –Advanced Requirement Engineering. CS/SE 4351, Section 001, Fall 2011. http://www.utdallas.edu/~chung/CS4351/syllabus.htm

2. WRS.docx http://www.utdallas.edu/~chung/RE/ Presentations10F/supernova/

3. 2 - WRS.pdf http://www.utdallas.edu/~chung/RE/Presentations10F/Team-hope/

The HOPE system was thought of in response to the fact that the elderly face many challenges as they get older with things such as speech, hearing, vision, and/or memory loss. These individuals often require the assistance of others to help them communicate and complete day-to-day tasks. Some of these tasks could include, eating, taking a bath, walking, and using the restroom. When they struggle with communication it can sometimes be difficult to let the person helping them understand what they would like. Aside from everyday task there is also a need for everyday greetings and communication, along with recreational activities such as watching television.

The elderly are also prone to suffering from memory loss. This can be a problem for those who require daily medicine or frequent doctors visits. They could face problems of forgetting their medicine all together, forgetting whether they already took it, or not knowing which medicine they need to take at a certain time. These types of problems can cause severe health issues.

2.2 Goal

We aim to aid those with unclear speech and memory loss, who often require outside assistance with the completion of tasks. Our system will be able to aid these individuals by providing essential features to enhance their ability to deal with these issues in their daily lives. These features include the ability to display sentences to the screen of the phone, or to message these sentences to a primary caregiver, an alarm system that can remind the user when to take a certain medicine and when a doctor appointment is soon. The program also includes an emergency contact ability, where a help message can be sent to the caregiver, or the user can easily dial 911 for an emergency. This area also contains emergency medical information, such as allergies, medications, etc. for easy access.

The following is a summary of the domain requirements.

The elderly and their assistants will be the stake holders. This device will be used by both groups as it will help each other.

• 
  This device will mostly benefit the elderly as it would help them communicate with their assistants to help them with their needs. It will also help them for memory related issues.
  

Assistants

• 
  To better help the elderly, the assistants can use the device to understand what they need or give them information.
  

The purpose of our HOPE system is to provide a platform for helping the elderly that are having unclear speech and memory loss problems, in day-to-day communication. This platform shall

assist the users in their communication by use of a sentence helper, search utility, emergency contact tool, and a reminder system.
The following is a summary of the functional requirements.

S. No	Requirements Specification	Forward Traceability
FR1	Allow for users to navigate through categories to select a sentence that they cannot write.	FR001
FR2	Allows for a selected sentence to be displayed or messaged to a care giver.	FR002
FR3	If a sentence is used often, if will be put in a special “Commonly used sentences” for quick and easy selection	FR003
FR4	If a sentence does not exist, the user can add a sentence to a category.	FR004
FR5	A quick find of sentences containing keywords should be found via a search function.	FR005
FR6	For fast medical information concerning health, pills, insurance, etc. are available from a button on the home screen.	FR006
FR7	User can place calls to 911 or to the care giver.	FR007
FR8	A reminder system is placed to remind the user of doctor appointments and when to make medicine.	FR008, FR011, FR012
FR9	The user can take a picture of medicine for a reminder so they know which medicine to take.	FR009, FR010
FR10	Allow the phone’s dominant functions to operate in priority over the H.O.P.E. system.	FR013

2.6 Software System Requirements: Non-Functional Requirements

The system must be usable by the elderly and their assistants. Particular concerns include vision, hearing, memory loss, and usability.

The elderly often have poor knowledge of technology and how to use it. If the user is an elderly person then he/she might not be able to properly use the application.

1. Have a very simple user interface so it is as elderly friendly as possible.

2. Have a tutorial program

Decision and rationale:

We chose option 1 because a tutorial program relies in the fact that the user will have good memory and can recall and apply what he/she learnt before. Accessing the tutorial program every time the user wants to do something is not feasible.

When trying to gather the functional and non-functional requirements we tend to try to include every possible functionality that we can think of, but doing so we run the risk of not meeting the deadline.

1. Include every function that we can think of and submit the assignment late

2. Build a more focused application with limited but only the most important set of features

Decision and rationale:

We decided to chose option 2 and include only the most important set of features. This will allow us to build a very robust application, as we will have more time for testing and fixing errors. The rationality of this approach is as we stated above, there is always a finite amount of time and we won’t be able to implement every functionality that we can think of. This is consistent with out philosophy of keeping things simple and manageable.

1. An alarm will go off and a popup will appear to confirm that that user has acknowledged the alarm.

2. Just a popup will appear to notify the user.

Decision and rationale

1 would be the best choice. The user may not notice a popup without sound. Thus it would be better for an alarm to go off to draw the users attention.

The user doesn’t hear or is not near the device when the alarm goes off.

1. The alarm could go off every five or ten minutes after the first alarm until the user acknowledge the alarm.

2. The alarm could continually go off until the user acknowledges the alarm.

Decision and rationale

1 would be the best choice. This would be less annoying to people besides the user and it would save battery life on the service device.

1. Let the phone’s call application take over until the call is finished and return to the Hope system.

2. Prohibit phone calls while using the Hope system.

Decision and rationale

1 would be the best choice. Phone calls are the primary function of smart phones thus our application should not halt such an event, as it may be important to the user.

1. Let the user make a new category.

2. Have the user put the new sentence in a the “Other” category.

Decision and rationale

2 would be the best choice. The chance that the user will need a whole new category is small. Granted that their new category may only have that one new sentence. Thus to keep the user from creating too many categories, the new sentence will go into “Other” if it fits no category.

1. Change requirement wording to reflect the option of using any picture for each medicine.

2. Allow user to take picture of the specific pill in order to remember which medicine to take.

Decision and rationale

The requirement wording should be changed so that the user can take a picture of anything such as the pill itself.

1. Leave 911 feature in the system.

2. Take out 911 call feature in the system.

Decision and rationale

1 would be the best choice. This is because if the user is already in our system they can access 911 call easier than having to back out of the application and calling 911.

The text shall not be a font that isn’t readable, such as Joker. The default font can be Time news roman, and the device can give other font options. The icons will have a clear and simple image that will represent the function, so nothing fancy and complicated.

1. Use sounds that are loud and piercing.

2. Use sounds that are loud and pleasing.

Decision and rationale

Option 1 would not be recommended as piercing sounds would be annoying, such as police sirens and air horns, and it might deafen users. So option 2 is the best however, there will need to be a range of sounds as some sounds maybe pleasing to some and annoying to others.

The following table summarizes the updated world requirements with improved understanding.

The following table summarizes the updated functional requirements with improved understanding.

The following table summarizes the updated non-functional requirements with improved understanding.

We can handle a changing rate of up to 10% total of change to any requirements. Our team is smaller than most at only 7 members, so we do not have as many resources available to handle incoming requirements and the changes that would have to be implemented in the project.

Our team is a focused team. Instead of trying to implement a large number of features in our launch program, we are focusing on a few key features centered towards speech impaired individuals. By focusing on these key features, our team will be able to fine tune the features needed and have a market ready app by the end of the semester.

• 
  Our group put in an intense effort to make the HOPE system easy to use for both elderly people and caregivers.
  
• 
  We utilized the spiral model to allow team members to slowly build the system, layering functions in order to better provide a stable system.
  
• 
  We focused on ensuring that all requirements, both functional and non-functional, were achieved to the best of the group’s ability.