wsu-4110 / leftovr Goto Github PK

Repository for the LeftOvr group.

CSS 2.29% JavaScript 2.14% HTML 8.77% Python 86.80%

pycharm html5-css3-javascript python3 bootstrap

leftovr's Introduction

About us

Food waste has been a problem for ages.
While many go hungry and even starve to death all around the world,
others throw food away daily.
We as individuals throw away food at home
but restaurants and grocery stores also throw away a ton of food.
--------
Through this platform, we wish reduce atleast some amount of food waste
by connecting individuals with restaurants.

The Look

Some Elements

* Home Page, About Us, Contact Us
* Learn Why we choose this project/brand purpose
* Sign up as a customer
* Sign up a restaurant

Getting Started

* Download Latest Version of Python
* Download PyCharm
* Download Django
* Download the things in requirement.txt

After opening project in pycharm, on terminal run commands:

python manage.py runserver  
            or
python3 manage.py runserver

Developers

FrontEnd:

   Susanna Arun
   Fahmida Chowdhury

BackEnd

  De'jon White 
  Omari King

leftovr's People

Contributors

Stargazers

Watchers

leftovr's Issues

NFR2. Valid Business ID

NFR2. Require Business ID for SignUp
Goal: The System should validate the authenticity of the restaurant
Stakeholders: Restaurants
Description: When a restaurant visits our website, they will be directed to a sign-up page. The page will ask, what they want to Sign Up as, a restaurant or a customer. Once the desired option is chosen, they will be asked for their Name, Restaurant email, Restaurant Name, Restaurant's location, business ID, and password. In the case of the business ID, the system should check to see if it is an actual business ID and if the ID matches the name and address provided. If not then the system will display an error message, asking the individual to re-enter the information accurately.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 28/09/2020

FR25. About Us

FR25. About Us
Goal: The goal is to inform customers about the business
Stakeholders: Customers and restaurants
Description: This option will allow users to learn about the platform. It will explain to the users what the platform is about, what it has to offer, and how they can use it. It will also explain the purpose of the platform to the customers.
Origin: Based on the initial project specification document, team members came up with this description during the seventh meeting.
Version: 1.0
Date: 09/11/2019

NFR10. Responsive Refresh Time

NFR10. Responsive Refresh Time
Goal: The data for available restaurants should take at most 10 seconds to refresh
Stakeholders: Customers
Description: The website should be built in a way that allows information from the database to be pulled in seconds to allow the efficient service in providing the location of nearby restaurants offering leftover food.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR26. User ID Directory

FR1. Internal countdown clock system UI
Goal: System will have a countdown system that counts down from 24 hours.
Stakeholders: Customers
Description: The system will start at 24 hours from the time that the moment the product is confirmed to be picked up so that no other food is order until 24 hours have passed not allowing the user to order another order within that time span.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR6. Internal Clock System

FR6. Internal Clock System
Goal: The system counts down from 24 hours once the meal is confirmed to have been picked up
Stakeholders: Customers
Description: System lacks required tools, so unable to complete feature. Once a customer picks up the food they reserved, there will be a clock that counts down from 24 hours, within that time frame the user will not be able to pick up or reserve another meal until that timer is up.
Version: 1.0
Date: 09/28/2020

NFR5.Authentic login ID

NFR5.Authentic login ID
Goal: To allow easy access to the login to a website every time the customer would like to use his/her account
Stakeholders: Customers
Description: The website will save all the login information on a database so that the user has his/her own unique ID to login with. The user will be allowed to log in either using their phone number or email, along with the password they set up during registration. (Licence/state ID number required during the registration process)
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR27. Contact Us Directory

FR27. Contact Us Directory
Goal: The goal is to have user feedback stored
Stakeholders: Customer and restaurant
Description: When a customer, restaurant, or visitor, uses the contact us form, the data provided such as name, email, and text from the individual should be stored for future reference. This will allow admin users to contact the individual in regard to the provided feedback if necessary.
Origin: Based on the initial project specification document, team members came up with this description during the seventh meeting.
Version: 1.0
Date: 09/11/2019

FR30. Nav Change - Customer

FR30. Nav Change- Customer
Goal: After login, the menu/navigation bar should change
Stakeholders: Customer
Description: Before log in the nav-bar includes things such as login, but after the customer logs in the bar should change. And include a search bar along with the profile button, receipts button, and log-out button.
Origin: Based on the initial project specification document, team members came up with this description during the seventh meeting.
Version: 1.0
Date: 09/11/2019

FR 12. User must be able to upload profile picture

FR 12. User must be able to upload profile picture
Goal: Identification purposes
Stakeholders: Customers
Description: This feature will allow restaurants to double-check before giving out a free meal and make sure the individual who ordered through the website is the same as the one who is picking up the free meal.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR.21 View Receipt

FR.21 View Receipt
Goal: The system should create a receipt.
Stakeholders: Customers
Description:
After an item is reserved, the system should create a receipt and the receipt should be visible to customers along with other past receipts.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR22: Home Page

FR22: Home Page
Goal: The system should welcome users
Stakeholders: all
Description: The system should have the main page that is displayed once anybody visits the website.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

NFR9. Accessible on any device

NFR9. Accessible on any device
Goal: The software will be available regardless of what modern device is used
Stakeholders: Customers and restaurants
Description: The website will be able to handle mobile, tablet, and laptop/desktop users. For mobile smartphone users, they will have the option of using an email or a phone number. The other devices will be able to access through a wifi hotspot or wireless connection using an email to log in.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

issue deleted

FR.23 Sign Up Options

FR23. Sign Up Options
Goal: Display roles to clear confusion
Stakeholders: All
Description: When an individual visits that website, he/she should be asked to pick his/her role before signing up. Our system has two roles for users: Restaurant and Customer.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

NFR 11. Users and dependants get 1 meal each every 24 hours

NFR 11. Users and dependants get 1 meal each every 24 hours
Goal: To ensure that everyone, the user and other people added under the account users name, is granted at least 1 meal per day each.
Stakeholders: Customers
Description: This should allow customers to get 1 meal and only 1 meal every 24 hours. However, because a user is able to create multiple accounts this feature isn't feasible.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR18. Passwords and email change

FR18. Passwords change
Goal: The system should allow users to change password, and should also have a forget password option
Stakeholders: Customers and restaurants
Description: For personal reasons, users may want to change passwords. So, the system should allow that. However, the system should make sure that State ID, driver’s license ID, and business ID is not being changed. Also, in the log-in screen, an option for forgetting a password should be displayed, which would redirect them to an alternative page to enter the email ID for the account so that a reset password email can be sent.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR1. Registering with State/Driver license ID UI

FR1. Registering with State/Driver license ID UI
Goal: The system should require the customer to sign up using an ID
Stakeholders: Customers
Description: When a customer visits the website for the first time, they will be asked to register as a customer. They will need to enter an email address, phone number, first and last name, a password, and their state/driver license ID number.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/11/2019

FR31. Restaurant Header and Logo Upload

FR31. Restaurant Header and Logo Upload
Goal: Display the given images on the restaurant's page
Stakeholders: Customer and restaurant
Description: System should allow the restaurant to add a logo image and a header image so it can be displayed in the restaurant profile.
Origin: Based on the initial project specification document, team members came up with this description during the seventh meeting.
Version: 1.0
Date: 09/11/2019

FR 25: Create Location in database for Comparison Use

FR7. Leaving Reviews

FR7. Leaving Reviews
Goal: The user should be able to leave reviews for the restaurant
Stakeholders: Customers
Description: Depending on how the experience was for customers, be it going to the restaurant to pick up the leftovers, or the meal itself, people will be able to see how the employees service was based on how many people ranked it. It gives incentive for restaurants to provide good service through the website and gives people an idea as to how good the food is along with how well they were treated.
--

| Origin: Based on the initial project specification document, team members came up with this description during the first meeting.|
| Version: 1.0 |
|Date: 09/28/2020| Priority: 1 |

-----------------------

FR29. No Search Result
Goal: User should be notified if there are no restaurants available
Stakeholders: Customer
Description: When a customer searches for a restaurant nearby and there isn't one with available meals, the system should provide a message saying, "Sorry. There are no restaurants available at this time. Try again later." For example, this may happen at night around 2 AM, since many restaurants will be closed at that time.
Origin: Based on the initial project specification document, team members came up with this description during the seventh meeting.
Version: 1.0
Date: 09/11/2019

FR32. Past Receipts

FR32. Past Receipts
Goal: allow the customer to view old receipts
Stakeholders: Customer
Description: This issue will allow the customer to view a maximum of 6 previous transaction list. This will not include the current/most recent receipt. The system will provide a different page for that. When clicking to view receipt details user will receive an error message because all information about each receipt won't be stored.
Origin: Created during progress.
Version: 1.0
Date: 11/05/2020

FR4. Add Address/Zip code (1 or more) UI

FR4. Add Address/Zip Code (1 or more) UI
Goal: The system should allow customers to add one or more addresses or zip codes.
Stakeholders: Customers
Description: For a customer to search for a restaurant, they are required to provide a zipcode or address. Therefore, the system should allow the customer to change or add more addresses. These zip codes or/and addresses should be stored in the customer's directory. If a customer, wishes not to search with their full address, they may also choose to search using a zip code.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

NFR20. Multiple Customers Accessing a Restaurant

NFR20. Multiple Customers Accessing a Restaurant
Goal: The system will unable to safeguard itself from crushing due to multiple transactions happening at once
Stakeholders: Customers
Description:
When more than one customer is checking out or accessing one particle restaurant, it is likely that the system, in that case, will crash. The website needs to be built in a way that it can handle the capacity of trying to reach the same goal.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

NFR19. Protection of users data

NFR19. Protection of users data
Goal: The system will be unable to prevent data breaches
Stakeholders: Customers and restaurants
Description: If for some reason, the system hacked or compromised there is a risk of customers’ and restaurants’ information being leaked. The system will not be able to prevent it from happening.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR28. Restaurant Directory

FR28. Restaurant Directory
Goal: The goal is to ensure information about the restaurant is stored
Stakeholders: Customer and restaurant
Description: The information provided by the restaurant should be kept securely under accurate restaurant user ID. The information includes logo image, cover picture, meal picture, available meals, restaurant contact information, operation hours. This way the customer will be available to view correct and accurate information about the restaurant
Origin: Based on the initial project specification document, team members came up with this description during the seventh meeting.
Version: 1.0
Date: 09/11/2019

FR 13. Reserve /Add Checkout item

FR 13. User should be able to pick an item and reserve it
Goal: Reserve items
Stakeholders: Customers
Description: The system should allow users to pick any available item and check it out. Once they chack it put the system should display a thank you message and it should let the user know when he/she should pick the item up
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR 15. Add & Remove food Items(HTML Layout)

FR 15. Restaurant is able to add/remove food that is leftover from a meal to their menu on the app
Goal: To visual to customers about the options available at the restaurant
Stakeholders: Resturants
Description: After every meal is picked up, the restaurant needs to log it into the website and reduce the number of meals available. The same goes if there's an extra meal, and it needs to be added under the restaurant's log. This allows the users to know how many meals are available of a particular dish.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR3. Ability to Search for Restaurants Nearby UI

FR1. Ability to Search for Restaurants Nearby UI
Goal: This feature will allow customers to look for nearby restaurants
Stakeholders: Customers
Description: After a customer logs into the system, they will be able to use a search bar and search the system using keywords or names of restaurants. The system will then list the restaurants available within a certain area or radius based on their zip code.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 28/09/2020

NFR17. Push Notifications

NFR17. Push Notifications
Goal: The system will allow customers to customize their push notifications
Stakeholders: Customers
Description: When a customer is interested or favors a restaurant or a meal, he/she should be able to set up a notification about that meal's giveaway, or the restaurant. The customer should also be able to set up notification based on current available meals nearby.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR16. Restaurants visibility to customers

FR16. Restaurants visibility to customers
Goal: The system should allow restaurants to change their visibility
Stakeholders: Customers
Description: When a restaurant is not giving away any food, then they should be allowed to change its visibility to “Not Visible To Customer.” So when the customers search for nearby restaurants, that particular restaurant will not show up in the search results.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR 14. Log out

FR 14. Log Out
Goal: User can log out of his/her account
Stakeholders: Customers
Description: After log in the system must allow the customer or restaurant to log out. After they log out users shouldn't be able to access information that they were able to access when they were logged in. Logout should direct user to the Login or index page.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020

FR8. Contact Option

FR8. Contact Option UI
Goal: If the user is having issues with the application there should be an option for them to contact anyone on the website for help
Stakeholders: Customers
Description: When a customer is having issues with the application whether it be to check if something is correct within the app or ask for assistance using it, there should be an option on the site to ask someone for help. As long as the restaurant is still open, someone is available online to help answer questions.
Origin: Based on the initial project specification document, team members came up with this description during the first meeting.
Version: 1.0
Date: 09/28/2020