DeliverUS is a made-up company whose business is focused on delivering food from 3rd parties (restaurants) to customers. To this end, we are requested to develop the needed software products which hopefully will boost the company. After interviewing the product owners and some stakeholders, the general objectives and requirements have been agreed, as described in this document.
The software has to enable customers to order products to restaurants. To this end the following objectives have been identified
- Objective 1: Restaurants management
- Objective 2: Restaurants' products management
- Objective 3: Restaurants' order management
- Objective 4: Customers' order management
- Objective 5: Users management
DeliverUS expects two types of users: restaurant owners and customers. The following information should be stored: First name, last name, email, phone number, avatar image, address and postal code. For login and authentication purposes, a password, a token and a tokenExpiration date should also be stored.
Owners manage restaurants. The following information should be stored: name, description, address, postal code, url, email, phone number, logo, hero image (it will serve as restaurant background image), shipping costs (default for orders placed to this restaurant), average service time in minutes (which will be computed from the orders record), status. A restaurant status represent if it is accepting orders, currently unavailable, or temporarily/permanently closed. There are some predefined restaurant categories on the system, so the restaurant will belong to one restaurant category.
Products are sold by restaurants. Each product belongs to one restaurant. The following information should be stored: name, description, price, image, order and availability. The order is intended for sorting purposes that could be defined by the owner so the products are ordered according to his/her interests.
There are some predefined product categories on the system, so the product will belong to one product category.
Orders are placed by customers. Each order will include a set of products from one particular restaurant. Orders cannot include products from more than one restaurant. The following information should be stored: creation date (when the customer places the order), start date (when a restaurant accepts the order), sent date (when the order leaves the restaurant) and delivery date (when the customer receives the order), total price of the products included, the address where it has to be delivered, and the shipping costs. Thus, each order can be in one of the following states/statuses: 'pending', 'in process', 'sent', 'delivered'.
The system has to store the quantity of each product included in the order and the unitary price of each product at the moment of order placement.
From the information requirements and objectives described, the following class diagram is proposed:
- BR1: If an order total price is greater than 10€ the shipping costs will be 0€ (free shipping).
- BR2: An order can only include products from one restaurant
- BR3: Once an order is placed, it cannot be modified.
As a customer, the system has to provide the following functionalities:
Customers will be able to query all restaurants.
Customers will be able to query restaurants details and the products offered by them.
A customer can add several products, and several units of a product to a new order. Before confirming, customer can edit and remove products.
If an order is confirmed, it is created with the state pending. Shipping costs must follow BR1: Orders greater than 10€ don't have service fee. An order is automatically related to the customer who created it. If an order is dismissed, nothing is created.
A Customer will be able to check his/her confirmed orders, sorted from the most recent to the oldest.
A customer will be able to look his/her orders up. The system should provide all details of an order, including the ordered products and their prices.
Customers will be able to query top 3 products from all restaurants. Top products are the most popular ones, in other words the best sellers.
If the order is in the state 'pending', the customer can edit or remove the products included or remove the whole order. The delivery address can also be modified in the state 'pending'.
If the order is in the state 'sent' or 'delivered' no edition or removal is allowed.
As a restaurant owner, the system has to provide the following functionalities:
Restaurants are related to an owner, so owners can perform these operations to the restaurants owned by him. If an owner creates a Restaurant, it will be automatically related (owned) to him. If a restaurant is removed, all its products must be removed as well.
An owner can create, read, update and delete the products related to any of his owned Restaurants.
An owner will be able to inspect orders of any of the restaurants owned by him. The order should include products related.
An owner can change the state of an order. States can change from: pending to in process, from in process to sent, and finally from sent to delivered.
#yesterdayOrders, #pendingOrders, #todaysServedOrders, #invoicedToday (€)
The system has to provide users the possibility to be accessed and run through the most popular operating systems for mobile and desktop devices.
Backend should include basic measures to prevent general security holes to be exploited such as: sql injection, contentSecurityPolicy, crossOriginEmbedderPolicy, crossOriginOpenerPolicy, crossOriginResourcePolicy, dnsPrefetchControl, expectCt, frameguard, hidePoweredBy, helmet.hsts, ieNoOpen, noSniff, originAgentCluster, permittedCrossDomainPolicies, referrerPolicy, xssFilter.
For login and authentication purposes, a password, a token and a tokenExpiration (token authentication strategy) date should also be stored for users.
Note: This subject does not focus on security topics, but we will use libraries made by cybersecurity experts that will help us to include these measures. In Node.js ecosystem, Sequelize includes data sanitization and other measures to prevent SQL injection attacks and we will use the helmet package for the rest of potential security holes when publishing REST services.
The system should use a stack of technologies that could be deployed in more than one machine, horizontal scalability ready.
Once that requirements have been analyzed by our company's software architects, the following general architecture is proposed:
- Client-server architecture model.
- Front-end and backend independent developments.
- One front-end development for each type of user (Customer and Owners).
Moreover, these architects propose the following technological stack:
- Backend:
- Relational database, Mariadb server. It may be deployed on a machine other than where the rest of subsystems are deployed.
- DeliverUS backend application logic developed in Node.js application server that publishes functionalities as RESTful services helped by Express.js framework.
- Front-end:
- React-native based clients for both front-ends, deployable as Android, iOS or web Apps.
- DeliverUS-Owner App for the functionalities intended for restaurants' owners.
- DeliverUS-Customer App for the functionalities intended for customers.
Students will group together to develop the course project. The size and complexity of the project to be developed is intended for groups from 3 to 4 students.
During lab sessions, teachers will conduct and instruct students about the development of the backend and frontend of the DeliverUS App requirements related to owner functionalities. Specifically:
- Lab 1, 2 and 3: Backend required developments to support owner frontend app and some common functionalities.
- Lab 4, 5, 6, 7 and 8: Frontend app for owners.
Students will be provided with:
- A backend template that includes the implementation of labs 1, 2 and 3
- A frontend implementation of the DeliverUS app for owners.
- A frontend template for the DeliverUS app for customers.
Students are required to:
-
Complete the backend template provided to include the required functionalities for customers.
-
Complete the frontend template provided to develop the customer frontend App.
Implement the described functional requirements in the backend:
- FR3: Add, edit and remove products to a new order.
- FR5: Listing my confirmed orders.
- FR8: Edit/delete order.
Ensure that backend automatic tests pass.
Implement the described functional requirements in the
customerfrontend application:- FR1: Restaurants listing.
- FR7: Show top 3 products.
- FR2: Restaurants details and menu.
- FR5: Listing my confirmed orders.
- FR6: Show order details.
- FR3: Add, edit and remove products to a new order.
- Keep in mind FR4: Confirm or dismiss new order. You have to allow user to confirm or dismiss the order before sending it to the backend.
Implement the described functional requirements in the
customerfrontend application:- FR8: Edit/delete order