1 / 29

Team Crutch

Team Crutch. Vision Statement. Team crutch aims to develop portable, inexpensive, user-friendly software for the Android platform that mitigates communication barriers for the communication disabled. Agenda. Domain Functional Requirements Non-Functional Requirements Prototype

friese
Télécharger la présentation

Team Crutch

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Team Crutch

  2. Vision Statement Team crutch aims to develop portable, inexpensive, user-friendly software for the Android platform that mitigates communication barriers for the communication disabled.

  3. Agenda Domain Functional Requirements Non-Functional Requirements Prototype Project Status Why Team Crutch?

  4. Agenda Domain Functional Requirements Non-Functional Requirements Prototype Project Status Why Team Crutch?

  5. Domain 1. Disability Definition Issue – Type/Extent of disability not specified Decision – System will accommodate speech, hearing, vision loss, motor difficulties, memory issues, reading disabilities

  6. Domain 2. Assistive Person Issue – Whether assistive person will use device directly not stated Decision – Assistive person only participates in initial set-up of the system

  7. Domain 3. Generation/Age Assumption Issue – “Elderly users” is an ambiguous and limiting qualification. Decision – The system will accommodate any user with a disability, regardless of age and technical knowledge.

  8. Agenda Domain Functional Requirements Non-Functional Requirements Prototype Project Status Why Team Crutch?

  9. Functional Requirements 1. Home Screen Issue – Home screen categories not specified Decision – Speak, Emergency, Favorites, Contacts, Me, Everything About Me are the Home Screen categories

  10. Functional Requirements 2. Emergency Issue – Types of emergencies not addressed Decision – Medical, fire, and police emergencies accommodated

  11. Functional Requirements 3. Text To Speech Issue – How meaning is given to icons not addressed Decision – Text labels provided below each icon, audio provided for icon after performing 1-second long press

  12. Functional Requirements 4. Icon Size Issue – Icon sizes supported not addressed Decision – - 6 category buttons per screen - All buttons take up 3/4 of total screen

  13. Agenda Domain Functional Requirements Non-Functional Requirements Prototype Project Status Why Team Crutch?

  14. Non-Functional Requirements 1. Usability Issue - “Usability” is not clearly defined. Decision - “Usability” will be defined as a measure of how intuitive the system is; the system needs to be easy to use.

  15. Non-Functional Requirements 2. Quick-to-learn Issue - “Quick-to-learn” is not clearly defined. Decision – If the user can understand the system within ten minutes, the system will be considered quick-to-learn.

  16. Non-Functional Requirements 3. Vocabulary Issue - “Intuitive and clear vocabulary” is not clearly defined. Decision – To avoid confusion, only formal English will be supported.

  17. Non-Functional Requirements 4. Navigability Issue - “Navigation should be seamless and evident to all users” is not clearly defined. Decision – Because the Android UI is becoming commonplace, an interface with a similar functionality will be easy to understand.

  18. Non-Functional Requirements 5. Accuracy of Emergency Calls Issue – How is “accuracy” defined in the context of emergency calls? Decision - “Accuracy” when performing an emergency call is dependent on the ease and precision of choosing the appropriate authorities.

  19. Non-Functional Requirements 6. Extensibility Issue – What types of variations should the system be able to accommodate? Decision – The system should accommodate changes to language, users, hardware, visual elements, or changes to the code.

  20. Agenda Domain Functional Requirements Non-Functional Requirements Prototype Project Status Why Team Crutch?

  21. Prototype

  22. Agenda Domain Functional Requirements Non-Functional Requirements Prototype Project Status Why Team Crutch?

  23. What has been done -Developed initial Process Plan -Identified Issues in Preliminary Requirements Definition -Developed initial draft of Improved Understanding • Developed interactive mock-up

  24. What remains to be done 1. Traceability matrix 2. Operationalize NFR to FR 3. Further validation of requirements At this point some validation was completed with 4 individuals ranging in age ~73 to 93 years old (caretakers & elderly). Input was incorporated.

  25. What remains to be done 4. Identify more NFRs. 5. Define lists for vocabulary and categories 6. Extend prototype 7. UML diagrams 8. Implement our programs according to class diagram 25% Creeping Rate

  26. Agenda Domain Functional Requirements Non-Functional Requirements Prototype Project Status Why Team Crutch?

  27. Why Team Crutch? • Difference is Key • Customer oriented • Communication disabled • Elderly • Simple Interface = Usable • Big Icons • Descriptive Icons and Text http://www.proloquo2go.com/About/article/iphone-and-ipod-touch

  28. Why Team Crutch? Emphasis: Requirements Quick Prototype Validation + Requirements =

  29. Questions?

More Related