Team CrutchTeam Crutch

Vision StatementVision Statement

Team crutch aims to develop Team crutch aims to develop portable, portable, inexpensive,inexpensive,user-friendly user-friendly

software for the Android platform software for the Android platform that mitigates communication that mitigates communication barriers for the communication barriers for the communication disabled.disabled.

AgendaAgenda

DomainDomain Functional RequirementsFunctional Requirements Non-Functional RequirementsNon-Functional Requirements PrototypePrototype Project StatusProject Status Why Team Crutch?Why Team Crutch?

AgendaAgenda

DomainDomain Functional RequirementsFunctional Requirements Non-Functional RequirementsNon-Functional Requirements PrototypePrototype Project StatusProject Status Why Team Crutch?Why Team Crutch?

DomainDomain

1. Disability Definition1. Disability Definition

Issue – Type/Extent of disability Issue – Type/Extent of disability not not specified specified

Decision – System will Decision – System will accommodate speech, hearing, vision accommodate speech, hearing, vision loss, motor difficulties, memory issues, loss, motor difficulties, memory issues, reading disabilitiesreading disabilities

DomainDomain

2. Assistive Person2. Assistive Person

Issue – Whether assistive Issue – Whether assistive person will use device directly not person will use device directly not statedstated

Decision – Assistive person only Decision – Assistive person only participates in initial set-up of the participates in initial set-up of the systemsystem

DomainDomain

3. Generation/Age Assumption3. Generation/Age Assumption

Issue – “Elderly users” is an Issue – “Elderly users” is an ambiguous and limiting qualification.ambiguous and limiting qualification.

Decision – The system will Decision – The system will accommodate any user with a accommodate any user with a disability, regardless of age and disability, regardless of age and technical knowledge. technical knowledge.

AgendaAgenda

Domain Domain

Functional Functional RequirementsRequirements

Non-Functional RequirementsNon-Functional Requirements PrototypePrototype Project StatusProject Status Why Team Crutch?Why Team Crutch?

Functional RequirementsFunctional Requirements

1. Home Screen1. Home Screen

Issue – Home screen categories Issue – Home screen categories not specifiednot specified

Decision – Speak, Emergency, Decision – Speak, Emergency, Favorites, Contacts, Me, Favorites, Contacts, Me, Everything About Me are the Everything About Me are the Home Screen categoriesHome Screen categories

Functional RequirementsFunctional Requirements

2. Emergency2. Emergency

Issue – Types of emergencies not Issue – Types of emergencies not addressedaddressed

Decision – Medical, fire, and Decision – Medical, fire, and police emergencies accommodatedpolice emergencies accommodated

Functional RequirementsFunctional Requirements

3. Text To Speech3. Text To Speech

Issue – How meaning is given to Issue – How meaning is given to icons not addressedicons not addressed

Decision – Text labels provided Decision – Text labels provided below each icon, audio provided for below each icon, audio provided for icon after performing 1-second long icon after performing 1-second long presspress

Functional RequirementsFunctional Requirements

4. Icon Size4. Icon SizeIssue – Icon sizes supported not Issue – Icon sizes supported not

addressedaddressed

Decision – Decision – - 6 category buttons per - 6 category buttons per

screenscreen- All buttons take up 3/4 of - All buttons take up 3/4 of

total total screenscreen

AgendaAgenda

Domain Domain Functional RequirementsFunctional Requirements

Non-Functional Non-Functional RequirementsRequirements

PrototypePrototype Project StatusProject Status Why Team Crutch?Why Team Crutch?

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.

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.

Non-Functional Requirements

3. Vocabulary

Issue - “Intuitive and clear vocabulary” is not clearly defined.

Decision – To avoid confusion, only formal English will be supported.

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.

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.

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.

AgendaAgenda

Domain Domain Functional RequirementsFunctional Requirements Non-Functional RequirementsNon-Functional Requirements

PrototypePrototype Project StatusProject Status Why Team Crutch?Why Team Crutch?

PrototypePrototype

AgendaAgenda

Domain Domain Functional RequirementsFunctional Requirements Non-Functional RequirementsNon-Functional Requirements PrototypePrototype

Project StatusProject Status Why Team Crutch?Why Team Crutch?

What has been doneWhat has been done

-Developed initial Process Plan-Developed initial Process Plan

-Identified Issues in Preliminary -Identified Issues in Preliminary Requirements DefinitionRequirements Definition

-Developed initial draft of Improved -Developed initial draft of Improved UnderstandingUnderstanding-Developed interactive mock-upDeveloped interactive mock-up

What remains to be doneWhat remains to be done

1. Traceability matrix1. Traceability matrix

2. Operationalize NFR to FR2. Operationalize NFR to FR

3. Further validation of requirements3. Further validation of requirements

At this point some validation was At this point some validation was completedcompleted with 4 individuals with 4 individuals ranging in age ~73 to 93 ranging in age ~73 to 93 years old years old (caretakers & elderly). Input was (caretakers & elderly). Input was incorporated.incorporated.

What remains to be doneWhat remains to be done

4. Identify more NFRs.4. Identify more NFRs.

5. Define lists for vocabulary and 5. Define lists for vocabulary and categoriescategories

6. Extend prototype6. Extend prototype

7. UML diagrams7. UML diagrams

8. 8. ImplementImplement our programs our programs accordingaccording to to class diagramclass diagram

25% Creeping Rate25% Creeping Rate

AgendaAgenda

Domain Domain Functional RequirementsFunctional Requirements Non-Functional RequirementsNon-Functional Requirements PrototypePrototype Project StatusProject Status

Why Team Crutch?Why Team Crutch?

Why Team Crutch?Why Team Crutch?

Difference is KeyDifference is Key Customer orientedCustomer oriented

Communication disabledCommunication disabled ElderlyElderly

Simple Interface = UsableSimple Interface = Usable Big IconsBig Icons

Descriptive Icons and TextDescriptive Icons and Text

http://www.proloquo2go.com/About/article/iphone-http://www.proloquo2go.com/About/article/iphone-and-ipod-touchand-ipod-touch

Why Team Crutch?Why Team Crutch?

Emphasis: RequirementsEmphasis: Requirements

Quick PrototypeQuick Prototype

Validation + Requirements = Validation + Requirements =

Questions?Questions?