TEAM NAME : ANDROMEDA Instructor: Prof. Dr. Lawrence Chung

Aarthi Giridharan (lead) Balaji Shanmugam Govindarajan Panneerselvam Kumaran Senapathy Neha Malloli Sriram Sridharan Vignesh Swaminathan

System Requirements Specification – Synopsis  Project Outline  Requirement Engineering Process  Problems & Proposed Solutions  Requirement Analysis  Writing Specifications  Model Development  Future Enhancements

 There is need for devices to help the speech, hearing and vision impaired.  Devices currently developed by Augmentative and Alternative Communication (AAC) are bulky to handle and are not multi-functional.  A mobile communication device is the best option to use as a Single tool to serve as a multi-functional help device.  All the day-to-day needs could be communicated to the one who is helping by using just one device

 A classic approach definition to an “all-in-one” solution where the user need not depend on any other device but the mobile phone to meet most of the basic needs.  Drastically reducing the level of dependency on a third person as many of the services are available in a pocket device.  Developing user friendly application to support features like emergency contacts, speed dialing, drug reminders, speech recognition, profiles, etc.

 Designing comprehensible GUI helps the users to access any of the applications with a just a click or touch on the main screen.  Implementing HOPE on a smart phone that uses the ANDROID platform to run these applications with the help of other JAVA based applications.  Developing HOPE applications with the ultimate goal of meeting the need of an elderly person who might require assistance in times of emergency.

 Analyze the essential requirements for the project development and discussing with the other co-developers.  Build the deliverables.  Check for correctness and completeness in the deliverables.  Before final submission, review and check the deliverables.

PhaseDeliverableStart DateEnd Date Phase 0 PRELIMINARY PROJECT PLAN Jan 24, 2012Jan 25, 2012 Phase 1 INTERIM PROJECT 1  REQUIREMENT SPECIFICATION  REQUIREMENT ANALYSIS  PRESENTATION Jan 27, 2012Feb 29, 2012 Phase 1 FINAL PROJECT 1  IMPROVED REQUIREMENT SPECIFICATION  IMPROVED REQUIREMENT ANALYSIS  PRESENTATION Mar 02, 2012Mar 26, 2012 Phase 2 INTERIM PROJECT 2  IMPROVED REQUIREMENT SPECIFICATION/ANALYSIS  IMPLEMENTATION  TESTING  PRESENTATION Mar 28, 2012Apr 16, 2012 Phase 2 FINAL PROJECT 2  MODIFIED IMPLEMENTATION  MODIFIED TESTING  PRESENTATION Apr 18, 2012Apr 30,2012

PhaseDeliverableDevelopersReviewers PHASE 0SOFTWARE PROJECT MANAGEMENT PLAN KUMARAN BALAJI GOVINDARAJAN AARTHI PHASE 1REQUIREMENTS SPECIFICATIONSRIRAM VIGNESH NEHA BALAJI PHASE 1ANALYSIS MODELBALAJI AARTHI KUMARAN SRIRAM PHASE 2CODEAARTHI BALAJI GOVINDARAJAN KUMARAN NEHA SRIRAM VIGNESH VIGNESH, NEHA PHASE 2SYSTEM TESTKUMARAN SRIRAM NEHA GOVINDARAJAN PHASE 2USER DOCUMENTATIONBALAJI VIGNESH GOVINDARAJAN KUMARAN

PHASEMANAGEMENT FUNCTIONAL DUTY RESPONSIBLE PRELIMINARY PROJECT PLAN GOVINDARAJANDOCUMENTATION GOVINDARAJAN, AARTHI, BALAJI, NEHA, KUMARAN, SRIRAM, VIGNESH INTERIM PHASE I KUMARAN, VIGNESH DOCUMENTATION AARTHI, SRIRAM, BALAJI, VIGNESH PRESENTATION GOVINDARAJAN, NEHA, KUMARAN

 Incompleteness  Undefined terms  Incomplete list  Uncertainty  Dubious terms  Unclear phrases  Inconsistency  Contradictory Statements

 Detect the problem  Suggest appropriate solutions  Use different approaches to solve  List the essential requirements for solving

Reflects the environment in which the system operates Criteria to judge the operation of the system Reflects the set of inputs, its behaviors and resulting outputs

DR-01 : EmergencyDR-02 : Speech2Text DR-03 : Text2Speech DR-04 : FaceLook

DR-05 : MyPageDR-06 : PillTracker DR-07 : MyShelfDR-08 : DietManager

DR-09 : Walk-O-MeterDR-10 : PicTalk

Domain Requirement (DR) Functional Requirement (FR) Event Generated by End-UserSystem Response to the Event DR-01FR-01Touch on the Emergency IconDisplays list of Emergency contacts that could be called by a single touch DR-02FR-02Touch the Speech2Text Icon and feed the voice input Voice input is converted in textual form DR-03FR-03Touch the Text2Speech Icon and feed the textual input Textual input is processed into a voice output DR-04FR-04Touch the FaceLook Icon to search contacts by pictures/names Displays all the details of the selected contact DR-05FR-05Touch the MyPage Icon to retrieve information about one’s self Displays all personal information stored by the user

Domain Requirement (DR) Functional Requirement (FR) Event Generated by End-UserSystem Response to the Event DR-06FR-06Touch the PillTracker Icon to store the medicine stock and the intake timings Alerts the user at the stored time to consume the medicine and updates medicine stock. DR-07FR-07Touch the MyShelf Icon to store the information about the location of the frequently used items at home. Prompts the user about the location on selecting the item DR-08FR-08Touch the DietManager Icon to specify the blood sugar level, cholesterol level, etc. Displays the list of food items one should and should not consume DR-09FR-09Touch the Walk-O-Meter Icon to specify the start time/end time of a walking session Displays the distance covered and calories burnt in that session DR-10FR-10Touch the PicTalk Icon to convey a message by choosing the pictures available Displays and produces the sound for the chosen picture

USER SPECIFIED NFR RELIABILITY SCALABILITY USABILITY EMERGENCY SPEECH2TEXT PILLTRACKER ALL THE DRs PICTALK MYSHELF FACELOOK

SYSTEM SPECIFIED NFR TESTABILITY INTEROPERABILITY EXTENSIBILITY CHECK AGAINST VARIOUS HYPOTHESIS IMPORTING/ EXPORTING DATA SHOULD WORK ON VARIOUS PLATFORMS

 Unambiguous: Each requirement definition shall have no more than one interpretation  Concise: Minimal words yet maximum information  Wholeness: The specification contains all requirements known  Stableness: There are no conflicting requirements  Systematized: Organized into meaningful groups

 Follow uniquely recognizable naming convention  Maintain a solitary storage spot for all SRS  Use a single standard document format  Abide by the customary rules for writing a good WRS  Make an accommodative/adaptive document quality

A prototype of the application Speach2Text – STEP 1

Self Explanatory – Icons/App Names Unique Apps V Model Wide Area of Service User Friendly Layout

One Touch Emergency Text/ Voice Message Wireless Medical Report Transmission Profile Retrieval Using Image Recognition

Project Status (completed stage)Accommodation Percentage Requirement40-55% Analysis15-40% Design10-15% Implementation 0-10%