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 Domain Functional Requirements Functional Requirements Non-Functional Requirements Non-Functional Requirements Prototype Prototype Project Status Project Status Why Team Crutch? Why Team Crutch?

4. Agenda Domain Domain Functional Requirements Functional Requirements Non-Functional Requirements Non-Functional Requirements Prototype Prototype Project Status Project Status Why Team Crutch? 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 Domain Functional Requirements Functional Requirements Non-Functional Requirements Non-Functional Requirements Prototype Prototype Project Status Project Status Why Team Crutch? 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 Domain Functional Requirements Functional Requirements Non-Functional Requirements Non-Functional Requirements Prototype Prototype Project Status Project Status Why Team Crutch? 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 Domain Functional Requirements Functional Requirements Non-Functional Requirements Non-Functional Requirements Prototype Prototype Project Status Project Status Why Team Crutch? Why Team Crutch?

21. Prototype

22. Agenda Domain Domain Functional Requirements Functional Requirements Non-Functional Requirements Non-Functional Requirements Prototype Prototype Project Status Project Status Why Team Crutch? 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 Domain Functional Requirements Functional Requirements Non-Functional Requirements Non-Functional Requirements Prototype Prototype Project Status Project Status Why Team Crutch? Why Team Crutch?

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

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

29. Questions?