Fridge Management SRS

1
Fridge Management System

Group Members (Alphabetical):
Jamaal Bernabe, Nandini Hariprasad, Marcus Ngooi, Tatsiana Ptushko, Sukhmannat Singh,
Yuko Yamano
Software Requirements Specification Document
Version: 1.0.14 Date: December 18, 2021

Software Requirements Specification for Fridge Management System
Contents
Part A: Project Scope and Requirements 5
Section 1: Problem Statement 5
1.1.a. Problem & Need 5
1.1.b. List of Capabilities and Benefits 6
1.2 Identify the stakeholders and their roles 6
1.3 Identify the sub-systems of your application (What are its functional components) 7
1.4 Who are the intended users of the SRS documentation? 7
Section 2: General Overview Modelling 8
2.1 Context Flow Diagram (CFD) 8
Section 3: Requirements - Functional and Non-Functional 9
3.1 Non- functional Requirements 9
3.2 Goal Use Cases and Functional Requirements 10
3.2.1 User Access and Identification Subsystem 10
3.2.1.1 Functional Requirements and Goal Use Cases 10
3.2.1.2 Use Case Diagram 11
3.2.1.3 User Stories 11
3.2.2 Tracking Subsystem 12
3.2.3 Recommendation Subsystem 14
Section 4: Domain Class Diagram 16
4.1 List of classes 16
4.2 Diagram 17
Section 5: ERD 18
Section 6: Systems Sequence Diagrams 19
6.1 Tracking Subsystem 19
6.2 Recommendation Subsystem 20
2
Section 7: State Diagrams 20

7.1 FridgeItem Class 20
7.2 Recommendation Class 21
Section 8: Technologies 21
Section 9: Project Management (Gantt Chart) 22
Part B: Software Design Architecture 23
Section 1: Requirements Edits to Part A 23
1.1 Domain Class Diagram (section 4.2) 23
1.2 ERD (section 5) 23
1.3 Systems Sequence Diagrams (section 6) 23
1.4 State Diagrams (section 7) 23
1.5 Use Cases 23
Section 2: Overview Model 24
2.1 Intended users of the SDD document 24
2.2 Architectural Context diagram (ACD) derived from Context Flow Diagram (CFD) 24
2.2.1 Context Flow Diagram (From SRS: 2.1) 24
2.2.2 Architectural Context Diagram 25
Section 3: Modularization 26
3.1 Partition the analysis model 26
3.2 First-Cut Design Class Diagram 28
3.3 Class Responsibility Collaboration (CRC) 31
3.3.2 Tracking Subsystem (Automatic food update use case NOT included) 32
3.3.3 Recommendation Subsystem (Use Case - Grocery Recommendation) 33
3.4 Sequence Diagrams 34
3.4.1 Tracking Subsystem: Use case - Automatically update food from Grocery store 34
3.4.2 Recommendation Subsystem: Use case - Recipe Recommendation 34
3
3.5 Final Design Class Diagram 35

3.6 Package Diagrams 38
Section 4: State Machine Diagrams 41
4.1 Objects: FridgeItem Class (use case: Notify users of expiring food) - From SRS 41
4.2 Objects: Recommendation Class (use cases: Recipe Recommendation) - From SRS 42
Section 5: Data Layer 43
5.1. Database schema. 43
Section 6: Technology List Update 43
Section 7: Project Management (Gantt Chart Update) 44
Part C: System Design Document 45
Section 1: Corrections to System Design Document Part B 45
1.1 Modularization (Section 3) 45
Section 2: Software Design Patterns 46
2.1 Applicable Software Design Patterns 46
2.1.1 Singleton - Account 46
2.1.2 Adapter - Third-Party API 47
2.1.3 Facade - Search Functionality 48
Section 3: Using Common Software Design Patterns 49
3.1 Pattern Organization Table 49
3.2 User Access and Identification Subsystem Final DCD with Singleton Pattern 49
3.3 Tracking Subsystem Final DCD with Adapter Pattern 50
3.4 Recommendation Subsystem Final DCD with Facade Pattern 51
Section 4: UI/UX Design 52
Section 5: High-Level Component/Deployment Diagram 55
Section 6: Technology List Update 56
Section 7: Project Management (Gantt Chart Update) 56
4
Part A: Project Scope and Requirements

Section 1: Problem Statement
1.1.a. Problem & Need
In today’s hectic world, it can be difficult to manage the contents of the refrigerator. The average household is busy;
everyone has hectic schedules. It can be hard to keep the refrigerator organized, much less keeping track of
availability and expiry dates.
For those who want to lead a healthy lifestyle, planning meals takes time, effort, and can often become
monotonous. If an individual finds out they are missing the ingredients needed to prepare a healthy dish, they may
instead opt to purchase take-out or order online; this is more likely to occur if they have a very busy schedule.
Individuals can be allergic to specific foods as well, and ignoring the ingredients a product is made of can lead to
hazardous situations. Oftentimes, individuals want variety, but it can be difficult to buy something they want that
is still healthy. This can also lead to a collapse in willpower and, consequently, failure of the diet plan; guilt and
regret ensuing.
The lack of knowledge on expiry dates often leads to food wastage. The City of Toronto estimated that the average
household threw away approximately $1,100 worth of food per year1. Households waste over 100 kilograms of
food annually1. If we combine this cost estimate with the extra cost of purchasing take-out or ordering online, it
can be a painful number to acknowledge for any household that is budget-conscious.
The frequency of this problem will vary between households, but anywhere between daily to bi-weekly. Most often,
anyone with a busy schedule is a potential victim of this problem.
1
City of Toronto. (2021, August 23). Food waste. City of Toronto. Retrieved September 14, 2021, from
https://www.toronto.ca/services-payments/recycling-organics-garbage/long-term-waste-
strategy/waste-reduction/food-waste/.
5
1.1.b. List of Capabilities and Benefits
Capabilities Benefits
1. Store food quantity, quality, and information. 1. Users know what they need when they go
2. Inform users of upcoming expirations. grocery shopping.
3. Can connect to 3rd party API for food and 2. Users won’t waste food because they will be
recipe information. notified when food is expiring.
4. Provide ingredient suggestions if not enough 3. Users can plan in advance what to cook.
is available for a recipe. 4. Users can choose not to plan in advance and use
the suggestions of the software product.
5. Users can check the ingredients of a product to
avoid foods they are allergic to.
1.2 Identify the stakeholders and their roles
Internal External
1. Programmers 1. Household Individuals

2. Project Managers 2. Hardware Technician
3. Testers 3. Software Maintenance Technician
4. Hardware Manufacturer
5. Investors
6. Marketing Staff
7. Salesperson
8. Business Manager
6
1.3 Identify the sub-systems of your application (What are its functional components)
1. User Access and Identification Subsystem.
2. API Management Subsystem.
3. Tracking Subsystem.
4. Recommendation Subsystem.
1.4 Who are the intended users of the SRS documentation?

Internal External
1. Programmers 1. Project Managers

2. Project Managers 2. Investors
3. Testers 3. Marketing Staff
4. Business Manager
7
Section 2: General Overview Modelling

2.1 Context Flow Diagram (CFD)
8
Section 3: Requirements - Functional and Non-Functional

3.1 Non- functional Requirements
NFR# Category Description Priority Requester
NFR001 Usability Users should be able to learn the user interface within 30 Medium UX Designer
seconds.
NFR002 Security Unauthorized users should not be able to access other High Developers
users’ personal data.
NFR003 Security The system should pass DDoS testing, penetration testing, High Developers
and malicious script testing. It should also comply with
ISO/IEC 27001 and 27002.
NFR004 Usability The system should comply with Section 508 of the High UX Designer
Rehabilitation Act.
NFR005 Reliability The software system should have a mean time to failure Medium Developers
(MTBF) of 48,180 hours (estimate based on 5 years
continuous operation with 10% increase for maintenance).
NFR007 Performance System response time should be between 314 milliseconds High Developers
and 862 milliseconds2.
NFR008 Supportability The ability of the faults in the software to be easily found High Developers
and fixed.
9
3.2 Goal Use Cases and Functional Requirements

3.2.1 User Access and Identification Subsystem
3.2.1.1 Functional Requirements and Goal Use Cases
FR# Goal Use Case Role Player Description

FR01 Log in to the system Household Individual, Log in to the system to access a personal
Software Maintenance account after validation of user login
Technician information.
FR02 Change password Household Individual, Allow a registered user to change the
Software Maintenance password.
Technician
FR03 Logout of the system Household Individual, Allow the user to log out of the system at any
Software Maintenance time.
Technician
FR04 Create/update/delete Household Individual Allow the user to register in the system.
profile Allow a registered user to view and update
personal information such as location, recipe
preferences, etc. Allow users to remove
profiles from the system.
FR05 Create/update/delete user Household Individual, Allows software maintenance technicians to

Software Maintenance create, update, and delete users.
Technician
FR06 Save payment information Household Individual Allow users to save payment information
that will be used to order ingredients online
using a third-party payment system.
10
3.2.1.2 Use Case Diagram
3.2.1.3 User Stories

User Story: As a user, I want to create, login, access, modify, and delete my profile.
Acceptance Criteria:
1. User must complete all required fields to register an account.

2. Submission from the same IP can only be made two times within 20 minutes.
3. The user will receive a notification email after a successful registration.
4. A registered user can login, modify and delete their account.
User Story: As a user, I want to be able to change my password if I need to reset my account.
1. User must provide an email to obtain an account recovery link.

2. Provided email must be the email originally registered with the user account.
3. User receives a confirmation email of a successful password change.
11
User Story: As a user, I want to be able to change information on my profile when I choose.
1. User must be logged in to change the profile for that particular user.
2. Notification window appears confirming successful profile change.
3.2.2 Tracking Subsystem

FR# Name (Goal Use case) Role Player Description
FR07 Automatically update Household Allows fridge software to receive food
food Individual purchase information and add it to the
stored food.
FR08 Barcode Scanner Household Allow manual entry of food items by

Individual scanning barcodes.
FR09 Food quantity Household Allows software to give the user

information Individual information on the fridge’s current
contents when requested.
FR10 Notify users of expiring Household Send notification to the user when food
food Individual has been in the fridge for too long.
FR11 Fridge Camera Household Allow users to access internal fridge

Individual images via camera inside the fridge.
12
User Story: As a user, I want to have my groceries automatically added to the fridge inventory.
1. User must be logged on to be able to perform an order.

2. User must navigate to the 3rd party application or website through the system.
3. User receives a notification that their order information was successfully stored in the fridge database.
User Story: As a user, I want to view the information of all food items currently stored in the fridge.
1. User must be logged in to access fridge content information.

2. Food information of the items in the fridge is displayed to the user in an organized fashion.
13
User Story: As a user, I want to be notified when the expiration date for food is near.
1. User will receive a notification window of any expiring foods.
3.2.3 Recommendation Subsystem

FR# Name (Goal Use case) Role Player Description
FR12 Recipe Recommendation Household Allow the fridge management system to
Individual access multiple recipe sites and list
recommended recipes based on the food
available in the refrigerator.
Allow fridge management systems to
filter the recommended recipes by the
user's preferred cuisine.
FR13 Grocery Household Allow the users to choose to either

Recommendation Individual restrict the recommended recipes only
based on food available, or show recipes
with missing ingredients as well. Create a
shopping list of the missing ingredients
required for the selected recipe.
14
User Story: As a user, I want to get recommendations of recipes without going grocery shopping.
1. User must be logged in to receive recommendations.

2. User will be prompted with recommendations based on their profile.
3. User will be prompted with recommendations based on food in the fridge.
User Story: As a user, I want to get recommendations of recipes and I’m willing to go grocery shopping.
1. User must be logged in to receive recommendations.

2. User will be prompted with recommendations based on their profile.
3. User will be prompted with a missing ingredient list for the recommended recipe.
15
Section 4: Domain Class Diagram

4.1 List of classes
1. Account
2. Technician
3. User
4. Profile
5. Item
6. Recipe
7. Recommendation
8. Fridge
9. Camera
16
4.2 Diagram
17
Section 5: ERD
18
Section 6: Systems Sequence Diagrams

6.1 Tracking Subsystem
19
6.2 Recommendation Subsystem
Section 7: State Diagrams

7.1 FridgeItem Class
20
7.2 Recommendation Class
Section 8: Technologies
App Development: React Native for iOS and Android.
API utilization: JavaScript, JSON.
Database: Firebase.
21
Section 9: Project Management (Gantt Chart)
22
Part B: Software Design Architecture

Section 1: Requirements Edits to Part A
1.1 Domain Class Diagram (section 4.2)
1. Removed Inventory.
2. Removed aggregation relationship between Profile and User.
3. Moved Name attribute from Technician and User up to Account.
4. Added ModelNumber and Manufacturer attributes to Fridge.
5. Added Owner attribute to Profile.
6. Added association classes: FridgeItem, ProfileRecipe, ProfileItem.
7. Fixed aggregation relationship between Fridge, Scanner, and Camera.
1.2 ERD (section 5)

1. Moved Name attribute from Technician and User up to Account.
2. Added Scanner entity.
3. Added FridgeItem entity.
4. Changed Item_Item to ProfileItem.
5. Changed Recipe_Item to ProfileRecipe.
6. Added FavoriteRecipe field to profile entity.
7. Removed ProfileID field from Recipe.
1.3 Systems Sequence Diagrams (section 6)

1. Converted Sequence Diagrams to Systems Sequence Diagrams.
1.4 State Diagrams (section 7)

1. Overhauled State Diagrams utilizing adjectives for states and synchronization bars.
2. Added additional states for Recommendation class: 1) Archived, 2) Ignored, 3) Accepted, 4) Rejected.
1.5 Use Cases

1. Added “Create Account” use case to User Access and Identification Subsystem.
23
Section 2: Overview Model

2.1 Intended users of the SDD document
1. Programmers
2. Project Managers
3. Testers
2.2 Architectural Context diagram (ACD) derived from Context Flow Diagram (CFD)
2.2.1 Context Flow Diagram (From SRS: 2.1)
24
2.2.2 Architectural Context Diagram
25
Section 3: Modularization
3.1 Partition the analysis model
1. Login interface
2. Account
3. User
4. Technician
26

1. Tracking interface
2. Item
3. FridgeItem
4. Fridge
5. Scanner
6. Camera
27

1. Recommendation
2. Profile
3. ProfileRecipe
4. Item
5. ProfileItem
6. Recipe
7. Account
8. User
3.2 First-Cut Design Class Diagram

28
29
30
3.3 Class Responsibility Collaboration (CRC)

31
3.3.2 Tracking Subsystem (Automatic food update use case NOT included)
32
3.3.3 Recommendation Subsystem (Use Case - Grocery Recommendation)
33
3.4 Sequence Diagrams

3.4.1 Tracking Subsystem: Use case - Automatically update food from Grocery store
3.4.2 Recommendation Subsystem: Use case - Recipe Recommendation
34
3.5 Final Design Class Diagram

35
36
37
3.6 Package Diagrams

38
39
40
Section 4: State Machine Diagrams

4.1 Objects: FridgeItem Class (use case: Notify users of expiring food) - From SRS
41
4.2 Objects: Recommendation Class (use cases: Recipe Recommendation) - From SRS
42
Section 5: Data Layer

5.1. Database schema.
Section 6: Technology List Update

API utilization: JavaScript, JSON, React, Node.js
Database: MongoDB Atlas
43
Section 7: Project Management (Gantt Chart Update)
44
Part C: System Design Document

Section 1: Corrections to System Design Document Part B
1.1 Modularization (Section 3)
1. Updated CRC cards for Recommendation Subsystem - Grocery Recommendation use case.
2. Updated Final-Cut DCD for Recommendation Subsystem to account for initial search for FridgeItems.
3. Update MVC Pattern Diagram for Recommendation Subsystem to match recommended format.
4. Update MVC Pattern Diagram for User Access and Identification Subsystem to match recommended
format.
5. Update MVC Pattern Diagram for Tracking Subsystem to match recommended format.
45
Section 2: Software Design Patterns

2.1 Applicable Software Design Patterns
2.1.1 Singleton - Account
Name: Singleton
Problem: Only one account should be logged in at a time. Only

one instance of the Account class’ subclasses should
be instantiated at a particular time.
Solution: The singleton design pattern allows us to maintain this

constraint.
Example:
Benefits and consequences: There is no need to worry about more than one
account being logged in at the same time because it
won’t be possible with the singleton design pattern.
When a technician needs access to a particular
system, all users of that system will have to be logged
out.
46
2.1.2 Adapter - Third-Party API

Name: Adapter
Problem: The APIs will differ between grocery stores and may
not always be compatible with the ThirdPartyAPI class
Solution: The adapter translates components of the third-party

API (shopping list from the grocery store) to the
components of the fridge system.
Example:
Benefits and consequences: Adapter creates a single class that is responsible for
joining functionalities of independent classes. The
adapter changes the interface of the existing object so
it's less transparent to the application.
47
2.1.3 Facade - Search Functionality

Name: Facade
Problem: Users should be able to search key terms and get

either recipes and items including recipe and/or item
recommendations. This makes the recommendation
subsystem complex. However, users should see and
interact with a simple interface on the screen.
Solution: The facade design pattern will simplify the interface

for the user while interacting appropriately with the
complex subsystem.
Example:
Benefits and consequences: The facade design pattern will simplify the interface
for the user while interacting appropriately with the
complex subsystem.
48
Section 3: Using Common Software Design Patterns

3.1 Pattern Organization Table
Creational Structural
Data/Content Adapter
Architecture Singleton
Component-level Singleton Adapter
User Interface Singleton Facade
3.2 User Access and Identification Subsystem Final DCD with Singleton Pattern
49
3.3 Tracking Subsystem Final DCD with Adapter Pattern
50
3.4 Recommendation Subsystem Final DCD with Facade Pattern
51
Section 4: UI/UX Design

Implemented Golden Rules of UI/UX Design:
● Make Interface Consistent. The reappearance of the menu icons and the colours are the same from
screen to screen.
● Place User in Control. The user knows where he/she is and what he/she is doing (Breadcrumbs); technical
internals are hidden from the casual user; the design is created for direct interaction with screen objects.
● Reduce User’s Memory Load. Information is disclosed in a progressive fashion. The layout of the
interface has visual clues.
Home Link Design Pattern
Problem: The user needs to go back to the start location of the application
Solution: Create a link to the starting point with the text ‘Home’ and home image. The link should always be in
the same location on all screens.
Breadcrumbs Design Pattern
Problem: The user needs to know their location in order to possibly browse back. (Put user in control)
Solution: Labels are shown in the hierarchical path that leads to the current screen. Each label is a link to a
section. The label of the current screen is at the end of the breadcrumb and is not linked. Each label is separated
with a special character >. Are not used on the welcome page.
Settings Design Pattern
Problem: The user needs to indicate preferences for how the application should behave.
Solution: Provide a place for users to customize their specifications. Keep configurable options well-organized,
predictable, and manageable in number.
Continuous Scrolling Design Pattern
Problem: The user needs to view data that is not easily displayed on a single page.
Solution: New data is automatically retrieved as the user has scrolled to the bottom of the page.
52
User Interface: Home page.
53
User experience flow for the use case Grocery Recommendation:
54
Section 5: High-Level Component/Deployment Diagram
55
Section 6: Technology List Update

API utilization: JavaScript, JSON, React, Node.js
Database: MongoDB Atlas
Section 7: Project Management (Gantt Chart Update)
56

Fridge Management SRS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fridge Management SRS

Uploaded by

Copyright:

Available Formats

1

Fridge Management System

Software Requirements Specification Document

Version: 1.0.14 Date: December 18, 2021

Section 7: State Diagrams 20

3.5 Final Design Class Diagram 35

Part A: Project Scope and Requirements

1.1.b. List of Capabilities and Benefits

1.2 Identify the stakeholders and their roles

1. Programmers 1. Household Individuals

1.4 Who are the intended users of the SRS documentation?

1. Programmers 1. Project Managers

Section 2: General Overview Modelling

Section 3: Requirements - Functional and Non-Functional

3.2 Goal Use Cases and Functional Requirements

FR# Goal Use Case Role Player Description

FR05 Create/update/delete user Household Individual, Allows software maintenance technicians to

3.2.1.2 Use Case Diagram

3.2.1.3 User Stories

1. User must complete all required fields to register an account.

1. User must provide an email to obtain an account recovery link.

3.2.2 Tracking Subsystem

FR08 Barcode Scanner Household Allow manual entry of food items by

FR09 Food quantity Household Allows software to give the user

FR11 Fridge Camera Household Allow users to access internal fridge

3.2.2.2 Use Case Diagram

3.2.2.3 User Stories

1. User must be logged on to be able to perform an order.

1. User must be logged in to access fridge content information.

1. User will receive a notification window of any expiring foods.

3.2.3 Recommendation Subsystem

FR13 Grocery Household Allow the users to choose to either

3.2.3.2 Use Case Diagram

3.2.3.3 User Stories

1. User must be logged in to receive recommendations.

1. User must be logged in to receive recommendations.

Section 4: Domain Class Diagram

Section 6: Systems Sequence Diagrams

6.2 Recommendation Subsystem

Section 7: State Diagrams

7.2 Recommendation Class

API utilization: JavaScript, JSON.

Section 9: Project Management (Gantt Chart)

Part B: Software Design Architecture

1.2 ERD (section 5)

1.3 Systems Sequence Diagrams (section 6)

1.4 State Diagrams (section 7)

1.5 Use Cases

Section 2: Overview Model

2.2.2 Architectural Context Diagram

3.1.2 Tracking Subsystem

3.1.3 Recommendation Subsystem

3.2 First-Cut Design Class Diagram

3.2.2 Tracking Subsystem

3.2.3 Recommendation Subsystem

3.3 Class Responsibility Collaboration (CRC)

3.3.3 Recommendation Subsystem (Use Case - Grocery Recommendation)

3.4 Sequence Diagrams

3.4.2 Recommendation Subsystem: Use case - Recipe Recommendation

3.5 Final Design Class Diagram

3.5.2 Tracking Subsystem

3.5.3 Recommendation Subsystem

3.6 Package Diagrams