Google Glass Virtual Memory App Requirements



Download 110.92 Kb.
Page3/3
Date conversion08.07.2018
Size110.92 Kb.
1   2   3

2.3 Organizational boundaries and interfaces


This project will not have additional resources, so we are limited to current resources. The abilities of each individual, as well as the research material available online regarding Google Glass development are the extent of the resources utilized.

2.4 Project responsibilities


Each resource is required to take meeting notes at least once.

Each resource is required to participate in presentations.

Each resource is required to provide content in a timely manner.

3. Managerial Process

3.1 Management objectives and priorities


Our group is developing the requirements for a Google Glass application from the perspective of UTD graduate students. We have an interest in the varying applications Google Glass has the ability to service. One we have chosen at this time is to focus on dementia and Alzheimer’s patients. Our project scope is therefore limited to this one application, with few resources and time devoted to this project since each member of the team is a employed during the day and have other academic commitments.

Varying business needs are addressed by our application. For the doctor the application provides a treatment option which is of tangible value to their patients. The doctor is able to offer a treatment option to retain the patient as a client. The hospital or clinic/practice associated with the doctor is distinguished in its market by providing the latest technology in difficult to treat neurological condition.


3.2 Assumptions, dependencies, and constraint


Once developed, the real world application will reside on the Google Glass platform. Basic functionality already covered by Google Glass platform will not be addressed. Google Glass hardware and software platform requirements are also a constraint. We assume the technology described in Google’s requirements exists, or will be in place before needed in production.

3.3 Risk management


Timeline and scope creep are always project risks. A competitor app may come to market first. A competitor app may come to market with a richer set of features more appealing to either the doctor or the patient. Google Glass hardware and/or software requirements may change, requiring extensive rework of our designs.

Additionally our team my suffer the loss of team members and/or wasted resources on requirements which do not ultimately benefit the project.


3.4 Monitoring and controlling mechanisms


We will address timeline and scope creep with a strict timeline of team defined deliverables and regular weekly meetings; or as needed.

3.5 Division of work


  • Who is the end user – individuals with early onset of dementia and alz., still in their personal home. Family members help to integrate them into the capabilities of GG.

  • Engineering requirements

    • Hardware – Dylan/Ben

      • Functional – uses the phone (android?) to serve up data/net

      • Non-functional

    • Software – Ben/Dylan

      • Functional – apps to help you find common objects

      • Non-functional

    • Support - Randi

    • Maintenance - Randi

  • Marking requirements - Nik

  • Sales requirements - Nik

4. Technical process

4.1 Methods, tools, and techniques


  • MS Office Suite, including Word, PowerPoint, Visio, Excel

  • Communications we are using Facebook, email, Dropbox

  • PMI project management methodology including all phases of SDLC

  • RE-Tools requirements modeling toolkit 

  • Wix.com webpage design and hosting

4.2 Software documentation


To be done in MS Word, and Adobe PDF.

4.3 Project support functions


We will consult the Alzheimer's Foundation - alzfdn.org‎ to get their requirements and endorsement.

5. Work elements, schedule, and budget

5.1 The domain


The domain of our application is limited to the software and hardware platforms established by Google for their Google Glass project. An android smartphone communicates with Google Glass, and provides real-time connectivity to the cellular data network. Our application is downloaded onto the Android smartphone from the Google Play application store, and services Google Glass with an assistive technology for the wearer. The family or caregiver customizes the app via the Android smartphone to meet the unique needs of the patient. The environment of the patent is all-inclusive of the real-world, ranging from a care-facility on one extreme with limited range of activities, to active individuals still engaged with relative degrees of independence.

5.2. Stakeholders


The stakeholders for the Virtual Memory app are presenter below.


Who

Expected Skill Level

Why Virtual Memory App?

Patient suffering from early on-set Alzheimer’s

Familiarity with smartphones. Concept of virtual/augmented reality a plus.

Provide a supplement to daily life to minimize effects of disease.

Spouse, Partner of patient

Familiarity with smartphones.

Experience benefits of patient’s ability to be more self-sufficient and consistent to traditional behavior. Provide input to application to customize it to the patient’s needs.

Professional caregiver

Familiarity with care for those affected by neurological degenerative diseases.

Monitor patient for the management of symptoms, calibration of application.

Doctor

Familiarity with neurological degenerative diseases, and various forms of treatment and care management.

Monitor patient for the management of symptoms, calibration of application.

Insurance

Familiarity with benefits of technological aided disease management

Few other treatment options exist for the management of Alzheimer’s.




5.3 Non-functional objectives


The non-functional objectives are to provide a stable usable and secure application that can interface to Google Glass. Another important non-functional objective is to make the application easy to use for older less tech savvy users.


5.4 Functional objectives


The functional objectives would be broken down into two general areas:

Patient care management

Medical History and medication information repositories

Insurance and provider information repositories

Family and close friends & caregiver bios including photos and voice recordings

Patient assist



Personalized reminders for appointments and medication etc.


5.5 Schedule


Phase 1 Purpose: Develop Prototype for UAT

Week

Phase Name

Comment

1

Planning and Discovery

Initial project planning, project scope and charter

2-4

Detailed Design

Requirements design, WRS

5-6

Build and Unit Testing

Software development of basic functionality for proof of concept

7

Business and User Acceptance Testing (UAT)

Limited UAT to 20 participants and their care givers. Participants required to be at very early stages of diminished capacity, able to provide feedback.

8-12

Interviews/Feedback Sessions

One on one interviews conducted with each participant and with each care giver. Feedback categorized into expectations, requirements, nice to have, ease of use, functionality


Phase 2 Deliverable: Version 1

Week

Phase Name

Comment

13-14

Planning and Discovery

Following interview session, that information is used to develop more detailed requirements.

15-16

Detailed Design 1




17-18

Build and Unit Testing 1




20

Business and User Acceptance Testing 1 (UAT)

Identification of low risk/high value updates to increase usability of existing functionality.

21

Detailed Design 2




22

Build and Unit Testing 2




23

Business and User Acceptance Testing 2 (UAT)




24

Detailed Design 3

Bug Fixes Only – No New Functionality

25

Build and Unit Testing 3

Testing, Any issues identified will categorized as critical to stop go-live or for the next release

26

Business and User Acceptance Testing 3 (UAT)

Testing, Any issues identified will categorized as critical to stop go-live or for the next release.

Focus on user and training modules



27

Cut-over and Training

Training for sales and medical professionals

28

Post Cut-over Support

Cut-over delivery to sales and medical professional

5.6 Budget


There is no budget for the requirements project. We are poor grad students.

If we approach Google, they may choose to invest significantly in our project

We need to identify at least 3 issues we encountered with our overarching design requirements. We wanted to do X, BUT, and then list the issues encountered and how addressed.

Show criteria, pluses/minuses, how we reached our final decision to handle this requirement issue.


5.7 Creeping Requirements


Nutrition information presented to the patient. Alzheimer’s as with any disease, including neurological conditions, is affected by the health of the dependent range of nutrition the affected organ (the brain) receives. A diet high in saturated fat is detrimental to the blood supply of the brain received from the cranial arteries. Our team decided an additional benefit of our application will be to allow the caregiver of the patient to input foods the patient shall be encouraged to eat by the application, and those which should be reduced or avoided entirely. The addition of this requirement to the application in a future version will provide benefit to

  • Show Justification why our requirements are better. Can we make the change requested and why yes/no

  • The ability to delete appointments

6. Requirements Specification

6.1 Non-functional Requirements Specifications


The Non Functional Requirements for Visual Memory application are divided into the following categories:

  1. Compatibility

    1. The software shall be compatible with the Android version 4.03 and above

    2. The software shall be compatible with the Google MyGlass app.

    3. The web portions of the software shall be compatible with Google Chrome (version 27 or higher), MS Internet Explorer (version 9 or higher), and Firefox (version 22 or higher).

  2. Availability

    1. The software shall be available for download from GooglePlay store.

  3. Usability

    1. The software shall be easily operated by those with minimal computer skills.

    2. The software functions shall be accessible through both the smart phone app, tablet app, and the web portal.

    3. The GUI application interface shall be easily navigable for inexperienced users.

    4. The GUI application interface shall be configurable with a zoom magnification of not less than 200%.




  1. Performance

    1. The software error handling shall notify the user of an error once it is identified.

    2. The software shall have an error rate of less than 5%.

    3. The software shall respond near instantaneous to the user’s inputs.

    4. The software shall respond to 100% of its notifications.

    5. The software shall not drop or miss notifications when battery life is available.

    6. The software shall request ratings from the end user to collect APMs.

  2. Integrity

5.1 The master database shall be kept on the website but shall be fully accessible from the smart phone.

    1. All updates shall be controlled by the website. The smart phone shall request an update but the confirmation and control of updates shall remain with the website.

  1. Security

    1. The smart phone software shall not allow any unsolicited update requests.

    2. Access to website will require a unique userid/password combination.

  2. Maintainability

    1. The software shall be well documented and follow good design practices to facilitate ease of maintainability.

    2. The software code shall follow standard good programming practices for code comments

    3. The software shall be written in a commonly used programming language that is suitable for the Android platform.



6.2. Software System: Functional Requirements


The Functional Requirements for Visual Memory are divided into the following seven functional categories:

  1. Visual Memory Application

    1. Upon initialization, the application will require the user to create a username and password and supply an email address.

    2. The application shall require authentication through the activation link sent to the user’s email.

    3. The application shall notify the user of the Visual Memory website and the personal fact sheet.

    4. The home screen of the application will have icons to access the Schedule, Family, Recordings, Provider, Medication, History, and Insurance.

    5. The application shall allow for the user to quickly return to the home page.

    6. The application shall allow for uploading photos from the user’s Android phone or tablet.

  2. Schedule

    1. The schedule menu shall be accessible as its own icon from the main menu via a picture icon and text indicating schedule.

    2. The schedule shall allow for synchronization between the schedule app, the medication app, the recordings app, the family app, and the Visual Memory website calendar.

    3. The schedule shall display all of the user’s appointments.

    4. The schedule shall allow the user to select what format to display the appointments.

    5. The schedule shall provide a warning if a scheduling conflict exists.

    6. The schedule shall allow the user to create appointments.

    7. The appointment shall allow the user to specify the subject of the appointment.

    8. The appointment shall allow the user to specify the location of the appointment.

    9. The appointment shall allow the user to specify the start date of the appointment.

    10. The appointment shall allow the user to specify the end date of the appointment.

    11. The appointment shall allow the user to specify the start time of the appointment in hours and minutes (increments of 5) and AM or PM.

    12. The appointment shall allow the user to specify the end time of the appointment in hours and minutes (increments of 5) and AM or PM.

    13. The appointment shall allow the user to place notes in the appointment.

    14. The appointment shall allow the user to set a reminder alarm.

    15. The appointment shall allow the user to select a notification time for the reminder, subject to the following options: At time of event, 5 minutes before, 15 minutes before, 30 minutes before, 1 hour before, 2 hours before, 1 day before, 2 days before.

    16. The appointment shall allow the user to customize the reminder alarm.

    17. The reminder alarm shall allow the user to attach a photo from the family bio storage and retrieval app.

    18. The reminder alarm shall allow the user to attach a recording from the audio capture app.

    19. The reminder alarm shall allow the user to select the display interface for Google Glass: text only, text and audio, text and custom audio, text and photo, text audio and photo, text custom audio and photo.

    20. The appointment shall allow the user to set future reoccurrences.

    21. Future reoccurrences shall provide the following sections: every day, every week, every 2 weeks, every month, or every year.

    22. The user shall be able to select the calendar display for all appointments as a List, Daily, Weekly, or Monthly view.

    23. The schedule shall allow users to interface with it on an Android phone or tablet, or via the Visual Memory website.

    24. The schedule shall allow users to modify or edit the fields of an existing appointment.

    25. The schedule shall allow users to delete appointments.

    26. The software shall be updateable.

    27. The calendar shall allow registration online from nxw111230.wix.com/semgoogleglass

    28. The software shall expose data to standard RESTful API calls.

  3. Family(Ben)

    1. The family app shall be accessible from the main menu as its own icon and text indicating family.

    2. The software shall provide the ability for the user to input the following information:

Name of person

Photo of person

Familial relation (or friendship context)

Audio recording of person’s voice



    1. The software shall expose data to standard RESTful API calls.

    2. The software shall respond to queries based on a person’s name to retrieve selected information.

    3. The software shall allow for retrieval of any part or all of the biographical data

    4. The software shall provide an interface that shall allow the user to browse through the database for purposes of familiarizing the user with the people in the database.

  1. Recordings

    1. The recordings menu shall be accessible the main menu as its own icon and text indicating recording.

    2. The software shall provide an interface for the user to record audio input to a maximum length of 10 seconds per recording.

    3. The software shall require an id tag for the person whose audio is recorded for purposes of tracking the recording in the system.

    4. The software shall provide a mechanism to delete or modify existing recordings

    5. The software shall provide a mechanism for retrieval and playback of recordings based on the key of the unique personal id of the person whose voice is recorded.

  1. Provider

    1. The provider menu shall be accessible from the main menu via a picture icon and text indicating Provider.

    2. The software shall provide the ability for the user to input the following information:

Provider name

Office address

Office hours

Office phone#

Emergency phone#

Specialty



    1. The software shall provide the ability for the user to enter appointment dates and times for any provider in the provider list.

    2. All data in the provider software shall be exposed to the calendar software.

    3. All data in the provider software shall be exposed using standard RESTful API calls.

  1. Medication

    1. The medication menu shall be accessible from the main menu via a picture icon and text indicating medication.

    2. The interface shall provide the ability for the user to input the following information:

Medication name

Dosage


Frequency taken

Preferred time(s) of day to take

Pill count per prescription

# refills

Prescribing doctor

Cost


    1. The software shall calculate the number of pills left in the prescription based on the pill count, frequency taken and number of prescriptions left and shall communicate with calendar software to issue an alert to get prescription refilled two weeks prior to the calculated date that prescription would be fully consumed.

    2. The software shall communicate with calendar software to issue reminders to take medication based on the preferred time of day entry for each medication in the database.

    3. All prescription data shall be exposed via standard RESTful API calls.

  1. History

    1. The history menu shall be accessible from the main menu via a picture icon and text indicating history.

    2. The interface shall provide the ability for the user to input the following information:

Diagnosed diseases

Recorded surgeries

Medication allergies

Food or other allergies

Immunization records


    1. All medical history data shall be exposed to standard RESTful API calls.

  1. Insurance

    1. The insurance menu shall be accessible from the main menu via a picture icon and text indicating insurance.

    2. The software shall provide the ability for the user to input the following information

Insurance carrier name

Type of insurance (medical/dental/vision etc)

Group #

Member #


Phone # for providers

Phone # for members



Claims processing address

    1. All insurance carrier data shall be exposed to standard RESTful API calls.

  1. Interface Requirements (Glassware to smart phone APP) (Dylan)

    1. Glassware will allow wireless tethering to the user’s Android phone or tablet via WIFI or Blue Tooth 4.0+

    2. Glassware shall utilize the Google Mirror API and appropriate RESTful calls as the access to the Glass operating system.

    3. The calendar Glassware shall display reminder alarms and notifications from the Visual Memory application.

    4. The calendar Glassware shall allow for text reminders/notifications.

    5. The calendar Glassware shall allow for audio reminders/notifications.

    6. The calendar Glassware shall allow for photo reminders/notifications.

    7. The calendar Glassware shall display the subject, time, and location as default for reminders/notifications from the Visual Memory application scheduled appointment.

    8. The calendar Glassware shall display reminder alarms per the user’s interface selection: text only, text and audio, text and custom audio, text and photo, text audio and photo, text custom audio and photo.

  2. Website (Dylan)

    1. The website shall allow for synchronization between the Visual Memory application

    2. The website shall allow for inputting calendar appointments, family biographical information, and medical records including provider information, medication, medical history, and insurance information.

    3. The website shall provide links to Alzheimer’s support and information for caregivers.

    4. The website shall provide a personal fact sheet.




1   2   3


The database is protected by copyright ©dentisty.org 2016
send message

    Main page