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



Download 159.36 Kb.
Date01.07.2017
Size159.36 Kb.
#22357

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.


Download 159.36 Kb.

Share with your friends:




The database is protected by copyright ©ininet.org 2024
send message

    Main page