Running head: LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Lab 2 – Nutricipe Prototype Product Specification
Sections 3.1 and 3.2
Blue Team
CS411
Professor Janet Brunelle
Old Dominion University
November 16, 2010
V2.3
1
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
2
Table of Contents
3.1 Functional Requirements ......................................................................................................4
3.1.1
Database (Erik) ............................................................................................................. 4
3.1.1.1
SR22 Database .......................................................................................................4
3.1.1.2
Nutricipe Database .................................................................................................7
3.1.1.3
Functional Requirements......................................................................................11
3.1.1.4
Populating the Databases .....................................................................................12
3.1.2
Algorithms .................................................................................................................. 14
3.1.2.1
Calorie Needs Algorithm (Olga) ..........................................................................14
3.1.2.2
Food Variety Algorithm (Erik) ............................................................................16
3.1.2.3
Nutritional Content Calculator (Cole) ..................................................................18
3.1.2.4
Recipe Selection Algorithm (Adam) ....................................................................21
3.1.2.5
Shopping List Generator (Olga) ...........................................................................24
3.1.2.6
Food Tracking Algorithm (Erik) ..........................................................................27
3.1.2.7
Goal Tracking Algorithm (Adam)........................................................................29
3.1.3
GUI Interfaces ............................................................................................................ 32
3.1.3.1
“About us” page (Mark) .......................................................................................32
3.1.3.2
“Contact us” page (Mark) ....................................................................................33
3.1.3.3
User Registration (Ben) ........................................................................................35
3.1.3.4
Account Maintenance (Ben).................................................................................38
3.1.3.5
User Authentication Process (Ben) ......................................................................40
3.1.3.6
Administrative Interface (Or’Sasha) ....................................................................42
3.1.3.7
Profile Set up and Maintenance Screen (Ben) .....................................................45
3.1.3.8
Daily Caloric Needs Display (John).....................................................................48
3.1.3.9
Food Variety Display (John) ................................................................................49
3.1.3.10 Recipe Search Prompt (John) ...............................................................................50
3.1.3.11 Recipe Search Report Display (John) ..................................................................52
3.1.3.12 Recipe Card Display (John) .................................................................................54
3.1.3.13 Nutritional Values and Percentage of Daily Goals of Selected Meal Components
Display (John) ......................................................................................................56
3.1.3.14 Meal Builder Display (John) ................................................................................58
3.1.3.15 Shopping List Display (Olga) ..............................................................................60
3.1.3.16 User Meal History Display (Erik) ........................................................................62
3.1.3.17 User Goal Achievement Display (Adam) ............................................................63
3.1.3.18 User Satisfaction Survey Prompt (Mark) .............................................................65
3.1.3.19 User Satisfaction Survey Report (Mark) ..............................................................66
3.2 Performance Requirements .................................................................................................68
3.2.1
Database read/write speed .......................................................................................... 68
3.2.2
Web serving speed ...................................................................................................... 68
3.2.3
Algorithm output speed .............................................................................................. 68
Appendix A ....................................................................................................................................69
Appendix B ....................................................................................................................................71
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
3
List of Figures
Figure 1. USDA SR22 Database Schema........................................................................................6
Figure 2. Nutricipe Database Schema ...........................................................................................10
Figure 3. Calorie Needs Algorithm Flow Chart ............................................................................15
Figure 4. Food Variety Algorithm .................................................................................................17
Figure 5. Nutrient Content Calculator Flow Chart ........................................................................19
Figure 6. Recipe Selection Algorithm Flow Chart ........................................................................23
Figure 7. Shopping List Generator Flow Chart .............................................................................26
Figure 8. Food Tracking Algorithm Flow Chart ...........................................................................29
Figure 9. Goal Tracking Algorithm Flow Chart ............................................................................31
Figure 10. About Us Page GUI .....................................................................................................33
Figure 11. Contact Us Page GUI ...................................................................................................34
Figure 12. Registration Page GUI .................................................................................................35
Figure 13. Registration Process Flow Chart ..................................................................................37
Figure 14. Account Maintenance Flow Chart ...............................................................................39
Figure 15. Profile Login Module ...................................................................................................40
Figure 16. User authentication Flow Chart ...................................................................................41
Figure 17. Admin Interface ...........................................................................................................43
Figure 18. Admin User Interface ...................................................................................................43
Figure 19. Admin Option Interface ...............................................................................................44
Figure 20. “Edit Profile” Module ..................................................................................................46
Figure 21. Profile Maintenance Flow Chat ...................................................................................47
Figure 22. Food Variety Display GUI ..........................................................................................50
Figure 23. Recipe Search Prompt GUI .........................................................................................52
Figure 24. Recipe Search Report Display GUI ............................................................................53
Figure 25. Top of Recipe Card with Recipe Name, Ingredients, and Directions .........................55
Figure 26. Bottom of Recipe Card with Nutritional Facts Table .................................................56
Figure 27. Nutritional Values and Percentage of Daily Goals of Selected Meal Components
Display GUI ...............................................................................................................58
Figure 28. Meal Builder with Recipes ..........................................................................................59
Figure 29. Meal Builder without Recipes.....................................................................................60
Figure 30. Screen to Request Shopping List .................................................................................61
Figure 31. Screen to Display Generated Shopping List ................................................................61
Figure 32. User Mea History Display............................................................................................63
Figure 33. User Goal Achievement Display..................................................................................64
Figure 34. User Satisfaction Survey Prompt .................................................................................65
Figure 35. User Satisfaction Survey Report ..................................................................................67
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
3.1
4
Functional Requirements
The functional requirements define the capability and behaviors associated with the
Nutricipe product. Each functional area will contain individual requirements describing a part of
the prototype. The functional requirements will include database specification, database data
import, algorithms, and GUI interfaces.
3.1.1 Database (Erik)
The database will be implemented using MySQL and will be stored on the Computer
Science department's Unix servers. Two databases are being used: the USDA SR22 database,
and the proprietary Nutricipe database. The USDA database contains nutritional information for
a wide variety of ingredients, while the Nutricipe database will contain user account information
(such as user name and password), user goals, likes, dislikes, recipes, a history of a users
transactions with the server, and nutritional information for recipes. The scope of the database
will be modeled as close to the RWP database as possible. Diseases, for instance, are not taken
into account for the prototype but the tables are still included, but not populated. Scale is greatly
reduced. A RWP with over 50,000 recipes and millions of users will be a goal, while the
prototype is being tested with 20 recipes.
3.1.1.1 SR22 Database
Figure 1 shows the USDA SR22 database schema. Here is a description of each table:
1. DATA_SRC: Contains information about where the data about food items have come
from (irrelevant to the Nutricipe product).
2. DATSRCLN: An intermediary table for the DATA_SRC table (irrelevant to the
Nutricipe product).
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
3. DERIV_CD: Contains information on how NUT_DATA values were determined
(irrelevant to the Nutricipe product).
4. FD_GROUP: Links to the FOOD_DES table to describe which food group a food item
belongs to.
5. FOOD_DES: Contains descriptions of food items (ingredients). The NDB_No is this
table’s primary key and is used as a link in several other tables.
6. FOOTNOTE: Contains additional information about food items (irrelevant to the
Nutricipe product).
7. NUT_DATA: Contains nutritional information for each food item.
8. NUTR_DEF: Provides extra information to the NUT_DATA table such as units of
measurement.
9. SRC_CD: Contains further NUT_DATA statistical information (irrelevant to the
Nutricipe product).
10. WEIGHT: Shows weight in grams for a number of common amounts for various food
items.
[This space intentionally left blank]
5
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Figure 1. USDA SR22 Database Schema
6
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
7
3.1.1.2 Nutricipe Database
Figure 2 shows the schema for the Nutricipe database. Here is a description of each
table:
1. billing: Contains payment information (not populated for the prototype).
2. calorie_level_needs: Contains information about caloric intake, various food types intake
(such as fruits, vegetables, meats, oils, and grains), and amount of calcium and vitamin C
needed to be consumed to meet the nutritional goals. These data are associated with the
age, gender, and activity level.
3. combinations_bad: A list of food combinations considered bad for digestion (not
populated for the prototype).
4. combinations_good: A list of food combinations considered good for digestion (not
populated for the prototype).
5. disease: Contains a list of diseases with descriptions to be used in the RWP (not
populated for the prototype).
6. disease_bad: Contains ingredients that are known to be harmful for a certain disease (not
populated for the prototype).
7. disease_good: Contains ingredients that are known to be beneficial for a certain disease
(not populated for the prototype).
8. dislikes: Contains a list of ingredients and/or recipes a user dislikes.
9. events: A name and description of events used by the history table.
10. goals: An intermediary table listing various goals that Nutricipe offers (for example,
increase of calcium).
11. history: A log of user interactions with the website with a timestamp.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
8
12. ingredient: Contains an image for a particular ingredient.
13. ingredient_goal: An intermediary table that lists ingredients that satisfy the nutritional
goals that Nutricipe offers.
14. ingredient_list: An intermediary table associating ingredients from the SR22 database
with individual recipes.
15. ingredients_available: A list of ingredients in a user’s pantry.
16. likes: Contains a list of ingredients and/or recipes a user likes.
17. meal: A group of recipes and ingredients a user has included in a meal.
18. meal_ingredient: A table associating a group of individual ingredients that are included
in a meal.
19. meal_recipe: A table associating a group of recipes that are included in a meal.
20. nut_facts: Nutritional information for each recipe.
21. profile_goals: A description of individual goals a user can set.
22. recipe: A recipe with a name, list of instructions, preparation time, and image.
23. recipe_fd_group: A table associating a recipe with a basic food group from the SR22
database.
24. recipe_goal: An intermediary table that lists goals a recipe satisfies.
25. us_address: Contains the user’s address. If the user lives outside the United States other
tables (not implemented for the prototype) will capture the appropriate address format.
26. user_health_stats: A user’s statistics such as weight and activity level.
27. user_roles: A list of user roles with the name of the role.
28. user_profile: Contains basic signup information such as user name, email, etc.
a central table linking other user specific information.
It is also
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
29. user_roles_assoc: An intermediary table listing a user’s roles.
30. user_survey: Contains user satisfaction survey results for each user.
[This space intentionally left blank]
9
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Figure 2. Nutricipe Database Schema
10
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
11
3.1.1.3 Functional Requirements
The database must adhere to the following functional requirements:
1. Must provide a database handler that provides a tested and encapsulated way to access
the database.
2. Must conduct regular and automatic backups of the Nutricipe database.
3. Must keep the database normalized. This requirement will have to be balanced against
the speed requirement as too many tables can lead to a slowdown of the database.
4. Must be populated with the recipes, nutritional values of the recipes, nutritional goals that
Nuticipe provides, caloric intake, different food groups’ intake by the developers prior
the Nutricipe solution is used (see section 3.1.1.4 for more details on importing data).
5. Must communicate with the User Registration display (see section 3.1.3.3) to store the
user’s personal information.
1. Must store the user’s personal information (for example, name, email, and
password) into the user_profile table (see Figure 2 for the full list of data stored in
the user_profile table).
2. Must store user’s roles into the user_roles_assoc table.
6. Must communicate with the Account Maintenance display (see section 3.1.3.4) to allow
users to modify their account information (for example, user name and email address).
7. Must communicate with the Profile Set up and Maintenance display (see section 3.1.3.7)
to store the users’ profile information.
1. Must store user’s age, gender, and activity level in the user_health_stats table.
2. Must store user’s nutritional goals into the profile_goals table.
3. Must store the ingredients and/or recipes that the user likes into the likes table.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
12
4. Must store the ingredients and/or recipes that the user dislikes into the dislikes
table.
5. Must store the pantry ingredients into the ingredients_available table.
8. Must communicate with the Profile Set up and Maintenance display (see section 3.1.3.7)
to allow users to modify their likes, dislikes, age, gender, activity level, nutritional goals,
and pantry ingredients.
9. Must communicate with the Calorie Needs Algorithm (see section 3.1.2.1) to store a
caloric intake for the user into the user_health_stats table.
10. Must communicate with the Food Variety Algorithm (see section 3.1.2.2) to store food
intake amounts for the user into the user_health_stats table.
11. Must communicate with the Meal Builder Display (see section 3.1.3.14) to store the
user’s meals and meals’ components.
12. Must communicate with the Nutritional Values and Percentage of Daily Goals of
Selected Meal Components Display (see section 3.1.3.13) to store a log of user
interactions in the history and event tables.
13. Must communicate with the User Satisfaction Survey Prompt (see section 3.1.3.18) to
store the survey results into the user_survey table.
14. Must communicate with the Administrative Interface (see section 3.1.3.18) to allow
changing activation_flag field in the user_profile table from true to false and vice versa in
order to activate and deactivate the accounts.
3.1.1.4 Populating the Databases
Importing data into the database will be done manually for the prototype since the scale
of the database is reduced. However, if a free database of recipes can be found during the
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
13
prototype construction, the process can be automated by importing into the Nutricipe database.
For recipe lists residing in text files, a text parser can be created to extract needed elements such
as the recipe title, ingredients, recipe description, and nutritional values. One assumption being
made is that the nutritional data for every recipe is provided together with the recipe by an
external data source. By keeping nutritional values for recipes in its own table, faster and fewer
database accesses will be needed. Another assumption being made is that the project will only
use recipes with ingredients that currently exist in the SR22 database.
The actual task of transferring the SR22 database involved downloading the database
files from the USDA site. The script to create the SR22 tables is available in Appendix A. Once
tables were created, they were populated by running the script that inserts all the data from the
downloaded text files into the created tables. The script to load data from the text files into the
tables is available in Appendix B.
For the Nutricipe database, text files were created storing recipes, nutritional data of
recipes, and USDA guidelines (caloric and food intake for different ages, genders, and activity
levels). The columns in the file are separated in a comma delimited format. The "LOAD
DATA LOCAL INFILE" command was used to populate the recipe and ingredients_list table.
The calorie_level_needs, recipe_fd_group, nut_facts, goals, recipe_goal, ingredient_goal,
user_roles, and event tables were all populated using this method. Due to the reduced scope of
the prototype the following tables will not be populated: us_address, billing, disease,
disease_good, disease_bad, combinations_good, combinations_bad. The following tables will be
populated by the user via different GUIs: user_profile, likes, user_health_stats, user_roles_assoc,
ingredients_available, meal, meal_recipe, dislikes, profile_goals, history, and user_survey.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
14
3.1.2 Algorithms
Algorithms are one of the major components of the Nutricipe prototype. There are seven
different algorithms developed for the prototype. These algorithms will be able to retrieve data
from the database, accept variables passed from GUI, store data in the database, generate
necessary data, and pass that data to GUI in order to present users with the meaningful and
consistent reports.
3.1.2.1 Calorie Needs Algorithm (Olga)
The purpose of the Calorie Needs Algorithm is to determine the daily caloric intake for
the user. It must acquire the user profile identification (user_profile_id) in order to generate the
right amount of calories that the user needs to consume daily. The Daily Caloric Needs Display
(see section 3.1.3.8) passes that data to the Calorie Needs Algorithm.
In order to find the calorie needs for the particular user, the algorithm needs to find the
user’s age, gender, and activity level. That data is stored in the user_health_stats table and can be
accessed by the user’s user_health_stats_id. Thus, the algorithm retrieves the
user_health_stats_id from the user_profile table based on the user_profile_id value. Then, the
algorithm retrieves the user’s age, gender, and activity level from the user_health_stats table
based on the user’s user_health_stats_id.
The calorie_needs value is retrieved from the calorie_level_needs table. The calorie
needs variable is passed to the Daily Caloric Needs Display (see section 3.1.3.8). The algorithm
updates the user_health_stats table and stores the calorie needs value for the user. Figure 3 shows
the flow chart for the Calorie Needs Algorithm.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Figure 3. Calorie Needs Algorithm Flow Chart
15
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
16
The Calorie Needs Algorithm must adhere to the following functional requirements:
1. Must obtain the user profile identification number from the Daily Caloric Needs
Display (see section 3.1.3.8).
2. Must retrieve the user’s age, gender, and activity level from the database for the
user with the provided user profile identification number.
3. Must retrieve the calorie needs value from the database that corresponds to the
determined user’s age, gender, and activity level.
4. Must provide the calorie needs variable to the Daily Caloric Needs Display (see
section 3.1.3.8).
5. Must store the calorie needs variable into the database for the user with the
provided user profile identification number.
3.1.2.2 Food Variety Algorithm (Erik)
The food variety algorithm is designed with two goals in mind. The first is to produce a
report of recommended food types based on the USDA "food pyramid." This report will include
food groups such as grains, oils, meats, and beans. The second goal of the algorithm is to create
lists of ingredients that meet defined user goals. If a user, for instance, specified that they want
more Vitamin C and to lower their calorie intake, a list of ingredients with high amounts of
Vitamin C and another list of ingredients with low amounts of calories will be displayed. This
report will allow the user to look for recipes or pre-made meals outside the Nutricipe program
and know whether they help reach their goals. For the RWP family history, diseases, personal
goals, and preferences will be taken into account when making these recommendations. For the
prototype only the personal goals and preferences are being used.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
17
Figure 4 shows the flow for the Food Variety Algorithm. The Food Variety Display will
provide the user_profile_id to the algorithm. The user_profile_id can be used to access the
user_health_stats table for age, gender and weight. Combined with the USDA guidelines, the
daily recommended intake report will give the user their recommended amounts on the food
pyramid. Further information is required to complete the recommended foods (ingredients)
report. A user’s likes and dislikes will be extracted from likes and dislikes tables, as well as the
user’s nutritional goals from the user_goals table. At this point, the algorithm will use the SR22
database to find the appropriate ingredients and will display a list for each of the user goals while
excluding disliked ingredients.
Figure 4. Food Variety Algorithm
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
18
The Food Variety Algorithm must adhere to the following functional requirements:
1. Must acquire user_profile_id from the Food Variety Display (see section 3.1.3.9).
2. Must retrieve the user's age, gender, and activity level from the database.
3. Must retrieve the user’s goals from the database.
4. Must retrieve the user’s likes/dislikes from the database.
5. Must retrieve the amount of fruits, vegetables, grains, meats, milk, and oils from
the calorie_level_needs table that corresponds to the determined user's age,
gender, and activity level.
6. Must search the ingredient_goal table for the ingredients that meet user goals, and
likes/dislikes.
1. Must create lists of recommended foods based on nutritional goals and
taking into accounts likes and dislikes.
2. Each goal must result in separate, alphabetical list of ingredients that
fulfill that goal.
7. Must pass the amount of fruits, vegetables, grains, meats, milk, and oils to the
Food Variety Display (see section 3.1.3.9).
8. Must pass the list of recommended foods to the Food Variety Display (see section
3.1.3.9).
3.1.2.3 Nutritional Content Calculator (Cole)
The Nutritional Content Calculator algorithm is designed to take various types of items
(recipes, ingredients, meals) and appropriately calculate the nutritional content for that type. The
GUI forwards user selections to the Nutritional Content Calculator having already determined
the type based on the user's selection. The type of selection, along with its accompanying data, is
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
19
formatted into a tiered array and passed as a single parameter to the Nutritional Content
Calculator. Since the calculator is run recursively for multiple items, if the top-most item is not
of type "meal", the item is assumed to be singular and handled accordingly. If the top-most item
is of type "meal", the entire array is passed to the "meal parser" sub-routine, that recursively calls
the Nutritional Content Calculator for each item in the meal, summing the nutrients for all items
in the meal.
Figure 5. Nutrient Content Calculator Flow Chart
Once the parameter has been received by the Nutritional Content Calculator, it
determines the type of data: type meal, recipe, or ingredient. If the item is of type meal, it will be
handled by the "meal parser" subroutine. If the item is of type recipe, it is handled as a single
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
20
item and a routine is run to query the recipe, ingredient_list, and nut_facts tables to retrieve the
associated pre-formatted nutritional data for that recipe. If the item is of type ingredient, it is
handled as a single item and a routine is run to query the USDA SR22 NUT_DATA and
NUTR_DEF tables to retrieve the appropriate nutritional facts for that ingredient. The data
passed to the Nutritional Content Calculator is an array with keys of strings indicating the table
the item is associated with (which will be recognized and used to determine which “type” the
parameter is) and the value of which is the unique identifier for that item (e.g. NDB_No for
USDA SR22 ingredients, etc.). The only exception is the first key/value pair in the array must
represent the user_profile_id of the currently logged in user. Nutritional data calculated by the
Nutritional Content Calculator algorithm is formatted as an array of nutrient types with their
associated values including their percent towards the user's daily nutrient needs and goals.
The Nutritional Content Calculator must adhere to the following functional requirements:
1. Must obtain the array of items from the Food Tracking Algorithm and Nutritional Values
and Percentage of Daily Goals of Selected Meal Components Display (see sections
3.1.2.7 and 3.1.3.13 respectively).
2. Must determine the “type” of item(s) in the array If an item in the array has an unknown
“type”, must issue an error.
3. If the type of item is a recipe, must retrieve information for that recipe from the recipe
table of the database.
4. If the type of item is an ingredient, must retrieve information for that ingredient from the
USDA SR22 NUT_DATA table for the NDB_No of that ingredient provided by the
Nutritional Values and Percentage of Daily Goals of Selected Meal Components Display
( see sections 3.1.3.13) or the Meal Parser.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
21
5. If the type of item is a meal, must pass the meal to the Meal Parser sub-routine to be
parsed into individual recipes and ingredients.
6. Must calculate the percent of daily goals contained in the ingredient(s) and/or recipe(s)
based on the user’s nutritional goals and based on their user_profile_id (user_profile_id
of currently logged-in user provided with array from caller).
7. Must provide an array of nutritional information for each item to the Nutritional Values
and Percentage of Daily Goals of Selected Meal Components Display (see sections
3.1.3.13).
8. Must provide the percentages of daily goals for each item(s) and/or meal(s) to its caller
(Goal Tracking Algorithm and Nutritional Values and Percentage of Daily Goals of
Selected Meal Components Display, see sections 3.1.2.7 and 3.1.3.13 respectively).
3.1.2.4 Recipe Selection Algorithm (Adam)
The Recipe Selection Algorithm is designed to allow the user to build a list of recipes
generated through a variety of search parameters. The recipes are then displayed to the Recipe
Search report display. Searches may be based on a particular ingredient, on-hand ingredients and
by avoiding disliked ingredients. The Recipe Search Prompt (see section 3.1.3.10) passes the
search parameters and the user_profile_id to the algorithm.
There are four different search paradigms: specified ingredient, on-hand exclusive, onhand inclusive and suggested. Users are able to select a specific ingredient; the GUI will pass
that to the algorithm. The recipe database is searched for recipe_id numbers that have the
specified ingredient included in their ingredients list (NDB_No). These recipe_id numbers are
stored in an array.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
22
If the user has items in their pantry they would prefer to use, their pantry can be loaded
from the ingredients_available table for the user’s user_profile_id. The user then decides if they
want to select recipes that contain only ingredients found in ingredients_available, or if they
want to include all recipes that contain at least one ingredient found in ingredients_available. If
the user does not want to generate recipes based on a search term or ingredients on-hand, recipes
will be suggested based on the user’s dislike table: if an ingredient (NDB_No) is found on the
dislike table, recipes that require that ingredient will not be returned.
If no recipes were found that satisfied the search parameters and the recipe array is
empty, the algorithm will output a message to the user requesting the user try again and then exit.
If there was at least one recipe found, the first recipe (recipe_id) in the array will be checked for
nutritional content (recipe_stats). It is assumed that recipes will have nutritional content, so there
is no need to send the recipe to the Nutritional Content Calculator.
If the recipe’s nutritional content (recipe_stats) does not contribute to meeting the
nutritional goals of the user, the user will have the option to remove the recipe from the array.
Then the next recipe is retrieved and it is again checked for nutritional content. This continues
until the entire array has been traversed. The array of recipe_id numbers is then passed back to
the Recipe Search Report Display (see section 3.1.3.11), and the algorithm exits. Figure 6 shows
the flow chart for the Recipe Selection Algorithm.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Figure 6. Recipe Selection Algorithm Flow Chart
23
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
24
The Recipe Search Algorithm must adhere to the following functional requirements:
1. Must obtain the user identification number from the Recipe Search Prompt (see
section 3.1.3.10).
2. Must retrieve User’s goals from goals table.
3. Must obtain search term from Recipe Search Prompt (see section 3.1.3.10) or
allow user to choose a search paradigm.
4. Must not include recipes in the recipe array that should be excluded based upon
user search decision.
5. Must exit algorithm if recipe array is empty after generation.
6. Must allow user to remove recipes_id numbers from recipe array that do not
contribute to nutritional goals set by user.
7. Must pass recipe array to Recipe Search Report Display (see section 3.1.3.11)
upon termination of algorithm.
3.1.2.5 Shopping List Generator (Olga)
The purpose of the Shopping List Generator is to determine what food items should be
included in the shopping list for the customized meal. The Shopping List Generator must acquire
the user profile identification number (user_profile_id) and meal identification number
(meal_id). The Shopping List Display (see section 3.1.3.15) passes the user profile identification
number and meal identification number to the Shopping List Generator.
The first step for the Shopping List Generator is to retrieve the food items (NDB_Nos)
that the user has on-hand and to store these food items into an array of available ingredients. The
second step is to retrieve all the individual ingredients that the meal contains. The NDB_No,
FdGrp_Co, Long_Desc, FdGrp_Desc are retrieved for each ingredient. The algorithm stores that
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
25
data for each ingredient into the ingredients array. While storing the data into the array, it checks
if the array of ingredients or the array of available food items already has the same ingredient.
The third step is to retrieve all the recipe_ids for the meal with meal_id. The algorithm
retrieves every food item for every recipe in the meal. The NDB_No, FdGrp_Co, Long_Desc,
FdGrp_Desc is also retrieved for each ingredient by the Shopping List Generator. The algorithm
stores the data for each ingredient into the ingredients array. It checks if the array of ingredients
or the array of available food items already has the same ingredient. The ingredients array
consists of unique food items only and is sorted by the food group code (FdGrp_Cd).
The algorithm creates a shopping_list array from the ingredients array. The shopping_list
array has only FdGrp_Desc and Long_Desc information about every ingredient in the shopping
list. The Shopping List Generator passes this array to the Shopping List Display (see section
3.1.3.15) to display the shopping list to the user. Figure 7 shows the flow chart for the Shopping
List Generator.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Figure 7. Shopping List Generator Flow Chart
26
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
27
The Shopping List Generator must adhere to the following functional requirements:
1. Must obtain the meal identification number from the Shopping List Display (see
section 3.1.3.15).
2. Must obtain the user identification number from the Shopping List Display (see
section 3.1.3.15).
3. Must retrieve all the ingredients from the database for the meal with the provided
meal identification number.
4. Must retrieve all the ingredients from the database for every recipe that the meal
with the provided meal identification number consists of.
5. Must check if the retrieved ingredients are not listed among user’s available
ingredients to insure their uniqueness.
6. Must check if the retrieved ingredients are not duplicated to insure their
uniqueness.
7. Must combine only unique retrieved ingredients.
8. Must provide the combined ingredients and their descriptions to the Shopping List
Display (see section 3.1.3.15).
3.1.2.6 Food Tracking Algorithm (Erik)
This algorithm searches a user's history for meals they have consumed. A list is
produced that shows the name of the recipes with links to the full recipe and its nutritional
information. It is sorted by date eaten and the user is allowed to select a timeframe such as
"meals eaten in the last month". The algorithm flow is shown in Figure 8.
The Shopping List Generator must adhere to the following functional requirements:
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
28
1. Must acquire the user_profile_id from the User Meal History Display (see section
3.1.3.16).
2. Must acquire a time frame to display the history from the User Meal History
Display (see section 3.1.3.16).
3. Must access history table for list of meals selected along with time selected.
4. Must access event table for meal_id.
5. Must retrieve meal name using meal_id.
6. Must output a list of meals eaten, sorted by date eaten to the User Meal History
Display (see section 3.1.3.16).
1. The meal list must be composed of combinations of recipe names,
ingredient names, and date eaten.
.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
29
Figure 8. Food Tracking Algorithm Flow Chart
3.1.2.7 Goal Tracking Algorithm (Adam)
The Goal Tracking Algorithm is designed to allow the user to view how successful they
have been in reaching the goals they set over a specified timeframe (number of days). The Goal
Tracking Algorithm receives this timeframe and the user_profile_id from the User Goal
Achievement Display (see section 3.1.3.17). The history table with the user_profile_id of the
user is accessed and events with event_id equal to “MEAL_SELECTED” will be returned.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
30
An array is generated and the meal_id numbers of the events with event_timestamp
greater than the current time minus the timeframe are added to the array. The meal_id is sent to
the nutrient calculator, which will return the percentages of the user’s daily goals that are met by
that meal. The results are added to an array which will sum, nutrient-wise, the different
percentages that are returned.
The next meal_id is sent to the nutrient calculator, and this process will repeat until the
entire array has been traversed. Each element in the nutrient percentage array is divided by the
timeframe, giving an average percentage of each nutrient measured over the time period that the
user has selected. This calculated average is returned to the User Goal Achievement Display
(see section 3.1.3.17). Figure 9 shows the flow chart for the Goal Tracking Algorithm.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Figure 9. Goal Tracking Algorithm Flow Chart
31
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
32
The Goal Tracking Algorithm must adhere to the following functional requirements:
1. Must obtain the user identification from the User Goal Achievement Display (see section
3.1.3.17).
2. Must obtain the timeframe from the User Goal Achievement Display (see section
3.1.3.17).
3. Must only return event_id numbers from the history table that are of type
MEAL_SELECTED.
4. Must only include meal_id numbers with event_timestamp greater than current time
minus timeframe.
5. Must return the nutrient percentage array to the User Goal Achievement Display (see
section 3.1.3.17).
3.1.3 GUI Interfaces
The GUI interfaces provides a user interaction interface with the Nutricipe prototype. The
GUI requirements include, but are not limited to, user authentication, user registration, user
profiles, recipe search, meal builder, display nutritional information to the user, and user
administration. Depending on the level of access, each user will be able to access different pages
and perform different tasks.
3.1.3.1 “About us” page (Mark)
The purpose of the "About us" page is to summarize the product's description for
potential users. This page will be available to all access levels and only displays information
about the product. Figure 10 shows the static GUI page displaying the information.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
33
Figure 10. About Us Page GUI
The "About us" page must adhere to the following functional requirements:
1. Must display a summary of Nutricipe in an easy to understand format.
2. Must be accessible for all users (including non-authenticated).
3. Must provide a link to the Nutricipe main page (home page).
4. Must use the Nutricipe CSS template.
3.1.3.2 “Contact us” page (Mark)
The purpose of the "Contact us" page is to provide a means for all users (Nutricipe and
potential) to get in touch with the Nutricipe team operators and administrators. This page will be
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
34
available to all access levels and only displays the contact information in a static format. Figure
11 shows the static GUI page displaying the contact information.
Figure 11. Contact Us Page GUI
The "Contact us" page must adhere to following functional requirements:
1. Must display an intentionally falsified email address to Nutricipe.
2. Must display an intentionally falsified mailing address to Nutricipe.
3. Must be accessible for all users (including non-authenticated).
4. Must provide a link to the Nutricipe main page (home page).
5. Must use the Nutricipe CSS template.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
35
3.1.3.3 User Registration (Ben)
The purpose of the user registration process is to provide a way for Nutricipe customers
to create accounts. The registration process must allow the user to choose a username, a
password, and an email address (at minimum). This information must then be placed into the
database in the form of a new user account.
Figure 12. Registration Page GUI
The first step in registering an account is to visit the registration page. Here a user is
presented with the GUI screen shown in Figure 12; they must input information into the
username, password, and email fields at minimum. The other fields may be filled out if the user
opts to, but it is not required. Once a username, password, and email are entered, the user must
click the “register” button to continue.
The second step is to send data from the GUI to a registration process. Three PHP
classes (session, form, and database) handle all registration, login, and profile/account
information from this step forward. When the “register” button is clicked, each value in every
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
36
field is loaded into the session object. The registration process then automatically checks the
format/validity of the soon-to-be user’s chosen username and email address; if either is in an
unacceptable format, then the registration process is cancelled and the errors are explained to the
user. If there is no problem with formatting or a taken username, then the registration process
continues.
The final step is to send the data to the database, thereby formally creating the user’s
account. This is accomplished by sending the registration data from the session object to the
database object. The database object then calls one of its own functions to insert the user’s
account information to the actual database. Figure 13 shows the process in a flow chart format.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
37
Figure 13. Registration Process Flow Chart
The user registration process must adhere to the following functional requirements:
1. Must allow a non-authenticated user make an account.
2. Must allow only one account per user.
3. Must take input from registration page and output to the user_profile table in the
database.
4. Must run checks that ensure the user provided valid email.
5. Must run checks that ensure the user provided valid username.
6. Must run checks that ensure the user provided valid password.
7. Must use the Nutricipe CSS template.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
38
3.1.3.4 Account Maintenance (Ben)
The purpose of the account maintenance screen is to provide users with a way to change
their account settings. This requires the user to be logged in (i.e., authenticated) under a specific
username. Once he/she navigates to the Account screen, there is an “Edit Account” area under
the “View Account” module.
The first step is to have the user change his/her information as desired; this is done with a
GUI page that is similar to the registration page GUI. This area is only visible if the user owns
the account being viewed. Aside from changing his/her username, any other aspect of their
account can be modified or left blank. Once the user has typed new values into whichever fields
he/she wishes, the “submit” button within the “Edit Account” area must be pressed to finalize the
changes.
The second step is to send the data to the web server. When the user presses the “submit”
button, the modified account information is sent to the web server where it is stored in the
session object. After checking the format of any new email, the new data is then sent to the
database object.
The final step is to find the user’s account in the user_profile table and replace the old
data that is in the Nutricipe database with the “new” data coming from the database object. This
is done via an SQL UPDATE command, where the user’s username is used to identify which
row to update. Figure 14 shows a flow chart describing this process.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
39
Figure 14. Account Maintenance Flow Chart
The user registration process must adhere to the following functional requirements:
1. Must require an account to be registered before accessing it.
2. Must require a user to be authenticated by the system before accessing an account.
3. Must not allow a user to edit another account other than his or her own.
4. Must allow a user to edit only their account.
5. Given that requirements 1 and 2 are satisfied, must allow a user to access an
account.
6. Given that requirements 3 and 4 are satisfied, must allow a user to edit their
account.
7. Must use the Nutricipe CSS template.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
40
3.1.3.5 User Authentication Process (Ben)
The purpose of user authentication is to provide a process whereby users may log in to
their respective accounts. When carried out successfully, this action allows an authenticated user
to “unlock” portions of the site’s functionality (i.e., meal planning/building, account/profile
maintenance, administrative interface, etc) based on their account’s access level. In order to be
authenticated, a user must sign in to the site via the “login area” on the home page.
Figure 15. Profile Login Module
The first step is to require the user to be viewing the login area. In order to use the login
module, the user must first have an account and must not be logged in already. As long as these
prerequisites are met, the user may enter their username and password into the first and second
fields, respectively. Once the “Log in” button is clicked, a process is spawned where the session
object stores the login information.
The second step is to pass the username and password (from the login module) to the
database object. From here, the database object uses these values to build a SELECT query to the
database. One row is expected to be found; if no rows or multiple rows are returned, the process
fails. If one matching row is returned (i.e, there is no difference in the username/password
between the login module and Nutricipe database), then the database object returns to the session
object all account data for that given user.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
41
The third step is to store the returned data into PHP’s Session array. This is a special
array that is built in to PHP; when variables are stored into Session, they are accessible to any
web page under your current directory (if the site is viewed in a separate browser, then the
variables won’t exist for that browser). Once this is done, the user’s account data can be used to
render or send data to other modules such as the meal planning/building, goal achievement, and
meal history screens. Figure 16 shows a flow chart representation of this process.
Figure 16. User authentication Flow Chart
The User Authentication Process must adhere to the following functional requirements:
1. Must require user to submit their username and password.
2. Must send authentication data (username and password) to web server.
3. Must retrieve user registration data (username and password) from the database.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
42
4. Must compare the login data with the account data acquired from the database.
5. If the provided username and password are the same in the user’s account, must
allow user access/authentication (refer to Table 4).
6. If the provided username and password do not match, output an error message to
the user and deny access.
7. Must assign user levels to different groups (i.e., users, health club moderators,
administrators).
8. Must use the Nutricipe CSS template.
3.1.3.6 Administrative Interface (Or’Sasha)
The purpose of the Administrative Interface is to provide complete access and control
over Nutricipe. This page will only be accessible to Administrators. Figure 17 shows the GUI
screen that appears when an Admin is logged in. When an Admin chooses to modify a user they
have several options. They have the ability to create new accounts for any user, deactivate, and
reactivate existing accounts. An Admin will also have access to the User Satisfaction Reports
which redirects to the “User Satisfaction Survey Report” GUI screen (see section 3.1.3.19) upon
click.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
43
Figure 17. Admin Interface
When an Admin chooses to modify a user a drop down menu will be displayed as shown
in Figure 18. All users in the database will be included in the drop down menu. An admin must
select a current user or select “New User”.
Figure 18. Admin User Interface
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
44
After selecting a user, an Admin needs to select an option from another drop down menu
and click on submit to perform that action. Figure 19 illustrates the GUI screen that will be
displayed. When “Create” is selected, the Admin will be redirected to the “User Registration”
GUI screen (see section 3.1.3.3). An Admin will create a user if and only if a user needs
assistance. When an Admin selects “Deactivate,” the account of the user that is selected will be
disabled. A user’s account will become active again when an Admin selects “Reactivate”.
Figure 19. Admin Option Interface
The Admin Interface must adhere to the following functional requirements:
1. Must only be accessible to Admins.
2. Must be able to list all users in the database.
3. Must be able to modify user’s accounts.
4. Must have an option to create new users.
5. Must be redirected to “User Registration Page” GUI screen when Admin chooses to
create a new user.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
45
6. Must be able to deactivate users’ accounts.
7. Must be able to reactivate users’ accounts.
8. Must have access to the User Satisfaction Survey Reports.
9. Must be redirected to “User Satisfaction Survey Report” GUI screen when Admin
clicks on “User Satisfaction Survey Report”.
10. Must perform an action when clicking submit.
11. Must use the Nutricipe CSS template.
3.1.3.7 Profile Set up and Maintenance Screen (Ben)
The purpose of profile creation and maintenance is to allow users to change their age,
gender, activity level, likes, dislikes, and goals. Changes to likes and dislikes will promote or
remove (respectively) certain results that the meal building algorithm will return, whereas
changes to a user’s goals will affect the reports that a user will see in his/her account page.
Changes to a user’s age, gender, or activity level will affect the recommended amount of calories
that a user may consume. In order to make these changes, the user must navigate to their account
page and make changes in the user profile module.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
46
Figure 20. “Edit Profile” Module
The first step is to require the user to be logged in and viewing their profile page. If these
conditions are satisfied, then an “edit profile” button will appear in the profile view module. By
clicking this button, the page will be reloaded with the profile maintenance module.
The second step is to accept changes made in the profile maintenance module and
commit them to the database. From here, a user may edit their age, gender, activity level, and
ingredients on hand. For the prototype, the pantry builder will allow a user to select from a list of
roughly 20 ingredients that the user may have. They may also add items to or remove items from
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
47
their likes/dislikes/goals list. Once the “submit” button has been clicked, these changes are sent
to the web server and stored in the session object.
The third step is to commit these changes to the user’s profile. This is done by assigning
the profile data held in the session object to the database object. Once this is done, a check will
be run to see if this user has any existing profile. A user’s username identifies which row in the
profile table to update. If no row in the profile table exists, then an SQL “insert” command is
issued and the user’s selected likes/dislikes/goals are added to his/her profile. If a profile already
exists, then an SQL “update” command is sent, and the same process is carried out. Figure 21
shows this process in flow chart format.
Figure 21. Profile Maintenance Flow Chat
The user authentication process must adhere to the following functional requirements.
1. Must require user to specify their likes and dislikes in maintenance screen.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
48
2. Must require user to select their goals from a menu in maintenance screen; available
choices are “low sodium”, “low cholesterol”, “high calcium”, and “high Vitamin C”.
3. Must store the user’s selections to the database.
4. Must allow user to edit his/her age and verify that age is valid and within defined
range (ages 0-90).
5. Must allow user to edit his/her gender; valid selections are limited to male or female.
6. Must allow user to edit his/her activity level; choices are sedentary or active.
7. Must allow user to edit his/her goals.
8. Must allow user to edit his/her ingredients on hand (pantry).
9. Must use the Nutricipe CSS template.
3.1.3.8 Daily Caloric Needs Display (John)
The Daily Caloric Needs Display will display the calorie needs for a user. It will get a
user’s daily caloric needs by using the Calorie Needs Algorithm (see section 3.1.2.1). The Daily
Caloric Needs Display must adhere to the following functional requirements:
1. Must get the user profile identification number from the Session Control Array.
2. Must pass the Calorie Needs Algorithm (see section 3.1.2.1) the current user profile
identification number.
3. Must accept integer result from the Calorie Needs Algorithm (see section 3.1.2.1).
4. Must display the returned integer with a message stating that it is the user’s daily
caloric needs.
5. Must use the Nutricipe CSS template.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
49
3.1.3.9 Food Variety Display (John)
The Food Variety Display shows users which foods they should be eating based off their
user profile. It will pass the user profile identification number to the Food Variety Algorithm
(see section 3.1.2.2). This algorithm will return a set of foods the user should eat. The Food
Variety Display will use this information and display it for the user. Figure 22 shows what the
display will look like.
The Food Variety Display must adhere to the following functional requirements:
1. Must obtain user profile identification number from Session Control Array.
2. Must pass user profile identification number to the Food Variety Algorithm (see
section 3.1.2.2).
3. Must accept a list of recommended servings of the basic food groups from the Food
Variety Algorithm (see section 3.1.2.2).
4. Must accept a list of ingredients that meet the user’s nutritional goals from the Food
Variety Algorithm (see section 3.1.2.2).
5. Must use the returned results to display recommended servings of the basic food
groups.
6. Must use the returned results to display recommended foods that help meet user’s
goals.
7. Must have a link to add recommended items to meal.
8. Must add the Nutrient Databank Number to the meal_table in the database when a
user clicks to add item to meal.
9. Must use the Nutricipe CSS template.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
50
Figure 22. Food Variety Display GUI
3.1.3.10
Recipe Search Prompt (John)
The Recipe Search Prompt as shown in Figure 23 allows users to enter a term to search the
database for recipes or ingredients. A recipe search will return recipes, and an ingredient search
will return a single ingredient. Two forms will be displayed to distinguish the two different
search types.
Users will be able to search for recipes by a specified ingredient, ingredient availability, or
profile goals. A form with one textbox will be used to get the specified ingredient, two
checkboxes will be used for users to specify availability and goal filters, and a submit button will
invoke The Recipe Selection Algorithm (see section 3.1.2.4). When a search is invoked the form
information will be sent to The Recipe Selection Algorithm (see section 3.1.2.4).
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
51
The last way to search the database is for a raw ingredient, and will be implemented using its
own text box and submit button. When a user clicks submit it will call a function that searches
by ingredients. The function will query the database for an ingredient that matches the search
term. The first hit in the database will be returned.
The Recipe Search Prompt must adhere to the following functional requirements:
1. Must have two forms. One to search for recipes and one to search for ingredients from
the database.
2. For the recipe search:
1. Must have a text field, pantry checkbox, goal checkbox, and search button.
2. Must get the user profile identification number from the Session Control Array.
3. Must pass the Recipe Selection Algorithm (see section 3.1.2.4) the user profile
identification number, checkbox filters, and search term.
4. Must accept an array of recipe identification numbers from the Recipe Selection
Algorithm (see section 3.1.2.4).
5. Must make the array accessible to the Recipe Search Report Display (see section
3.1.3.11).
3. For the ingredient search
1. Must have a text field and search button.
2. Must send the search term to a search ingredient function.
3. Must accept a string from the search ingredient function.
4. Must use the Nutricipe CSS template.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
52
Figure 23. Recipe Search Prompt GUI
3.1.3.11
Recipe Search Report Display (John)
The Recipe Search Report Display will display the results from the Recipe Selection
Algorithm (see section 3.1.2.4). Each returned recipe will display the recipe picture and name,
have the ability for users to add it to their meal, and provide a way for users to navigate to the
Recipe Card Display (see section 3.1.3.12). The results will be easy to read and paged. Figure
24 shows how the Recipe Search Report Display.
The Recipe Search Report Display must adhere to the following functional requirements:
1. Must have access to the recipe identification number array returned from the Recipe
Selection Algorithm (see section 3.1.2.4).
2. Must query the database for every recipe identification number to get recipe name and
picture.
3. Must display recipe name, recipe picture, link to Detailed Recipe Display, and link to add
recipe to meal for every recipe identification number.
4. Must pass recipe identification number to Recipe Card Display (see section 3.1.3.12)
when the user clicks on the recipe.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
53
5. Must add recipe identification number to meal_table in the database when user clicks to
add to their meal.
6. Must display an error message if no results are returned.
7. Should have paged results with only 10 recipes per page.
8. Must use the Nutricipe CSS template.
Figure 24. Recipe Search Report Display GUI
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
3.1.3.12
54
Recipe Card Display (John)
The Recipe Card Display shows users the recipe name, ingredients, directions, and
nutritional facts table. This information is stored in the database, and will be pulled using the
recipe identification number. The top of the recipe card is displayed in Figure 25, and the bottom
of the recipe card is displayed in Figure 26. Users will have the ability to add the recipe to their
meal directly from this page.
The Recipe Card Display must adhere to the following functional requirements:
1. Must accept a recipe identification number from the calling page.
2. Must use the recipe identification number to query the database for the recipe
name, ingredients, instructions, and nutritional facts.
3. Must display the recipe name, ingredients, and instructions.
4. Must use the nutritional facts to display a nutritional facts table.
5. Must allow users to add recipe to meal.
6. Must add recipe identification number to meal_recipe table in the database when
users click to add it to their meal.
7. Must use the Nutricipe CSS template.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Figure 25. Top of Recipe Card with Recipe Name, Ingredients, and Directions
[This space intentionally left blank]
55
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
56
Figure 26. Bottom of Recipe Card with Nutritional Facts Table
3.1.3.13
Nutritional Values and Percentage of Daily Goals of Selected Meal
Components Display (John)
The Nutritional Values and Percentage of Daily Goals of Selected Meal Components Display
shown in Figure 27 show users the nutritional value and percentage of daily goals of their meal.
The nutritional value of the meal will be displayed in a nutritional facts table. For each meal
component, users will have access to the Recipe Card Display (see section 3.1.3.12). Also, users
will be able to add the meal into their meal history and select a date they are going to eat it.
The Nutritional Values and Percentage of Daily Goals of Selected Meal Components Display
must adhere to the following functional requirements:
1. Must obtain user identification number from the Session Control Array.
2. Must use the user identification number to query the meal_table for recipe and ingredient
identification numbers in the user’s current meal.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
57
3. Must use the recipe identification number to query the database for recipe image, name,
and nutritional value.
4. Must display recipe image and name.
5. Must display nutritional value of all recipes in the user’s meal.
6. Must have a link and date input for users to insert this meal into their meal history, and
must insert meal into meal history table in the database.
7. Must provide users with a link to Recipe Card Display (see section 3.1.3.12).
8. Must use the Nutricipe CSS template.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Figure 27. Nutritional Values and Percentage of Daily Goals of Selected Meal Components
Display GUI
3.1.3.14
Meal Builder Display (John)
A user’s current meal, Recipe Search Prompt (see section 3.1.3.10), and a link to the
Nutritional Values and Percentage of Daily Goals of Selected Meal Components Display (see
section 3.1.3.13) will be shown in the Meal Builder Display. Figure 29 shows what the meal
builder will display if a user’s current meal is empty. When a user adds a recipe to their meal,
the meal builder will display it as shown in Figure 28.
58
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
The Meal Builder Display must adhere to the following functional requirements:
1. Must get user identification number from Session Control Array.
2. Must use user identification number to query the database for user’s current meal.
3. Must use the recipe identification numbers to get recipe name and image.
4. Must display recipe name and image for all recipes in the user’s current meal.
5. Must include Recipe Search Prompt (see section 3.1.3.10) to add recipes.
6. Must display a message if meal is currently empty.
7. Must display the Food Variety Display (see section 3.1.3.9).
8. Must have a link to Nutritional Values and Percentage of Daily Goals of Selected
Meal Components Display (see section 3.1.3.13).
9. Must use the Nutricipe CSS template.
Figure 28. Meal Builder with Recipes
59
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
60
Figure 29. Meal Builder without Recipes
3.1.3.15
Shopping List Display (Olga)
The purpose of the Shopping List Display is to allow the user to request the shopping list
for the customized meal and to view its content. Figure 30 shows the screen to request the
shopping list to be generated. Figure 31 shows the generated shopping list.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
61
Figure 30. Screen to Request Shopping List
Figure 31. Screen to Display Generated Shopping List
The Shopping List Display must adhere to the following functional requirements:
1. Must get the user profile identification number from the Session Control Array.
2. Must only be accessible to the authenticated users (not administrative personnel)
3. Must display the option for the user to request a shopping list.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
62
4. Must call the Shopping List Generator (see section 3.1.2.5) to create a shopping
list content when the user requests a shopping list.
1. Must pass the user profile identification number and the meal
identification number to the Shopping List Generator (see section 3.1.2.5)
2. Must accept the list of ingredients and their food groups descriptions from
the Shopping List Generator (see section 3.1.2.5).
5. Must display the shopping list content to the user when requested.
5. Must use the Nutricipe CSS template.
3.1.3.16
User Meal History Display (Erik)
This screen displays a history of meals that the user has consumed. The screen is shown
in Figure 32. The list is populated based on a timeframe the user will specify, and is sorted
based on the most recent selections.
The User Meal History Display must adhere to the following functional requirements:
1. Must get the user profile identification number (user_profile_id) from the Session
Control Array.
2. Must allow user to select a timeframe.
3. Must pass the user_profile_id to the Food Tracking Algorithm (see section
3.1.2.6).
4. Must pass a timeframe to the Food Tracking Algorithm (see section 3.1.2.6).
5. Must retrieve a list of recently eaten meals from Food Tracking algorithm (see
section 3.1.2.6).
6. Must list date and sort by most recently eaten.
7. Must provide the names of the meal’s components and date eaten.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
63
8. Must not be accessible to non-authenticated users.
9. Must use the Nutricipe CSS template
Figure 32. User Mea History Display
3.1.3.17
User Goal Achievement Display (Adam)
The purpose of the Goal Achievement Display is to allow users to track how well they
are meeting their goals. The user enters a number into the search box and clicks search. The
Goal Achievement Display sends the user_profile_id and the length of time (or timeframe) to the
Goal Tracking Algorithm. The Goal Tracking Algorithm returns an array of average percentages
for the different nutrients. The Goal Achievement Display then displays the values. Figure 33
shows a sample of the report after having been run for one day.
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Figure 33. User Goal Achievement Display
The User Goal Achievement Display must adhere to the following functional
requirements:
1. Must get the user profile identification number (user_profile_id) from the Session
Control Array.
2. Must call Goal Tracking Algorithm (see section 3.1.2.7).
3. Must pass user_profile_id to the Goal Tracking Algorithm (see section 3.1.2.7).
4. Must obtain a positive integer from the user.
5. Must not be accessible to non-authenticated users.
6. Must accept results of Goal Tracking Algorithm (see section 3.1.2.7).
7. Must round results down to nearest whole number.
8. Must return only positive numbers.
9. Must return only events related to the user_profile_id of the currently logged-in user.
64
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
65
10. Must use the Nutricipe CSS template.
3.1.3.18
User Satisfaction Survey Prompt (Mark)
The purpose of the User Satisfaction Survey Prompt is to display a survey to the
Nutricipe users that they must fill out in order to continue using Nutricipe. The survey will
include questions about how satisfied the users are with Nutricipe and how helpful it is with
achieving their goals. These questions will be displayed every thirty days with the answers being
stored.
Figure 34. User Satisfaction Survey Prompt
The User Satisfaction Survey Prompt must adhere to the following functional
requirements:
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
66
1. Must display a list of questions required to be answered by the user.
1. The questions will be limited to four preselected questions.
2. Must be displayed every 30 days.
3. Must be displayed for each regular authenticated Nutricipe user (not health moderators
or Admins).
4. Must lock the account until survey is completed.
5. Must store the survey results in the respective user's profile section (user_survey table)
in the database.
6. Must use the Nutricipe CSS template.
3.1.3.19
User Satisfaction Survey Report (Mark)
The purpose of the User Satisfaction Survey Report is for health club moderators and
administrators to receive the results from the surveys for future improvements to the product as
well as analysis and statistical research. The reports are only able to be generated from the
administrator's interface page for the administrators and health club moderators. Figure 35
displays the GUI screen for the administrator's page for the User Satisfaction Survey Reports.
[This space intentionally left blank]
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Figure 35. User Satisfaction Survey Report
The User Satisfaction Survey Prompt must adhere to the following functional
requirements:
1. Must be viewable by only the health club moderators and administrators.
2. Must display each individual report upon request.
3. Must display a compiled report of all surveys taken for that month.
4. Must retrieve user surveys from profile database.
5. Must display list of users which correlate to the retrieved surveys.
6. Must use the Nutricipe CSS template.
67
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
3.2
68
Performance Requirements
The following performance requirements will define how well each component of the
Nutricipe prototype must perform in measurable terms. Each performance requirements will
correspond to one or more functional requirements. The test cases will be developed based on
these requirements.
3.2.1 Database read/write speed
The Nutricipe database is a major component of the Nutricipe solution. It is essential for
the database to meet the performance requirements. Hence, database read/write speed must be a
small number.
The Nutricipe database must adhere to the following performance requirements:
1. Database read/write speed must be no longer than five seconds
3.2.2 Web serving speed
The Nutricipe product will be hosted on a web server. Thus, the web serving speed must
be a small number. Otherwise, it will only take a small number of users to congest the system.
The web serving speed must adhere to the following performance requirements:
2. The web serving speed must take no longer than seven seconds
3.2.3 Algorithm output speed
All seven algorithms used in the Nutricipe prototype must generate data in a fast manner.
It must take a small number of seconds to produce the data and pass it to the GUI. Otherwise, the
response time will not be satisfying for the user.
The algorithm output speed must adhere to the following performance requirements:
1. Must take no longer than seven seconds to produce the data and pass it to the GUI
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Appendix A
Script to create the SR22 tables:
DROP TABLE IF EXISTS
DATSRCLN,
DERIV_CD,
FD_GROUP,
FOOD_DES,
FOOTNOTE,
NUT_DATA,
NUTR_DEF,
WEIGHT,
ABBREV,
SRC_CD,
DATA_SRC;
CREATE TABLE DATSRCLN
(NDB_No
INT,
Nutr_No
INT,
DataSrc_ID VARCHAR(12)
);
CREATE TABLE DERIV_CD
(Deriv_CD VARCHAR(8),
Deriv_Desc VARCHAR(240)
);
CREATE TABLE FD_GROUP
(FdGrp_CD VARCHAR(8),
FdGrp_Desc VARCHAR(120)
);
CREATE TABLE FOOD_DES
(NDB_No INT,
FdGrp_Cd VARCHAR(8),
Long_Desc VARCHAR(400),
Shrt_Desc VARCHAR(120),
ComName
VARCHAR(200),
ManufacName VARCHAR(130),
Survey VARCHAR(2),
Ref_Desc VARCHAR(270),
Refuse INTEGER,
SciName
VARCHAR(130),
N_Factor FLOAT,
Pro_Factor FLOAT,
Fat_Factor FLOAT,
69
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
CHO_Factor DOUBLE,
INDEX (NDB_No)
);
CREATE TABLE FOOTNOTE
(NDB_NO
INT,
Footnt_No
VARCHAR(8),
Footnot_Typ
VARCHAR(2),
Nutr_No
INT,
Footnot_Txt
VARCHAR(400),
INDEX (NDB_NO)
);
CREATE TABLE NUT_DATA
(NDB_No
INT,
Nutr_No
INT,
Nutr_Val DOUBLE,
Num_Data_Pts INTEGER,
Std_Error DOUBLE,
Src_Cd VARCHAR(4),
Deriv_Cd VARCHAR(8),
Ref_NDB_No INT,
Add_Nutr_Mark VARCHAR(2),
Num_Studies INTEGER,
Min DOUBLE,
Max DOUBLE,
DF DOUBLE,
Low_EB DOUBLE,
Up_EB DOUBLE,
Stat_Cmt VARCHAR(20),
INDEX (NDB_No)
);
[This space intentionally left blank]
70
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
Appendix B
Script to import data from the SR22 text files into the SR22 tables:
#!/usr/bin/perl
use strict;
use DBI;
# Make sure you import sr21.sql first
# Don't forget to change the password, etc
my $dbh = DBI->connect('', '', '');
# The key is the name of the file, the value is the number of fields
my %files = (
'ABBREV.txt' => 51,
'DATA_SRC.txt' => 9,
'DATSRCLN.txt' => 3,
'DERIV_CD.txt' => 2,
'FD_GROUP.txt' => 2,
'FOOD_DES.txt' => 14,
'FOOTNOTE.txt' => 5,
'NUT_DATA.txt' => 17,
'NUTR_DEF.txt' => 6,
'SRC_CD.txt' => 2,
'WEIGHT.txt' => 7,
);
for my $file ( keys %files ) {
my $table = $file;
$table =~ s/\.txt//;
# The DBI lets us pass ? instead of the actual value now,
# and then pass the value later. Not that SQL injection
# should be an issue here, but it's good practice.
my $values = join ',', qw/?/ x $files{$file};
# The files are in CRLF format, but some fields have LF
# characters in them. This makes sure the fields parse
# properly.
local $/ = "\r\n";
open SRFILE, "<$file";
while ( my $line = <SRFILE> ) {
# Tildes denote text fields, but we don't need that here.
$line =~ s/~//g;
71
LAB 2 – NUTRICIPE PROTOTYPE PRODUCT SPECIFICATION
# Break into fields.
my @vals = split( /\^/, $line );
# We don't need to say what the fields are, since the
# SQL table definitions had them in the right order.
my $sql = "INSERT INTO $table VALUES ( $values )";
query( $sql, @vals );
}
close SRFILE;
}
exit;
# prepare and execute query, all at once
sub query {
my ( $query, @values ) = @_;
my $sth = $dbh->prepare($query);
$sth->execute( @values );
return $sth;
}
72