PROJECT PHASE 1 System Requirements Specification INSTRUCTOR : Dr. LAWRENCE CHUNG TEACHING ASSISTANT : RUTVIJ MEHTA
SYNOPSIS• Project Overview • Requirement Engineering Process• Issues & Resolutions• Writing Specifications• Prototype• Future Work
PROJECT OVERVIEW
Why??• Every ailment comes with a cost. The accessories to assist
end up troubling the elderly more!!
• The Cell Phone is “IN”(Especially a Google phone) \m/
• It becomes “Exceedingly Difficult” to keep these N accessories “Running” all the time
What??• One comprehensive system to address all possible ailments of the
elderly like reduced vision, hearing and memory.
• With all these features incorporated the dependency factor on other people(relatives or Children) to help them in carrying out daily activities is reduced and hence they become more self reliant.
• Easier ways to manage finances, vital health sign monitoring and other auxiliary features thereby looking beyond their basic ailment necessities.
How??• Easy to use Graphical User Interface is Developed such that the user can
access features like Speech to Text Converter and so in just a click of a button.
• This is realized through a Smart Phone(Google Phone) which runs on Android with various Java Applications running on this platform, each to serve a specific purpose.
• The applications are tailored to meet a range of needs of the elderly, and address possible ailments they might face with age and since it is all incorporated on a single phone, it is easily accessible and available at emergencies when they need it.
REQUIREMENT ENGINEERING PROCESS
PROCESS MODEL
PROCESS• Analyzing and discussing requirements with
stakeholders • Constructing deliverables • Reviewing deliverables for consistency and
completeness • Making final changes to the deliverables before
submission
PROJECT DELIVERABLESPHASE DELIVERABLE DATE
PHASE 0 PRELIMINARY PROJECT PLAN SEPTEMBER 2ND, 2010PHASE 1 INTERIM PROJECT 1
REQUIREMENT SPECIFICATION REQUIREMENT ANALYSIS PRESENTATION
SEPTEMBER 30TH/OCTOBER 5TH, 2010
PHASE 1 FINAL PROJECT 1 IMPROVED REQUIREMENT SPECIFICATION IMPROVED REQUIREMENT ANALYSIS PRESENTATION
OCTOBER 21ST, 2010
PHASE 2 INTERIM PROJECT 2 IMPROVED REQUIREMENT SPECIFICATION/ANALYSIS IMPLEMENTATION TESTING PRESENTATION
NOVEMBER 11TH, 2010
PHASE 2 FINAL PROJECT 2 MODIFIED IMPLEMENTATION MODIFIED TESTING PRESENTATION
NOVEMBER 30TH/DECEMBER 2ND, 2010
TEAM ROLES• DEVELOPER: The developer will be responsible for constructing the
deliverable and performing relevant software engineering processes.
• REVIEWER: The reviewer will review the deliverables and suggest appropriate modifications when necessary.
• • TEAM LEAD: The team lead will facilitate communication between
developers and reviewers, resolve conflicts between them and ensure the production of good quality deliverables before the deadline.
PROJECT ROLES
PHASE 1
DELIVERABLES DEVELOPERS REVIEWERS TEAM LEAD
PRELIMINARY DEFINITION
JAYASHREESINDHUJASAHANAAMRUTASUPRIYAPRATHIBADEENA
JAYASHREESINDHUJASAHANAAMRUTAASHOK
RYAN/ASHOK
PRESENTATION
JAYASHREESINDHUJASAHANAAMRUTASUPRIYAPRATHIBADEENA
SUPRIYAPRATHIBADEENARYAN
RYAN/ASHOK
ISSUES
Definition Issues• Incompleteness– Undefined terms– Incomplete list
• Ambiguity– Dubious terms– Unclear phrases
• Inconsistency– Contradictory Statements
Identifying Issues and Their Solutions
• Identify the issue• Propose elements of the solution• Negotiate different approaches• Specify a preliminary set of solution
requirements
Types of requirements• Domain : Services the system should provide
• Functional : Describe functionality or system services
• Non- Functional : Constraints on the services/functions of the system
Domain Requirements• DR1) Old people suffering from hearing problem will need a
converter• DR2) Old people with visual imparities will need a tool for
object recognition• DR3) Some elderly people who have memory loss will not
remember to have their medicines at the correct time. This feature will generate reminders to help these people have their
tablets at the correct time
Domain RequirementsDR4) Old people suffering from hearing problem will need a converterDR5) Old people suffering from speech disorders may need
images/icons for immediate help in emergency situations.DR6) Old people with visual imparities will need a tool for object
recognitionDR7) Add a Finance planner applicationDR8) Remote devices such as weighing machine, cardio belt, etc. must be blue tooth enabled
FUNCTIONAL REQUIREMENTS ISSUES AND SOLUTIONS• FR009: Stores picture album consisting of the photos of relatives and friends of the user
to help the user recognize them. FR009: A photo album consisting of the photos of relatives and friends of the user is
stored so that the user can browse and select the person they cannot recognize and the name and customizable description of the person is displayed.
• FR010: Reminds user to take their medicines by displaying the name or image of the medicine.
FR010: The medication assistant reminds the user to take their medicines by displaying the name or image of the medicine at the time prescribed by the doctor.
FUNCTIONAL REQUIREMENTS ISSUES AND SOLUTIONS• FR011: Elderly people can draft budgets; meet bill payment deadlines; manage current finances in bank
accounts, property and other investments; procure the insurance amount when needed by linking the user's insurance and bank accounts for direct fund transfers.
FR011: The system will help the old people to draft budgets, meet utilities and insurance payment deadlines. There has to be a precise budget that needs to be drafted for the various financial factors considered as it will enable them in managing a portion of their finances.
• FR013: Elderly people send the results of their blood pressure readings etc. to their doctors by taking readings from devices such as weighing machine, sphygmomanometer, cardio belt etc. via Bluetooth and transfer the data to a smart phone.
FR013: The medical device monitor allows elderly people to send their vital signs data from remote devices such as a
weighing scale, sphygmomanometer and cardio belt to the smart phone via Bluetooth, where it is saved in the same format in which it is received and maintaining the case history of patients.
NON-FUNCTIONAL REQUIREMENTS ISSUES AND SOLUTIONS
• NFR013: Store few photos to identify a contact, pet or an object.
NFR013:The system should allow storage for at least 2 photos to identify a contact, pet or object.
• NFR015: The phone should display the name or image of the medicine at the correct time.
NFR015:The phone should never display the wrong medicine image.
NON-FUNCTIONAL REQUIREMENTS ISSUES AND SOLUTIONS
• NFR017: Budgets should be drafted accurately NFR017:Financial Budgets should be drafted up to 3 digits after the
decimal point.
• NFR022: Data transferred and recorded should be accurate and precise since it will be used in maintaining the case history of the patient.
NFR022:Vital signs data should be transferred from the medical device to
the Android phone within 30 seconds
IMPROVED UNDERSTANDING• Lack of ambiguity – There is one and only one possible
interpretation for each requirement statement• Conciseness – Represented in minimal number of words • Completeness – The specification contains all requirements
known• Consistency – There are no conflicting requirements• Traces to origins – The source/origin of each requirement is
identified. It may have evolved from a more general requirement• Organized into logical meaningful groups
WRITING SPECIFICATIONS• Uniquely identify each specific requirement to make referencing
them easier (e.g. DFR001, FR013, NFR015)• Establish a single source for requirement storage (SRS Document)• Follow a standard or recommended guide for adopting a structure
for the document. (WRS Template)• Adhere to standard rules for writing good requirements
statements (atomic requirements, appropriate use of shall/should/will)
• Assess and improve document quality (traceability matrix, percentage of possible change)
PROTOTYPE
HEARING
VISION
MEMORY
SPEECH
EVERYDAY LIVING
EMERGENCY CALL
MAIN MENU
WHY ARE WE BETTER?• Our system has special features ,which may not be in other teams systems. a)Medical remainders, Doctor appointment and personal meetings remainders for the elder people with memory loss. b)Helps the elderly people in managing their finances(bank accounts, finances) c)Readings taken from the weighing machine, sphygmomanometer ,cardio belt
etc. can be sent to the doctor in the remote area via Bluetooth. d)Elder people can get the updated news instantly by clicking on the icon rather
than browsing for the news. • In our project we are using the spiral model because of its design flexibility, it
allows changes to be implemented at several stages of the project and estimates done using this are more realistic. Other teams might have used Role Actor Diagrams which does not allow to go back and do the changes.
WHY ARE WE BETTER?• The Pareto Principle (also known as the 80/20 rule) the idea
is that by doing 20% of the work you can generate 80% of the benefit of doing the whole job. We have used Pareto 80-20 principle for the measurement of the percentage of the changes in the requirements.
• All icons are self-explanatory, other teams may not be more specific.
• There is more compliance between our prototype and our requirements, which may not between those of other teams.
PERCENTAGE CHANGETo be done and presented by Deena
FUTURE WORKTo be done and presented by Deena
ANY QUERIES?
THANK YOU!