1. Aaron Jacobs, Allen Helton, Chris Mudd, Jeff Allain, Jessi Cardoso, Matthew Jacobs, Prerak Patel, Richard Vanderdys, Saurav Shrestha

2. Before focusing on the solution, we must thoroughly understand the problem. “He felt that it was possible to waste a lot of time writing programs when one should have spent that time thinking more about the problem.” David L. Parnas speaking about one of his teachers, Leo Aldo Finzi. “Who Taught Me About Software Engineering Research?”

3. What type of system are we building? The HOPE System is: An Interactive System: A system that involves a significant degree of user interaction. A Safety Critical System: Where failure of a system endangers human life.

4. Interactive Systems In an interactive system, special consideration must be taken in formulating ‘external requirements.’ External requirements: Requirements which may be placed on both the product and the process and which are derived from the environment in which the system is developed. Example: Safety- To ensure that the speech-to-text function does not produce undesirable results, a limited dictionary will be utilized. This dictionary will constrain the possible interpretations by the software when a person speaks.

5. Safety scenario An old person wants to relay a message to their caregiver regarding an important doctors appointment, the person says, “I need to go to the proctologist right away.” But the system interprets the speech as “I need to go to the proctologist Friday.” The old person subsequently suffers from renal failure due to the misinterpretation of the system.

6. Critical Systems The failure of a critical system may result from a failure to meet a functional requirement but, more often, it results from a failure of the system to satisfy some non-functional constraint on its operation. Principle non-functional constraints relevant to critical systems: reliability, performance, security, usability, safety

7. The difficulty of formulating non-functional requirements Certain constraints, for example the availability rate of the system (a reliability requirement), are related to the design solution that is unknown at the requirements stage. Non-functional requirements tend to be related to one or more functional requirements. Non-functional requirements tend to conflict and contradict each other. There are no rules and guidelines for determining when non-functional requirements are optimally met.

8. Some non-functional requirements Product requirements – specify the desired characteristics that a system or subsystem must possess.  The HOPE System shall have an availability rate of 99%  The system shall be developed for the Google Android platform Process requirements – are constraints placed upon the development process of the system.  A disaster recovery plan for the system development must be specified.  The system shall conform to the IEEE 830 standard for software requirements specification.

9. The importance of the emergency button If the emergency button fails to meet performance or reliability requirements, the loss of human life may take place. The system should have a fault-tolerant design: If each component, in turn, can continue to function when one of its subcomponents fails, this will allow the total system to continue to operate, as well. At this stage of the project, it is difficult to quantify an achievable reliability and performance rate.

10. The ability to accommodate change “One must anticipate changes before one begins the design.” David L. Parnas “Designing Software for Ease of Extension and Contraction.”

11. Accommodating change We must design a family of programs in which some members are subsets of other family members or several family members share a common subset. We must follow the following principles:  Simplify functions so that each function performs one task.  Identify items that are likely to change. These items are termed ‘secrets.’  Generating desired sentences and represent them pictorially as well as associate with a sound/voice.  Giving a specific meaning to each picture to reduce the ambiguity.

12. Accommodating change (continued)  Location of the specialized components in separate modules.  Designing intermodule interfaces that are insensitive to the anticipated changes. The changeable aspects or “secrets” of the modules are not revealed by the interface. The Uses Hierarchy Level 0: Providing a way for the users to select proper categories and navigate through various dimensions of vocabulary. Level I: -Placing emergency calls and messages. -Making each vocabulary item available through a search interface.

13. Functional Requirements

14. Text to Speech Features To assist elderly with poor speech. Text-To-Speech (TTS). Also known as "speech synthesis", allows your Android device to "speak" text of different languages. Organized categories of common phrases.

15. Speech to Text Feature is useful to elderly people who have bad hearing issues. Speech Recognition in Android SDK 1.5 Our software listens to speech and writes them into txt.

16. Reading Out Loud For elderly that have problems seeing our software will insure that every menu and options will be read out load. When an option is pressed, the name of the option is read out load.

17. Font Size Font size can be made bigger or smaller depending on the customer preference.

18. Emergency Services If activated, it send a text message to the people on their emergency contacts and also dials 911.

19. Reminder Birthdays Appointments Alarm Medicine

20. Ease of Use Recent history and programs used

21. Flashlight A flash light will be handy in the dark. Specially at night to go to the restroom or just look for a medicine and water by the bed. Best to use flash but white screen is good too.

22. Zoom In Elderly may have trouble reading so our software will open up the camera app and it can be used to zoom into objects.

23. Where’s my phone? The elderly tend to lose things and misplace very easily. The application will have a loud alert ring every 15 minutes so that the phone can be located.

24. Tutorial The software will provide a tutorial on how to use the features of the phone with step-by-step instruction

25. Scenarios…

26. The End “Detailed knowledge of arcane system interfaces and languages is no substitute for knowing how to apply fundamental design principles.” David Lorge Parnas “Software Engineering: An Unconsummated Marriage”