Team Awesome hope

Download 96.48 Kb.

Date	25.06.2017
Size	96.48 Kb.
	#21788

Team Awesome

HOPE	Version: 1.0
Vision	Date: 28/Nov/11

HOPE

Vision Document

Final Phase

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/

Revision History

Date	Version	Description	Author
05/Nov/11	1.0	created document	Amanda Lim
26/Nov/11	1.0	edited for final phase	Amanda Lim

Table of Contents

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

1.4 References

2. Positioning

2.1 Business Opportunity

2.2 Problem Statement

2.3 Product Position Statement

3. Stakeholder and User Descriptions

3.1 Market Demographics

3.2 Stakeholder Summary

3.3 User Summary

3.4 User Environment

3.5 Stakeholder Profiles

3.6 User Profiles

3.7 Key Stakeholder or User Needs

3.8 Alternatives and Competition

4. Product Overview

4.1 Product Perspective

4.2 Summary of Capabilities

4.3 Assumptions and Dependencies

4.4 Cost and Pricing

4.5 Licensing and Installation

5. Product Features

5.1. Sentence Generator

5.2. Emergency Contact

5.3. Alarms

5.4. Medical Information

6. Constraints

7. Quality Ranges

8. Precedence and Priority

9. Other Product Requirements

9.1 Applicable Standards

9.2 System Requirements

9.3 Performance Requirements

9.4 Environmental Requirement
10. Documentation Requirements

10.1 User Manual

Vision

1. Introduction

1.1 Purpose

The purpose of this document is to collect, analyze, and define high-level needs and features of the HOPE Android system. It focuses on the capabilities needed by the stakeholders and the target users, and why these needs exist. The details of how the HOPE System fulfills these needs are detailed in the use-case and supplementary specifications.

1.2 Scope

This Vision document applies to the HOPE System which will be developed by Team Awesome as an Android application for mobile phones. The HOPE System provides a sentence generator, alarm system, and emergency contact features.The system supports phones that use the Android platform.

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

TBD

2. Positioning

2.1 Business Opportunity

The business opportunities for this HOPE project are aimed mainly towards nursing homes, hospitals, retirement homes, and anywhere elder people are needing care.

2.2 Problem Statement

The problem of	The amount of care-taking and amount of assistance needed for elder people with medical problems and other various problems associated with elder age
affects	Elder people, family members, caretakers
the impact of which is	Difficulty and time which is required for care-taking elder people and overall well-being of elder person
a successful solution would be	A simple, yet effective mobile application that can used by an elder which can provide assistance to an elder person, which can not necessarily replace, however make the job of care-takers/nurses/family members much easier. The application will have reminders, emergency alerts, and various ways of communicating important messages to the elder person.

2.3 Product Position Statement

For	Elder people, nursing homes, hospitals
Who	require assistance, daily functionality help, reminding
Helping Our People Easily (H.O.P.E.) Application	mobile application
That	Gives elder people a means of having critical information communicated to them, communicate and make their day to day lives easier
Unlike	Complicated mobile applications which are not user friendly and make organizing and remembering more complicated for elders
Our product	A simple mobile application that can used by an elder which would provide assistance to an elder person, which would make the day to day life of an elder simpler.. The application will have reminders, emergency alerts, and various ways of communicating important messages to the elder person

3. Stakeholder and User Descriptions

3.1 Market Demographics

The key market demographic is elderly people, presumably over the age of 60, that have some sort of disability in the at least one of the areas: vision, speech, hearing, or memory loss. These individuals are looking for some sort of assistance to compensate for these disabilities to help in their every day lives. Along with the elderly needing assistance those assisting them will also be a part of the market demographic. There are many individuals over the age of 60 that would benefit from and have access to the H.O.P.E. system. These individuals can spend thousands of dollars on aides and services in order to assist them such as hearing aides or other expensive technology systems. At this point in time because of the baby boomers more and more people are reaching the age to where they will start to need these type of services. The technology industry is becoming more and more mobile and accessible to everyone. Our organization is new to the market but are working to become familiar with the market and industry. We would like to be well received within the market and that people will be pleased with the product we are providing. Being that our goal is to assist those with disabilities and make their day to day lives easier, our product helps meet that goal by providing a way to communicate with others either for social reasons or for assistance, and help remember important dates, appointments, and to take appropriate medications at the correct times.

3.2 Stakeholder Summary

System Analyst	This stakeholder works with the other stakeholders to gather information about their needs.	Is in charge of gathering requirements and use-case modeling the different functions of the system. Identifies what actors exist and how they will interact with the system.
Requirements Specifier	This stakeholder works with the System Analyst to translate the needs and requests in to requirements that will be used in the design.	Specifies the details of the functionality of the system by providing details about the requirements, including functional and non-functional.
Technical Reviewer	This stakeholder maintains the development cycle.	Is responsible for reviewing the technical process and providing feedback within a timely manner.
Software Architect	This stakeholder is the leader of software development.	Responsible for the architecture of the software design. This includes technical decisions, implementation, and overall constraints. Responsible for making sure the system will fulfill all functional and non-functional requirements and that it is maintainable.
Project Manager	This stakeholder is in charge of the overall software development.	Responsible for determining priorities, deciding how resources will be allocated and used, initiating interactions with the users and customers, and managing the development team. Also determining the practices used to make sure a quality product is developed.
Market Analyst	This stakeholder makes sure that the product is marketed correctly.	Responsible for making sure there is an actual market for the product and that there is a demand for a product with the features and services it provides.

3.3 User Summary

Elderly Person	Primary end user of the system.	Inputs necessary information into the program. Use for communication and assistance with memory. Also use emergency services.	Self.
Caregiver	End user of the system.	Help elderly person install, set up, and input information as needed.	Self.

3.4 User Environment

Each task is designed to be able to be completed by the elderly person on their own. If necessary though the caregiver will be able to assist them in the tasks. How long each tasks takes to complete depends on the person using the device and what they are trying to do. The tasks are designed to take as few steps as possible to increase the speed of completion. As long as the device is on and working the H.O.P.E. system will be functional. The H.O.P.E. system is currently running on the latest Android Mobile Operating System and any future updates. The system only uses native Android applications.

3.5 Stakeholder Profiles

Elderly Person

Representative
Description	A private individual that will use the system for assistance with every day tasks.
Type	This person is a casual user, with some experience with using a smart phone or a beginner with no experience.
Responsibilities	Ensure that all the services and aides are provided for the typical elderly person with disabilities.
Success Criteria	Success is defined by the customer continuing to use the system.
Involvement	There will be sample customers to evalutae the system in order to help guide the vision.
Deliverables
Comments / Issues

Caregiver

Representative
Description	A private individual that will use the system as needed to assist the elderly person.
Type	This person is a casual user, with some experience with using a smart phone or a beginner with no experience.
Responsibilities	Ensure that all the services and aides are provided for the typical elderly person with disabilities.
Success Criteria	Success is defined by the customer continuing to use the system.
Involvement	There will be sample customers to evaluate the system in order to help guide the vision.
Deliverables
Comments / Issues

3.6 User Profiles

See previous section.

3.7 Key Stakeholder or User Needs

Need	Priority	Concerns	Current Solution	Proposed Solutions
Easy to use.	High	Elderly people might not have a lot of experience with smart phones. In addition if it is diffiuclt to use then the less helpful it becomes.	None	Provide a user friendly, simple, and straightforward system.
Responsive	High	In order for the system to be effective it must respond in a timely manner otherwise the system will not be helpful. Also, if the emergency call service is not responsive it could be too late.	None	Keep the design simple so that the run time stays fast and the system does not get bogged down. Also keep as few steps as possible for each task.

3.8 Alternatives and Competition

Apple IPhone’s Siri.
Other HOPE groups.

4. Product Overview

4.1. Product Perspective

4.2 Summary of Capabilities

Customer Benefit	Supporting Features
Customers can help themselves, lowering support costs and improving response time.	Allowing the User to message a caregiver sentences or requests for support , allows for the user to have indepentance.
Remember events easily.	The user can set alarms to memory events.
Medical staff have quick access to user health information.	The user’s medical information is stored in the system.
Ease of use.	The system has a simple to use GUI interface that has a small learning curve.

4.3 Assumptions and Dependencies

1. The customer knows how to use a touch screen application.

2. The customer has some understanding of how a smart phone works, even if just a small portion.

3. The customer knows how to search for applications and can find the application in the Android Market Place.

4. The customer knows English and can navigate with that knowledge.

4.4 Cost and Pricing

TBD

4.5 Licensing and Installation

The licensing will be dependent on the cost and pricing. The installation and maintenance will be handled by the Android Market Place by the customer.

5. Product Features

5.1. Sentence Generator

5.2. Emergency Contact

5.3. Alarms

5.4. Medical Information

6. Constraints

1. Performance

System should respond to user input within 1 second.

2. Usability

Simple interface.

The 9-1-1 screen should be accessible from any other screen within the application.

3. Capacity

The maximum number of predefined sentences shall be (50).

The maximum number of user-generated sentences shall be (1000).

7. Quality Ranges

7.1 Performance

The system should respond between 0.5 seconds and 1 second.

Performance should not degrade as storage increases.
7.2 Usability

New users should be able to learn the system, on average, between 2 to 5 hours.

8. Precedence and Priority

Precedence	Feature
High	Sentence Generator
Medium	Alarms, Emergency Contact
Low	911 Calling

9. Other Product Requirements

9.1 Applicable Requirements

9.1.1. The cell phone must to be an Android platform.

9.2 System Requirements

9.2.1. The cell phone must come with a camera.

9.2.2. The cell phone must come with speakers.

9.2.3. The cell phone must be touch-screen

9.2.4. The phone’s screen must be large and clear enough to support the icons and text.

9.3 Performance Requirements

1. Photos should be opened within 5 seconds.

2. The time between the sound created after a click of an icon should be less than 1 second.

3. The audio should output within 1 second.

4. The audio should not output faster than 100 words per minute.

5. The font size should be in the range of 12 to 30.

6. The alarms should go off within 2 seconds.

7. Emergency calls should be made within 10 seconds.

9.4 Environmental Requirements

None specified.

10. Documentation Requirements

10.1 User Manual

A short user manual will be provided with the application. Please see the user manual document

for more information.

Confidential

Team Awesome, 2011

Page

Directory: ~chung -> CS4351 -> Presentations11F -> Team-Awesome
CS4351 -> Hope (Helping Old People Easily) Phone Application System Preliminary Project Plan (Phase 0) se 4351 Section 001 Team Name: HelpSoft 9
~chung -> Editor Version Comment
Team-Awesome -> Hope (Helping Our People Easily) Mobile Phone Application System wrs document Phase 2 Final se 4351 Section 001 Team Name: Team Awesome
Team-Awesome -> Hope (Helping Our People Easily) Mobile Phone Application System Software Project Management Plan Phase 2 Final se 4351 Section 001 Team Name: Team Awesome
Team-Awesome -> Hope (Helping Our People Easily) Mobile Phone Application System Final Phase se 4351 Section 001 Team Name: Team Awesome

Download 96.48 Kb.

Share with your friends:

Team Awesome hope

5.1. Sentence Generator

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

1.4 References

2. Positioning

2.1 Business Opportunity

2.2 Problem Statement

2.3 Product Position Statement

3. Stakeholder and User Descriptions

3.1 Market Demographics

3.2 Stakeholder Summary

Requirements Specifier

This stakeholder works with the System Analyst to translate the needs and requests in to requirements that will be used in the design.

Specifies the details of the functionality of the system by providing details about the requirements, including functional and non-functional.

Technical Reviewer

This stakeholder maintains the development cycle.

Is responsible for reviewing the technical process and providing feedback within a timely manner.

Software Architect

This stakeholder is the leader of software development.

Responsible for the architecture of the software design. This includes technical decisions, implementation, and overall constraints. Responsible for making sure the system will fulfill all functional and non-functional requirements and that it is maintainable.

Project Manager

This stakeholder is in charge of the overall software development.

Responsible for determining priorities, deciding how resources will be allocated and used, initiating interactions with the users and customers, and managing the development team. Also determining the practices used to make sure a quality product is developed.

Market Analyst

This stakeholder makes sure that the product is marketed correctly.

Responsible for making sure there is an actual market for the product and that there is a demand for a product with the features and services it provides.

3.3 User Summary

3.4 User Environment

3.5 Stakeholder Profiles

Elderly Person

Caregiver

3.6 User Profiles

3.7 Key Stakeholder or User Needs

3.8 Alternatives and Competition

Apple IPhone’s Siri.

Other HOPE groups.

4. Product Overview

4.1. Product Perspective

4.2 Summary of Capabilities

4.3 Assumptions and Dependencies

1. The customer knows how to use a touch screen application.

4.4 Cost and Pricing

4.5 Licensing and Installation

5. Product Features

5.1. Sentence Generator

6. Constraints

7. Quality Ranges

8. Precedence and Priority

9. Other Product Requirements

9.1 Applicable Requirements

9.2 System Requirements

9.3 Performance Requirements

9.4 Environmental Requirements

10. Documentation Requirements

10.1 User Manual

A short user manual will be provided with the application. Please see the user manual document

for more information.