HOPE Helping Our People Easily Phase I - Interim Team KRAFT.

Slides:



Advertisements
Similar presentations
Ease of Access and Assistive Technology on Windows 7 Computer Access for Individuals with Visual Impairments.
Advertisements

Chapter 11 Designing the User Interface
Information technology solutions development Fundamentals of Information Technology Session 3.
The University of Texas at Dallasutdallas.eduThe University of Texas at Dallasutdallas.edu.
Software Modeling SWE5441 Lecture 3 Eng. Mohammed Timraz
1 CS 501 Spring 2002 CS 501: Software Engineering Lecture 11 Designing for Usability I.
The Design Process Engineering Graphics Dr. Stephen Crown.
System Requirements Specification INSTRUCTOR : Dr. LAWRENCE CHUNG
Alternate Software Development Methodologies
Final Presentation Team Crutch. Agenda Process – Justin Vision Document Issues Use Case Diagram Domain Diagram SIG Prototype Why Team Crutch?
Requirements Specification
Inspection Methods. Inspection methods Heuristic evaluation Guidelines review Consistency inspections Standards inspections Features inspection Cognitive.
Requirements Engineering Processes
COMP 350: Object Oriented Analysis and Design Lecture 2
1 CMPT 275 Software Engineering Requirements Analysis Process Janice Regan,
Chapter 13: Designing the User Interface
Marbles Your Name. Project Phase 1 System Requirements Specification Instructor:Dr. Lawrence Chung Teaching Assistant:Rutvij Mehta Subject:Advanced Requirement.
CS 235: User Interface Design August 27 Class Meeting Department of Computer Science San Jose State University Fall 2014 Instructor: Ron Mak
TEAM NAME : ANDROMEDA Instructor: Prof. Dr. Lawrence Chung.
Team Crutch. Vision Statement Team crutch aims to develop portable, inexpensive, user-friendly software for the Android platform that mitigates communication.
By: HelpSoft9 Allen Helton, Chris Mudd, Aaron Jacobs, Jeff Allain, Jessi Cardoso, Matthew Jacobs, Prerak Patel, Richard Vanderdys, Saurav Shrestha.
Chapter 4 – Requirements Engineering
COMM1PCOMM1P Alan Woolrych Accessibility 9 COMM1P9COMM1P9 SCET MSc EC/ECA © Alan Woolrych 2001 Introduction Accessibility “Making Content Available to.
Demystifying the Business Analysis Body of Knowledge Central Iowa IIBA Chapter December 7, 2005.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
Ann White Keyboarding for Kindergarten As children are learning their letters, they can also learn recognition of those letters on the keyboard and learn.
IT Requirements Management Balancing Needs and Expectations.
May05-36: Boone Cemetery Management Software Boone Cemetery Management Software May05-36 Greg Thede, Director, Boone Parks Department Dr. Kothari Joseph.
SEG3120 User Interfaces Design and Implementation
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Screen design Week - 7. Emphasis in Human-Computer Interaction Usability in Software Engineering Usability in Software Engineering User Interface User.
Team Think For You. Outline  Introduction  Process  Requirements Engineering  Architecture  Detailed Design  Testing  Demo  Extensibility  Conclusions.
IS2210: Systems Analysis and Systems Design and Change Twitter:
Requirements Reference: Chapters 5, 6, & 8. CMSC 345, Fall Objectives To introduce the concepts of user and system requirements To explain functional.
© Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
Requirements Collection By Dr. Gabriel. Requirements A requirement is any function, constraint, or property that the system must provide, meet, or satisfy.
Systems Analysis and Design in a Changing World, Fourth Edition
1 Software Requirements l Specifying system functionality and constraints l Chapters 5 and 6 ++
Chapter 4 Software Requirements
CS 5150 Software Engineering Lecture 7 Requirements 1.
SOFTWARE ARCHITECTURE FOR A KWIC SYSTEM TEAM: GLOBAL 14.
Requirements Engineering Requirements Engineering in Agile Methods Lecture-28.
Mobile AAC Application for Sentence Creation Team Members: Kevin Greene, Christina Fries, Wei Liao, Hien Huynh, Jiho Kim, Apoorva Dewangan Mentor: James.
NEW REQUIREMENTS New requirements – American Sign Language – Recently Generated Sentences Issues with Requirements Options for Implementation Choice and.
Requirements Analysis
Mobile AAC Application for Sentence Creation Team Members: Kevin Greene, Christina Fries, Wei Liao, Hien Huynh, Jiho Kim, Apoorva Dewangan Mentor: James.
ANALYSIS PHASE OF BUSINESS SYSTEM DEVELOPMENT METHODOLOGY.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 13 Usability 1.
Interface Types and Models Dr. Dania Bilal IS 588 Spring 2008.
Requirements in the product life cycle Chapter 7.
Aaron Jacobs, Allen Helton, Chris Mudd, Jeff Allain, Jessi Cardoso, Matthew Jacobs, Prerak Patel, Richard Vanderdys, Saurav Shrestha.
ASSISTIVE TECHNOLOGY Mitchell Johnston. Many students within our classrooms have difficulties with reading, writing, and /or math. While other students.
Bridging the Generation Gap Through Stories Aro Muttilainen Oliphant Sammander Sen.
| Mobile Accessibility Development Making an Accessible App Usable Scott McCormack.
Assistive Technology for Students with Exceptionalities Joseph Davis.
 System Requirement Specification and System Planning.
Jake Terranova Stefan Howansky Dr. Jean F. Coppola Seidenberg School of CSIS Pace University.
2 |2 | Overview of the presentation What is disability? What is the global situation for persons with disabilities? What is accessibility? What is ICT.
CMPE 280 Web UI Design and Development August 29 Class Meeting
Computer Aided Software Engineering (CASE)
CSC480 Software Engineering
Successful Website Accessibility Testing
UNIT II.
Communication Disability
Requirements Analysis
Software life cycle models
CS/SE ADVANCED SOFTWARE ARCHITECTURE AND DESIGN FALL 2015
Presentation transcript:

HOPE Helping Our People Easily Phase I - Interim Team KRAFT

Vision We aim to develop a mobile, inexpensive, user-friendly application that mitigates communication barriers for the communication disabled while being aesthetically pleasing and discrete in public use.

Agenda Introduction Process & Team Organization Requirements Engineering Traceability Prototype To be done Our Strengths

Introduction The Problem Elderly people tend to have hearing, speech, vision, and memory disabilities o Communication difficulties o Lack of independence  frustration and seclusion Who’s Affected? o People with hearing, speech, vision, and memory disabilities o Assistive persons o Family members o …

Introduction Traditional Aids o Costly, bulky, and difficult to use Our Solution o Focus on user needs o Simple interface and navigation o Balanced and unique set of features o Mobile application for Android

Stakeholders Users o Elderly o Assistive person Customer Kraft o Requirements Engineers o Project/Product Manager o Developers o QA & Testing

Our Process Software Development Process – Customized Spiral Model with two iterations – 1.x and 2.x – Interleaving, Iterative (Agile) and Incremental – Fluid Teams (RE, Arch + Implementation, Testing, QA & Documentation) IterationActivities Phase I Assign members to fluid teams Problem + Domain analysis Drafting WRS + Surveys + User Manual Creating Prototype Phase II Shuffling members of fluid teams Improved understanding + updating WRS Development Testing

Our Process Key Features: (Re)planning Role Play WBS – Work Breakdown Structure SVN SDM-Systematic Design and Management Issue(s) Identification Issue(s) Resolution Tradeoff Analysis

Our Process

Domain Requirement: Source exerpt – A1: As people get older, they tend to experience difficulties with hearing, speaking, vision and memory loss, and muscle weakness. – A3 : go beyond the current realm of AAC to identify all the physical and mental disorders – A6 : expands from the initial definition of AAC which is to deal with speech disorder, and take consideration the speech, hearing, memory and/or vision impairment up to varying degrees. – A8 : In the application domain, the communication typically consists of: An elderly with speech, hearing, vision and/or memory loss.

Domain Requirement: Source exerpt – A10: An assistive person is one that is either a disabled person or a non- disabled person with whom the user wants to communicate. – A12: In a typical scenario, people uses visual aids like pictures and icons and text and/or speech to communicate a message to the elderly having hearing loss and a weak memory – A21: The purpose of HOPE is to provide a platform for helping the elderly, the disabled – having unclear speech, hearing loss, weak vision and/or memory loss

Domain Requirement: Issue Issue : No clear definition of type of “disabilities” to tackle Options How to select disabilities to tackle – O1. base on project deadlines – O2. base on technical feasibility – O3. base on the similarity of disorders. – O4. base on the most frequent disabilities the elderly population suffers from. Vision Hearing Speech Muscular Memory

Domain Requirement DR1 The system will be used by people that suffer from communication disabilities who have been alphabetized. The disabilities that the system addresses are defined below: hearing disabilities speech disabilities memory disabilities vision disabilities

FR Source excerpt from A19: “Just like the elderly user, the system should be easily usable by the assistive person, e.g. by providing a good search interface through which that person need not know the entire system and can bring up any part by just visiting the search page. “ Issue 9: What defines a “good” search interface? Options O1. “Google-like” search O2. Search with auto-completion O3. Search by complete words O4. Search by incomplete words O5. Search stored sentences O6. Search using voice recognition based on Google API

FR Choice and Rationale O3 O5 O6

FR: I  O FR 2: The system shall provide a search interface to allow users to retrieve: Favorite sentences Built-in common greetings Recently generated sentences Individual vocabulary items FR 2.1 The search feature shall be reachable from anywhere in the system. FR 2.2 The search input shall be converted from the recognized voice of the user. FR 2.3 Search results shall be returned in a scrollable list format containing an image and a text description of a sentence or vocabulary item for search result. FR 2.4 When the user clicks on a search result item, the system shall speak the item description out loud. I: a vocal input O: a list of search results showing image and description

NFR Source excerpt : “The system should be quickly understandable (the learning time should be very low) and very easy to use “ Issue I25: The system should be quickly understandable Description: What is meant by understandable ? Understandable is Ambiguous here. Options: O1. Text is easy to read O2. Low learning curve O3. Visual aids should have a minimal specified resolution (e.g., not blurry) O4. The user should be able to learn how to use the application in 2 weeks, using it 3 hours a day. Choice: O1, O2, O3.

Issue with the choices Issue I25.1: Text is easy to read. Description: What functional features shall realize “easy to read”. Options: O1. Choose contrasting colors O2. Choose a large icon size O3. Choose a large text size Choice: O1,O2,O3

Issue with the choices Issue I25.2: Low learning curve. Description: What functional features shall realize “Low learning curve”. Options: O1. One touch help shortcut O2. User manual written in non-technical language O3. Icons with descriptive text O4. Provide technical support O5. Interactive tutorial built-in the application Choice: O1,O2,O3

To be done Expand upon our issues and our rationale Finalize prototype concerns Prioritizing our requirements Update our domain model Verify our traceability matrix Complete product user manual

Why chose us? Dedicated to addressing user needs Focused on delivering the best product User-friendly Unique features Market Insight Consistently working with our clients Always considering new approaches Committed to the quality of our process