Helping elder project

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

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

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

5. 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

6. 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.

7. 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.

10. 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.

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

12. Understand
Problems
Establish
Outline
Requirement
Select
Prototyping
System
Evaluate
Prototype
Develop
Prototype
Req Engg
Domain
Expert
Req Engg
End User
Software
Engg.
Project Mgr
Req Engg
Software
Engg
Domain Expert
End-User
Software Engg
Req Engg
Phase 0 / Phase 1 Phase 2

13. Phase Deliverable Developers Reviewers
PHASE 0 SOFTWARE PROJECT
MANAGEMENT PLAN
KUMARAN
BALAJI
GOVINDARAJAN
AARTHI
PHASE 1 REQUIREMENTS SPECIFICATION SRIRAM
VIGNESH
NEHA
BALAJI
PHASE 1 ANALYSIS MODEL BALAJI
AARTHI
KUMARAN
SRIRAM
PHASE 2 CODE AARTHI
BALAJI
GOVINDARAJAN
KUMARAN
NEHA
SRIRAM
VIGNESH
VIGNESH, NEHA
PHASE 2 SYSTEM TEST KUMARAN
SRIRAM
NEHA
GOVINDARAJAN
PHASE 2 USER DOCUMENTATION BALAJI
VIGNESH
GOVINDARAJAN
KUMARAN

14. PHASE MANAGEMENT
FUNCTIONAL
DUTY
RESPONSIBLE
PRELIMINARY PROJECT
PLAN
GOVINDARAJAN DOCUMENTATION
GOVINDARAJAN,
AARTHI,
BALAJI,
NEHA,
KUMARAN,
SRIRAM,
VIGNESH
INTERIM PHASE I
KUMARAN,
VIGNESH
DOCUMENTATION
AARTHI,
SRIRAM,
BALAJI,
VIGNESH
PRESENTATION
GOVINDARAJAN,
NEHA,
KUMARAN

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

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

19. Requirements
Domain Functional
Non
Functional
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

20. DR-01 : Emergency DR-02 : Speech2Text
DR-03 : Text2Speech DR-04 : FaceLook

21. DR-05 : MyPage DR-06 : PillTracker
DR-07 : MyShelf DR-08 : DietManager

22. DR-09 : Walk-O-Meter DR-10 : PicTalk

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

24. Domain
Requirement
(DR)
Functional
Requirement
(FR)
Event Generated by End-User System Response to the
Event
DR-06 FR-06 Touch 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-07 FR-07 Touch 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-08 FR-08 Touch 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-09 FR-09 Touch 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-10 FR-10 Touch the PicTalk Icon to
convey a message by choosing
the pictures available
Displays and produces the
sound for the chosen picture

25. NON FUNCTIONAL
REQUIREMENTS
SYSTEM SPECIFIC
USER SPECIFIC

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

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

28. 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

30. 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

33. A prototype of
the application
Speach2Text –
STEP 1
Sample
prototype of the
app
“Speech2Text”
STEP 1

34. Sample
prototype of the
app
“Speech2Text”
STEP 2

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

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

38. Project Status (completed stage) Accommodation Percentage
Requirement 40-55%
Analysis 15-40%
Design 10-15%
Implementation 0-10%