SECTION A: Sprint Backlog
The sample sprint backlog for the Personal Health Assistant project is shown in Figure A.1.
This
is
a
variant
of
the
sprint
backlog
on
slide
25
of
http://www.engr.uconn.edu/~steve/Cse2102/finagile.pptx and captures. There are four product
backlog items (PBIs –see Figure F.1 in Section F).
For each item, there is:



Primary and secondary individual in charge of the item (initials)
The different task for the PBI in the sprint.
Effort in hours for weeks 1, 2, 3, and 4
Note that each team member is 10 hours/week or 40 hours for the sprint.
The excel spreadsheet is an embedded object in MS word. You can right click, Worksheet
Object, Open and it will open the spreadsheet in excel. You can use this as a template for your
sprint backlog.
Note that as a rule of thumb we are going to establish that each team member works for 10 hours/week on the project
Each team member should add up to a total of 10 hours for each week across all of the various tasks
BD, LN, WL, etc. are the initials of each team member and there are both primary and secondary (backup)
Primary
Secondary
Description
Week 1
Week 2
Week 3
Week 4
Total Estimated Days of Effort:
BD
WL
MS
LN
JD
WL
BD
WL
LN
JD
BD
LN
BD
WL
LN
JR
JR
LN
Medication Management
Improving editing and modifiation of medication data
Enhancing and debugging the GUI
Supporting uploading of images (pill bottles, pills, etc.)
Allergies
Improving editing and modifiation of allergy data
Enhancing and debugging the GUI
Conditions
Improving editing and modifiation of chronic medication conditions
Supporting tracking of data for congestive heart failure
Supporting tracking of data for diabetes
Supporting tracking of data for asthma
Figure A.1 Sprint Backlog for the Personal Health Assistant Project.
1
4
4
2
4
2
4
4
2
4
4
0
0
2
4
4
2
2
2
2
2
2
2
2
SECTION B: User Stories/Use Cases
The initial use case diagram of PHA is shown in Figure B.1 and illustrates the main
possible actions of both the patient and the health care provider. The patient has a profile
designated by his or her personal Microsoft HealthVault account. By signing in through this
account, the patient will have the options, through the PHA to record daily activity, use the
disease center to monitor specific health concerns, and use the medication center to track and
record medication and nutritional supplements. On the other end, the health care provider will
have his or her own profile and will be able to view the patient information, analyze information
recorded by the patient, provide feedback and request additional information.
Figure B.1: Use Case Diagram for PHA Patient and Provider Users.
There will be another component (server side) of the proposed system to handle disease
specific analysis. Advanced analysis, such as graphs and algorithms (e.g. diabetes algorithm),
will occur when the health care provider accesses the information. In this way, the interaction
between HealthVault and the patient user end remain very basic, simply receiving a request and
2
either storing or relaying a JSON object. The patient use case diagram in Figure B.2 details the
patient and interface interactions.
Figure B.2: Use Case Diagram of Patient Options
The provider app allows the healthcare provider as shown in the use cased diagram in Figure B.3
to review medication information and daily measurement input from their patients. It would also
alert the healthcare provider of any potential threats to the health of the patient based on the data
provided by the patient. This interface will allow the health care provider to take the following
actions: view the patient information, analyze information recorded by the patient, provide
feedback and request additional information.
3
Figure B.3 Use Case Diagram of Health Care Provider Options
From a healthcare provider’s perspective, he/she has the option to specify requested information
in addition to the default options on the user interface end. Mainly, the healthcare provider
interface provides means to view and analyze the data and give patient feedback. This is not
done through direct communication with the patient, but again through HealthVault using JSON
objects. The health care provider end holds the functionality for advanced analysis
SECTION C: User Based Specification/Interfaces
The current conceptualization of the PHA with its current and to be include features include a
series of screens as shown in Figure C.1 that will have options corresponding to each of the
possible patient actions: Profile, Medication Center, Disease Center, Daily Activity, and Settings.
We examine each of these options in turn.
The first screen (upper left in Figure C.1), allows the user to enter their personal
information, such as name, age, gender, profile picture, and Windows Live ID account. Since
Microsoft HealthVault allows the user to sign up using a Facebook account, we have included an
option that allows the user to link their Facebook account and HealthVault database. Users who
don’t have either account can create a Windows Live ID in this section or in a separate browser.
The bottom half of the screen also shows the medicines that user is currently taking.
The Mediation Center (shown in the upper middle of Figure C.1) keeps track of the
medicines the user is currently taking and gives information on medication. The medications are
categorized in the disease the medicines are related to. When a user selects a medicine from the
drop-down menu, related information to this medicine is displayed, such as the last time the user
has taken the medicine, recommended daily intake, and instructions on medication.
The Disease Center (shown in the lower left of Figure C.1) is the place for a patient to
manage and keep track of their condition, gives patient data which is related to the disease the
patient wishes to track, and generates diagrams and graphs to allow the patient to see a
progression in their health.
4
Figure 5: PHA Screen Shots – Patient Version.
Figure C.1 Patient and Provider Screens
The Daily Activity Screen (shown in the lower middle of Figure 5) lets the patient enter
in daily information. This includes their diet, medication intake, exercise, and other data related
to the specific diseases (daily measurements). The data entered is then uploaded to Microsoft
HealthVault using an openEHR. Finally the settings option let users modify their personal info,
alerts setting, reminder, sync calendar, backup data, and privacy settings.
5
Section D: Detailed Design
Class Diagram –B.D.
The software design for the mobile component of the project in Figure D.1 will follow a
model view controller (MVC) design. In this case the model will encapsulate the disease, fitness
and dietary information of the user. Though it will not store the specific information, it will have
the methods to interact with the server and retrieve the data to relay it to the view. The view will
be the user screen specific to the model that will allow for easy user interaction. The motivation
of the MVC pattern is to make the model independent from the views. This allows the interaction
of the application with the server to be independent and isolated to the model which contains
access to the information. In the future, if any changes are made to the interaction of the model
with the server, the view can remain unchanged. This abstraction allows for a greater
maintainability of the code by separating the server interaction from the model that stores the
data and the user interface. This is aided with the use of the observer pattern. The observer class
will provide a mechanism to alert other objects of state changes without introducing
dependencies on them. The individual views implement the observer interface and register with
the controller. When a view changes, the controller will be notified and make appropriate
adjustments to the information the model has to access and display the appropriate modified or
new view with the updated data. In this way, every time the user moves to a new page or
refreshes a page, she/he will view the most up to date information. This will also make different
views of the same data possible, for example if the user would like a pie chart versus a table to
view data.
The models will also have a mediator class that will observe and control interactions
within the model class and subclasses. The main model class will have three subclasses, each
built to access data applicable to the three major components of the project: Fitness, Disease, and
Diet. Due to our need to implement specific data for specific diseases, the DiseaseModel will
have four subclasses, one for each disease. Also, each disease will know how to access and
submit its specific data to the database using the secure server compatible with Microsoft
HealthVault. This will make the addition of any new diseases very simple. Similar to the already
existing diseases, the specific disease model will be registered with the mediator.
The mediator is responsible for handling all communication from the models. One major
goal of the design for understandability and simplicity is to eliminate redundant information.
This is why the disease is separated from the diet and the fitness models. Almost all of the
diseases require information from these two categories and to repeat entering the information
would be both tedious to the user and redundant for the programmer. Instead, the mediator will
keep track of what information is required from each model and inform the controller
appropriately. Therefore, for a patient monitoring both obesity and asthma, the information in the
models will interact appropriately. Diet and carbs will be handled in the dietModel, fitness will
be handled in the exerciseModel and the blood glucose will be handled in the DiabetesModel,
which is a subclass of DiseaseModel. However, all the information can be accessed together for
an overall health view using the mediator, which will know of all the models and will be able to
retrieve the appropriate information using those models for the controller.
The controller will act as an intermediate between the models, which access and push the
information to and from the server, and the view, which will display the information and interact
with the user. The controller will interact with the mediator to pass data to and retrieve requested
information from the appropriate model. The model never actually saves or stores the
6
information, it simply knows how to accesses and push data to the server to eliminate security
involved with storing any personal data directly on the device. The controller will also be
responsible for navigation between views, and, as explained above, will be notified of requests
through the observer. Therefore, when a new DiseaseModel is added, it will be registered with
the mediator, controlled by the controller and then displayed using a specific view evoked by the
controller to display the appropriate information.
Figure D.1: Class Diagram
Entity-Relationship (ER) Diagram (Figure 1.5)– J.R
The ER diagram is subject to change after digging a little deeper into the interaction of
both new applications provided by Alberto. There is a definite use of a MySql database via the
HVMLS service for provider information but its real structure is unknown at the moment. The
ER diagram shown below (Figure D.2) is still the closest diagram representing the database that
we believe is accurate. If there are any changes, they will not be very different. The biggest
change will be the organization of tables and the introduction of more roles other than just
Physician and Patient. There are also more roles for the provider that define their specialty as a
doctor and therefore can see different set of patients.
The relational model starts with the user as a central entity. The user logs into an account
that contains their userID as their primary key, username and password, their role, and
HealthVault login credentials. The role specifies whether the user is a patient or a type of
provider. The userID will provide the ability for the tables to interact with one another and keep
patient and providers tied to each other. It will also serve as an identifier for each user’s security
rules. When the user logs on and is a patient, the system will search all the physicians that the
user is sharing information with and display it on their settings screen. If the user is a provider,
then the list of patients will appear on their main screen with options to request further
7
information about each patient. The provider app uses the database to look up the stored patient
id and record ids.
The patient will be able to search for physicians he/she can add to their shared list. Once
information is shared, Figure D.2shows that the patient can share with N amount of providers,
while the providers can have access to N amount of patients. It is also important to add that every
user must have an account with a UserID and supporting information. Permissions are also a big
part of keeping the security aspect of PHA a priority. Although Alberto handles most security
aspects, the team needs to implement the sharing function on the patient application and
therefore the permissions. Each patient will have the permissions that tells the view and
controller what information to show the providers. These permissions can only be changed by
the patient.
Figure D.2: Entity-Relationship Diagram
Activity Diagram -W.L. (Patient App)
The first activity diagram in Figure D.3 describes how the user is likely to use the
application. To start, they would either create an account for new users or login for returning
users. Once logged in, the main menu would appear allowing the user to accomplish different
tasks. The profile screen would allow the user to view basic information about their health. The
settings screen would allow the user to change personal information including permission
settings. The Daily Activities screen allows the user to input data to be uploaded into the
Microsoft HealthVault. The data from the database can then be used to display data about
individual diseases. The Medication center gives the user information about their medications
including instructions and daily dosage.
This second activity diagram in Figure D.4 shows how the typical provider/doctor is
likely to use the provider PHA application. Typically, the provider will enter enter in their login
information which contains a username and password. After logging in, the provider will be able
to go to a list of all of their patients who are using the patient PHA application. From this list,
the patient can search for a patient by different categories. The provider would then be able to
view different aspects of the patient’s health. This includes different types of conditions,
allergies, medications, procedures, and lab tests. The provider can also view the patient’s
wellness which includes energy, happiness, comfort, mobility, and appetite which are rated by
8
one to 1 to 10.When viewing the patient’s current conditions, the provider can view health data
history to determine if action needs to taken. If it does, then the providers can notify/give
feedback to the patient through the application. The Provider can also view/edit allergies,
medical procedures, and lab tests as well as view the wellness of the patient. The provider can
also check-up on other patients in a single activity by going back to the patient list at anytime.
Figure D.3: Patient Activity Diagram
Figure D.4: Provider Activity Diagram
9
PHA State Diagrams
The state diagram for the initial stage in Figure D.5 is for when the patient starts the application,
the login screen will be shown initially. The patient then chooses one of the three options: Create
Account, Log-in, or Quit. The Login Menu will let the patient enter account name and password.
When they press “Log In”, it goes to the main Menu. If the patient chooses to create account,
he/she setups a PHA Account first, then go to HealthVault Account Selection Screen. Since MS
HealthVault allows patient to use either Windows ID or Facebook to login, we also let the
patient to choose which account they prefer to associate with PHA. When they are done and
press confirm, the application will automatically login and show the main menu. If the patient
press “Quit” or press home button, the patient exit PHA and goes back to mobile OS.
Figure D.5: Initial State
In the main menu state in Figure D.6 , the users are allow to choose one of five options
from the main menu: Profile, Medication Center, Disease Center, Daily Activity, and Settings.
When the user click an option, the app will open another window that shows the chosen option.
User can go back to this screen by pressing the physical back button on Android phone, or back
button on the navigation bar if using iOS device.
Once the patient presses “Profile” as detailed in Figure D.7, his/her personal information
and the medications they are currently taking will be shown in this menu. The patient can change
their personal info by pressing “Edit Account”, it goes to “PHA Account Edit Menu” and goes
back to Profile Menu when pressed “Confirm Changes”. It also allows the patient to change their
linked HealthVault account. The center of this menu is where “Current Medications” shown. If
they press one of the medicines, it directly goes to “Medications Center” and display the detail.
10
Figure D.6: Main Menu
Figure D.7: Profile
When the patient select “Daily Activity” as detailed in Figure D.8 from the Main Menu,
it goes to “Daily Activity Menu”. In this menu, the patient can choose a sub-menu “Diet &
Nutrition”, “Exercise”, and “Daily Measurement”. “Diet & Nutrition” menu shows the patient’s
11
diet chart and nutrition intake. He/She can directly updates diet info on the screen without going
to other menu. “Exercise” shows the fitness information and let patients update their fitness info.
“Daily Measurement” shows their Blood-Glucose or Peak-Flow measurement in a time chart.
This submenu allows the patient to input their measurement directly.
Figure D.8: Daily Activity Menu
Sequence Diagram- Patient Application (Linh Nhan)
A patient using the PHA App will be able to follow a sequence of steps when using the
application. Figure D.9 begins by showing that the patient will have the option to open the
application and close the application. When the patient chooses to open the application, they
will be directed to the log in screen where they will be able to log into the system using the
credentials they already have or sign up for an account if they are not registered yet. From
Figure 10, it is shown that the paths differ slightly in the beginning, but the destination, the main
menu and the actions that can be performed, are the same. These just reflect the different
choices the user can make when entering the system and then the steps that can follow. When
logging in with existing credentials, the patient is directed to the main menu screen upon
successful log in. If the patient chooses to sign up for an account, they will be able to choose to
create an account using a Windows ID or a Facebook ID. When a choice is made, the user will
then create the account where they will be able to fill out relevant information pertaining to the
account such as their name as well as the health issues pertaining to them. After filling in the
appropriate information, the patient, when they are done confirming the information in the
account, will be directed to the main menu screen. This is the part in Figure D.9 that the patient,
no matter which step they chose in the beginning, will be performing the same actions. Each of
these tasks can be performed one at a time by the patient. For example, the patient can choose to
go to any of the following screens: Profile, Medication, Disease Center, Daily Activity, or
Settings where they will be able to view and edit the information on these screens as they see fit.
Of course, he/she will only be able to edit one of these at a time. For example, the patient will
not be able to simultaneously edit their daily activity and the medication they are taking. When
12
the user has finished editing or viewing the content they wish, they will then close the
application, which will return them to their phone or tablet’s home screen.
This sequence diagram was based off of the state diagram that shows what the user is
able to do, but it shows the sequence that the actions can be performed in. Furthermore, it only
shows the action of one user versus what can be done simultaneously by other users such as what
is displayed in our activity diagram. For example, the user, before being able to view their
profile or medications, must be able to successfully log into the application first. Figure D.9
shows the beginning steps of a patient using the application up until the patient chooses to close
the application. Figure D.10 represents the sequence diagram for the provider. There are slight
differences in capability or what the provider is able to do as opposed to the patient when using
the application.
Figure D.10 depicts the actions that the provider is able to perform when using the
application. Similarly to the patient, the provider can open and close the application. When they
open the application, they will be directed to the log in screen where they will have the option of
logging in with their existing credentials or to sign up for an account if they are new to the
application. When the provider signs up for an account, they will be directed to an account
creation screen where he/she will have to fill out their account information. Once they confirm
their account, they will be directed to the main menu, which is where a provider, who logs in
with existing credentials, will be when they successfully log in. From Figure 11, it is shown that
the actions of new providers and returning providers will be the same; they will be able to view
the patients they have. New providers may or may not have patients in their list depending on
their interactions with their patients and if they have already shared information. After viewing
the patients, the provider will have the option of viewing and managing the information on
specific disease pages relevant to the patient. For example, the provider will be able to view the
Diabetes status of their patient. When they view the information, they will be able to make
recommendations and changes as necessary; once the provider chooses to save the changes, a
message will be sent to the user as well as a successful message returned to the provider. The
things that the provider will be able to manage and update will be dependent on the disease of the
respective patient they are viewing. When the provider is done tending to the patients, they will
then close the application, which will direct them to the respective screen on their phone or
tablet.
13
Figure D.9: Sequence Diagram for Patient using Med App
14
Figure D.10 - Sequence Diagram for Provider using Med App
15
Section E: Test plans
UI Testing
The user interface testing that will be done on personal health assistant, or PHA for short,
will be to show that not only do the screens appear in the correct order, but also that the screens
will not cause an error when opened. There are some screens for our application that we are
currently not able to test at the moment due to the fact that we have not created them yet such as
the reminders screens and the lab tests. When we implement these pages, we will be able to test
whether or not they work using the same approaches we are using in the test cases described
below. The test cases we will do for user interface testing will be done for both Android and iOS
platforms, but the images depicted below may select one or the other to display the
results. Furthermore, the entire Android emulator will not be shown unless the right half of the
emulator (which reflects the hardware of the phone, such as the menu button, back button, and
the physical keyboard) is explicitly used in the test case we are currently testing. Because we
have been concentrating on pushing and pulling data to and from the server for our second
prototype, we have not implemented the verification process yet. In other words, we have not
implemented the value checking needed for the inputs. As of right now, all of our inputs are
stored as strings as most of the information inputted are values such as names, descriptions, and
instructions.
Due to the wide range of screens that our provider and patient applications have, we will
not be including a screen shot for all of the screens in this user interface testing document. For
example, we have similar functionality in both the patient and provider applications that we will
perform the testing for, but we will only display the screen shots for the patient version. Also,
we will display the user interfaces for only some of the tabs for either Android or iOS. Since our
general process of performing the tests can be seen, the testing for the next couple of screens will
follow in a similar fashion. The following bold pieces of text state the general overview of the
test case we are going to be performing. When the user wants to go back to a previous page in
the Android application, they will be hitting the back arrow on the hardware side of the Android
emulator. This is slightly different than iPhone.
Opening the Application:
When the application begins, the first screen the user should be directed to will be the log
in screen; since we do not have security implemented on the Android version yet, we are not able
to verify the user based on username and password. For now, the user can get into the conditions
screen on the Android application simply by clicking the “Log In” button. Since both
applications, when launched, direct the user to the log in screen, we know that this test case
passes the order we are imposing on the usage of the application. Figures E.1 and E.2 show the
successful launches of the application to their respective log in screens.
16
Figure E.1: Android log in
screen
Figure E.2: iPhone log in
screen
After entering in a username and password (that is not verified) on iOS or by clicking the
“Log In” button on the Android application, the user will be directed to their conditions page.
Since the user is able to see the condition screen, we know that the log in was successful.
Figure E.3: Android conditions screen
17
Figure E.4: iPhone conditions screen
Viewing Allergies:
On the Android application, we will show that when you click on the “Allergies” tab that
the corresponding allergies screen displays appropriately. While the data is being generated or
pulled from the server then the screen will display a loading message to the user as shown in
Figure E.5. Figure E.6 depicts the screen successfully; all of the allergies that this patient have
are listed on this screen. Figure E.7 shows the user clicking on one of the allergies to view the
details of that allergy. The details of the allergy selected will be depicted in Figure E.8. To get
to the Figure E.10, we have to first select the menu button on the right half of the Figure E.8.
When you select this button, the edit option will appear on the bottom of the screen that, when
selected, will result in the redirection to the edit screen as shown in Figure E.9. Figure E.10 will
be displayed for the edit screen for editing allergies, but we have not implemented the backend
for these pages yet. For example, we have not populated the values on the allergy you are
currently editing on the screen when edit is opened so what you will see are empty fields with the
hint text displayed. There is also a button in Figure E.10 called “Save Changes” that, once
implemented, the user will be able to save the changes they make to the allergy they are editing.
Figure E.11 will show the popup that comes when the user selects “Delete Allergy” shown in
Figure E.8. The user is able to select whether to continue with the deletion or cancel, but the
backend for this has not been implemented yet.
Figure E.5: Android allergies
loading screen
18
Figure E.6: Android allergies
loaded on the screen
Figure E.7: Selecting an
allergy
Figure E.8: Details of the
selected allergy
Figure E.9: Trying to edit the allergy
Figure E.10: Edit screen for the allergy
Figure E.11: Deleting an allergy
Figures E.5 through E.11 depict the steps the user will follow when viewing and editing
(although currently a dummy screen) the allergy. Conditions and medications also have these
capabilities that are not displayed since the testing for it would have been done the same way.
Since none of the screen produced an error, the interfaces were successfully running, which
means that this user interface test passes.
Adding a New Allergy:
The user is able to add allergies to their profile. This is what we will be testing in this
case; since the adding steps will be the same for all of the tabs, we will not display the similar
19
steps for all of the available tabs. The first thing the user will do when attempting to add an
allergy is to select the menu button the Android application; when the user does this, two buttons
will appear at the bottom of the screen. Figure E.12 shows these buttons appearing on the
bottom of the screen and the user; in this case, we will select “Add Allergy”. Figure E.13 shows
the general add allergy screen with hint text shown in the fields so that users have an idea of
what they need to input. On Figure E.14, the user is attempting to add a date for the time the
allergy was first observed. This figure shows the date picker that appears when the user clicks in
the first observed text field. The date picker is currently not implemented on iOS yet because it
was not fully working. When the user selects “Done” in the date picker, the selected date will
appear in the text field for “First Observed” as shown in Figure E. 15. Figure E.15 also depicts
all of the other fields filled in with data as well. When the user selects “Save Allergy”, they will
have successfully added the allergy to their profile and pushed data onto the server.
.
Figure E.12: Trying to add an allergy
20
Figure E.13: Add allergy screen
Figure E.14: Date picker pops up
Figure E.15: All fields filled in
Figures E.12 through E.15 depict the steps the user will follow when trying to add an
allergy to the server. Because none of these screens crashed when attempting to add the allergy
to the server, this test passes as well.
iPhone Navigation Buttons:
The iOS implementation when navigating from screen to screen will be a little different
than that of Android. To move from screen to screen, someone using an iPhone will have the
navigation bar located at the top of the application available to them. Figure E.16 depicts the
allergies tab on the iPhone; from this figure, you can see that the way to add an allergy would be
to select the “+” button located in the upper right hand corner of the application. When the user
selects this button, the user will be directed to Figure E.17. Since the iPhone does not have a
menu button like Android phones, the options that appear in an Android application when the
menu button is selected will always be at the top of the screen for iPhones. Figure E.18 shows
the screen when the user selects an allergy; the details for that allergy are shown. If the user
selects the “edit” button in the upper right hand corner of the application, they will be directed to
Figure E.19 that shows the details of the allergy with a save or cancel option. Similarly to
Android, we have not implemented the populating of data from the existing allergy details to
display on the edit screen yet.
21
Figure E.16: iPhone allergies screen Figure E.17: iPhone add new allergy
Figure E.18: iPhone allergies detail
screen
Figure E.19: iPhone edit allergy
screen
Since none of the screens on the iPhone crashed when navigating from page to page and
successfully loaded, this test case also passed.
22
White Box Unit Testing
Component Tested Expected Result
Actual Result
Class: Conditions
Pull Conditions
JSON object
JSON object
JSON object
Pull current hunger Display in
TO BE TESTED
condition
conditions:
Hunger
Current: Currently
has this
Pull past hunger
Display in
condition
conditions:
Hunger
Past: No longer has
this
Navigate to details
for hunger
condition
Display hunger
condition details
23
Click button and
navigate to correct
details js with
specific condition
instance
information
Show correct
information for
specific condition
instance:
Start date
End data
How it ended
Opens conditions
details js
Success
YES
TBD
NO, displays
hungry
YES
YES
Click delete hunger
condition
Prompt user that
deleting the
condition will
remove all
information:
Delete
Cancel
YES, cancel
option brings
you back to
page and delete
option deletes
the correct
condition in the
database
Pull current
Insomnia Condition
Display in
conditions:
Insomnia
Current: Currently
has this
NO, does not
display:
“Current:
Currently has
this”
Still functional
Pull past Insomnia
Condition
Navigate to details
for Insomnia
condition
Display Insomnia
condition details
24
Display in
TO BE TESTED
conditions:
Insomnia
Past: No longer has
this
Click button and
Opens conditions
navigate to correct details js
details js with
specific condition
instance
information
Show correct
information for
specific condition
instance:
Start date
End data
How it ended
TBD
YES
YES
Click delete
insomnia condition
Prompt user that
deleting the
condition will
remove all
information:
Delete
Cancel
YES, cancel
option brings
you back to
page and delete
option deletes
the correct
condition in the
database
Pull past obesity
condition
Display in
conditions:
Obesity
Past: No longer has
this
YES
Pull current obesity
condition
Display in
conditions:
Obesity
Current: Currently
has this
Click button and
navigate to correct
details js with
specific condition
instance
information
Show correct
information for
specific condition
instance:
Start date
End data
How it ended
Navigate to details
for Obesity
condition
Display Obesity
condition details
25
TO BE TESTED
TBD
Opens conditions
details js
YES
YES
Click delete obesity
condition
Prompt user that
deleting the
condition will
remove all
information:
Delete
Cancel
YES, cancel
option brings
you back to
page and delete
option deletes
the correct
condition in the
database
Pull diabetes
condition
Display in
conditions:
Diabetes
Current: Currently
has this
YES
Pull past diabetes
condition
Display in
TO BE TESTED
conditions:
Diabetes
Past: No longer has
this
Click button and
Opens conditions
navigate to correct details js
details js with
specific condition
instance
information
Show correct
information for
specific condition
instance:
Start date
End data
How it ended
Glucose
intake
TBD
Navigate to details
for Diabetes
condition
Display Diabetes
condition details
26
YES
YES
Click delete
diabetes condition
Class: Meds
Pull all correct
meds from database
Display all the
correct meds from
the database
Medical
interactions
Class: Allergies
Pull all allergies
from the database
27
Prompt user that
deleting the
condition will
remove all
information:
Delete
Cancel
JSON file
containing all
current Meds in
database
show all current
Meds in database
Medical
interactions
displays all the
interactions
currently in the
database
JSON file
containing all
allergies currently
in the database
YES, cancel
option brings
you back to
page and delete
option deletes
the correct
condition in the
database
JSON file containing all YES
current Meds in
database
YES
YES
JSON file containing all YES
allergies currently in the
database
Display all allergies
from database
All allergies from
the database are
displayed correctly
with correct
corresponding
treatment
YES
Display correct
details for each
allergy from
database
All information for
each allergy is
correct for that
specific allergy in
the database
YES
Deleting the allergy
Deleting the
allergy removes
the correct
corresponding
allergy in the
database
28
Correct allergy is
removed from the
database
YES
Section F: Product Backlog Items (PBI)
The product backlog items (PBI) for the Personal Health Assistant project in Figure F.1. The
leftmost column of Figure F.1 contains the six PBI entries identified so far, where the
size/complexity of each item is labeled with: where S=Small, M=Medium, L=Large, and XL=
extra L. Of those six, four have been chosen for the initial sprint (second column of Figure F.1),
and for those four, all of the sprint items have been identified (blue boxes). Note that this figure
is using the notation from: http://scrumreferencecard.com/ScrumReferenceCard.pdf
The PPT below is an embedded object in MS word. You can right click, Presentation Object,
Open and it will open the spreadsheet in PPT. You can use this as a template for your PBI/Sprint
backlog.
Product
Backlog
Profile Edits
M
Med Mgmt
M
Sprint Backlog
Med Mgmt
Editing
M
Upload
Images
Allergies
Allergies
Editing
GUI Enhance
M
M
Conditions
Conditions
Editing
CHF
M
M
Diabetes
Asthma
Wellness
M
Misc Functs
S
Navigation
S
Provider App
L
Figure F.1 PBI and Sprint Backlog for Personal Health Assistant.
29