HOPE
HOPE (Helping Our People Easily) Mobile Phone Application System
WRS Document
Phase 2 Final
SE 4351
Section 001
Team Name: Team Awesome
Member’s Name
|
Email Address
|
David Pederson
|
dip091000@utdallas.edu
|
Weston Wofford
|
wbw081000@utdallas.edu
|
Eric Ly
|
eric.ly@utdallas.edu
|
Aakash Patel
|
ahp091020@utdallas.edu
|
Saad Ahmed
|
sxa054100@utdallas.edu
|
Angela Neff
|
aen072000@utdallas.edu
|
Amanda Lim
|
arl092020@utdallas.edu
|
Team Website: https://sites.google.com/site/utdhope001/
Version 2.0 11/29/2011
Table of Contents:
|
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
|
2. Preliminary Definition
2.1 Problem
2.2 Goal
2.3 Domain
2.4 Stakeholders
2.5 Functional Requirements
2.6 Non-functional Requirements
2.7 Use Case Diagram
2.8 Softgoal Interdependency Graph
2.9 Class Diagram
|
3. Issues with Preliminary Definition
3.1 Domain and Stakeholders
3.2 Functional Requirements
3.3 Non-functional Requirements
|
4. Improved Understanding of WRS
4.1 World
4.2 Requirement Specification
4.2.1 Functional Requirements - Improved Understanding
4.2.2 Non-functional Requirements - Improved Understanding
|
5. Traceability
|
A. Appendix
1. Requirements Creeping Rate
2. Our Team
|
1. Introduction
1.1 Purpose
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.
1.2 Scope
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.
1.3 Definitions, Acronyms, and Abbreviations
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/
2. HOPE (Helping Our People Easily): Preliminary Definition
2.1 Problem
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.
2.3 The Domain
The following is a summary of the domain requirements.
S.NO
|
Requirements Specification
|
Forward Traceability
|
DR1
|
Due to worsened eyesight, font cannot be too small
|
WF2
|
DR2
|
People with hearing loss need an alternate way to get information
|
WF3
|
DR3
|
People with memory loss must be able to use the program to aid them in remembering medication, food allergies, names, etc.
|
WF4
|
DR4
|
For those with speaking problems, a text to speech generator is needed.
|
WF5
|
DR5
|
Lack of experience with technology necessitates intuitive use.
|
WF1
|
2.4 Stakeholders
The elderly and their assistants will be the stake holders. This device will be used by both groups as it will help each other.
Elderly
-
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.
2.5 Software System Requirements: Functional Requirements
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 following is a summary of the non-functional requirements.
S. No.
|
Requirements Specification
|
Forward Traceability
|
NFR1
|
Icons shall be large so that they are clearly visible, with no more than 6 icons at a time.
|
NFR001
|
NFR2
|
Buttons shall be spaced out far enough so that the user does not accidentally press the wrong button.
|
NFR002
|
NFR3
|
Texts shall be large enough so that elderly people can read without difficulty.
|
NFR003
|
NFR4
|
The reminder alerts shall be loud enough for the user to hear without being annoying.
|
NFR005, NFR006
|
NFR5
|
Icons shall contain pictures of people and places so that the user can relate then with people and locations they are already familiar with.
|
NFR004, NFR007
|
NFR6
|
The entire system shall be easy to use with very little learning curve, so that people with memory problems can still use it as easily.
|
NFR008
|
NFR7
|
The user shall be able to use the camera and picture functions without knowledge of how the camera works.
|
NFR009
|
NFR8
|
The emergency app shall contain all the relevant information in a clear and organized fashion so that both the user and the medical staff can find them.
|
NFR010
|
NFR9
|
The emergency call button shall have a confirmation step to prevent accidental calling of emergency services.
|
NFR011
|
NFR10
|
The number of of clicks to navigate shall be kept to a minimum.
|
NFR012
|
NFR11
|
The user shall be able to search for names, medical records or other information all from one search tool.
|
NFR013
|
2.7 Use Case Diagram
2.8 Softgoal Interdependency Graph
2.9 Class Diagram
3. Issues with Preliminary Definition
3.1 Issues with Domain and Stakeholders
1.1 The elderly might not know how to use the application.
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.
Options:
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.
1.2 Trying to incorporate too many requirement objectives vs. the time constraint
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.
Options:
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.
3.2 Issues with Software System Requirements: Functional Requirements
2.1 The reminder system needs a method to notify the user.
Options:
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.
2.2 The user does not acknowledge that the reminder alarm has gone off.
The user doesn’t hear or is not near the device when the alarm goes off.
Options:
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.
2.3 User receives a phone call while using the Hope system
Options:
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.
2.4 While creating a new sentence from the sentence helper, the user notices that there is no category for the new sentence being created.
Options:
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.
2.5 The option for the user to take a picture of the medicine is not specific enough. Pictures of pill bottles all look the same; “picture of medicine” should be clearly defined.
Options:
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.
2.6 User is confused as to why the 911 feature is convenient when their phone has the ability to call 911 easily.
Options:
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.
3.3 Issues with Software System Non-Functional Requirements
3.1 Visuals such as icons and text should be large enough, but this is vague. Also there needs to be a clear and readable font and icons.
Decision and rationale
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.
3.2 Sounds that the user will hear
Options:
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.
4. Improved Understanding of WRS
4.1 World
The following table summarizes the updated world requirements with improved understanding.
S.NO
|
Requirements Specification
|
Backward Traceability
|
WF1
|
Due to lack of knowledge (unfamiliar with smart phones or handheld devices), elderly people might not be able to properly navigate the application or get the full benefit of the services provided.
|
DR5
|
WF2
|
As some people may have impaired eyesight, the application should not use small font sizes that are difficult to read.
|
DR1
|
WF3
|
People with hearing loss may not be able to hear ringtones, or other alarms. Thus, an alternate method of communicating with the user is needed.
|
DR2
|
WF4
|
People with memory loss must be able to use the program to aid them in remembering medication, food allergies, names, locations, and other important items.
|
DR3
|
WF5
|
For those with speaking problems (ie. the inability to effectively communicate important ideas or messages), a text to speech generator is needed.
|
DR4
|
4.2 Requirement Specification
4.2.1 Functional Requirements - Improved Understanding
The following table summarizes the updated functional requirements with improved understanding.
S. No
|
Requirements Specification
|
Backward Traceability
|
FR001
|
Allow for users to navigate through categories to select a sentence that they cannot write or speak themselves.
|
FR1
|
FR002
|
Allows for a selected sentence to be displaced or messaged to a care giver.
|
FR2
|
FR003
|
If a sentence is used often, if will be put in a special “Commonly used sentences” for quick and easy selection
|
FR3
|
FR004
|
If the category for a sentence does not exist he user can select for the sentence to be in the category labeled “Other”
|
FR4
|
FR005
|
A search function shall allow users to use keywords to quickly search for sentences containing those keywords.
|
FR5
|
FR006
|
For fast access to medical information concerning health, pills, insurance, etc. a button should be available on the home screen.
|
FR6
|
FR007
|
Users can place calls to 911 or care giver.
|
FR7
|
FR008
|
A reminder system is placed to remind the user of doctor appointments and when to take medicine.
|
FR8
|
FR009
|
The user can take a picture of medicine for a reminder so they know which medicine to take.
|
FR9
|
FR010
|
Allow users to take a picture of a specific pill in order to remember which medicine to take.
|
FR9
|
FR011
|
The reminder system shall play a sound and display a push notification that will need to be dismissed.
|
FR8
|
FR012
|
if the push notification is not dismissed within 5 to 10 minutes, depending on user preference, the alarm will resound.
|
FR8
|
FR013
|
If a call occurs while in the H.O.P.E. system let the call take over and then return to the H.O.P.E. system at the conclusion of the call.
|
FR10
|
4.2.2 Non-functional Requirements - Improved Understanding
The following table summarizes the updated non-functional requirements with improved understanding.
S. No
|
Requirements Specification
|
Backward Traceability
|
NFR001
|
Icons should be large so that they are clearly visible, with no more than 8 (6 was too restrictive and unnecessary) icons per screen.
|
NFR1
|
NFR002
|
Buttons should spaced out so that the user will not accidentally press the wrong button.
|
NFR2
|
NFR003
|
Text should be in a large, readable font.
|
NFR3
|
NFR004
|
Icons should have simple images that are easy to understand.
|
NFR5
|
NFR005
|
Alerts should be loud enough for users with hearing impairments to hear.
|
NFR4
|
NFR006
|
Alerts should be pleasing, not annoying.
|
NFR4
|
NFR007
|
Icons should be pictures of people and places the user is familiar with so they can relate them.
|
NFR5
|
NFR008
|
The system should be easy to use so that people with memory problems can learn the system with relative ease.
|
NFR6
|
NFR009
|
The camera should be easy to use, such that the user does not have to know how the camera works to use it.
|
NFR7
|
NFR010
|
The emergency application should contain all relevant information to the health and identity of the user, in a clear and organized manner.
|
NFR8
|
NFR011
|
The “Emergency Call” button should have a confirmation step to prevent accidental calling of emergency services.
|
NFR9
|
NFR012
|
The number of clicks to navigate the application should be kept to a minimum.
|
NFR10
|
NFR013
|
The user should be able to search for names, medical records, or other information all from one search tool.
|
NFR11
|
5. Traceability
|
DR1
|
DR2
|
DR3
|
DR4
|
DR5
|
FR1
|
X
|
X
|
|
|
X
|
FR2
|
X
|
X
|
|
X
|
|
FR3
|
|
|
X
|
|
X
|
FR4
|
|
|
|
|
X
|
FR5
|
|
|
|
|
X
|
FR6
|
X
|
|
X
|
|
|
FR7
|
|
|
X
|
|
X
|
FR8
|
X
|
|
X
|
|
|
FR9
|
|
|
X
|
|
|
NFR1
|
|
X
|
|
|
|
NFR2
|
|
|
|
|
X
|
NFR3
|
|
X
|
|
|
|
NFR4
|
|
X
|
X
|
|
|
NFR5
|
|
|
X
|
|
|
NFR6
|
|
|
X
|
|
X
|
NFR7
|
|
|
X
|
|
X
|
NFR8
|
X
|
|
X
|
|
|
NFR9
|
|
|
X
|
|
X
|
NFR10
|
|
|
|
|
X
|
NFR11
|
X
|
|
X
|
|
|
A. Appendix
1. Requirement Creeping Rate
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.
2. Our Team’s Reasoning for Best 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.
Share with your friends: |