A dvanced T echnology. A id C ollege C ampuses. Design Use Cases. Food Delivery App: SNACC ATTACC. Group Members:

Transcription

1 1 Design Food Delivery App: SNACC ATTACC A dvanced T echnology T o A id C ollege C ampuses Group Members: Jacques Chazelle Sarah George Shweta Kinger Catherine Lin Jonathan Luck Gregory Sabado Skyler Taylor Curtis Tong Victoria Tom Ben Tucker Kevin Wu

2 2 Table of Contents DUC 1 - User Account Creation 3 DUC 2 - User Login 5 DUC 3 - Forgot Password 7 DUC 4 - Check Order History 9 DUC 5 - Check Delivery History 11 DUC 6 - Becoming a Deliverer 13 DUC 7 - View Info 14 DUC 8 - Placing an Order 15 DUC 9 - List of Placed Orders - (In Queue) for the Deliverers 17 DUC 10 - Deliverer Accepting an Order 18 DUC 11 - Chat Client Between Deliverer and Orderer 20 DUC 12 - Confirming Meal Bought w/ Receipt 21 DUC 13A - Confirm order received 23 DUC 13B - Confirm payment received 25 DUC 14 - Cancelling an order 26 DUC 15 - Rating a Deliverer 27 DUC 16 - Rating an Orderer 29 DUC 17 - Deliverer Provides Pre-made Updates to Orderer 30 DUC 18 - User Logout 32 DUC 19 - User Settings 33

3 3 DESIGN USE CASE #1 - User Account Creation Dependent Pre-conditions Trigger Design The user creates a new account using their address and a password. The user will be able to create an account that they can use. The user wishes to create an account. N/A High SR 1 An account does not already exist with the entered as input and the user is on the login page. The system shall redirect the user to the login page. The user does not have an account yet and would like to register to use the application. 1. The frontend shall render Login.js 2. The user shall click on the Register button. 3. The frontend shall render and display the SignUp.js page. 4. The user shall input their name, , password, and phone number in the corresponding textboxes and click the Register button. 5. The backend (Firebase) shall validate the form. 6. The backend shall create a new user object under users with the info provided in adduser(). 7. The backend shall send an to the user s address with a link to verify their account. 8. The frontend shall alert the user that a verification has been said to their address. 9. The user shall access the received and click on the link. 10. The backend shall verify the user object in the database. Invalid Name: 4. The user shall input an invalid name containing non-alphabetic characters. 5. The system shall notify the user that the name can only contain alphabetic characters.

4 4 Invalid 4. The user shall input an invalid or already taken The system shall notify that the is invalid or taken. Not matching Passwords: 4. The user shall input nonmatching passwords. 5. The system shall notify the user that the passwords do not match. Invalid Phone Number: 4. The user shall input an invalid phone number not containing 10 characters and/or containing non-numeric #s. 5. The system shall notify the user that the name can only contain 10 numeric characters

5 5 DESIGN USE CASE #2 - User Login Dependent Pre-conditions Trigger Design The user can access their account using their and password. The user shall be able to login to the website using their account. The user wishes to login to the website using their account. DUC 1 High SR 3 The user already has a verified account, and has navigated to the login page. The system shall keep the user logged in until they logout. The user is not logged in and wants to access the application. 1. The frontend shall render and display the Login.js page. 2. The user shall enter their login credentials into the corresponding textboxes provided ( address and password) 3. The backend shall verify that the login credentials match the info of an active user object in the database, log the user into the application, and redirect the user to the Home.js page. 4. The frontend shall display the Home.js page to the user. Incorrect format: 2. The user shall enter their without the domain name (part and click the Login button. 3. The backend shall failed to authenticate the login and reject the login attempt. 4. The frontend shall display a notification to the user that the field is incorrectly formatted. User does not exist: 2. The user shall their and password without having registered and verified their account, and click the Login button. 3. The backend shall failed to authenticate the login and reject the login attempt.

6 6 4. The frontend shall display a notification to the user that user with the given does not exist. Incorrect password: 2. The user shall correctly their into the field and leave the password field blank (or enter it with incorrect info), and click the Login button. 3. The backend shall fail to authenticate the login and reject the login attempt. 4. The frontend shall display a notification to the user that the password is incorrect.

7 7 DESIGN USE CASE #3 - Forgot Password Dependent Pre-conditions Design The user will be able to reset their password by entering their . The user is sent an containing a link for resetting their password. The user shall be able to reset their password to be able to login into their account. The user wishes to reset their password to be able to login into their account. DUC1 Low SR 4 The user already has a verified account, and is on the login page. The system shall redirect the user to the login page. Trigger The user has forgotten their password and wants to access the application. 1. The frontend shall render Login.js. 2. The user shall click the Forgot Password hyperlink underneath the text boxes. 3. The frontend shall display a text box for the user to enter their address. 4. The user shall enter their address in the text box and hit the Submit button. 5. The backend shall verify that the entered is attached to the user s object in the database, and send an to the address with a link to reset the password. 6. The frontend shall notify the user that an has been sent to the given address and redirect them to the Login.js page. 7. The user shall log into their , click on the link redirecting the user to a Firebase-generated page to reset their password. 8. The user shall enter in a new valid password. 9. The user shall hit the Submit button 10. The frontend shall display text saying Password successfully changed to the user.

8 8 Invalid address The user enters an invalid address and hits Submit button. The backend checks the input address does not match the user s address in the database. The backend shall throw an error. The frontend shall display the message Invalid address. to reset password has not been sent. to the user. Invalid password The user enters an invalid new password and hits Submit button. The backend throws an error. The frontend shall display the message Invalid password to the user.

9 9 DESIGN USE CASE #4 - Check Order History Dependent Pre-conditions Trigger Design The user can view their history of placed orders. The user is brought to a page where they can view all their completed past orders. The user wishes to see completed orders with details. DUC1, DUC2 Low The system shall allow a user to see a list of orders they have placed, including the food items ordered, the cost, and the time delivered. The user has created an account and is logged in. The system shall display the list of food orders on the screen. The user wants to see all food orders that they have placed. 1. The user shall click on the Order History button on the Home.js page. 2. The frontend shall start rendering the OrderHistory.js page. 3. The backend shall pull list of past order IDs from the user object s pastorders section 4. The backend shall generate a OrderCardWithRating for each order ID, which will pull and render the order data from the database (the restaurant, the number of items, the delivery location, the time of order, the cost of the order and the user s rating of the deliverer) along with a Details button for more info. 5. The frontend shall render and display the all OrderCardWithRating objects on the OrderHistory.js page. User clicks the Details button on one of the order cards The frontend shall display the OrderDetails.js page for that order, which will display the orderer s name, deliverer s name and number, status, restaurant, items, special requests, total, delivery location, time placed, chat and uploaded receipt. The user wishes to return to the Home page The user shall press the Burger icon in the top left of the page The frontend shall render the Home.js page

10 No past orders The frontend shall display You do not have any past orders on the OrderHistory.js page 10

11 11 DESIGN USE CASE #5 - Check Delivery History The user can view all the orders they have delivered. Dependent Design Pre-conditions The user is brought to a page where they can view all their completed past deliveries. The user wishes to view past orders that they have delivered. DUC1, DUC2 Low The system shall allow a user to see a list of orders they have delivered, including the number of food items delivered, the cost, and the time delivered. The user is logged in to an account and is at the Home.js page. The system shall bring the user to a page displaying their delivered orders. Trigger The user wishes to see all orders they have taken and their corresponding details. 1. The user shall click on the Your Delivery History button in the Delivering tab. 2. The frontend shall render the TakenHistory.js page. 3. The backend shall pull list of past order IDs from the user object s pastdelivery section 4. The backend shall generate a OrderCardWithRating for each order ID, which will pull and render the order data from the database (the restaurant, the number of items, the delivery location, the time of order, the cost of the order and the user s rating of the deliverer) along with a Details button for more info. 5. The frontend shall display the all OrderCardWithRating objects on the TakenHistory.js page. Return to Home page The user shall press Burger icon on the navigation bar at the top left of the page

12 The frontend shall render the Home.js page Has not made any deliveries The frontend will display You do not have any past deliveries on the TakenHistory.js page 12

13 13 DESIGN USE CASE #6 - Becoming a Deliverer The user can become a deliverer so that they are able take and deliver orders Dependent Design Pre-conditions Trigger The user becomes a deliverer, unlocking the delivery options The user wishes to become a deliverer DUC1, DUC2 High The system shall allow a user to become a deliverer after they have entered their preferred payment options. The user has logged in to their account, has specified their preferred payment options on the User Settings page and is at the Home.js page The system shall let the user know that they have successfully become a deliverer. The user wishes to become a deliverer to earn some extra cash. N/A 1. The user shall click Become a Deliverer button under the Settings tab 2. The backend shall call set_deliverer() which will update the user object to be a deliverer if user has already set preferred payment options in settings. 3. The frontend shall re-render the Home.js page to include a Delivering tab and remove the Become a Deliverer button from the Settings tab.

14 14 DESIGN USE CASE #7 - View Info The user will be able to learn about how the application works, including pricing, transactions, and how to become a deliverer. Dependent Design Pre-conditions Trigger The user will be able to choose what food they want to order from the list of available restaurants. The user wishes to view information on the app. DUC2 Low SR 8 The user is logged in to an account and is at the Home.js page. User will have access to the menus of each available restaurant. The user wants to learn about how the application works. N/A 1. The user shall click on the Info button under the Settings tab. 2. The system shall list information about pricing, transactions, becoming a deliverer, disclaimers, and completing an order.

15 15 DESIGN USE CASE #8 - Placing an Order Dependent Design Pre-conditions Trigger The user will be able to place and customize an order by selecting a restaurant, their choice of menu items and where they want their food dropped off. The user will also be able to optionally input any special requests they have for their order (i.e. no sauce or substitute one item for another). The user successfully places an order which will be added to the queue. The user wants to place an order for food items from a specific restaurant to have delivered to them at a specified location. The user might also want to input a special request or specific details for their order. DUC1, DUC2, DUC7 High The user s choice of restaurant to order food items from is limited to those listed in the drop down list. The system shall limit orders to 3 per day and limit transaction subtotal to $20 per order. The user shall be limited to and must choose one of the available location options in a given drop-down menu. The user is logged into an account, is on the Home.js page and has not already placed an order. The user s order is placed and added to the queue for a deliverer to pick up. The user wants to place an order for delivery. 1. The user shall click the Place an Order button under the Ordering tab on the Home page. 2. The frontend shall redirect the user to the Order.js page. 3. The backend shall pull restaurants from the database and place them into a list. 4. The frontend shall render the list of restaurants into a drop-down table under the heading Step 1: Choose a restaurant. 5. The user shall select a restaurant from the drop-down table. 6. The backend shall pull the selected restaurant s menu items & prices from the database and place them into a list. 7. The user shall click the + Add An Item button.

16 16 8. The backend will call additem() which will generate a OrderCard object containing a drop-down table of the restaurant s menu items and prices (which starts at the first menu item), the subtotal of the given item quantity, a - and + button to decrease/increase the quantity of the selected item (which starts at 0), and an X button to delete the OrderCard object. 9. The frontend will render and display the OrderCard object as well as a button below it labelled + Add Another Item which will allow the user to generate another OrderCard object if it is pressed. 10. The user shall select a food item from the drop-down table in the OrderCard. 11. The user shall increase/decrease the quantity to a number of their choice with the + and - buttons. 12. The backend shall update the item s quantity and the subtotal of the order if the new subtotal does not go over the $20 limit. 13. The frontend will display the new quantity and subtotal. 14. The backend shall pull the delivery locations from the database and place them into a list. 15. The frontend will display the list as a drop-down table. 16. The user shall select a delivery location from the drop-down table. 17. The user shall optionally input special requests in a textbox with heading Step 4: Special requests. 18. The backend will take the subtotal of the order, apply a delivery fee and tax rate to it and set the value as the order total. 19. The frontend will display the subtotal, delivery fee + tax and total. 20. The user shall check one or both of the boxes for payment preferences (Cash and/or Venmo). 21. The user shall click the Submit Order button located at the bottom of the page. 22. The backend shall call submitorder() which will generate a new Order object using the order data specified by the user and then push it to the database. 23. The frontend shall notify the user that their order has been placed and redirect them to the Home.js page. User wants to return to home page The user shall press the Burger on the navigation bar at the top left of the page to return to the Home.js page. Subtotal above $20 The user shall click the + button of an item in an OrderCard, increasing the quantity of the item and subtotal of the order.

17 The backend shall find the new subtotal to be above $20 and therefore prevent the quantity and subtotal from being increased. The frontend shall display a popup Cannot add item. Exceeds spending limit for users who have reached the spending limit. 17

18 18 DESIGN USE CASE #9 - List of Placed Orders - (In Queue) for the Deliverers The user will be able to see all the possible order they can take on Dependent Design Pre-conditions Trigger The user is able to make a choice on what orders they want to take The user wants to see available orders DUC 2, DUC 6, DUC 8 High The list will only display orders that have not already been taken on by other deliverers. User is logged into an account, has registered as a deliverer, is on the homepage and has not placed an order. None The user wishes to view what orders they can take. 1. The user shall select the View Order Queue button under Delivering tab in Home.js 2. The frontend shall redirect the user to the AvailableOrders.js page. 3. The backend shall query the list of placed orders from the database that meet the payment preferences of the user 4. The frontend shall display the list of placed orders from oldest to newest (i.e. how long ago an order was placed). No Available Orders 3. The backend shall return an empty list, implying no currently placed orders 4. The frontend shall display No available orders at this time. on the AvailableOrders.js page.

19 19 DESIGN USE CASE #10 - Deliverer Accepting an Order The deliverer will be able to pick an order off of the queue and accept it, meaning the deliverer will fulfill it. Dependent Design The order is accepted by/assigned to the deliverer. The deliverer wants to accept an order to deliver. DUC 2, DUC 6, DUC 9 High The system shall allow a deliverer to accept an order. Pre-conditions The user is logged into an account, is a deliverer and has navigated to the Available Orders page. At least one order has been placed into the queue. Trigger The system shall assign the selected order to the deliverer. The user wants to deliver an order. 1. The user shall click on the Details button for one of the available orders. 2. The backend shall pull the order data for the selected order. 3. The frontend shall use the order data to render it s OrderDetails.js page. 4. The user shall scroll to the bottom of the OrderDetails.js page and click the Take Order button. 5. The backend will verify that the order has not been accepted, and will mark it as accepted in acceptorder(). 6. The frontend shall check the Order Taken box on the current order page for the orderer Order.js and open a chat box. Another orderer picks up order meanwhile: 4. The backend shall verify that the order has been accepted in acceptorder(), and deny the order. 5. The frontend shall display a popup to the deliverer saying Order has already been taken and remove the order from the queue in removeorder() in DQueue.js.

20 20 DESIGN USE CASE #11 - Chat Client between deliverer and orderer The app will provide an in-app chat client between deliverer and the recipient Dependent Design Pre-conditions Trigger The Deliverer and the Orderer are able to chat with each other The deliverer and orderer wish to communicate with each other UC 2, UC 6, UC 9 Medium None. The recipient has placed an order, the deliverer has taken that order. Both users navigate to the order details page for the order (i.e. orderer clicks the Your Current Order button from the home page, deliverer clicks Your Current Deliveries button then the Details button for the given order). The recipient and deliverer are able to chat with each other. The deliverer and the orderer want to communicate about the order. N/A 1. The backend shall call makechat() which will generate the chat box. 2. The user shall scroll down to the chat box, type a message in the textbox and press send. 3. The backend shall call makechatmessage() which will store the message, its sender and the time it was sent in the database. 4. The frontend shall render and display the message on the right side of the chat box for the sender of the message and on the left side of the chat box for the receiver of the message. The new message will be displayed below any earlier messages in the chat.

21 21 DESIGN USE CASE #12 - Confirming Meal Bought w/ Receipt The deliverer uploads a picture of the receipt, indicating the food has bought and is on the way. The receipt is also preserved in case of dispute. The deliverer successfully uploads a picture of the receipt for the orderer to see. The deliverer wants to inform the orderer that their food has been purchased. Dependent Design Pre-conditions Trigger DUC 2, DUC 6, DUC 9 Medium The system shall have camera and database functionality implemented to take a picture of the receipt and store it for safekeeping. The user is logged into an account and is on the Order Details page for the completed order. The image will be uploaded to the order s detail page and stored in the database for safekeeping. The deliverer wants to be able to prove they have bought the food to give an update on the order and prevent fraud. 1. The backend will call makeupload() which will generate the Upload Receipt option. 2. The frontend will display the Upload Receipt option at the bottom of the page. 3. The user (deliverer) shall scroll to the bottom of the page. 4. The user shall click the Browse button under the heading Upload Receipt. 5. The user shall choose the receipt image. 6. The user shall click the Submit Receipt button. 7. The backend shall save the receipt image to the database. 8. The frontend shall call makereceiptimage which will check for then display the receipt image.

22 22 Changing the receipt image 9. The user shall select the Browse button, which will prompt the user to select another image. 10. The user shall select an image. 11. The backend will replace the current receipt image in the database with the new image. 12. The frontend will display the new receipt image on the order detail page.

23 23 DESIGN USE CASE #13A - Confirm order received The orderer will be able to confirm that the order was received from the deliverer. Dependent Design To have a successful transaction, meaning the orderer received the food and the deliverer received payment. To notify the system that the order was received by the orderer. DUC 9 High SR 19 Pre-conditions User is logged into an account. An order has been placed and accepted by a deliverer. User is on the OrderDetail.js page for the order. Trigger The system will be notified that the transaction has been completed. The user has received the food from the deliverer. 1. The user (orderer) shall scroll down to the bottom of the page. 2. The frontend shall display a button labelled Order Received. 3. The user shall click the Order Received button. 4. The frontend will redirect the user to a Confirmation.js page for the order. 5. The backend shall set foodreceived to true in confirmorder() in OrderDetails.js. 6. The user shall click the Confirm Transaction Complete button. 7. The backend shall call checkcompleted() which will set order status to complete if moneyreceived and foodreceived have been set to true. 8. The frontend shall inform the user that the transaction has been complete. Deliverer has not confirmed money has been received.

24 6. The user shall click the Confirm Transaction Complete button. 7. The backend shall call checkcompleted() which will find that moneyreceived has not been set to true. 8. The frontend shall inform the user that they are waiting on the Deliverer to confirm money received. 24

25 25 DESIGN USE CASE #13B - Confirm payment received The deliverer will be able to confirm that the payment was received from the orderer. Dependent Design To have a successful transaction, meaning the orderer received the food and the deliverer received payment. To notify the system that the payment was received by the deliverer. DUC 9 High SR 20 Pre-conditions User is logged into an account. An order has been placed by orderer and accepted by user. User is on the OrderDetail.js page for the order. Trigger The system will be notified that the transaction has been completed. The user got prompted to finish the transaction. 1. The user (deliverer) shall scroll down to the bottom of the page. 2. The frontend shall display a button labelled Money Received. 3. The user shall click the Money Received button. 4. The frontend will redirect the user to a Confirmation.js page for the order. 5. The backend shall set moneyreceived to true. 6. The user shall click the Confirm Transaction Complete button. 7. The backend shall call checkcompleted() which will set order status to complete if moneyreceived and foodreceived have been set to true. 8. The frontend shall inform the user that the transaction has been complete. Orderer has not confirmed food has been received. 9. The user shall click the Confirm Transaction Complete button.

26 10. The backend shall call checkcompleted() which will find that foodreceived has not been set to true. 11. The frontend shall inform the user that they are waiting on the Orderer to confirm food received. 26

27 27 DESIGN USE CASE #14 - Cancelling an order The deliverer will be able to cancel an order if that order can t be completed for any reason. Dependent Design To notify the orderer that their order can not be completed. To notify the system that the order was cancelled by the deliverer. DUC 9 Medium SR 21 Pre-conditions User is logged in. An order has been placed. The order has been accepted by the deliverer. The deliverer will not be able to deliver the food for some reason. Trigger The system will be notified that the transaction has been cancelled. The deliverer could not deliver the food for some reason. N/A 1. The user shall navigate to the Delivering tab and click the Your Current Deliveries button on the home page. 2. The frontend shall render the orders and a Details button next to each order. 3. The user shall click the Details button for the order. 4. The frontend shall render the order details page as described in OrderDetails.js that will display a button that reads Cancel Order. 5. The deliverer shall click the button. 6. The backend shall mark the order as Pending in its database. 7. The frontend shall now display the order, with its new status of Pending.

28 28 DESIGN USE CASE #15 - Rating a Deliverer The orderer will be able to rate their satisfaction level with the deliverer with a thumbs up or thumbs down, with an option of comments. Dependent Design Pre-conditions Trigger The orderer wants to rate their level of satisfaction with the orderer, whether positive or negative. The orderer shall be able to rate their level of satisfaction with the deliverer, whether positive or negative. DUC 13 (A and B) High SR 22 The user is logged in. An order was placed, the order was accepted, and the exchange of food and payment has taken place. The deliverer will have an updated rating attached to them from combining this rating and their previous ones. The orderer desires to leave feedback about their experience. 1. The user shall click navigate to the Ordering tab and click on the Your Order History button on the home page. 2. The frontend shall render the order history page as described in OrderHistory.js. 3. The orderer shall press the Food Received button. 4. The backend shall redirect the user to the Confirmation.js page. 5. The orderer shall give a thumbs up/down rating. 6. The backend system update the deliverer s rating. 7. The system shall return the orderer back to the home page. 1. The user shall not give a rating. 2. The system shall redirect the orderer back to the home page.

29 29 DESIGN USE CASE #16 - Rating an Orderer The deliverer will be able to rate their satisfaction level with the buyer Dependent Design Pre-conditions Trigger The deliverer will rate the buyer after having delivered and received payment for the food The deliverer wants to rate their level of satisfaction with the buyer DUC 13 (A and B) Low SR 23 The user is logged in. An order was placed, the order was accepted, and the exchange of food and payment has taken place. The deliverer has rated the food buyer The deliverer wants to rate their satisfaction with the buyer 1. The deliverer shall navigate to the Delivering tab and click on Your Delivery History button on the home page. 2. The frontend shall render the history page described by OrdersTaken.js. 3. The deliverer shall press the Money Received button. 4. The backend shall redirect the user to the Confirmation.js page. 5. The deliverer shall give the orderer a thumbs up/thumbs down rating, and then press the Confirm Transaction Complete button. 6. The backend shall update the orderer s new rating. 7. The frontend shall direct the deliverer back to the home page. 1. The user shall not give a rating. 2. The frontend shall return the orderer back to the home page.

30 30 DESIGN USE CASE #17- Deliverer provides pre-made status updates to orderer The system provides pre-made status updates to the orderer once the deliverer has completed milestones in the food delivery process (e.g. buying the food, picking it up, and arriving at the destination building) Dependent Design Pre-conditions The deliverer provides the orderer status updates. This use case provides the orderer with information regarding the status of their order without the deliverer having to type out the messages and send them. DUC 9 Medium SR 24 The deliverer is logged in. The deliverer has signed up as a deliverer. At least one orderer has placed an order. The system has added the order to the order queue. The deliverer has accepted an order off the queue. After the deliverer presses a button for each status update, the system should display the status update to the orderer. Trigger The deliverer should send status updates after completing each milestone in the delivery process. 1. The deliverer shall click the Delivering tab on the homepage, and then click the Your Current Deliveries button. 2. The frontend displays all orders that the deliverer has as described in OrdersTaken.js. 3. The deliverer shall click Details button for the order. 4. The frontend shall display pre-made status updates as described in OrderDetails.js. 5. The deliverer shall press each status update as they complete them in real-life. (e.g. press the Food Purchased button once they complete the transaction at the restaurant) 6. The frontend shall display the status updates to the orderer in make().

31 31 N/A

32 32 DESIGN USE CASE #18 - User Logout User logs out of the system Dependent Design Pre-conditions Trigger The user is successfully able to log out of the system. Allows the user to logout of the system and end his session so no one else can illegally access the user s account UC 2 Low SR 25 The user is already logged into the system. The system shows that the user is successfully logged out and has the option to return to the login page. The user is done using the application and wants to end his/her session on the program. N/A 1. The user shall press the Logout button to logout of their account. 2. The backend shall end the user s session on the program. 3. The backend shall successfully log the user out of the system using the logout button implemented in Apps.js. 4. The frontend shall redirect the user back to the login page.

33 33 DESIGN USE CASE #19 - User Settings The user will be able to update their account settings by changing their name, password, and/or payment preferences. The user will have their name, password, and/or payment preferences updated. The user wishes to update their name, password, and/or payment preferences. Dependent Design Pre-conditions Trigger DUC 2 Low SR User is logged in. The user s settings will be modified in the system. The user wishes to change their password or name for privacy concerns, or their payment preferences for convenience. 1. The user shall navigate to the Settings tab and click the User Settings button on the home page. Password: 2. The user shall enter their current and new passwords into the respective fields (new password twice for confirmation), then click the Update Password button. 3. The backend shall update the user s password in the user object under Users in the database in updateuser(). 4. The frontend shall display a notification saying Password changed to the user. Name: 2. The user shall enter their new name into the respective field then click the Update Name button. 3. The backend shall update the user s name in the user object under Users in the database in updateuser().

34 34 4. The frontend shall display a notification saying Name changed to the user. Payments: 2. The user shall select their preferred payment types and enter their Venmo username if they choose it, then click the Update Payments button. 3. The backend shall update the user s payment preferences in the user object under Users in the database in updateuser(). 4. The frontend shall display a notification saying Payment Preferences changed to the user. Incorrect Password: 2. The user shall incorrectly enter their current and new passwords into the respective fields (new password twice for confirmation), then click the Update Password button. 3. The backend shall fail to authenticate the password and reject the password change. 4. The frontend shall notify the user that the password was incorrect. No Venmo Username Provided: 2. The user shall select Venmo as a preferred payment type but omit their username, then click the Update Payments button. 3. The frontend shall notify the user that a Venmo username must be provided if the option is checked.