Software Requirements Specification Personal Health Monitoring Application (PHMA)

Software Requirements
Specification
for
Personal Health Monitoring
Application (PHMA)

Version C

Prepared by George Roussis, Chris Guagliano,
Marvin Dizon, Michael Fung Quee

Hofstra University
Professor Scott Jeffreys
March 24, 2016

Software Requirements Specification vB for PHMA v1.0 Page 1

Table of Contents

Section Title Page
0 Contributors and Revision History 2
1 Introduction 3
1.1 Purpose 3
1.2 Document Conventions 3
1.3 Intended Audience and Document Overview 4
1.4 Product Scope 4
1.5 References 5
2 Overall Description 6
2.1 Product Perspective 6
2.2 Product Functions 6
2.3 User Classes and Characteristics 7
2.4 Operating Environment 7
2.5 Design and Implementation Constraints 8
2.6 User Documentation 8
2.7 Assumptions and Dependencies 9
3 System Features 10
3.1 Functional Requirements 10
4 Other Requirements and Concerns 13
4.1 Nonfunctional Requirements 13
4.2 Security and Confidentiality Requirements 13
4.3 Safety Concerns 14


Contributors

Contributors
Name Contributed To
George Roussis Introduction, Requirements, Security & Safety
Chris Guagliano Overall Description, Requirements
Marvin Dizon Overall Description, Requirements
Michael Fung Quee Overall Description, System Features, Requirements

Revision History

Date Version Reason For Changes
2/11/2016 A Initial Requirement Specifications Document
3/24/2016 B Updated To Reflect Feedback Comments and Project Progression
3/26/2016 C Updated Requirements Based on Project Progression


1. Introduction

1.1 Purpose

This document describes and sets forward the requirement specifications (SRS), both functional
and nonfunctional, for the Personal Health Monitoring Application (PHMA), version 1.0,
developed by George Roussis, Chris Guagliano, Marvin Dizon and Michael Fung Quee during
the Spring 2016 semester, specially prepared for Professor Scott Jeffreys. This document will
illustrate and provide the overall description, purpose, usage, and detail the development
concepts of the application. In addition, this document seeks to explain the drafted interface of
the application, and the interaction between PHMA and applicable API’s. Additionally, this
document will serve as a tool for the design/development team, managers, and software testers
involved in this project, to better understand the full scope of this application.

The purpose of this software application is to provide a clear, easy to use, and informative
application for users to track and visualize their overall health.

1.2 Document Conventions

When writing this SRS for the Personal Health Monitoring Application, the following
terminologies and standards are used:
● Application Program Interface (API): a set of programming instructions and standards for
accessing a Webbased software application or Web tool.
● Application : a software or program which is designed for use by an enduser for specific
operations.
● Android :
Android is a mobile operating system (OS) currently developed by Google,
based on the Linux kernel and designed primarily for touchscreen mobile devices such
as smartphones and tablets.
● National Nutrient Database for Standard Reference (NDB): An API provided by the
USDA intended to primarily to assist application developers wishing to incorporate
nutrient data into their applications or websites.
● Notification: an alert delivered from the application to the enduser’s device.
● User Interface (UI): anything that the user of an application may see, interact with, or
experience
● SQLite : Crossplatform C library that implements a selfcontained, embeddable, zero
configuration SQL database engine which does not require a network connection.
● BMI (Body Mass Index): a weighttoheight ratio, calculated by dividing one's weight in
kilograms by the square of one's height in meters and used as an indicator of obesity
and underweight.


● Functional and Nonfunctional requirements follow a 1 to 5 level priority scale, where
priority level 1 is of lowest importance, and level 5 is of highest importance.
● Every requirement statement has been given it’s own priority level, and have not been
inherited.
● This document uses Arial font throughout the entire document. Major headerlines use
size 18 font. Subsections are denoted in italics, size 14 font. All other portions of this
document use size 11 font. All sections and subsections are numbered accordingly.

1.3 Intended Audience and Document Overview

This document is intended for the software development team, managers, testing team and
planners, documentation group, and other groups interested or involved in this project.

The remainder of this document contains the overall product description, and the technical
system requirements specifications (functional and nonfunctional) for the application. It is
suggested to read this document in chronological order. Section 2 will discuss a higher level
description of the intended product, its implementation (such as operating environments), and
projected use and users of this product. Sections 3 and 4 will discuss and present detailed
descriptions of the specific requirements for the intended project, to include functional and
nonfunctional requirements, and the application interface requirements, which details the
interaction between the enduser and the software product. Sections 3 and 4 is intended to
highlight the major components and features to be included in the Personal Health Monitoring
Application as well as potential security, confidentiality and safety concerns. The document is
concluded by a Glossary of terms and abbreviations used throughout this document and
analysis models — a combination of text and diagrammatic forms to depict requirements for
data, function, and behavior of the intended health application.

1.4 Product Scope

The final product is intended to be a personal health monitoring or tracking application. The
application is intended to be used multiple times, daily, by the user as a tracking and information
service. Users will be able to track their daily food and meal intakes, and other health attributes.
The application will be able to compute standard health measurements such as BMI and total
caloric intake, and provide a historical, easy to understand and clear graphical interpretation of
the results. The final product will be able to determine food information (such as the amount of
protein, carbohydrates, etc.) when the user inputs their food, by pulling information via an API,
such as the USDA National Nutrient Database for Standard Reference, or NDB. The product is
intended to help the user be more informed about their overall health by providing trends and
data, and sending notifications to the user should their goal be exceeded, allowing users to
make healthier decisions in their life. The application is intended for use by anyone who is
interested in in personal health, or wants to be “more fit.” The final product will be available for


use on Android mobile device platforms via installation or download and is intended to be simple
and easy to use.

1.5 References

This document builds upon the following references:
● IEEE Software Specification Requirement template
● United States Department of Agriculture Agricultural Research Service:
http://ndb.nal.usda.gov/ndb/api/doc


2. Overall Description

2.1 Product Perspective

The final result of this project is a product that is a member of the “health and fitness”
application category. Some examples of applications in this family are: MyFitnessPal, Weight
Watchers, Fitness Buddy, and the like. This health application will be a selfcontained product
that encompasses features that will help the consumer to an easier and more efficient way to
live a healthier life. The main features of the software application include:
● User account login : The product will allow the user to create accounts or profiles,
providing the user the ability to update and view their own personal profiles.
● Home Page or Dashboard: a tab in the application that makes available to the user the
most important health information and attributes, including: how many calories to intake
per day, etc
● Progress : a tab in the application that provides graphs referring to certain date ranges(i.e
weeks,months) that have results such as showing the amount of weight gained/lost, the
influx of amount of calories eaten throughout the week, etc.
● Log : a history tab or database of activities logged and completed on a specific day.
Some examples include: what was eaten that day, amount of calories consumed,
number of pounds lost/gained that day, etc.
● Search : A search tool that enables the user to explore specific foods and/or drinks in
which the system will provide information such as calories, amount per serving, proteins,
carbohydrates, fats, etc.

2.2 Product Functions

A brief summary of the major product functions and what the enduser may perform on the
PHMA includes the following:

● User profile: Enable the user to input their weight, height, weight loss goal to make a
standard profile for the user
● Food search: Enable the user to search for nutritional values for certain foods and
beverages that they intake which then they can add to “log” tab for that specific day.
● Food tracker: Provide an interface for the user that shows their total calorie intake for the
day and warns the user if he/she is approaching the limit for that day(i.e. too much
carbohydrate intake or too less protein intake)


● Goal tracker: Enable the user to input a “Desired Weight Goal” which is the weight goal
that the user wants to achieve. The Desired Weight Goal will be used by the application
to show the evaluation and progress of how the user is doing towards that goal. For
example, a small message box will popup once the user opens the application and
display a message describing the progress towards the Desired Weight Goal.
● Graphical output:
Ability for the user to view their progress as a graphical output, over
time ranging from days to months.

2.3 User Classes and Characteristics

The initial users of our application front end will be health and/or fitness conscious individuals
who are familiar with operating and navigating a mobile application on Android and/or computer
devices. Health and/or fitness conscious individuals that may use this application include (but
are not limited to), personal trainers, athletes, dieters, and people looking to live a healthy life.
This software application will not be focused on meeting the needs of people not interested in
personal health.

Initial users may take a few brief moments to familiarize themselves with the application UI and
operations, however the application should be easy to navigate, learn and understand.

2.4 Operating Environment

The application will be specifically designed for use on mobile devices running Android OS 3.1
and above. Although it is not suggested, the application can run on an Android Tablet. Please
note that the application’s UI will be optimized for use on mobile Android devices with a screen
size of approximately 5.1 inches. In order for the user to obtain the application, it will be
available for download via the Google Play Store and the user must have access to an internet
connection. Once the application is installed, the user can access and/or alter their information
(eg. name, height, weight) without an internet connection. The user’s data will be stored in a
SQLite database which utilizes the phone’s storage as opposed to a SQL server. The only
problem, with this, in extreme cases, is if the user’s memory is full. Such a case is rare in this
day and age when mobile devices come standard with 32 GB or more memory. An internet
connection is required to look up calories for food. This operating requirement is caused by the
application’s need to access the NDB.


Figure 1. Operating Environment Diagram

2.5 Design and Implementation Constraints

Numerous limitations apply to our software engineering group. Specifically — three out of the
four developers have never made an application, and as a result, we have chosen to develop
for Android mobile platforms since it is written in Java, a language that the entire group is
comfortable with. Making an application is much more than writing simple Java code, creating a
steep learning curve for the group while using Android Studio. Producing a clean and intuitive
layout is something to be desired, and none of the group is familiar with UI design. This might
cause problems in the functionality and experience of the application, as a whole. Lastly,
graphing the user’s data could cause setbacks if Graph View open source libraries are poorly
documented.

2.6 User Documentation

A “Help” page will be available on the application providing explanations to all processes,
including but not limited to tracking a user’s . Aside from this, the user can email any of the
developers should a question arise which cannot be answered within the “Help” page.

As this application product is being designed and marketed to be clean, simple and easy to use,
ideally, the application will require no additional explanation or support. However, a common
FAQ and steps document will be available to users.


2.7 Assumptions and Dependencies

● We assume that the user has access to an Android mobile device.
● We assume that the user is aware of common functionalities of Android mobile devices.
● We assume that the user has a valid internet connection to be able to access nutritional
information through the NDB.
● We assume that the user will be able to find the nutritional information of consumable
items not listed in the USDA NDB database
● We assume that the user has enough memory to install and operate the base application
● We assume that the user does not have any significant physical impairments that could
deter the use of this application (color blindness, blindness, missing limbs, etc.)
● We depend on the USDA NDB API and servers be running and functional at all times.
● We depend on the correct operation between the application and SQLite databases.
● We depend on a prefabricated health application template (to be determined).
● We depend on an Android open source graph plotting library, titled Graph View, and its
accompanying documentation in order to plot and incorporate graphs.


3. System Features

3.1 Functional Requirements

Enumerated condensed functional requirements:
Requirement ID Requirement Priority
F/REQ1 This application will allow the creation of a user account. 2
The user should be able to specify his/her name, gender,
F/REQ2 height, weight and age in a user profile. 5
F/REQ3 The user should be able to change profile data as needed. 4
The application should have a homepage/dashboard which
displays user daily health information (total calorie intake,
F/REQ4 current weight, BMI, etc.) 4
The application should be able to calculate and display the
users BMI based on the information the user provided.
F/REQ5 (height, weight) 5
The application should output the user's historical data (such
F/REQ6 as weight, BMI) in a graphical manner. 5
The user should be able to document food/drink/meal intake
by entering the name of their food and any other known
F/REQ7 information about the food. 5
The application should be able to seek nutritional information
(calories, protein, etc.) via a database by taking input from
F/REQ8 the user. 3
User can define their own consumable item with a name and
F/REQ9 nutritional values 3

The Personal Health Monitoring Application will provide a variety of features to help users meet
their health and physical fitness goals. The features of this application will perform as follows:

The user of this application will be able to specify some initial information to create a
profile. This initial information, the User Profile, will include the user’s name, gender,
height, weight, and age. The information specified is necessary for the application to
display estimates and relevant data later on. When the user enters the application for the
first time, there will be a button on the screen that says “Create a new profile.” Once the
user presses this button, the application will display a new screen with several labeled
text boxes, in which, the user will input profile information. Once the user is finished, they


can either choose the “Cancel” button to save their changes or the “Confirm” button to
save changes.

After the creation of a profile, users may go back into their profile settings at anytime and
make changes as desired. This is done so that if the user made a mistake when creating
their profile or if there is some significant change with their body, it can be accounted for.
From the Homepage, there will be a button labeled “Settings.” Upon pressing this button,
the application to display a new page. One button on this screen will be labeled “Change
Profile Settings.” When this option is selected, the application will display a page similar
to that of creating a new profile. Once the user is done editing their settings, they can
either choose the “Cancel” button to not save any changes or the “Confirm” button to
save changes.

This application will contain a homepage/dashboard where a user can view daily health
information. The homepage/dashboard will display such things as the user’s total calorie
intake, their current weight, their BMI, and any other relevant health information. The
idea is to make the user’s health information readily available whenever the application
is accessed. The Homepage will also be the main screen from which users can select a
variety of different functions that the application has to offer..

This application will be able to calculate and display the user’s BMI (Body Mass Index)
based off of the weight and height provided in the user’s profile.The BMI will be used as
a general guideline to determine whether or not the user is healthy. This data will be
available on the user’s Homepage of the application.

The application will have a function to display a user’s historical data in a graphical
manner, the Graphical Output . The graph should serve to better the user’s
understanding of their progress or lack thereof when following a health plan. Graphs can
be created for any data that was previously inputted or calculated, including but not
limited to: weight, height, and BMI. There will be a button that can be selected from the
tab on the Homepage labeled “Graph my Progress”. When the user presses this button a
new screen will be displayed with the header “Graph by”. The page will also contain
several options to choose from which are labeled “weight”, “BMI”, etc. once an option is
selected, the user must press the “Cancel” button to return to the homepage or the
“Confirm” button to be brought to a page displaying the desired graph.

This application will allow the user to document their food/drink/meal (consumable item)
intake by entering the name of their desired consumable item using the Food Tracker.
The user will be able to save information about their consumable item intake on a daily
basis. On the homepage, there will be a tab that the user can drag across screen. One
of the buttons on this tab will be labeled “Daily Intake.” When the user presses on this
button, the application will display a page where the user can view their current intake
and button labeled “Add to Intake” that will allow the user to add new consumable items


to their daily intake list. The application will calculate the total intake thus far. The user
also has similar options on the Homepage tab for food and drinks individually.

Upon input from the user, the application will be able to search for nutritional information,
such as calories, fats and proteins for certain consumable items. These consumable
items will, by default, be defined by the application. So, if the user does not know the
know the nutritional value of any consumable items, the application can help provide an
estimate for them. On the homepage, there will be a text box with a button labeled
“Search” on the right side of the text box. Once the user has inputted a consumable item
name of their choice, they must press the “Search” button to display a new screen with
links to consumable items similar to what was specified in the search text box. When the
user chooses a link, a new page will be displayed that shows the nutritional information
of the desired consumable item. It is to be determined if whether this part of the
application will have additional functionality. Future functionality would allow a user to
add foods selected from this search to their “Daily Intake,” “User Defined Consumables,”
etc.

Additionally, a user may define their own consumable item. In the definition of the
consumable item, the user will be able to specify a name for the consumable item and
input any known nutritional value information. This information can be saved for future
use in the application. The user must press the “Settings” button on the homepage in
order to access this function. One of the options in the “Settings” display screen will be a
button labeled “User Defined Consumables”. After pressing this button, a new screen will
be displaying showing a list of the consumable items that the user has already defined
(nothing if the user hasn’t defined any). Additionally, there will be a button labeled
“Define New Consumable”. Upon pressing this button, the user will be prompted to enter
the name of their consumable and nutritional information that the user is aware of. To
leave this prompt, the user must either press the “Cancel” button to exit the prompt
without saving their input or the “Confirm” button to save their new consumable item to
the list.

The application will have a notification system available. The notification system will
initially display a message on the user’s screen in the event that their daily total calorie
goal is exceeded. The functionality of this system may change in the future with more
options to choose from in the settings menu.


4. Other Requirements and Concerns

4.1 Nonfunctional Requirements

Enumerated nonfunctional requirements:
The application should be able to keep a database
NF/REQ1 for all user data. 5
NF/REQ2 The application should be easy to use/user friendly. 5
The graphical data should be displayed in a clear
NF/REQ3 and neat way. 5
The application response should be quick. (i.e.
NF/REQ4 clicking a button, calculations) 4
The application should require minimal
NF/REQ5 maintenance. 2
The application should be reliable, with minimal
NF/REQ6 bugs/crashes and downtime. 3

4.2 Security and Confidentiality Requirements

Due to the sensitive nature of the data this application product will be producing, accepting and
storing, it was determined that specific security and confidentiality requirements were needed:
The system should be secure enough so that
personal health data may not be disclosed
SEC/REQ01 inappropriately or unauthorized. 5
System Application will have a secure "passcode" to
protect the enduser application from unauthorized
SEC/REQ02 access. 5
Developers will maintain the confidentiality of all
SEC/REQ03 user data knowledge. 5
PHMA will not affect any other applications or
software installed on the enduser's mobile device
nor will it cause any damage to the device or its
SEC/REQ04 internal components. 5


4.3 Safety Concerns

Potential safety concerns associated with the use of the application include:
● Endusers should not use the application while driving, operating machinery or in any
other situation in which the enduser’s focus is imperative.
● Endusers should consult with a doctor and other appropriate medical personnel before
making significant medical decisions based on information provided and/or accessed via
the PHMA.
● The developers of this software application product are not responsible or liable for any
advice, course of treatment, diagnosis or any other information, or consequences as a
result of information provided, accessed or disseminated via the PHMA.
● The PHMA is not intended for emergency medical use. In case of an emergency, users
should contact 911 or their primary doctor.

Software Requirements Specification Personal Health Monitoring Application (PHMA)

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Software Requirements Specification Personal Health Monitoring Application (PHMA)

Загружено:

Авторское право:

Доступные форматы

3.1 Functional Requirements 10

4.1 Nonfunctional Requirements 13

4.2 Security and Confidentiality Requirements 13

4.3 Safety Concerns 14

Вам также может понравиться