/
  162122   162122

162122 - PowerPoint Presentation

cheryl-pisano
cheryl-pisano . @cheryl-pisano
Follow
377 views
Uploaded On 2015-10-16

162122 - PPT Presentation

PROJECT PHASE 1 System Requirements Specification INSTRUCTOR Dr LAWRENCE CHUNG TEACHING ASSISTANT RUTVIJ MEHTA SYNOPSIS Project Overview ID: 162122

people requirements project requirement requirements people requirement project phone user phase system elderly issues deliverables functional 2010 finances deena

Share:

Link:

Embed:

Download Presentation from below link

Download Presentation The PPT/PDF document " 162122" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.


Presentation Transcript

Slide1
Slide2

PROJECT PHASE 1

System

Requirements

Specification

INSTRUCTOR : Dr.

LAWRENCE CHUNG

TEACHING ASSISTANT

:

RUTVIJ MEHTASlide3

SYNOPSIS

Project

Overview

Requirement Engineering Process

Issues & Resolutions

Writing Specifications

Prototype

Future WorkSlide4

PROJECT OVERVIEWSlide5

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 timeSlide6

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

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

REQUIREMENT ENGINEERING PROCESSSlide9

PROCESS MODELSlide10

PROCESS

Analyzing and discussing requirements with stakeholders

Constructing deliverables

Reviewing deliverables for consistency and completeness

Making final changes to the deliverables before submissionSlide11

PROJECT DELIVERABLES

PHASE

DELIVERABLE

DATE

PHASE 0

PRELIMINARY PROJECT  PLAN

SEPTEMBER 2

ND

, 2010

PHASE 1

INTERIM PROJECT 1

REQUIREMENT SPECIFICATION

REQUIREMENT ANALYSIS

PRESENTATION 

SEPTEMBER 30

TH

/OCTOBER 5

TH

, 2010

PHASE 1

FINAL PROJECT 1

IMPROVED REQUIREMENT SPECIFICATION

IMPROVED REQUIREMENT ANALYSIS

PRESENTATION

OCTOBER 21

ST

, 2010

PHASE 2

INTERIM PROJECT 2

IMPROVED REQUIREMENT SPECIFICATION/ANALYSIS

IMPLEMENTATION

TESTING

PRESENTATION

NOVEMBER 11

TH

, 2010

PHASE 2

FINAL PROJECT 2

MODIFIED IMPLEMENTATION

MODIFIED TESTING

PRESENTATION

NOVEMBER 30

TH

/DECEMBER 2

ND

, 2010Slide12

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

PROJECT ROLES

PHASE 1

DELIVERABLES

DEVELOPERS

REVIEWERS

TEAM LEAD

 

PRELIMINARY DEFINITION

 

JAYASHREE

SINDHUJA

SAHANA

AMRUTA

SUPRIYA

PRATHIBA

DEENA

 

JAYASHREE

SINDHUJA

SAHANA

AMRUTA

ASHOK

 

RYAN/ASHOK

 

PRESENTATION

 

JAYASHREE

SINDHUJA

SAHANA

AMRUTA

SUPRIYA

PRATHIBA

DEENA

 

SUPRIYA

PRATHIBA

DEENA

RYAN

 

RYAN/ASHOKSlide14

ISSUESSlide15

Definition

Issues

Incompleteness

Undefined terms

Incomplete list

Ambiguity

Dubious terms

Unclear phrases

Inconsistency

Contradictory StatementsSlide16

Identifying

Issues and

Their

Solutions

Identify the issue

Propose elements of the solution

Negotiate different approaches

Specify a preliminary set of solution

requirementsSlide17

Types

of requirements

Domain : Services the system should provide

Functional : Describe functionality or system

services

Non-

Functional : Constraints on the services/functions of the systemSlide18

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 timeSlide19

Domain

Requirements

DR4) Old people suffering from hearing problem will need a converter

DR5) 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 recognition

DR7) Add a Finance planner

application

DR8) Remote devices such as weighing machine,

cardio

belt, etc. must be blue tooth enabledSlide20

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

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

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

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 secondsSlide24

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 groupsSlide25

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)Slide26

PROTOTYPESlide27

HEARINGSlide28

VISIONSlide29

MEMORYSlide30

SPEECHSlide31

EVERYDAY LIVINGSlide32

EMERGENCY CALLSlide33

MAIN MENUSlide34

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

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

PERCENTAGE CHANGE

To be done and presented by DeenaSlide37

FUTURE WORK

To be done and presented by DeenaSlide38

ANY QUERIES?Slide39

THANK YOU!

Related Contents


Next Show more