Software Requirements Specification (SRS) Template s1

Health Monitor- Software Requirements Specifications

SOFTWARE REQUIREMENTS SPECIFICATIONS HEALTH MONITOR

ACS 560 – SOFTWARE ENGINEERING FALL 2010

SRS prepared by:

 Shilpashree Srinivasamurthy ([email protected])

Instructor:

 Dr. John Tanik

Report Submission Date:

 22/Nov/2010

of 30 05/08/18f Health Monitor- Software Requirements Specifications

Revision History

Version Date Description

V-1.1 11/22/2010

Table of Contents

1. INTRODUCTION 5

1.1 PURPOSE 5 1.2 SCOPE 5 1.3 DEFINITIONS, ACRONYMS, and ABBREVIATIONS. 6 1.4 REFERENCES 6 1.5 OVERVIEW 7

2. THE OVERALL DESCRIPTION 7

2.1 PRODUCT PERSPECTIVE 7 2.1.1 SYSTEM INTERFACES 9 2.1.2 INTERFACES 9 2.1.3 HARDWARE INTERFACES 9 2.1.4 SOFTWARE INTERFACES 9 2.1.5 COMMUNICATION INTERFACES 9 2.1.6 MEMORY CONSTRAINTS 9 2.1.7 OPERATIONS 9 2.1.8 SITE ADAPTATION REQUIREMENTS 11 2.2 PRODUCT FUNCTIONS 12 2.3 USER CHARACTERISTICS 15 2.4 CONSTRAINTS 15 2.5 ASSUMPTIONS AND DEPENDENCIES 15 2.6 APPORTIONING OF REQUIREMENTS. 15

3. SPECIFIC REQUIREMENTS 15

3.1 EXTERNAL INTERFACES 15 3.2 FUNCTIONS 15 3.3 PERFORMANCE REQUIREMENTS 21 3.4 LOGICAL DATABASE REQUIREMENTS 21 3.5 DESIGN CONSTRAINTS 22 3.5.1 STANDARDS COMPLIANCE 22 3.6 SOFTWARE SYSTEM ATTRIBUTES 23 3.6.1 RELIABILITY 23 3.6.2 AVAILABILITY 23 3.6.3 SECURITY 23 3.6.4 MAINTAINABILITY 23 3.6.5 PORTABILITY 23 3.7 ORGANIZING THE SPECIFIC REQUIREMENTS 25 3.7.1 USER CLASS 25 3.7.2 OBJECTS 25

4. CHANGE MANAGEMENT PROCESS 26

5. DOCUMENT APPROVALS 26

1. INTRODUCTION

1.1 PURPOSE

Physical activity and overweight obesity are two of ten leading health indicators for the prevention of long-term chronic disease as defined by the U.S Department of Health and Human Services. Physical activity and over-weight obesity determine health status for key clinical and public health concerns including Type 2 diabetes, heart disease and stroke, disability, chronic kidney disease and maternal and child health. Preventing overweight and obesity can help prevent the serious health, social and economic consequences of long-term chronic diseases for millions of people. Health Monitor is software which aims in helping people maintain healthy life style based on diet and physical exercises. The purpose of this document is to clarify the software requirements related to the Health Monitor – Software Systems Architecture and should be the only resource containing the system requirements. This document will detail the purpose of this the software along with its capabilities, interfaces, and user interactions. This document is intended for stakeholders, users and the designers of the system. It will be proposed to the instructor for approval.

1.2 SCOPE

This specification covers the overall description of the system but does not include specific requirements for the entire system. From a software perspective, the tool must be programmed take various factors from the user and produce a correct output. Health Monitor software provides a diet chart and fitness plan to the users based on various factors some of which include age, gender, race/ethnicity, BMI, individual life style which include diet and exercise plans. This tool will thus help the user to maintain a healthy life style and keep them away from various chronic diseases. In case if the user is already suffering from any chronic diseases this tool will help to keep them under control by designing a diet and fitness plan based on the current symptoms of the disease and medication. This tool also provides information various factors in their current life style which is affecting their health and explains about the various nutrients that are currently required for their body and also describes the importance of physical activities. The tool also provides links to various additional resources which will help the users to explore more in order to maintain a healthy life style.

All activities directly related to the purpose of the project (as defined by the course requirements) are considered to be in scope. All activities not directly related to the

purpose are considered to be out of scope. For example the medication details of various diseases are out of scope of this document.

1.3 DEFINITIONS, ACRONYMS, and ABBREVIATIONS.

Term, Acronym, Meaning Abbreviation BMI Statistical measure of body weight based on a person's weight and height which is used to estimate a healthy body weight based on a person's height. Body mass index is defined as the individual's body weight divided by the square of his or her height. Obesity A medical condition in which excess body fat has accumulated to the extent that it may have an adverse effect on health, leading to reduced life expectancy and/or increased health problems. Chronic Diseases An illness marked by long duration or frequent recurrence Web Application An application that is accessed over a network such as the Internet or an intranet. Diet Chart A chart showing the diet consisting of proper quantities and proportions of foods needed to maintain health or growth

1.4 REFERENCES

1. Systems Analysis and Design 8th Edition by Kendall and Kendall

2. Software Engineering, 8th Edition, Ian Sommerville. Boston: Addison Wesley Professional, 2006.

3. Designing Concurrent, Distributed, and Real-Time Applications with UML by Hassan Gomaa

4. IEEE. Ieee recommended practice for software requirements specifications. IEEE Xplore. [Online] June 25, 1998. [Cited: September 25, 2010.] http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=720574. IEEE Std 830-1998

5. Diet, Nutrition and the Prevention of Chronic Diseases : WHO Technical Report Series 916

6. Diet and Nutrition Surveillance for Chronic Disease: A White Paper on the National Report on Biochemical Indicators of Diet and Nutrition in the U.S. Population – 1999- 2002

7. Chronic Disease Alliance: A Unified Prevention Approach

8. Low-Fat Diet and Chronic Disease Prevention: the Women’s Health Initiative and Its Reception

9. Pennsylvania Nutrition and Physical Activity Plan to Prevent Obesity and Related Chronic Diseases: Department of Health

10. US Department of Health and Human Services and Advertising Council: Healthy lifestyles and disease prevention media campaign; Take a small step to get healthy.

Advisor Reference: - Dr. John Tanik

1.5 OVERVIEW

This document will cover detailed information about the software requirement specification defined for the Health Monitor. The following topics are covered in the document:  A statement of what the project is about.  Analysis of stakeholder needs.  Overall product description including analysis models.  Interfaces of the system to the environment  Analysis of functional requirements of the system.  External interface samples.  Analysis of design constraints.  Analysis of performance requirements.  Application attributes (Non-functional requirements).

2. THE OVERALL DESCRIPTION 2.1 PRODUCT PERSPECTIVE

Health monitor attempts to find a solution for the health problems in the current generation based on nutrition analysis and the current life style. This product helps people to evaluate their current food habits and exercises, and also provides them with a diet chart and fitness plan which will help them to keep away from many diseases or keep the chronic disease under control if they already have them, thus

leading them towards a healthy life style. The main functionalities of this software are as follows:  Register to the application  Login to the application  Obtain facts from the user  Provide feedback about the current life style of the user  Print the generated feedback  Generate a diet chart based on food habits of the user  Print the generated Diet Chart  Provide a fitness plan based on the daily routine of the user  Make the user aware of the importance of diet and fitness in preventing many serious health problems and motivate him/her towards healthy living

The following diagram shows the Block Diagram of the Health Monitor System

Figure 1: System Block Diagram

The system uses Model-View-Controller (MVC) architecture. The Data represents the data model. The View represents client presentation components. Controller represents implementation of the business logic and application workflow logic responsible for the allocation of resources available to the application.

2.1.1 SYSTEM INTERFACES

This system does not have any interfaces with any of the existing systems.

2.1.2 INTERFACES

This system is designed to be transparent to its users and hence all the complexity is hidden from the user. The user will interact with system using the GUI that is designed using JSP.

2.1.3 HARDWARE INTERFACES

Health Monitor is a web application that will make use of MVC architecture. This application uses standard java classes and databases. No additional specific hardware interfaces are needed during the operation of the Health Monitor application.

2.1.4 SOFTWARE INTERFACES

 The application uses JSPs for presentation that communicates with Servlets that form the controller through standard built in java interfaces.

 The Servlets interact with data model through standard interface such as JDBC or ODBC.

2.1.5 COMMUNICATION INTERFACES

No additional specific communication interfaces are needed during the operation of the Health Monitor application.

2.1.6 MEMORY CONSTRAINTS

The system is expected to have a memory capacity of 256 MB and disk space of 500 MB. But it is recommended that the system has a memory capacity of 1GB and disk space of 1 GB.

2.1.7 OPERATIONS

The basic operations of the Health Monitor are described as follows:

- The user when using the application for the first time has to register with the application.

- The user after registering, can login to the application with his username and password.

- The user will be initially shown with the form wherein he has to enter the details, about his age, gender, height, weight, food habits and lifestyle details.

- The system will then evaluate the lifestyle of the user and provide the feedback about his current lifestyle.

- The system will generate a diet chart that contains the details about the food that he has to intake everyday.

- The system will also generate a suitable fitness plan for the user that contains the details about the exercises that the user should follow for a healthy living.

- The system will also motivate the user to follow a healthy living by explaining the benefits of healthy lifestyle

- The user can logout of the application at any time by clicking on the logout button.

The operations of the Health Monitor can be represented by the use case diagram shown below.

Health Monitor Register

«extends»

User «uses»

«uses» «extends» Provide Feedback Print Feedback Enter Details «uses»

«extends» Generate Diet Chart Print Diet Chart «uses» «uses»

Generate Fitness «extends» Plan Print Fitness Plan Display Advantages

Figure 2: Basic Operation of Health Monitor

2.1.8 SITE ADAPTATION REQUIREMENTS

The system will require an application server for the runtime components and a database for storage. The system will run on select popular application servers and use select popular database for data storage. This system will use Apache Jakarta Tomcat 5.5.x or 6.0.x as application server and Oracle 10g for data storage.

2.2 PRODUCT FUNCTIONS

The main functionalities of the Health monitor are: 1. Register 2. Login 3. Obtain facts from the user 4. Provide feedback 5. Print feedback 6. Generate Diet Chart 7. Print Diet Chart 8. Provide Fitness Plan 9. Print Fitness Plan 10. Explain Advantages 11. Log out

Each of these functionalities is described below:  Register Each user who is new to the application should go through the process of registration. A registration form will be displayed to the user wherein the user has to provide the required details to the system and get registered.

 Login After registering the user should be able to login to the application with the user name and password.

 Obtain facts from the user The users should provide various details: age, gender, race/ethnicity, allergies, height, weight, BMI (if the user does not know his/her BMI the system calculates it), daily routine, details about food habits.  Provide feedback In this step the system will evaluate the lifestyle of the user and provides a feedback. The system provides the following information to the user: - The ideal weight - The food items that should not be consumed (or rarely consumed) - Number of hours of physical activities per day

 Print Feedback In this step, the user will print the feedback provided by the system.

 Generate Diet Chart The system provides a separate list of food items that should be consumed by the user for breakfast, lunch, snacks and dinner for each day in a week. (Sunday

may be excluded, so that the user will have some freedom to consume the food of his choice).

 Print Diet Chart In this step the user will print the diet chart provided by the system by clicking on ‘Print Chart’ button on the screen.

 Provide a Fitness Plan After evaluating the lifestyle of the user, considering the age of the user and his chronic diseases, the system will generate fitness plan. This plan consists of list of activities that should be performed by him on each day for specific amount of time.  Print Fitness Plan In this step the user will print the fitness plan displayed by the system by clicking on ‘Print Fitness Plan’ button on the screen.

 Explain Advantages The system explains the user about the importance of diet and fitness for leading a healthy life. The system also describes the risks the user may be facing as a result of his current lifestyle in long run. The software thus motivates the user to follow the diet and fitness chart provided by the system.  Log out The user will be logged out of the system and ‘Successful Log out’ message is displayed on the screen. All the above functionalities can be represented using an Activity Diagram as shown below.

Health Monitor Activity Diagram

Client Browser Web Server Back end

Form Transmitted Registration Details Register Form Receive Web Form Store User Record

Form Transmitted User ID and Password Log In Form Receive Web Form Get User Record

Record Status Send Error Message Display Error Message Not Found

Display Enter Details Form Web Form Sent Found Web Form Received User Details Enters all the required Details Receive Web Form Store User Details

Views the feedback Display the feedback Feedback Sent Evaluate Details Based on User Details Command Transmitted Press 'Print Feedback' button Prints the feedback displayed on the screen

Command Transmitted Request Press 'Generate Diet Chart' button on the screen Receive request Generate Diet Chart

Views the diet chart Display the Diet Chart Diet Chart Sent Response

Command Transmitted Press 'Print Diet Chart' button Prints the diet chart displayed on the screen

Request Command TransmittedReceive request Generates a fitness plan Press 'Generate Fitness Plan' button on the screen

Views the Fitness Plan Display the fitness plan to the user Fitness Plan Transmitted Response

Command Transmitted Prints Fitness Plan displayed on the screen Press 'Print Fitness Plan' button

Command Transmitted Press 'Log out' button The user will be logged out of the system

Log out Cancel Display Log out confirmation message Confirmation Sent

Figure 3: Activity Diagram of Health Monitor

2.3 USER CHARACTERISTICS

USR-1: General User: This software is similar to any other software and hence the user should be aware of using any software in general. The system under consideration has only general users who will login to the system to know more about their lifestyle and wish to improve it naturally through diet and exercises. The user does not need to have complete understanding of the complex functionalities and internal processing of the system.

2.4 CONSTRAINTS

Legal Constraints: The Health Monitor application shall comply with any copyright laws or regulations set by International Standards ISO/ IEC. The system shall meet any other legal requirements set by relevant stakeholder.

2.5 ASSUMPTIONS AND DEPENDENCIES

It is assumed that the user is familiar with operating computer. It is assumed that the user is familiar with using a web application. No other assumptions or dependencies are identified.

2.6 APPORTIONING OF REQUIREMENTS.

This is an academic project and hence all the requirements will be completed before the end of the semester. There will be no delay in the delivery of any of the requirements.

3. SPECIFIC REQUIREMENTS

3.1 EXTERNAL INTERFACES

There are no external interfaces identified at this point of time.

3.2 FUNCTIONS

This section of the requirements document provides the functional aspects for the Health Monitor as requested by the stakeholders of the system in the previous section. The following controls will be on the Health monitor: obtain facts from the user, provide feedback, generate diet chart, provide fitness plan, motivate user

FR-1 Register

The Health Monitor shall make the user enter the following fields in the registration form provided on the screen.

FR-1.1: The system shall allow the user to enter his first name

FR-1.2: The system shall allow the user to enter his last name

FR-1.3: The system shall allow the user to enter his age

FR-1.4: The system shall allow the user enter his city

FR-1.5: The system shall allow the user to enter his state

FR-1.6: The system shall allow the user to provide the country

FR-1.7: The system shall allow the user to provide his username

FR-1.8: The system shall allow the user to enter his life password

FR-1.9: The system shall allow the user to reenter his password

FR-1.10: The system shall allow the user to submit the details by clicking the ‘Submit’ button on the screen

FR-2 Login

The Health Monitor shall make the user enter the following fields in the login form provided on the screen.

FR-1.1: The system shall allow the user to enter his username

FR-1.2: The system shall allow the user to enter his password

FR-1.3: The system shall allow the user to login to the system by clicking on the ‘Log in’ button

FR-3 Obtain Facts from the User

The Health Monitor shall make the user enter the following fields in the form provided in the screen.

FR-3.1: The system shall allow the user to enter his age

FR-3.2: The system shall allow the user to enter his gender

FR-3.3: The system shall allow the user to enter his height

FR-3.4: The system shall allow the user enter his weight

FR-3.5: The system shall allow the user to enter his race/ethnicity

FR-3.6: The system shall allow the user to provide the food habit details

FR-3.7: The system shall allow the user to provide his exercise details

FR-3.8: The system shall allow the user to enter his life style details

FR-4 Provide Feedback

The Health Monitor shall provide the user the detailed feedback about how healthy his diet and exercise is.

FR-4.1: The system shall provide the range of his ideal weight

FR-4.2: The system shall allow the user to obtain a feedback as how healthy his diet is.

FR-4.3: The system shall provide the user feedback on the physical activities entered by the user in the previous screen.

FR-5 Print Feedback

This functionality shall allow the user to print the feedback provided by the health monitor.

FR-5.1: The system shall allow the user to print the feedback by clicking on ‘Print Feedback’ button on the screen.

FR-6 Generate Diet Chart

The system shall generate a diet chart for the user on clicking on ‘Generate Diet Chart’ button on the screen. This chart consists of a specific list of food items for breakfast, lunch, snacks and dinner for each day in a week. The system shall also provide the nutritional importance of these foods including their calorie content.

FR-6.1: The system shall allow the user to click on ‘Generate Diet Chart’ button on the screen.

FR-6.2: The system shall generate a diet chart to the user which consists of details about the food that should be consumed for breakfast, lunch, snacks, and dinner.

FR-6.3: The system shall be provided with the nutritional information and the calorie content of each of the food items provided in the chart.

FR-6.4: The system shall provide the user a list unhealthy food items and snacks that should be out of their diet.

FR-7 Print Diet Chart

This functionality shall allow the user to print the diet chart provided by the health monitor.

FR-7.1: The system shall allow the user to print the feedback by clicking on ‘Print Diet Chart’ button on the screen.

FR-8 Provide Fitness Plan

The system shall provide a list of exercises that should be performed by the user for a specified amount of time on clicking on ‘Generate Fitness Plan’ button on the screen. The system shall also provide the details about the amount of calories burnt in each of the activities provided in the list.

FR-8.1: The system shall allow the user to click on ‘Generate Fitness Plan’ button on the screen.

FR-8.2: The system shall generate a list of physical activities that should be performed by the user on each day

FR-8.3: The system shall provide the specified amount of time for each of those activities.

FR-8.4: The system shall provide information about the amount of calories that will be burnt as a result of the physical activities in the specified amount of time.

FR-9 Print Fitness Plan

This functionality shall allow the user to print the fitness plan provided by the health monitor.

FR-9.1: The system shall allow the user to print the feedback by clicking on ‘Print Fitness Plan’ button on the screen.

FR-10 Explain Advantages

The system shall motivate the user by explaining the user the importance of diet and exercises for leading a healthy life. The system also explains the health risks that the user would face due to the lack of physical activities and unhealthy junk food consumption.

FR-10.1: The system shall explain the user about nutrition and exercise importance for a healthy living

FR-10.2: The system shall explain the health risks that may arise as a result of lack of exercise and unhealthy junk food consumption.

FR-11 Log out

The system shall allow the user to log out of the system

FR-11.1: The system shall allow the user to click on the ‘Log out’ button on the screen.

FR-11.2: The system shall logout the user and display ‘Successful Log out’ message on the screen.

These functional requirements can re represented using the SysML Requirements Diagram as follows:

Health Monitor «requirement» Explain Advantages «requirement» Text= The system Health Monitor IdShall= explain the Text= Text Advantages of healthy Id= Text lifestyle ID = 10

«requirement» «requirement» «requirement» «requirement» «requirement» Register Login Obtain Facts Provide Feedback Log out Text= The user shall Text = The User has Text= The user TextThe= system will Text= The user will «verify» Has to enter the «satisfy» Id= provide the To provide Login Id= GiveId feedback= on the IdChoose= to logout registration details Required facts The user details current lifestyle of the of the system ID = 1 ID = 2 ID = 3 user ID = 11 ID = 4 <> «only if»

Generate Print «print»

«requirement» «requirement» «requirement» «requirement» «requirement» Generate Diet Chart Generate Fitness Plan Print Diet Chart Print Fitness Plan Print Feedback Text= The system shall Text= The system shall Text= The system shall Text= The system shall Text= The system shall print IdGenerate= diet chart Based IdGenerate= fitness plan IdPrint= the diet chart IdPrint= the fitness plan IdThe= feedback displayed on the facts entered by based on the facts entered Displayed on the screen Displayed on the screen On the screen the user By the user ID = 7 ID = 9 ID = 5 ID = 6 ID = 8

«print» «print»

Figure 4: SysML Requirements Diagram for Health Monitor

3.3 PERFORMANCE REQUIREMENTS

The subsection specifies the following requirements associated with the performance with which the Health Monitor shall operate.

PR-1: RESPONSE TIME

PR-1.1: The response time to load the application when the unit is turned on shall be less than 30 seconds.

PR-1.2: The response time to load the screen based on user’s operations should be less than 5 seconds.

PR-1.3: The response time to display the menu options on the display screen shall be less than 0.5 seconds.

PR-2: OPERATION

PR-2.1: The Health Monitor shall provide menu options that will be easy to navigate by the user and should be user friendly.

PR-2.2: The application shall not crash or freeze the system, other than as the result of the operating system error. In such case, the user should again login to the application.

PR-3: SCALING

PR-3.1: The system shall scale from 10 – 1000 users.

PR-3.2: The system shall support 1000 logged users and 100 simultaneous transactions.

3.4 LOGICAL DATABASE REQUIREMENTS

The database contains the following information:

- The registration details

- The details entered by the user

- The various details about the food such as calorie content, nutrition details and so on.

- The various details about the workouts such as calorie burnt, suitable age group and so on.

The database is accessed once for every action by the user for storing or retrieving information. ODBC connection is used for connecting the database tables and the java classes.

3.5 DESIGN CONSTRAINTS

CON-1: SOFTWARE CONSTRAINTS

CON-1.1: The Health Monitor Web application shall be designed for future upgrade as per needed.

CON-1.2: The application shall meet the general standards of web applications.

CON-2: HARDWARE CONSTRAINTS

There is no hardware constraints identified at this point.

CON-3: ACCEPTANCE CONSTRAINTS

To validate the system, the developers must complete the following:

CON-3.1: Demo the working system and any features upon request.

CON-3.2: Prove that all the significant functional requirements are met.

CON-3.3: Provide sufficient test cases to show that the system is complete and correct.

3.5.1 STANDARDS COMPLIANCE

Report Format: All the reports produced for this project are in compliance with the standard templates provided in the class by the advisor.

Naming Conventions: All the documents will be named using the standard naming conventions.

3.6 SOFTWARE SYSTEM ATTRIBUTES

3.6.1 RELIABILITY

The Health Monitor Software shall never crash or freeze. The unit shall inform the user to re-set the system if major software mal-function has been encounter by the system

3.6.2 AVAILABILITY

The application shall be available to any user who has an internet connection.

3.6.3 SECURITY

The data entered by the user shall be kept secured and private and shall not be disclosed. The application shall be protected against hackers and other malwares. The system shall make use security provided by the web server and database. Firewall and network security are outside the scope of the document.

3.6.4 MAINTAINABILITY

The software should not require any additional maintenance. If any errors occur, the user should be able to logout and login again with his credentials. The system shall be flexible enough to add new modules and upgrade the existing modules.

3.6.5 PORTABILITY

There is no portability requirements identified at this point.

Software System Attributes Tradeoffs

A Tradeoff Point is a property that affects one or more attributes. Essentially, changing one quality attribute often forces a change in another quality attribute either positively or negatively. This is important because knowing the prioritized system quality attributes and their Tradeoff Points aids the decision-making process during design activities.

The following table summarizes the relative importance of software system attributes where:

- H is High

- M is Medium

- L is Low.

It should be used to guide design where tradeoffs must be made. An ID marked to the right indicates that the attribute on the right is preferred.

ID Characteristic H/M/L 1 2 3 4 5 6 7 8 9 10 11 12 1 Correctness H 1 1 1 1 1 1 1 1 1 1 1 2 Efficiency H 2 4 2 2 2 8 2 10 11 2 3 Flexibility M 4 5 3 3 8 3 10 11 3 4 Integrity/Security H 5 4 4 8 4 10 11 4 5 Interoperability M 5 5 8 5 10 11 5 6 Maintainability M 6 8 6 10 11 6 7 Portability M 8 7 10 11 7 8 Reliability H 8 10 11 8 9 Reusability M 10 11 9 10 Testability H 11 10 11 Usability H 11 12 Availability M

Definitions of the quality characteristics mentioned in the above table

• Correctness - extent to which program satisfies specifications, fulfills user’s mission objectives

• Efficiency - amount of computing resources and code required to perform function

• Flexibility - effort needed to modify operational program

• Interoperability - effort needed to couple one system with another

• Reliability - extent to which program performs with required precision

• Reusability - extent to which it can be reused in another application

• Testability - effort needed to test to ensure performs as intended

• Usability - effort required to learn, operate, prepare input, and interpret output

The graph below describes an example set of system quality attributes and their Tradeoff Points.

3.7 ORGANIZING THE SPECIFIC REQUIREMENTS

3.7.1 USER CLASS

The system consists of only general users and hence the system will behave in the similar way for every user accessing the system.

3.7.2 OBJECTS

The Health Monitor object consists of the following objects: - Register Object: This object contains the various details about the user entered during registration.

- User Object: This object contains the various details entered by the user after login to the application.

- Diet Chart Object: This object contains various information about the food and the amount to be consumed.

- Exercise Object: This object contains the various information related to exercises.

- Motivate Object: This object contains the information about the advantages of healthy lifestyle.

4. CHANGE MANAGEMENT PROCESS

All changes that impact this specification must be requested via e-mail to [email protected] or [email protected]. If accepted the change will be reflected in the next version of this specification.

Official versions of this specification will be found attached to the project Web site at http://cmaps.cmappers.net/rid=1HPP09T2V-1HQZPC4-N1G/Software_Engineering.cmap. Each version will be posted with the date as part of the filename. Accepted and rejected change requests will also be listed on the project Web site.

5. DOCUMENT APPROVALS

This specification is created as a part of ACS – 560 course requirements for an academic project. Approval of this document will be done by the advisor.

APPENDIX A

STAKEHOLDERS NEEDS

The understanding of customer problem that is to be solved is summarized as:  CN-1: The system should be user friendly

 CN-2: The system should be accessible remotely

 CN-3: The software should be not require any complex deployment procedure

 CN-4: The system should allow first time users to register to the application

 CN 4.1: The system should allow the user to enter his first name

 CN 4.2: The system should allow the user to enter his last name

 CN 4.3: The system should allow the user to enter his age

 CN 4.4: The system shall allow the user enter his city

 CN 4.5: The system shall allow the user to enter his state

 CN 4.6: The system shall allow the user to provide the country

 CN 4.7: The system shall allow the user to provide his username

 CN 4.8: The system shall allow the user to enter his life password

 CN 4.9: The system shall allow the user to reenter his password

 CN 4.10: The system shall allow the user to submit the details by clicking the ‘Submit’ button on the screen

 CN 4.11: If all the mandatory details are present, and passwords entered match, the system shall register the user and allow him to login to the application with his username and password. If the mandatory fields are missing, the system shall display error message showing the user to fill the mandatory fields that are missing. If the passwords don’t match, the system shall display a message telling the user to enter same passwords.

 CN-5: The system should allow the users to login to the application once they have registered.

 CN-5.1: The system should allow the user to enter username

 CN-5.2: The system should allow the user to enter the password

 CN-5.3: The system should allow the user to access the application if the username and password match. Otherwise an error message should be displayed to the user to enter correct username and password.

 CN-6: The system should let the user input their details.

 CN-6.1: The system should let the user input his/her age details

 CN-6.2: The user should be able to input his/her gender

 CN-6.3: The user should enter his height and weight

 CN-6.4: The user should enter his race/ethnicity

 CN-6.5: The user should provide the details of the chronic disease if he has any

 CN-6.6: The user should enter his/her diet details of a week. The user should give the details about his/her favorite food and some of the most frequently consumed food details.

 CN-6.7: The user should enter the details about daily physical activities. This should include the kind of physical exercises the user is involved in and also number of hours per day he is involved in it.

 CN-7: The tool should evaluate and provide feedback to the user about his/her present lifestyle

 CN-8: The tool should allow the users to print the feedback displayed on the screen.

 CN-9: The tool should generate a diet chart based on the user data.

 CN-10: The tool should allow the users to print the diet chart displayed on the screen

 CN-11: The tool should provide a fitness plan based on the user data.

 CN-12: The tool should allow the users to print the fitness plan displayed on the screen

 CN-13: The system should motivate the user to lead a healthy life style by describing the advantages of healthy diet and exercises.

 CN-14: The system should allow the user to logout of the application.

APPENDIX B

QUALITY FUNCTION DEPLOYMENT

Quality function deployment (QFD) is a “method to transform user demands into design quality, to deploy the functions forming quality, and to deploy methods for achieving the design quality into subsystems and component parts, and ultimately to specific elements of the manufacturing process.” QFD helps transform customer needs (the voice of the customer [VOC]) into engineering characteristics (and appropriate test methods) for a product or service, prioritizing each product or service characteristic while simultaneously setting development targets for product or service. Following diagram shows the QFD for “Health Monitor”.

Quality Function Deployment for Health Monitor

of 30 05/08/18f