Task one

Identification of the system/ subsystem

Concerning the Uber Eats system, the three provided cases are typically subsystems of the larger Uber Eats system. Uber Eats integrates two systems whose main functionalities are to order fast food and deliver fast food. The customer makes an order in the system, the driver/ rider receives an order and gets it from restraint and delivers to the specified address as ordered by the customer. The major systems involved in this case include;

• Customer ordering management subsystem
• Driver management subsystem
• Restaurant management subsystem

Two most complicated use cases

In the above-described case, the most complicated use case scenarios are the ordering subsystem and the order dispatch from the restaurant. The ordering case is initiated from the customer while the order dispatch is initiated by the restaurant staff, likely one of the waiters delegated to deal with this type of order.

    Use case 1: Food Ordering

     Process

The food ordering process is initiated by the customer who is the external entity of the entire system. Before ordering any of the system’s services, the respective customer needs to have a user account with the system thus will be required to sign-in if already registered and if not, the customer will be prompted to create an account. In this process, the customer will provide his/their address and contact details which play a major role in the order delivery.

On successful account creation or sign in, the customer is presented with a dashboard through which he/ she can browse through to find the specific type of food he/ she wants. The customer is also presented with search functionality to filter the foods he/ she wants. On selection, the customer is prompted to enter the units (amount) of the order he she wants (Caetano, et.al, 2016), the address and contact details are pulled from the data store and the customer is asked to confirm if that is the current address and contact address or would want to change them.

After successful confirmation, the customer is presented with payment methods, the system does not accept payment on delivery thus all payments are made before delivery. There are various payment methods such as card payment (VISA, Mastercard), Internet payment (Skrill, PayPal), Mobile money (Send wave, MPesa).

A customer is then given a digital receipt in form of a text to the phone number he/ she registered with at the time of registration.

     Extended use case

The ordering use case extends confirmation of the order, in the confirmation use case, the order is pulled with all fed in details asking the user to either change or proceed with the details provided. This allows the customer to change the number of units or delivery locations.

     Activity diagram

Figure 1: Activity diagram order

     Sequence diagram

Figure 2: Sequence diagram

   Use case 2: Order Dispatch

      Process

The dispatch use case allows the restaurant staff (waiter) to dispatch the order from the restaurant. The restaurant has an inventory-like storage mechanism that holds the abstract data of the food available in the restaurant on a particular day. When an order is received, the staff dispatches it to the relevant customer via the driver/ rider available. The major activities in this use case confirm the receival of order, check if the requested order is still available, package the order, subtract it from the system, check for the available driver/ rider, pick one driver/ rider, forward the order to the driver/ rider and confirm the dispatch of the order to the customer.

      Extended use case

Dispatching order typically is the release of order (Kaur, et.al, 2016), this use case extends picking driver/ rider to deliver the order to the respective customer. In this use case, the restaurant staff goes through the available drivers/ riders and selects the closest one to whom he/ she forwards the order. The whole use case then shifts to the driver as the main actor in this scenario to deliver the order to the respective customer.

      Activity diagram

Figure 3: Activity diagram for order dispatch

      Sequence diagram

Figure 4: Dispatch sequence diagram

Screen prototype

The screen prototype (Löchtefeld, et.al, 2020), for the ordering subsystem, is well illustrated in the invasion link shown here: https://techg.invisionapp.com/console/share/AR1MYOC6P4

Figure 5

Figure 6: browse through

Figure 7: select order

Figure 8: Payment method

Figure 9: confirmation

 

Task two

 

Introduction

Fast food/ restaurant management systems are usually large and if closely examined, it would be established these systems have different subsystems in them. These subsystems work in collaboration to realize the ultimate goal of these systems. This report seeks to examine such a system in terms of its component subsystems (Lim, 2018), their operation, and the consolidation of these operations to realize one common goal of facilitating the ordering system.

System Subsystems

There are three major subsystems in the case system described, these are; customers’ ordering subsystem, driver delivery subsystem, and kitchen/ restraint dispatch subsystem. These three major subsystems make up the ordering, dispatching delivering functionalities of the system.

Ordering Subsystem

The whole ordering functionality and subsystem is on the customers’ side. In this subsystem, the customer registers accounts into the system and if their respective accounts already exist, the customer simply authenticates themselves into the system. On successful authentication, the customer browses through to find the specific food type they want. If found, the customer can proceed to order the respective type of food and if not, they can also choose to continue the ordering by changing preferences or sign-out of the system. In the ordering process, the customer is required to confirm or edit the delivery details.

Dispatching Subsystem

Once the customer has ordered for a given order, the respective restaurant receives the order, and the staff processes the order. The order processing involves the staff making the necessary deductions from the inventory. On completion, the restaurant staff forwards the order to the available driver/ rider. The forwarding process shifts the case to the driver who receives the delivery details as ordered by the customer.

Delivering Subsystem

The delivery subsystem is a simple case in which the driver/ rider confirms with the customer if the delivery details are correct. This is optional and the driver can simply choose to deliver using the provided details by the customer at the ordering stage.

Consolidation

From the description of each subsystem above, it is clear that the three work in collaboration with each other. A complete order goes through the three major activities of the system, ordering, dispatching, and delivering to the right customer. The consolidation of the three major functionalities would be as described herein (Liu, 2020). The whole process begins from the customer’ side, the customer authenticates themselves into the system, if the authentication is successful, the customer is presented with a dashboard menu displaying all the available food per given restaurant. The customer chooses the fast food vendor to see what food they offer. This functionality has been made available since there might arise cases in which a given restaurant may not have some specific type of food thus another option is given. If the customer finds his/their preference, he or she proceeds to make an order. In the ordering case, the customer specifies the units (amount) of the respective order and is asked to confirm or edit the delivery details. The respective vendor staff receives the order request and begins processing it. The processing of the order involves the staff packaging and forwarding the order to the available driver/ rider. The forwarded order displays the delivery details of the customer to the rider. As discussed earlier, the rider/ driver can choose to confirm with the customer if the delivery details are correct. The driver then delivers to the order to the respective customer. Taking the ordering subsystem case, the screen prototype is illustrated in the link herein: https://techg.invisionapp.com/console/share/AR1MYOC6P4.

Conclusion

With the complexity of systems, the developers have found efficient ways of simplifying the systems thus making it easy for them during the development process. This is achieved by breaking down big systems into subsystems that are commonly referred to as modules. The system in this project for instance has been broken down into three major subsystems with each appearing to be autonomous (Foran, et.al, 2019). These subsystems are later integrated to form one big system that realizes the ultimate goal as would have been stated in the project objectives. This modular approach not only does it simplifies the whole process of development but also makes it precise for the developers thus allows the development team to work in groups such that a group can be assigned a given subsystem to implement.

Reference List

Caetano, A., Silva, A. R., Tribolet, J., Neves, J., & Sinogas, P. (2016, June). The Modify Project: Combined Business and System Modeling for Adaptable Enterprise Computing System Design. In Atas da Conferência da Associação Portuguesa de Sistemas de Informação (Vol. 1, No. 1).

Foran, C. M., Rycroft, T., Keisler, J., Perkins, E. J., Linkov, I., & Garcia-Reyero, N. (2019). A modular approach for assembly of quantitative adverse outcome pathways. ALTEX-Alternatives to animal experimentation, 36(3), 353-362.

Kaur, H., & Sharma, A. (2016, March). A measure for modeling non-functional requirements using the extended use case. In 2016 3rd international conference on computing for sustainable global development (INDIACom) (pp. 1101-1105). IEEE.

Legowo, M. B., Indiarto, B., & Prayitno, D. (2019). Application of EKD-CM Method for Quality Assurance Information System Modeling. International Journal of Progressive Sciences and Technologies, 12(2), 173-180.

Liu, Y. (2020). U.S. Patent Application No. 16/725,358.

Lim, J. W. (2018). Fast food ordering system using the mobile application (Doctoral dissertation, UTAR).

Löchtefeld, M., Jensen, W., Häkkilä, J., Colley, A., & Müller, H. (2020, April). Prototyping Transparent and Flexible Electrochromic Displays. In Extended Abstracts of the 2020 CHI Conference on Human Factors in Computing Systems (pp. 1-4).

Xu, Y., & Szmerekovsky, J. (2017). System dynamic modeling of energy savings in the US food industry. Journal of Cleaner Production, 165, 13-26.