Deliverable 1: Project definition and Software Requirements Specification - alejoriosm04/F2F GitHub Wiki
Table of Contents
1. Introduction
1.1 Purpose
The purpose of the FridgeToFeast project is to address the common issue of not knowing what to cook with the ingredients available in one's kitchen. This issue often results in food wastage, unhealthy meal choices, or creative frustration. FridgeToFeast was conceived to offer a solution to this problem by providing personalized recipe recommendations based on the user's available ingredients. The project aims to mitigate these issues by fostering healthier eating habits, reducing food waste, and encouraging culinary creativity. FridgeToFeast is designed to assist busy individuals in meal planning, cater to culinary enthusiasts seeking diverse recipes, and support individuals aiming to enhance their dietary habits.
1.2 Scope
We will develop a web application named FridgeToFeast, which will serve as a personalized recipe recommendation platform. Users will be able to request customized recipes based on their list of ingredients. The software will allow users to edit their ingredient list as needed. Additionally, the application will include a feature to store and manage favorite recipes created by users.
The primary functions of the software include:
-
Recipe Generation: The software will function as a recipe recommendation system, using generative artificial intelligence to create personalized recipes based on the ingredients provided by the user.
-
Ingredient Management: Users will be able to edit and manage their list of ingredients to tailor recipe suggestions to their preferences and dietary restrictions.
-
Favorite Recipes: The application will enable users to save and manage their favorite recipes for future reference.
-
Report Generator: The software will include a report generator feature. This feature will generate bi-monthly reports detailing the user's activity within the application. Insights provided in these reports will be derived from the analysis of the user's most recent generated recipes.
The application aims to serve as a convenient tool for meal planning, reduce food waste, promote healthier eating habits, and provide users with valuable insights into their culinary preferences and behaviors.
1.3 Product overview
1.3.1 Product perspective
FridgeToFeast is a web application designed to provide personalized recipe recommendations based on user-inputted ingredients. As a standalone product, it relies on modern browsers to render its interface accurately. Prioritizing responsiveness, the design ensures ease of use on smartphones.
Developed using the Django web framework, written in Python, FridgeToFeast leverages built-in features for database access and view rendering. With minimal rich media requirements, memory constraints are not a significant issue for the application.
The core functionality of FridgeToFeast involves interacting with external APIs, such as those provided by OpenAI or Google, to generate recipe suggestions. This interaction forms a critical aspect of the product's perspective.
1.3.2 Product functions
The web app will:
-
Keep track of the user's current ingredients.
-
Show a recipe based on those ingredients.
-
Show the history of recipes generated.
-
Report the results of analyzing the most recent recipes.
-
Keep track of the favorites state of each recipe.
1.3.3 User characteristics
Our target users are:
-
People with few things to cook with
-
Couples or families who have little time to cook
-
Cooking enthusiasts with a wide-range of experience
-
Technology enthusiasts, who might be more comfortable with a desktop computer
We don't expect the users to have technical expertise. A responsive web application allows for an intuitive user experience. It also has the advantage of readily accommodating those who prefer a desktop version.
1.3.4 Limitations
It's common for APIs to have an hourly rate limit on requests. For example, Google's "Gemini" has a rate limit of 60 queries per minute. If too many users try to use the service at about the same time, it's possible that the request will rejected or it will time out
In addition to the rate limit constraints commonly encountered with APIs, there are several other limitations that need to be considered during the development of FridgeToFeast:
a) Regulatory policies: Compliance with regulatory policies regarding data privacy, user information handling, and other legal requirements may restrict certain features or functionalities of the application, necessitating careful consideration and adherence to relevant regulations.
b) Hardware limitations: The application's performance may be influenced by hardware limitations, such as signal timing requirements or processing capabilities, which could impact its responsiveness and overall functionality.
c) Interfaces to other applications: Integration with external applications or services may be subject to their specific interfaces and limitations, potentially affecting the seamless interaction between FridgeToFeast and these external platforms.
d) Parallel operation: FridgeToFeast may face challenges related to parallel operation, particularly when handling a significant number of user requests concurrently. This could impact the application's scalability and ability to effectively manage concurrent user interactions.
e) Audit functions: Implementing comprehensive audit functions may be constrained by factors such as the availability of data and the system's ability to track and analyze user interactions effectively, potentially limiting the depth and scope of audit capabilities.
f) Control functions: Certain control functions within the application may be subject to limitations, affecting the extent to which the system can manage and optimize its operations efficiently.
g) Signal handshake protocols: The application's communication protocols, such as XON-XOFF or ACK-NACK, may impose constraints on data transmission and reception;factors such as network congestion, synchronization issues, or errors in data reception could impact the reliability and efficiency of communication between components.
h) Quality requirements: Meeting quality requirements, such as reliability, scalability, and performance, may impose limitations on the design and implementation of FridgeToFeast, requiring careful consideration to ensure the application meets user expectations and standards.
i) Criticality of the application: The criticality of the application lies in its ability to provide accurate and timely recommendations for personalized recipes, as well as its capacity to ensure user data privacy and security.
j) Safety and security considerations: Compliance with safety and security standards and protocols is essential to protect user data and ensure the integrity and confidentiality of information transmitted and stored within the application.
k) Physical/mental considerations: Consideration of physical and mental accessibility requirements is necessary to ensure the application is inclusive and accessible to users with disabilities or special needs, potentially imposing constraints on design and usability.
1.4 Definitions
| Term | Definition |
|---|---|
| AI | Artificial Intelligence. A branch of computer science focused on creating systems capable of performing tasks that normally require human intelligence, such as understanding natural language and recognizing patterns. |
| API | Application Programming Interface. Used to interact with an external system via code. |
| Ingredient | An ingredient is defined as any food item or product that a user has available and can be used as part of a recipe. |
| Kitchen | A section of the application for managing the user's current ingredients. |
| LLM | Large Language Model. A program that generates text based on a large corpus of data on which it was trained. |
| Prompt | The text sent to the LLM. Analogous to a question or request. |
| Recipe | A recipe is a structured set of instructions generated by the application's artificial intelligence, based on input from users regarding available ingredients. It includes a detailed list of ingredients (with specific quantities and units of measure when applicable), step-by-step cooking or preparation directions, and additional information such as cooking time, serving size, and nutritional facts. |
| User | A user is defined as an individual who interacts with the application's interface to input ingredients, receive customized recipe suggestions, manage personal profiles, and utilize additional features provided by the application. |
2. References
[1] Google AI for Developers, βGemini API Pricing.β Accessed: Feb. 16, 2024. [Online]. Available: https://ai.google.dev/pricing
[2] OpenAI, βHow can I access GPT-4?β Accessed: Feb. 15, 2024. [Online]. Available: https://help.openai.com/en/articles/7102672-how-can-i-access-gpt-4
Also, there are some key points regarding food waste in America, presenting a concerning picture of how and why food is wasted. Here's a condensed overview:
- Annually, the U.S. discards about 60 million tons (120 billion pounds) of food, nearly 40% of its food supply, equaling 325 pounds per person.
- A significant reason for this waste is confusion over expiration labels, leading over 80% of Americans to discard still-good food.
- Excessive purchasing habits and not fully using food contribute to the problem.
- Food waste also poses a considerable environmental issue, accounting for 11% of global greenhouse gas emissions.
3. Specific requirements
3.1 External interfaces
| Interface | Ingredient Input Interface | Recipe Generation API | User Data Storage | FridgeToFeast Web Interface |
|---|---|---|---|---|
| Name of item | Ingredient Input Interface | Recipe Generation API | User Data Storage | FridgeToFeast Web Interface |
| Description of purpose | Allows users to input ingredients they have available. | Generates recipes based on input ingredients. | Stores user profiles, ingredient inputs, and saved recipes. | Main user interface for inputting ingredients, viewing recipes, and managing user profiles. |
| Source of input or destination of output | User via web application. | Input from FridgeToFeast; output to FridgeToFeast web application. | Input from web application; output to web application for user profile and recipe retrieval. | User interaction; output displayed on user's device. |
| Valid range, accuracy, and/or tolerance | Any valid food ingredient; input validation for spelling and relevance. | Dependent on API capabilities and ingredient database. | Structured data format; validation for data integrity. | Responsive design for various devices; user-friendly and accessible. |
| Units of measure | Not applicable (textual input). | JSON format. | Database-specific formats (e.g., SQL, NoSQL). | Pixels for layout; seconds for response times. |
| Timing | Real-time as users input their ingredients. | API call made after ingredient submission; response time dependent on API. | Continuous availability for read/write operations. | Real-time user interaction. |
| Relationships to other inputs/outputs | Directly relates to recipe outputs. | Inputs are user-provided ingredients; output is recipes. | Interacts with all other interfaces for data storage and retrieval. | Central hub for all inputs and outputs. |
| Screen formats/organization | Text input field with autocomplete for ingredient names. | Not applicable. | Not applicable. | Clean, intuitive layout with navigation menu, input fields, and recipe display areas. |
| Window formats/organization | Embedded within the main application interface. | Not applicable. | Not applicable. | Modular design for different functions (e.g., ingredient input, recipe display). |
| Data formats | Textual, possibly JSON for API submission. | JSON for both request and response. | SQL, NoSQL, or other database formats. | HTML, CSS, JavaScript for dynamic content. |
| Command formats | Not applicable. | HTTP request with JSON payload. | Database query languages (e.g., SQL queries). | User actions through clicks, taps, and typing. |
| Endmessages | Confirmation message upon submission. | JSON response containing recipes. | Success or error messages for database operations. | User feedback messages for actions (e.g., recipe saved, ingredient added). |
3.2 Functions
| Code | Requirement |
|---|---|
| FR01 | If the user wants to add ingredients to the request, the web app shall allow writing the ingredients if the list of items in their Kitchen is nonempty. |
| FR02 | After adding all ingredients, the web app should allow the user to write the request in a text box element. |
| FR03 | If the user wants to manage an ingredient, the web app shall provide the ability to edit their Kitchen. |
| FR04 | When the Kitchen is updated, the system should save the timestamp in the database. |
| FR05 | As soon as the request is sent the web app shall be able to display from the LLM API answer the recipe if the ingredients were actually edible |
| FR06 | When the user wants a new recipe, the web app could allow choosing the kind of food to eat or cook. |
| FR07 | If a new user wants to use the platform, the web app shall require signing up with email and password. |
| FR08 | Upon entering, the authentication system should allow login associated with their email. |
| FR09 | If the user wants to see statistics, the web app shall provide custom reports if there is data in the statistics section. |
| FR10 | If the user wants to connect on different devices, the web app could be accessed on any modern cell phone or computer. |
| FR11 | When entering on a Monday, the web app should remind the user to update their Kitchen information. |
| FR13 | If the user wants to see their recipes history, the web app should provide access if there is data in their profile. |
| FR14 | When a recipe is generated the web app shall be able to display from the LLM API answer the recipe image |
| FR15 | When the user wants a new recipe, the web app could allow indicating the number of people to cook for. |
| FR16 | When the user wants to generate a new report, the web app should provide custom reports if the last report was generated at least 15 days before. |
| FR17 | Upon entering, the authentication system should authorize access for allowed users only. |
| FR18 | Before sending the request to an LLM API the system shall count all daily requests sent by the user |
| FR19 | When a recipe is generated, the web app shall allow the user to mark the recipe as favourite. |
| FR20 | If the user wants to unmark a favourite recipe, the web app shall allow this if the favourites list is not empty. |
| FR21 | Upon entering, the web app shall allow the user to see the favourites list in the favourites section. |
| FR22 | While the application is loading, the web app should display an animation of a food item. |
3.3 Usability requirements
| Code | Requirement | Definition |
|---|---|---|
| UR001 | Accessibility: Color | The web app design should use colors which contrast enough to make it easily readable by users with colorblindness. |
| UR002 | Simple Layout | The various sections of the web app should be visible, rather than hidden behind several menus. |
| UR003 | Descriptive Error Messages | When the web app fails it should display an error message as descriptive as the system can diagnose. No technical information, just a general reason for failure. |
| UR004 | Account Security Through Login Attempt Limitation | To enhance user account security and prevent unauthorized access, the system must implement a mechanism that temporarily blocks a user account after 3 consecutive failed login attempts. |
| UR005 | Theme Customization for User Preference | The platform should offer users the ability to switch between a pre-defined dark theme and light theme according to their preference. This feature aims to accommodate diverse user needs and lighting conditions, improving accessibility and comfort. |
3.4 Performance requirements
| Code | Requirement | Definition |
|---|---|---|
| PR001 | Server Response Time | The project shall ensure that the server response time does not exceed 300 milliseconds under normal operating conditions. This requirement aims to provide users with quick feedback and a smooth interaction experience with the platform. |
| PR002 | Data Transfer Rate | The system must support a minimum data transfer rate of 3 Mbps to ensure efficient data exchange and a satisfactory user experience. This rate is crucial for supporting timely data delivery for user actions and content loading. |
| PR003 | System Resource Utilization | The system's CPU usage should not exceed 70-80% for processing a user request, ensuring that sufficient resources are available for handling concurrent requests and maintaining overall system performance. |
| PR004 | Maintainability Index | The project shall aim for a maintainability index above 70, considering factors such as code complexity and inter-component dependencies. This index reflects the ease with which the software can be understood, repaired, and enhanced. |
| PR005 | Data Synchronization | Upon updating their Kitchen inventory or settings, users must see these changes reflected immediately in the recipe generation section, enabling them to select updated options in real-time. Additionally, the system must ensure that these updates are synchronized across all of the user's devices seamlessly. |
3.5 Logical database requirements
| Code | Complete Requirement | Types of Information Used | Frequency of Use | Access Capabilities | Data Entities and Relationships | Integrity Constraints |
|---|---|---|---|---|---|---|
| LDR01 | The web application shall enable users to authenticate their account using their email address and password for access | Name, Email, Password (String data types) | High for reads during login; medium for writes during profile updates | Users can access and update their information; administrators have full access | User (Entity) | Email must be unique; Password stored securely |
| LDR02 | If a user wants to view or update their kitchen inventory, then the web app shall allow the user to add, update, or delete ingredients. | Ingredient Name (String), Quantity (Float, Nullable), Unit (Integer, Nullable), Date Entered (Date) | High for both reads and writes (frequent updates, queries for recipe suggestions) | Users can manage their inventory; system processes it for recipe suggestions | Ingredient (Entity) related to User | Quantity and Unit can be null if not applicable; validation for ingredient names |
| LDR03 | The application shall log each request made to the LLM API for generating recipe suggestions, capturing the user ID and timestamp, to facilitate later monitoring and analysis. | Log ID (Integer), User ID (Integer or String), Timestamp of Request (Timestamp) | High for writes (logging each API request); moderate to high for reads (analysis) | Automated system for logging; restricted access for analysis | Recipe Suggestion related to User | Log ID and Timestamp must be unique and not null |
| LDR04 | The database shall store information regarding users' favorite recipes, allowing authenticated users to mark suggested recipes as favorites for future reference | Recipe Name (String), Favorite Status (Boolean) | High for reads (reviewing favorites); medium for writes (adding or removing favorites) | Users can mark recipes as favorites; view their favorite recipes | Recipe (Entity) many-to-many relationship with User (Favorites) | Proper handling of favorite status; association between users and recipes must maintain integrity |
| LDR05 | The web app shall log the ingredients used and the parameters of each request made for recipe suggestions, to accurately match ingredients to recipes and validate user input. | Ingredient List (String or relation to Ingredients entity), Request Parameters (Text or various data types) | High for reads (each recipe request) | Users input ingredients; system generates suggestions based on inventory | Recipe Suggestion involves User and Ingredient entities | Accurate matching of ingredients to recipes; user input validation |
3.6 Design constraints
| Code | Requirement | Definition |
|---|---|---|
| DC001 | Maximum Message Requests for LLM API tools | The system must impose a strict limitation on the number of message requests that can be sent to any Large Language Model (LLM) APIs, setting a cap at a maximum of 24 requests per user per day. This constraint is designed to ensure fair usage policies, manage system load, and prevent abuse. |
| DC002 | Web Accessibility Standards | The system's design and user interface must adhere to Web Content Accessibility Guidelines (WCAG) 2.0 AA or higher to ensure accessibility for users with disabilities. |
| DC003 | Mobile Responsiveness | The system's design must be responsive, adapting seamlessly to different screen sizes and orientations, including mobile devices, tablets, and desktops. |
| DC004 | Data Security and Privacy Compliance | The system design must adhere to data security and privacy regulations, such as GDPR or any local data protection laws, to ensure the protection of user information and data. |
| DC005 | Technology Stack Specification | The development of the system must exclusively utilize Django as the main web framework and Python as the primary programming language. This constraint mandates that all server-side logic, data handling, and web interface development adhere to the capabilities and standards provided by Django and Python. While this requirement specifies the core technologies for the project, it leaves flexibility regarding the choice of design frameworks and database platforms. |
| DC006 | Database Structure Standardization | The system's database structure must adhere to a standardized schema that supports scalability, efficiency, and data integrity. This constraint encompasses the use of specific data types, indexing strategies, naming conventions, and relationships among tables. |
| DC007 | Cloud-Based Hosting and Database Constraint | The system must exclusively utilize cloud-based services for both hosting its application and managing its database. This constraint mandates that all operational and data storage solutions be implemented using cloud infrastructure to ensure scalability, reliability, and accessibility. The selection of specific cloud providers (e.g., AWS, Google Cloud Platform, Microsoft Azure) is flexible, provided they can meet the system's performance, security, and compliance requirements. |
4. Video
https://www.youtube.com/watch?v=lxi5NILhVKY
5. Project management
- Weekly meetings and Retrospective.
- See Backlog