cafeteria ordering system srs

______________________________________________

Software Requirements Specification

For

CAFETERIA ORDERING SYSTEM

Prepared by

WHITE COLLAR CREW

1. RAM ANUDEEP KUCHIBHOTLA

2. NAGA RAVI TEJA MALLADI

3. DAAMAN BEHAL

Date: 05/19/2016

Contents1. INTRODUCTION.............................................................................................................................4

1.1. Purpose..............................................................................................................................41.2. Scope.................................................................................................................................41.3. Abbreviations....................................................................................................................41.4. References.........................................................................................................................41.5. Overview...........................................................................................................................5

2. OVERALL DESCRIPTION..............................................................................................................5

2.1. Product Perspective...........................................................................................................52.2. Product Features................................................................................................................52.3. User classes and Characteristics.......................................................................................62.4. Operating Environment.....................................................................................................62.5. Design and Implementation and Implementation Constraints..........................................62.6. User Documentation.........................................................................................................72.7. Assumptions and Dependencies.......................................................................................7

3. USECASE DIAGRAMS AND DESCRIPTIONS..........................................................................8

4. EXTERNAL INTERFACE REQUIREMENTS.............................................................................36

4.1. User Interfaces................................................................................................................364.2. Hardware interfaces........................................................................................................364.3. Software interfaces..........................................................................................................364.4. Communication interfaces..............................................................................................36

5. OTHER NONFUNCTIONAL REQUIREMENTS.........................................................................37

5.1. Performance Requirements.............................................................................................375.2. Safety Requirements.......................................................................................................375.3. Security Requirements....................................................................................................375.4 Software Quality Attributes............................................................................................38

6. OTHER REQUIREMENTS............................................................................................................39

7. DATA FLOW DIAGRAMS....................................................................................................................39

8. FUNCTIONAL REQUIREMNETS................................................................................................42

8.1. FR #1 – Login to the application....................................................................................428.2. FR #2 - Order Meal.........................................................................................................428.3. FR #3 - Processing Payment...........................................................................................428.4. FR #4 – Order meals from local restaurants...................................................................43

8.5. FR #5 – Tracking the order using GPS...........................................................................438.6. FR #6 – Make Reviews...................................................................................................438.7. FR #7 – Make custom menu...........................................................................................438.8. FR #8 – Create and updating menu.................................................................................448.9. FR #9 – Ordering custom meals.....................................................................................448.10. FR #10 – Creating Personal menu..................................................................................448.11. FR #11 – Making meal subscription...............................................................................458.12. FR #12 – Updating Delivery Man..................................................................................458.13. FR #13 – Providing COS access.....................................................................................458.14. FR #14 – New recipes using ingredients........................................................................458.15. FR #15 – Request for Delivery........................................................................................46

9. SEQUENCE DIAGRAMS......................................................................................................................46

9.1 Order meals from the cafeteria menu..................................................................................469.2 Order meals from local restaurants......................................................................................479.3 Create, view, modify, and delete meal service subscriptions..............................................479.4 Create, view, modify, and delete cafeteria menus.............................................................489.5 Produce recipes and ingredient lists for custom meals from cafeteria................................489.6 GPS track of the order.........................................................................................................499.7 system access through corporate Intranet, order meal and make payment.........................499.8 order custom menu and make payment.............................................................................509.9 Writing the review............................................................................................................50

10. CLASS DIAGRAMS.......................................................................................................................51

10.1. Initial Class Diagram...................................................................................................5110.2. Modified Class Diagram.............................................................................................5210.3. Detailed Class Diagram...............................................................................................53

1. INTRODUCTION

1.1. Purpose The objective of the COS project is to implement the design of the project mentioning the functional and nonfunctional requirements in addition to the functionality of the project. This SRS document will specify what features and requirements are included for the COS in this project

Intended audience The initial plan is to design and develop the document which will be helpful in designing

the project for cafeteria ordering system for the customers to be able to order meals from different restaurants and get it delivered.

1.2. ScopeThe Cafeteria Ordering System enables in ordering the desired food items online to be either picked up by the customer or to be delivered to customer. The chief aim of the COS is to make sure to maintain the service to the customer and providing him/her with features for more unique experience. The customers will have the option to choose from a wide range of menu, from multiple restaurants on the application and can also choose ingredients and items of their own choice. The application also provides the user to have his/her own account from which, they can have a personal menu saved and can change it whenever they need. The application will also allow the customer to view the delivered meal through live GPS tracking system in the application. The customer will also be provided with the feature of reviewing the COS and the delivered food.

1.3. Abbreviations COS- Cafeteria Ordering System

SRS- Software Requirements Specification

GUI-Graphical User Interface

GPS-Global Positioning System

1.4. References1. Wiegers, Karl. Process Impact Intranet Development Standard, Version 1.3, www.processimpact.com/corporate/standards/PI_intranet_dev_std.doc

2. UML diagrams from https://www.gliffy.com/uses/uml-software/

https://www.gliffy.com/uses/uml-software/

http://www.processimpact.com/corporate/standards/PI_intranet_dev_std.doc

1.5. OverviewThis document describes the features and functionalities of the project and indicating the constraints of the application. Through the SRS document, we can identify the requirements, design and document the COS application. The document has information about the scope of the project, overview of the project, product perspective, use case diagrams, external and internal functional requirements, nonfunctional requirements, functional requirements, sequence diagrams, data flow diagram and class diagrams, providing the user with the documentation of end to end features and functionalities of the project. The sole purpose of the documentation is to make sure that everything is noted and documented for future reference. The document has every feature and functionality listed, making it easier to understand it in future.

2. OVERALL DESCRIPTION

2.1. Product Perspective

The project is based on the COS through an application enabling the unique features allowing user to order meals from the main restaurant and even the other restaurants around him.

2.2. Product Features

The main features of the product are:

FE-1: Order meals from the cafeteria menu to be picked up or delivered

FE-2: Order meals from local restaurants to be delivered

FE-3: Create, view, modify, and delete meal service subscriptions

FE-4: Register for meal payment options

FE-5: Request meal delivery

FE-6: Create, view, modify, and delete cafeteria menus

FE-7: Order custom meals that aren’t on the cafeteria menu

FE-8: Produce recipes and ingredient lists for custom meals from cafeteria

FE-9: Provide system access through corporate Intranet or through outside Internet access by authorized employees

FE-10: Provide the user with a custom login and register page with a payment gateway

FE-11: Provide the user with a live GPS track of the order placed for delivery

FE-12: Provide the user with the feature of writing the review to improvise in the COS standards

FE-13: Provide the user with the feature of customizing his own menu in the COS account and storing it as order custom meal option.

2.3. User classes and Characteristics

UC-1: Customer: A customer is a customer who views the menu, selects desired food item, orders it, customizes his own meal and pay the bill. The customer will have to register in the COs, to enjoy the services and customize and order meals and for the payment options. The customer can give reviews to the restaurant.

UC-2: Manager: The cafeteria manager plays a vital role. He manages all the online meal requests and responds to them. He can edit items and prices in cafeteria menu. He can update daily menu and can add specials offers. He checks the payment receipts and maintains an account for all payment done.

UC-3: Delivery Man: After the customer places an order, the manager assigns the delivery task to the deliverer. He has to follow the delivery instructions and deliver the food in-time to the correct place and person. The delivery will be tracked and the GPS live tracker will help in locating the information of the delivery person.

UC-4: Bank: The bank is an important use case, as every transaction that is made from the customer through the COS, the bank has to approve the transaction and check if it is processed or not.

UC-5: Customer Reviewer: The customer reviewer is an important use case, which helps the user’s reviews to be reached to the manager. The reviews inputs and comments given by the user will be reviewed by the reviewer and takes it to the manager for better improvement of the service through COS.

2.4. Operating Environment

OE-1: This product shall run on any web browser with the latest update

OE-2: It is a mobile application which shall be running on multiple mobile operating systems.

2.5. Design and Implementation and Implementation Constraints

DI-1: The UX design including the customer and COS persona is created.

DI-2: The user interface shall be designed and the sitemaps are created.

DI-3: All the development is done based on the domain chose to create the application.

2.6. User Documentation

UD-1: The system/administration shall provide the users and managers with the formal documentation, including the usage of the application and the development process.

UD-2: The system shall provide the user (customer) with the privacy policy and the terms of use for proper usage of the application.

UD-3: The user will be provided the documentation for the implementation of the API’s in the future.

2.7. Assumptions and Dependencies

AS-1: The restaurant shall provide service from other restaurants linked to the COS.

AS-2: The customer is loyal and provides the COS with correct information and no fraudulent activities are performed.

DE-1: The system’s operation shall work on the user and the database does not crash during multiple entries of order data.

DE-2: The customer’s information is right and the payment gateways are passed with every transaction.

DE-3: The COS application is dependent on the customer and the bank’s payment gateway and transaction has to be approved.

3. USECASE DIAGRAMS AND DESCRIPTIONS

Fig 1: Overall description of the use cases

‘ Fig 2: Overall description of the use cases

Use Case ID: UC-1

Use Case Name:

USE ACCOUNT

Created By: White Collar Crew Last Updated By: White Collar Crew

Date Created: 03/10/2016 Last Revision Date:

04/16/2016

Actors: CUSTOMER(PRIMARY), MANAGER(SECONDARY)

Description: The customer will visit the application and login into the account to order meals

Trigger: The customer when opens the application.

Preconditions:1. Customer should have the application pre-installed on the device.

Post conditions:1. Customer successfully logs into cafeteria ordering system.

Normal Flow: 1.01. The user shall open the COS application.2. The user shall get an authentication from the COS system.3. The user shall successfully login.

Exceptions: 1.0.E.1 if the user enters invalid data.(at step 2)1. Authentication error.

Includes: Login page

Frequency of Use: High

Special Requirements: Application server should always be available.

Assumptions: None

Notes and Issues: None

UC 1: use case diagram for login account

Use Case ID: UC-2

Use Case Name:

ORDER MEAL



04/16/2016

Actors: Customer(primary actor), Manager(primary), Bank(secondary), Delivery boy(secondary)

Description: The customer orders the meal from the menu and the system provides the option of the order to be delivered or picked up by the customer

Trigger: The customer views the menu and chooses the items.

Preconditions: 1. Successful login.2. The menu has to be successfully opened

Post conditions: 1. Order is accepted and COS is updated.2. Successful authentication by bank.3. If requested, Information is send to delivery boy.

Normal Flow: 2.01. The user shall login successfully.2. The user shall view the menu.3. The user shall order the meal.4. The user shall choose pickup or delivery option.5. The user shall get payment confirmation.

Alternative Flows: None.

Exceptions: 2.E.0.11. Transaction failure in server point of view.2. Non-availability of item.

Includes: Views the menu.

Frequency of Use: Low to medium.

Special Requirements: None

Assumptions: None

Notes and Issues: The ordered meal should be available in the restaurant’s menu.

UC 2: use case diagram for order meal.

Use Case ID: UC-3

Use Case Name:

Order Meal from local restaurant



04/16/2016

Actors: Customer(primary), manager(primary), Deliveryman(secondary)

Description: The customer orders the meal from the menu of a local restaurant present in the COS and the system provides the option of the order to be delivered or picked up by the customer.

Trigger:The customer views and orders from other restaurant.

Preconditions: 1. Successful login.2. Access to that particular restaurant.

Post conditions:1. Order has to be placed to the local restaurant1.2. Authentication3. Information sent to the delivery boy.

Normal Flow: 3.01. The Customer shall login successfully.2. The user shall choose the restaurant from which he wants the

delivery.3. The user shall view the restaurant’s menu.4. The user shall get the payment confirmation.5. The information regarding the user’s delivery shall be given to the

delivery boy.

Alternative Flows: NONE

Exceptions: 3.0.E.1 Not listed in the database of restaurants1. Restaurant is unavailable in the list.2. Transaction error from server point of view.3. Non-availability of item.

Includes: Menu of other restaurants.


Special Requirements: View order history.

Assumptions:None

Notes and Issues: The restaurant should be available in the COS system in order to request for delivery of order.

UC 3: use case diagram for ordering meal from a local restaurant

Use Case ID: UC-4

Use Case Name:

Subscribing Meal



04/16/2016

Actors: Customer(primary), manager(secondary)

Description: The customer will get the option to create, modify, delete and view his subscribed meal.

Trigger: The customers when requests for subscription meal.

Preconditions:1. Customer shall need to login to his account.2. The user shall request for a subscription meal.

Post conditions: The users request for subscription is accepted.

Normal Flow: 4.01. The user needs to login to his account.2. The user shall request for a meal subscription.3. The user shall create his own meal subscription4. The user shall view his meal subscription.5. The user shall modify his meal Subscription.6. The user shall delete his meal subscription.

Exceptions: 4.0. E.1 In step 2 of the normal flow, if the meal subscription is disallowed.1. Subscription meal request is not approved.

Includes: Create, view, modify, and delete subscription meal.

Frequency of Use: Once a month.


Assumptions: 20-30 customers might request for subscription meal.


UC 4: use case diagram for subscription meal.

Use Case ID: UC-5

Use Case Name:

PAY FOR MEAL



04/16/2016

Actors: Customer(primary), manager(primary), Bank(primary)

Description: The customer after ordering the meal will be provided with an option of payment and bank will authenticate the customer account.

Trigger: The customers tires to pay for the order.

Preconditions: The manager shall know the order of the customer.

Post conditions: The payment of customers order is received.

Normal Flow: 5.01. The customer’s should order for an item.2. The ordered item should be processed by the manager.3. The customer should then pay for the order.4. The bank authenticates the payment made by the customer.5. The customer gets the payment confirmation.

Alternative Flows:5.1 If the customer wants to pay for meal (at step 2)1. The user orders his personal menu.2. The user pays for the meal at the counter if he does not choose the

delivery option.3. Use Case resumes on step 5.

Exceptions: 5.0. E.1 In step 2 of the normal flow, if the customer ordered item is unavailable.

1. The customer order is unsuccessful.5.0.E.2If the customer does not have sufficient funds in his bank account.(at step4)

1. The system informs and cancels the order of the customer.

Includes: Choose payment option.


Special Requirements: View order history.

Assumptions: 20% of customers choose debit card as payment option.


UC 5: use case diagram for payment for meal.

Use Case ID: UC-6

Use Case Name:

Request for delivery



04/16/2016

Actors: Customer(primary), Manager(primary), delivery man(secondary)

Description: The customer requests the COS to deliver the meal to a specific location.

Trigger: The customer requests for delivery of order.

Preconditions: The customer should have completed payment for the order.

Post conditions: The customer will be delivered the order by the delivery man.

Normal Flow: 6.01. The customer should login to his account.2. The customer views the menu and orders.3. The customer then pays for the ordered items and requests for

delivery.4. The manger informs the delivery man regarding the deliverable.5. The delivery man delivers the deliverable to the customer.

Alternative Flows:None.

Exceptions: 6.0. E.1 In step 3 of the normal flow, if the order request is not issued.

1. The delivery of the customer’s order is unsuccessful.

Includes: Request for delivery option.

Frequency of Use: 100 per day.


Assumptions:More than half of the customers might choose delivery option.


UC 6: use case diagram for request for delivery.

Use Case ID: UC-7

Use Case Name:

Create and updating menu



04/16/2016

Actors: Manager(primary), Customer(secondary)

Description: The Manager will get the option to create, view, modify or delete the COS menu. The customer will get the option to view the COS menu.

Trigger: The manager tries to create and update cafeteria menu.

Preconditions: The managers needs to create the menu of the COS.

Post conditions: The customer can view the COS menu.

Normal Flow: 7.01. The manager should create the COS menu.2. The manager should modify the COS menu.3. The manager should be able the delete the COS menu.4. The customer can view the COS menu.

Includes: Change menu option.

Frequency of Use: Once a week.


Assumptions: Manager might change the menu for every two weeks.

Notes and Issues: The manager has the authorization to change the COS menu.

UC 7: use case diagram for creating and updating menu.

Use Case ID: UC-8

Use Case Name:

Order Custom meals



04/16/2016

Actors: Customer(primary), Manager(primary)

Description: The customer can order a custom meal from the COS.

Trigger: The customer when chooses the custom meal option.

Preconditions: The Customer logins into the system.The customer views the menu.

Post conditions: The Custom meal was accepted.

Normal Flow: 8.01. The customer logins into COS.

2. After viewing the menu, if the customer is unsatisfied and might want to customize the meal.

3. The customer will order the custom meal.

4. The manager of the COS will accept the order.

5. The order is processed and the customers pay for the order.

Alternative Flows: 8.1 If the customer wants his custom menu.1. The customer chooses his custom menu from his personal

account.2. Use Case resumes on step 4.

Exceptions: 8.0. E.1 In step 4of the normal flow, the requested item may not be available in the COS.

1. The customer logs out of COS.

Includes: Order custom meal.

Frequency of Use: Once in ten days.


Assumptions: About 10% customers might choose custom meal option.


UC 8: use case diagram for ordering custom meals.

Use Case ID: UC-9

Use Case Name:

Producing new recipes using ingredients



04/16/2016


Description: The customer has the option to provide new recipes and with ingredients available with the Cafeteria.

Trigger: The customer on choosing the recipes and ingredients option.

Preconditions: The Customer logins into the system.The customer provides the custom recipes.

Post conditions: The customer successfully logs into the system.The custom recipes and ingredients provided are processed by the COS.

Normal Flow: 9.01. The user logins into the system.2. The user then views the menu.3. The user provides custom recipes and ingredients.4. The manager processes the information provided by the customer.5. The manager will check with the ingredients present in the cafeteria.6. The customer orders meal.7. The payment is made by the customer.8. The customer gets the payment confirmation.

Alternative Flows: None

Exceptions: 9.0.E.1 In step 4of the normal flow, if the customer information is not processed

1. The customer recipes and ingredients are not accepted by the manager.

Includes: Recipes and ingredients option.

Frequency of Use: Once in two weeks.


Assumptions: 30% of the customers might add recipes.

Notes and Issues: The customer can add one recipe per month.

UC 9: use case diagram for producing new recipes using ingredients.

Use Case ID: UC-10

Use Case Name:

Providing access



04/16/2016


Description: The COS application checks if the user ordering the meal is authorized or not, and if not the COS does not allow the user to continue the transaction

Trigger: The user when

Preconditions: The customer tries to use the COS services through corporate intra-network

Post conditions: The customer successfully uses the COS services.

Normal Flow: 10.01. The user tries to login and use COS services through corporate

intra-network.2. The user gets authenticated by the manager to use the Cos features.3. The customer requests for order from COS.4. The manager accepts the order of the customer.5. Payment for the order is done by the customer and the customer gets

the payment confirmation.


Exceptions: 10.0.E.1 In step 1of the normal flow, if the customer login information is not valid

1. The customer cannot login due to incorrect login information.

Includes: None

Frequency of Use: 50 per hour.


Assumptions: None


UC 10: use case diagram for providing access.

Use Case ID: UC-11

Use Case Name:

Track delivery with GPS



04/16/2016

Actors: Customer(secondary), Manager(primary), Delivery man(secondary)

Description: The user can check the order being delivered with the live track of the order through the GPS enabled service

Trigger: The user on choosing the track delivery option.

Preconditions: The customer orders an item from COS.

Post conditions: The customer successfully tracks the deliverable with GPS.

Normal Flow: 11.01. The manager processes the customers’ orders and completes it.2. The manager then informs the delivery man giving him the

customer information.

3. The deliveryman then starts for delivery of the deliverable.4. The customer can track the deliverable.5. Once the deliverable is delivered, then the delivery process is

complete.


Exceptions: 11.0.E.1 In step 1of the normal flow, if the customer login information is not valid

1. The customer cannot login due to incorrect login information.

Includes: Tracking delivery option.



Assumptions: Over 70% of the user who choose delivery option might use this.

Notes and Issues: The customer should a GPS enable phone in order to track delivery.

UC 11: use case diagram for tracking delivery with GPS.

Use Case ID: UC-12

Use Case Name:

Reviewing cafeteria



04/16/2016

Actors: Customer(primary), Customer reviewer(primary)

Description: After successful completion of the order delivery the customer will have the feature of reviewing the order and give inputs that will be delivered to the customer reviewer , which will help improve the service of the restaurant

Trigger: The user chooses the write review option.

Preconditions: The customer writes a review about the COS system.

Post conditions: The customer Reviewer receives the customers review.

Normal Flow: 12.01. The customer gets the deliverable from the COS.2. The customer then writes a review about the COS system.3. The customer reviewer then reviews the Customers review.4. The Customers review is assessed by the Customer reviewer and

takes an appropriate action.

Alternative Flows:None

Includes: Write review option.



Assumptions:Almost all the customers might write reviews about restaurants.

Notes and Issues: The restaurant must be present in the COS.

UC 12: use case diagram for reviewing cafeteria.

Use Case ID: UC-13

Use Case Name:

Creating Personal menu



04/16/2016

Actors: Customer(primary), Manager(secondary)

Description: After logging in the application, the user can create his own custom meal and can order it every time he needs a custom meal

Trigger: The user chooses the custom menu option in his personal account.

Preconditions: The customer should have a COS account.

Post conditions: The customer can apply for a personal menu.

Normal Flow: 13.01. The customer logins into his account.2. The customer chooses the personal account.3. The personal preferred menu is added by the customer in his

personal account.4. This personally preferred menu is viewed by the manager.5. The customer’s regular order is in his personal account.6. This menu is processed and the customer gets a confirmation.


Includes: Custom menu option.



Assumptions:50% of the users might use this option.


UC 13: use case diagram for creating persona menu

Use Case ID: UC-14

Use Case Name:

Processing payment



04/16/2016

Actors: Manager (secondary), Bank(primary)

Description: The customer’s payment option will be processed by the manager with the bank regarding the payment information

Trigger: The manager after accepting the order and processes order.

Preconditions: The customer pays for the order.

Post conditions: The Bank authenticates the payment and gives confirmation to the manager.

Normal Flow: 14.01. After ordering the meal, the COS will ask the customer to pay.2. The customer will make payment.3. The COS will ask the bank to process the payment.4. The bank will authenticate the user account.5. The bank will send the confirmation regarding the payment to the

manager.


Exceptions 14.0.E.11a. In step 2 of the normal flow, the customer might enter incorrect card details.

1. The customer will be asked to re-enter the details.14.0.E.22a. In step 4 of the normal flow, due to insufficient amount the bank may not authenticate the customer account.

1. The customer’s payment process will be at halt.

Includes: None



Assumptions:None


UC 14: use case diagram for processing payment

Use Case ID: UC-15

Use Case Name:

Updating Delivery man



04/16/2016

Actors: Manager(primary), Delivery man(secondary)

Description: The customer’s order will be updated by the manager to the delivery man for the delivery and can be reviewed by the manager and the customer through live GPS tracking enabled

Trigger: The manager updates the delivery details to the delivery man.

Preconditions: The Customer’s confirmed order has to be delivered.

Post conditions: The customer’s order is delivered by the delivery-man

Normal Flow: 15.01. The customer gets the order confirmation from COS and request for

delivery.2. The manager accepts the delivery option opted by the customer.3. The manager gives the information regarding the delivery to the

delivery-man.4. The delivery-man delivers the deliverable to the customer.5. The customer gets the deliverable.

Alternative Flows: None.

Exceptions 15.0.E.11a. In step 2 of the normal flow, the customer might enter incorrect card details.

2. The customer will be asked to re-enter the details.15.0.E.22a. In step 4 of the normal flow, due to insufficient amount the bank may not authenticate the customer account.

2. The customer’s payment process will be at halt.

Includes: Order Delivery details.



Assumptions: None

Notes and Issues: The Deliveryman should be given the delivery details.

UC 15: use case diagram for updating delivery man.

4. EXTERNAL INTERFACE REQUIREMENTS

4.1. User Interfaces

UI-1: - The COS application has to be easily accessible by all the users under different platformsUI-2: - The users can access the application, and based on the user experiences, the interface is built with the visualized mannerUI-3: - The GUI system is very friendly and the GPS live tracker has to be properly embedded into the applicationUI-4: - The application provides the user with the ease of writing reviews and interacting with the customer service easily.

4.2. Hardware interfaces

HI-1: - Bill generators are directly connected to the credit/debit card machines, and they are connected to the banking application directly.

HI-2: - The delivery person has the GPS tracker installed and the hardware has to be constantly updated and foreseen by the admin.

4.3. Software interfaces

SI-1: - The COS is developed using the mobile application interface.

4.4. Communication interfaces

CI-1: - The COS can be used for ordering meals using the application or the direct phone call service to place the order.CI-2: - The COS will send the confirmation message on the successful completion of order and receipts generated to the user through an email.

CI-3: - The COS will communicate with the user and provides the user with a continuous tracking of the GPS.

5. OTHER NONFUNCTIONAL REQUIREMENTS

5.1. Performance Requirements

The performance requirements will specify the performance of the application and type of features it can take to run the application successfully. Below listed are some of the performance requirements.

PE-1: On the successful completion of the transaction from the user, the details of the transaction have to be stored in the database for six months and can be retrieved when needed in less than 3 seconds.

PE-2: The COS application runs without interruptions if the software is updated to date, with no inconsistency in the total run of the application and has to be bug free.

PE-3: Processing of the order should not take more than five seconds after the user confirmation. Confirmation email is to be sent to the user and the admin for final confirmation.

PE-4: Multiple registrations should be accepted by the COS application and database cannot close unexpectedly due to loss of internet, and even when it closes unexpectedly the information should be stored.

PE-5: The accessibility of the system is tracked by the user using the GPS system for the order delivery and the delivery time should not exceed 30 minutes.

5.2. Safety Requirements

SR-1: The authentication of the user is important and hence, the user will have to provide personal information about email, phone number and card details to get registered with the application

SR-2: All transactions made to the COS are constantly monitored and stored in the database for six months before getting deleted for references.

5.3. Security Requirements

SER-1: Only the registered users shall be allowed to order items from the COS application

SER-2: Admin shall have the flexibility to change the passwords of the main account and maintain records.

SER-3: When using debit/credit card transactions, identification of the user is important and the contact details should be specified by the user

SER-4: Manager/ Admin shall have the right to change or modify menu in the application and will interact with the various restaurant people and manage orders.

SER-5: Manager shall be the point of contact for the customer reviews and inventory management and will receive information about changes in order or reviews

SER-6: On unsuccessful entry of pin for more than two times, the system (admin) shall cancel the transaction of the user

SER-7: Every change in the order or delivery shall be updated to the manager by the delivery man

SER-8: The location of the delivery man shall be tracked by the GPS and is constantly monitored by the admin

5.4 Software Quality Attributes

Availability: The COS application should be available to all the users with the application installed on their smart phones and the application should be available on android and iOS.

Robustness: The application is robust in nature and the downtime should be very minimal and the application should be accessed by the user almost all the time.

Accessibility: The application can be accessed easily by the users and the restaurants from which the order is placed should be available in the menu

Deliverable: The order that the customer places needs to be delivered at the right time and constant monitoring of the order is done through the GPS tracker.

Adaptability: The COS application can adapt the new inputs such as custom meals, new meal and recipe orders from the customer and will be implemented in the application and will adapt to the various operating systems and environments.

Interoperability: The system/Admin makes sure that the information received from the customer regarding the order is genuine and will be stored in the database. Information regarding the phone number, email addresses and card details will be checked.

6. OTHER REQUIREMENTS

6.1. OPERATION-1: The cafeteria ordering system constantly will try to provide constant service to the customer in the hours of operation and develops the business with new business tie ups with restaurants.

6.2. OPERATION-2: The cafeteria ordering system will be updated with new build for every three weeks and the database information has to store to different storage service

7. DATA FLOW DIAGRAMS

DFD 1: level 0

DFD 2: Level 1

DFD 4: Level 2

DFD 5: Level 2

DFD 6: Level 2

8. FUNCTIONAL REQUIREMNETS

8.1. FR #1 – Login to the application8.1.1 Introduction: The customer has to login to the COS application to order meals.8.1.2. Inputs: The customer has to provide information about him, contact details and card information for payment of ordered meals.8.1.3 Processing: After the successful login and registration, the customer will have the option to view the menu and order meals, and pay for the ordered meals after the order, meal is delivered. 8.1.4 Outputs: The COS application will provide a user with a notification of successful login into the account.8.1.5 Error Handling: 8.1.5. E1: If the given username, password does not match, the system generates a message in the COS to the customer that the credentials do not match and login again8.1.5. E2: If the password does not match, the COS application has an option to update information and change password when forgot.

8.2. FR #2 - Order Meal8.2.1 Introduction: The customer will select an item from the list of items available on the COS page8.2.2 Inputs: The customer will need to have to select a meal8.2.3 Processing: The customer will choose a meal from the COS and order a meal. The ordered meal is processed by the manager through COS and order is placed. On the successful completion of the order placement, the customer has to choose a payment option and pay. The meal is now ordered 8.2.4 Outputs: The system will alert the manager of the order, and the order is prepared8.2.5 Error Handling: 8.2.5. E1: If there is an error during the payment, the system shall notify the customer that there is a problem8.1.5. E2: If the meal ordered is not available in the COS, the customer shall be notified of it before the confirmation.

8.3. FR #3 - Processing Payment8.3.1 Introduction: The customer has to select a meal, and then move to the payment options8.3.2. Inputs: The customer has to provide the COS with the details of the debit/credit card for the payment8.3.3 Processing: Once the card details are entered, the COS application will process it, and the manager will check with the bank, about the transaction. Once there is a clearance from bank, the payment received message will go to the customer. 8.3.4 Outputs: The COS application will generate a message to the customer about the order confirmation8.3.5 Error Handling: 8.3.5. E1: If the debit/credit card information is not taken by the COS application, the customer has to provide additional information and can pay while during the pickup

8.4. FR #4 – Order meals from local restaurants8.4.1 Introduction: The customer can order meals through COS from local restaurants.8.4.2 Inputs: The COS application should have the menu from local restaurants and the customer has to choose the menu he/she wants. 8.4.3 Processing: After the meal is placed, the COS application checks if the meal ordered is available and if yes, confirmation is sent to the customer and the manager and the order is placed8.4.4 Outputs: The meal ordered from local restaurant is placed and is delivered or waited for pickup. 8.4.5 Error Handling:8.4.5.1 E1: The meal ordered by the customer from local restaurant may not be available8.4.5.1 E2: The payment options chose by the customer may not be suitable for the transaction to be complete.

8.5. FR #5 – Tracking the order using GPS8.5.1 Introduction: The customer has an additional option in the COS application to track his delivery via live GPS tracker

8.5.2. Inputs: The customer will order the meal and the live GPS tracker on the COS application, will allow the customer to view his delivery. 8.5.3 Processing: Once the order is placed, and ready for delivery the customer will receive a notification about the delivery and can choose the option to track the delivery. The GPS live tracker will allow the customer to view the status of the delivery until delivered to the customer. 8.5.4 Outputs: The customer can view the delivery of the order through the live GPS in the COS application8.5.5 Error Handling:8.5.5. E1: If the location services of the mobile phone of the delivery man are turned off, the live GPS might not be tracked8.5.5 E2: If there are many orders that are to be delivered, then the GPS tracker may show the customer about the delivery but might actually take longer to deliver

8.6. FR #6 – Make Reviews8.6.1 Introduction: After the meal is delivered, the customer can write reviews about the meal on the COS application 8.6.2. Inputs: The customer has an option to review the meal after the delivery8.6.3 Processing: Once the customer receives the delivery of the meal, the COS application has an option to review the meal. The review will be generated to the manager for improvement in the future 8.6.4 Outputs: The reviews given by the customer will be stored in the COS application under the customer’s account and will be generated to the manager for improvement in the future.8.6.5 Error Handling:8.6.5. E1: If the customer provides a review, due to some technical difficulties it might not be saved in the COS application

8.7. FR #7 – Make custom menu8.7.1 Introduction: The customer has an additional feature in the COS application to make custom menu8.7.2. Inputs: the customer will have the option to add his custom meal to the menu, in his account in the COS application8.7.3 Processing: Once the customer orders for a custom meal option in his account through the COS application, the custom meal order is processed and made ready to delivery or pickup for the customer8.7.4 Outputs: The custom meal ordered is made ready and available to the customer for delivery or pickup8.7.5 Error Handling:8.7.5. E1: The custom meal ordered by the customer, may not be available in the store.

8.8. FR #8 – Create and updating menu8.8.1 Introduction: The COS application has an option to create and update new menu and modify menu’s8.8.2. Inputs: The manager has an option to create and update new menus and existing menu using the COS application 8.8.3 Processing: Once the COS application is opened and the manager has the feature to update the existing menu and can update it in the application. 8.8.4 Outputs: After the menu is updated the user can view the new modified menu in the application.8.8.5 Error Handling:

8.8.5. E1: If the menu is updated and not saved, the updated menu will not be displayed in the application and will provide the user with the information that update is not successful and has to re update the details

8.9. FR #9 – Ordering custom meals8.9.1 Introduction: The customer has an option to order custom meals using the COS application 8.9.2. Inputs: The customer can order and update custom meals in the COS application using his login details. He/she can update and review the new custom meals in the application 8.9.3 Processing: Once the customer needs to order a custom meal, he can choose the option of custom meals where the customer can provide information on the custom meal and order it online in the application. 8.9.4 Outputs: The customer can view the ordered custom meals and wait for ordering the meals8.9.5 Error Handling:8.9.5. E1: While entering the details of the custom menu, the new meals cannot be updated due to problems and while encountering this problem, message is displayed to the customer

8.10.FR #10 – Creating Personal menu8.10.1 Introduction: The customer can create their own personal menu in the application8.10.2. Inputs: The customer can create his own personal menu by selecting the items and ingredients 8.10.3 Processing: After the customer provides the custom personal menu by selecting the ingredients and items, the order is processed and the end order is delivered to the customer by delivery/ pickup option. 8.10.4 Outputs: The COS application will provide the user with the notification after the order is ready8.10.5 Error Handling:8.10.5. E1: If the ordered ingredients and items are not available in the restaurant, the COS application will notify the user of the non-available ingredients and provides an option to choose from other available ingredients.

8.11. FR #11 – Making meal subscription8.11.1 Introduction: The customer can provide meal subscriptions in the application8.11.2. Inputs: The customer can subscribe for meals for a particular month by paying the required amount and selecting the option of meal subscription8.11.3 Processing: After the successful login, the customer will have an option of meal subscriptions for one particular month in the COS application, and upon payment for the subscription the meal subscription plan is implemented for the user. 8.11.4 Outputs: After successfully choosing meal subscription and payment options, the customer receives a notification stating completion of subscription plan8.11.5 Error Handling: 8.11.5. E1: If there is a payment problem during subscription for the meals, error notification is displayed to the customer in the COS application 8.11.5. E2: If the customer wants to withdraw the meal subscription plan, the money will be deposited into the customer’s bank account directly for the non-used days of the meal plan subscription

8.12. FR #12 – Updating Delivery Man8.12.1 Introduction: The manager can update the delivery man about the orders to be delivered and notify him8.12.2. Inputs: The manager will notify the delivery man about the delivery orders with the addresses and customers information 8.12.3 Processing: The order is processed and updated to the delivery man about the order8.12.4 Outputs: The manager informs the delivery man about the order and the order is out for delivery by the delivery man and the delivery will start8.12.5 Error Handling:8.12.5. E1: If there is a difference in the address mentioned and address available, the delivery man will be updated by the customer8.12.5. E2: If there is a disturbance in the delivery, the customer should be notified about the delay in delivery

8.13. FR #13 – Providing COS access8.13.1 Introduction: The customer can access the portal of the cos, within intranet or internet areas and can access it8.13.2. Inputs: The customer can access the COS, within the intranet or internet access and can order the meals8.13.3 Processing: After the successful login, the customer can access the cos from intranet or internet and can order the meals8.13.4 Outputs: The access is granted, and the customer can order meals from the application8.13.5 Error Handling:8.13.5. E1: If the customer’s internet or intranet connection is not secured or is interrupted, the order cannot be completed and the information will be stored in the user’s database and can be retrieved when the internet/intranet connection is restored.

8.14. FR #14 – New recipes using ingredients8.14.1 Introduction: The customer can provide his own custom ingredients and new recipe methods for customizable meal8.14.2. Inputs: The customer can provide his own list of ingredients and recipe options to the cafeteria to process the order8.14.3 Processing: If the given set of ingredients are available in the cafeteria the order is processed 8.14.4 Outputs: After the successful completion of the order, the order is given to the customer and feedback is taken8.14.5 Error Handling: 8.14.5. E1: If the requested ingredients are not available with the COS, the order cannot be completed and the user shall be notified with the issue8.14.5. E2: If the customer wants to add additional ingredients to an already existing order, he shall be notified of the extra cost in the total order

8.15.FR #15 – Request for Delivery8.15.1 Introduction: The customer can access the feature of requesting for the delivery of the meal8.15.2. Inputs: The customer can choose for the option of delivery when processing his order and click on delivery8.15.3 Processing: After the successful completion of the order, the customer shall be notified of the order details and the time of delivery

8.15.4 Outputs: After the successful completion of the order, the user’s meal will be delivered to the user after the order is prepared8.15.5 Error Handling:8.15.5. E1: If the order places, is not in the location of the delivery, the notification will be sent to the user about the failure in the delivery

9. SEQUENCE DIAGRAMS

9.1 Order meals from the cafeteria menu

SED: 1 Order meals from the cafeteria menu

9.2 Order meals from local restaurants

SED: 2 Order meals from local restaurants

9.3 Create, view, modify, and delete meal service subscriptions

SED: 3 Create, view, modify, and delete meal service subscriptions

9.4 Create, view, modify, and delete cafeteria menus

SED: 4 Create, view, modify, and delete cafeteria menus.

9.5 Produce recipes and ingredient lists for custom meals from cafeteria

SED: 5 Produce recipes and ingredient lists for custom meals from cafeteria

9.6 GPS track of the order

SED: 6 GPS track of the order

9.7 system access through corporate Intranet, order meal and make payment

SED: 7 system access through corporate Intranet, order meal and make payment

9.8 order custom menu and make payment

SED: 8 order custom menu and make payment

9.9 Writing the review

SED: 9 writing the review.

10. CLASS DIAGRAMS

10.1. Initial Class Diagram

CD 1: Initial class diagram

10.2. Modified Class Diagram

CD 2: Modified class diagram

10.3. Detailed Class Diagram

CD 3: Detailed class diagram

cafeteria ordering system srs

Documents