CANTEEN MANAGEMENT SYSTEM

Submitted in partial fulfillment of the requirements

of the course

Software Design Lab (ITL601)

In

T. E. Information Technology

By

RUCHI DHOLARIA 171269

RHEA D’SOUZA 161030
RUSHIA FERNANDES 161033

Supervisor:

Ms. Shree Jaswal

Assistant Professor

Department of Information Technology

St. Francis Institute of Technology
(Engineering College)

University of Mumbai
2018-2019
 CERTIFICATE
This is to certify that the project entitled “Canteen Management System” is a
Bonafede work of Ruchi Dholaria (20), Rhea D’souza (23) and Rushia
Fernandes (27) submitted in partial fulfillment of the requirements of the course
Software Design Lab (ITL601)

(Name and sign) (Name and sign)

Supervisor/Guide Head of Department

i
 SDL Mini Project Report Approval for T.E.

This project report entitled Canteen Management System by Ruchi Dholaria,

Rhea D’souza and Rushia Fernandes is approved for the partial fulfillment of
the requirements of the course Software Design Lab (ITL601)

Examiners

1.---------------------------------------------

2.---------------------------------------------

Date:

Place:

ii
 Abstract
The purpose of the Canteen Management System is to automate the existing manual system by
the help of computerized equipment and full-fledged computer software, fulling their
requirements, so that their valuable data can be stored for a longer period with easy accessing
and manipulation of the same. The required software and hardware are easily available and
easy to work with.

Canteen Management System, as described above, can lead to error free, secure, reliable and
fast management system. It can assist the user to concentrate on their other activities rather to
concentrate on the record keeping. Thus, it will help organization in better utilization of
resources. The organization can maintain computerized records without redundant entries. Hat
means that one need not be distracted by information that is not relevant, while being able to
reach the information.

iii
 Contents

Chapter Contents Page No.

1 INTRODUCTION
2 SRS in IEEE format
3 SYSTEM ANALYSIS
3.1 Use-Case Diagrams and description
3.2 Class diagram
4 ANALYSIS MODELING
4.1 Activity Diagram
4.2 Sequence Diagram
4.3 TimeLine Chart and Work Breakdown Structure
5 DESIGN
5.1 Architectural Design
5.2 User Interface Design
5.3 Type of Testing used
5.4 Test cases
6 CONCLUSION

iv
 List of Figures

Fig. No. Figure Caption Page No.

2.2.2.1 Level 0 DFD

2.2.2.2 Level 1 DFD
2.3.3.1.1 Use Case
3.1.1 Use Case Diagram
3.2.1 Class Diagram
4.1.1 Activity Diagram
4.2 Sequence Diagram for Ordering
4.3.1 Timeline Chart
4.3.2 Work Breakdown Structure
5.1.1 Architectural Design
5.2.1 Home Page
5.2.2 Registration Page
5.2.3 Login Page
5.2.4 Order Page
5.2.5 Chef’s Portal
5.2.6 Feedback + Logout Page
5.4.1 Test Case for Registration
5.4.2 Test Case for Login
5.4.3 Test Case for Ordering
5.4.4 Test Case for Chef’s Portal
5.4.5 Test Case for FeedBack

v
 List of Tables

Table No. Table Title Page No.

2.3.2.1 Functional Requirements

3.1.1 Description for ‘Registration’
3.1.2 Description for ‘Login’
3.1.3 Description for ‘Places an Order’
3.1.4 Description for ‘Makes Payment’
3.1.5 Description for ‘Google Pay’
3.1.6 Description for ‘Paytm’
3.1.7 Description for ‘Credit Card’
3.1.8 Description for ‘Keeping Stock Information’
3.1.9 Description for ‘Tracking Customer or Employee Details’
3.1.10 Description for ‘Views Payment Transaction’
3.1.11 Description for ‘Responds to Queries / Feedback’
3.1.12 Description for ‘Authenticates Customers’
3.1.13 Description for ‘Verifies Transactions and Notifies Admin’
3.1.14 Description for ‘Processes Transactions’
3.1.15 Description for ‘Checks for Placed Order’
3.1.16 Description for ‘Completes Order’

vi
 List of Abbreviations

Sr. No. Abbreviation Expanded form

1 DSS Decision Support System

2 CMS Canteen Management System

vii
 Chapter 1
INTRODUCTION

The title of our project is CANTEEN MANAGEMENT SYSTEM. As we know a

canteen is common for Offices, Factories, Call Centres, Hostels, Schools, Clubs and Hospitals
to operate their own cafeterias for their employees and students. However, managing the
cafeteria menu, attendance and consumption is a challenging process. Manual and paper based
processes are cumbersome and error-prone, leading to inaccuracies and wastage of time and
material.
A canteen management system is essential for keeping track of food consumption. Our
project will offer a canteen management software that tracks item-wise food consumption and
also for a group of users. Different menus can be planned for breakfast, lunch, dinner, special
days and different occasions. This software allows tracking menu items, speedy transactions
and prevents accounting errors. It will also allow users to select menu items from any android
device.
 Chapter 2

SOFTWARE REQUIREMENTS SECIFICATION

for

CANTEEN MANAGEMENT SYSTEM

Version 1.0

Prepared by

Group Name: CMS

Ruchi Dholaria 20 patelruchi2110@gmail.com
Rhea D’souza 23 rheaofficial101@gmail.com
Rushia Fernandes 27 rushfernandes9@gmail.com

Instructor: Ms. Shree Jaswal

Course: Software Engineering and Project Management

Lab Section: Software Design Lab

Date: 28/02/2019
Chapter 2: Software Requirements Specification

Contents

REVISIONS 41
INTRODUCTION Error! Bookmark not defined.1.1
DOCUMENT PURPOSE
1.2 PRODUCT SCOPE Error! Bookmark not defined.1.3
INTENDED AUDIENCE AND DOCUMENT OVERVIEW
1.4 DEFINITIONS, ACRONYMS AND ABBREVIATIONS
1.5 DOCUMENT CONVENTIONS
1.6 REFERENCES AND ACKNOWLEDGMENTS

2 OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
2.2 PRODUCT FUNCTIONALITY Error! Bookmark not defined.2.3
USERS AND CHARACTERISTICS
2.4 OPERATING ENVIRONMENT Error! Bookmark not defined.2.5
DESIGN AND IMPLEMENTATION CONSTRAINTS
2.6 USER DOCUMENTATION Error! Bookmark not defined.2.7
ASSUMPTIONS AND DEPENDENCIES

3 SPECIFIC REQUIREMENTS Error! Bookmark not defined.3.1

EXTERNAL INTERFACE REQUIREMENTS
3.2 FUNCTIONAL REQUIREMENTS Error! Bookmark not defined.3.3
BEHAVIOUR REQUIREMENTS

4 OTHER NON-FUNCTIONAL REQUIREMENTS Error! Bookmark not defined.4.1

PERFORMANCE REQUIREMENTS
4.2 SAFETY AND SECURITY REQUIREMENTS Error! Bookmark not defined.4.3
SOFTWARE QUALITY ATTRIBUTES

5 OTHER REQUIREMENTS

3
Chapter 2: Software Requirements Specification

Revisions
Version Primary Author(s) Description of Version Date Completed
version Ruchi Dholaria Canteen Management System with basic SRS 00/00/00
1.0 Rhea D’souza
Rushia Fernandes

4
Chapter 2: Software Requirements Specification

1 Introduction
The title of our project is CANTEEN MANAGEMENT SYSTEM. As we know a canteen is
common for Offices, Factories, Call Centres, Hostels, Schools, Clubs and Hospitals to operate
their own cafeterias for their employees and students. However, managing the cafeteria menu,
attendance and consumption is a challenging process. Manual and paper based processes are
cumbersome and error-prone, leading to inaccuracies and wastage of time and material. A canteen
management system is essential for keeping track of food consumption. Our project will offer a
canteen management software that tracks item-wise food consumption and also for a group of
users. Different menus can be planned for breakfast, lunch, dinner, special days and different
occasions. This software allows tracking menu items, speedy transactions and prevents accounting
errors. It will also allow users to select menu items from any android device.

1.1 Document Purpose

This SRS describes the functional and non-functional requirements for release 1.0 of the project
Canteen management system. To implement and verify the functionality required by the user this
document is prepared. This document can be referred by project team members working on this
particular project to help get a vision regarding how to system will work.
This document presents a detailed explanation of the objectives, features, product scope, design
and implementation constraints of canteen management system. It will also describe how the
system will perform and how it will behave under certain circumstances.
Also, the required information about customers will be saved in the system which can be accessed
by the system admin.

1.2 Product Scope

This system will help to manage and run the canteen business systematically. In this system
customers can easily order their food. Feedback feature is also implemented so that customers can
share their feedback through which the owner of the canteen can evaluate and make required
changes to the system. All the information about daily expenses and profit will be saved in the
system.

1.3 Intended Audience and Document Overview

This document is intended for different types of readers such as canteen owner i.e. client, system
design, system developer as well as tester. By reading this document a reader can learn about what
the project is, methodology for the same.
This document has a sequential overview of the whole project starting from introduction which
includes sub parts such as purpose of the document, scope of the product being implemented,
intended audience and many such related sub parts. The document further describes overall
description of the product which covers sub topics such as perspective and functionality of the

5
Chapter 2: Software Requirements Specification

product, operating system characteristics supported by the system and includes some design and
implementation constraints. The flow of the document then covers some functional and non-
functional requirements of the system.

1.4 Definitions, Acronyms and Abbreviations

We will use bold letters to emphasis main topics and for all major functions of the system.
Underlines will represent hyperlinks. Italic will represent acronyms and useful notes. We have
used some acronyms in this document. Abbreviations and definitions of some useful terms used
by us are given below.

CMS – Canteen Management System

End users: people that will actually use the system

Admin: The person who manages the back end part of the system

1.5 Document Conventions

We have used bold letters to emphasis the main topics of the document. The document follows
Arial font with size 14 for main heading,size 12 for sub heading and Arial font with size 11 for
content. Italic will represent useful notes and comments.

1.6 References and Acknowledgments

● https://www.scribd.com/document/343606719/Synopsis-of-Canteen-Management-System
● https://www.matrixaccesscontrol.com/cafeteria-management.html

6
Chapter 2: Software Requirements Specification

2 Overall Description
2.1 Product Perspective

The Canteen Management System helps the canteen manager to manage the canteen more
efficiently and effectively, by computerizing meal ordering, billing and inventory controls.
The system, processes transactions and stores the resulting data that will help the manager generate
reports in order to make appropriate business decisions for the canteen. For example, knowing the
number of customers for a particular time interval, the manager can decide whether more chefs or
waiters are required. Moreover, he can easily calculate the daily expenditure and profit.
The whole management system is designed for a general Computerized, Digital Canteen. So that
any canteen owner can use to start an automated process in his canteen.
Implementing this system will lead to hire less waiters and create an opportunity to appoint more
chefs and better kitchen place to serve food faster. Customers can also make payment through
debit and credit cards

2.2 Product Functionality

All of the functions will be performed in the order given below,

● Food order via app

● Confirm order
● Online Payment
● Serve food
● Available goods
● Required goods
● Customer information
● Customer review

7
Chapter 2: Software Requirements Specification

fig.2.2.2.1. Level 0 DFD

fig.2.2.2.2 Level 1 DFD

8
Chapter 2: Software Requirements Specification

2.3 Users and Characteristics

The CMS has three active actors and one cooperating system. The customers can access the system
using their smartphones to order food. The online payment portal is accessed by the customer to
complete the payment transactions. The chef checks the order, and sends a confirmation once the
customer has paid for his order. After this the chef starts preparing the food and tells the system if
it’s ready. The customer can then go and collect the food from the collection counter. The admin
can add or delete contents from the menu, edit the price, count total earnings and expenditure, and
take feedback from the customer.

2.4 Operating Environment

OE-1: The CMS shall operate with the following Web browsers: Microsoft Internet Explorer
versions 5.0 and 6.0, Netscape Communicator version 4.7, and Netscape versions 6 and 7.
OE-2: The CMS shall operate on a server running the current corporate approved versions of Red
Hat Linux and Apache Web Server.
OE-3: The CMS shall permit user access from the corporate Intranet and, if a user is authorized
for outside access through the corporate firewall, from an Internet connection at the user’s home.

2.5 Design and Implementation Constraints

CO-1: There are some constraints that cost the system a-lot. A barrier that once crossed can
optimize the system to its best. Few such barriers are:
1. IOS App, Android and Windows App
2. Information flow or data flow can be controlled to be more effective
3. Faster servers such as Linux can be used
4. English language can be used for India
5. C# can be used for more security.

2.6 User Documentation

UD-1: It will provide specific guidelines to a user for using the CMS. A video will be provided to
demonstrate the functioning of the entire system.

2.7 Assumptions and Dependencies

AS-1: The canteen is open for breakfast, lunch, and dinner every working business day in
which employees are expected to be on site.
DE-1: The operation of the CMS depends on changes being made in System to
accept payment requests for meals ordered with the CMS.
DE-2: The operation of the CMS depends on changes being made in the Canteen Inventory
System to update the availability of food items as CMS orders are accepted.

9
Chapter 2: Software Requirements Specification

3 Specific Requirements
3.1 External Interface Requirements

3.1.1 User Interfaces

UI-1: The CMS screen displays shall conform to the Process Impact Internet Application User
Interface Standard, Version 1.0 [4].
UI-2: The system shall provide a help link from each displayed HTML page to explain how to use
that page.
UI-3: The Web pages shall permit complete navigation and food item selection using the keyboard
alone, in addition to using mouse and keyboard combinations.

3.1.2 Hardware Interfaces

No hardware interfaces have been identified.

3.1.3 Software Interfaces

SI-1: Canteen Management System

SI-1.1: The CMS shall transmit the quantities of food items ordered to the CMS through a
programmatic interface.
SI-1.2: The CMS shall poll the CMS to determine whether a requested food item is available.
SI-1.3: When the CMS notifies the CMS that a specific food item is no longer available, the CMS
shall remove that food item from the menu for the current date.

3.1.4 Communications Interfaces

CI-1: The CMS shall send an message to the customer to confirm acceptance of an order, price,
and delivery instructions.
CI-2: The CMS shall send an message to the admin to report any problems with the meal order or
delivery after the order is accepted.

10
Chapter 2: Software Requirements Specification

3.2 Functional Requirements

1. Registration and Login System a. Enable a new user to register to the system.
b. Authenticate and allow user to login on the web app.
c. Enable a registered user to change his password if
forgotten.

2. Menu and Ordering System a. Enable the customers to go through the menu and add his
choices to the cart.
b. Enable him/her to edit his choices before proceeding to
place the order.

3. Payment System a. Display the payment bill to the customer.

b. Enable the customer to pay for the placed order by
credit/debit card, GooglePay or Paytm.
c. Enable the system to notify the admin of the successful
transaction.

4. Chef’s Portal System a. Enable the Chef to check all placed orders.
b. Enable him/her to display the status of each order either
“Preparing order” or “Ready to pick up”.

5. Feedback System a. Enable a registered user to submit a Feedback on the

CMS, which contains a detailed explanation to his
problem if any.
b. Enable the admin to view, open and closed the submitted
Feedback.
c. Enable the admin to post a reply to the Feedback given.

Table no. 2.3.2.1. Functional Requirements

11
Chapter 2: Software Requirements Specification

3.3 Behaviour Requirements

3.3.1 Use Case View

fig.2.3.3.1.1 Use Case Diagram

12
Chapter 2: Software Requirements Specification

4 Other Non-functional Requirements

4.1 Performance Requirements

PR-1: The system shall accommodate 400 users during the peak usage time window of
8:00am to 10:00am local time, with an estimated average session duration of 8
minutes.
PR-2: All the pages generated by the system shall be fully downloadable in no more than
10 seconds over a 40KBps modem connection.
PR-3: Responses to queries shall take no longer than 7 seconds to load onto the screen after
the user submits the query.
PR-4: The system shall display confirmation messages to users within 4 seconds after the
user submits information to the system.

4.2 Safety and Security Requirements

The source code developed for this system shall be maintained in configuration management
tool.
Payment information and card details will be secured using encrpytion algorithms for security
purposes.

SR-1: All network transactions that involve financial information or personally identifiable
information shall be encrypted per BR-33.
SR-2: Users shall be required to log in to the CMS for all operations except viewing a menu.
SR-3: Admin shall log in according to the restricted computer system access policy per
BR-35.
SR-4: The system shall permit only canteen staff members who are on the list of
authorized Menu Managers to create or edit menus, per BR-24.
SR-5: Only users who have been authorized for home access to the corporate Intranet may
use the CMS from non-company locations.
SR -6: The system shall permit customers to view only their own previously placed orders, not
orders placed by other customers.

4.3 Software Quality Attributes

4.3.1.Availability-1: The CMS shall be available to users on the corporate Intranet and to dial-in
users 99.9% of the time between 5:00am and midnight local time and 95% of the time between
midnight and 5:00am local time.
4.3.2.Robustness-1: If the connection between the user and the system is broken prior to an order
being either confirmed or cancelled, the CMS shall enable the user to recover an incomplete
order.

13
Chapter 2: Software Requirements Specification

5 Other Requirements

Logical Database Requirements

The logical database requirements include the retention of the following data elements. The list
below is not complete but only designed as a starting point for development 3.16.1

Canteen Management System

• Customer fist name
• Customer surname
• Customer mobile number
• Customer order
• Customer payment
• Bank approval for transaction
• Payment received
• Chef’s regular order updates
• Customer collects order
• Customer feedback

14
 Chapter 3
SYSTEM ANALYSIS

3.1 Use-Case Diagrams and description

Fig.3.1.1. Use Case Diagram

Chapter 3: System Analysis

USE CASE Registration

PRIMARY ACTOR Customer

GOAL IN CONTEXT To register user to the system

PRECONDITION Proper validation should be implemented by the website

On completion of valid input by the user appropriate message

TRIGGER
should be displayed

User enters required details and if valid account of user should be

SCENARIO
added to the database

EXCEPTION Account already exisiting

In order to access features of the system user account should be

PRIORITY
created
Table3.1.1. Description for ‘Registration’

USE CASE Login

PRIMARY ACTOR Customer

GOAL IN CONTEXT To allow legitimate user access the site

Legitimate website’s URL must be stored in the database and user

PRECONDITION
must have done registration

On entering login details appropriate message should be displayed

TRIGGER
to user

User enter login credentials,system checks whether the details are

SCENARIO
valid and generate results

EXCEPTION Website goes down

PRIORITY Essential for authenticating valid user

Table3.1.2. Description for ‘Login’

USE CASE Places an Order

PRIMARY ACTOR Customer

GOAL IN CONTEXT To display updated menu to the user and to take the order list from
the user

PRECONDITION Order menu must be updated

16
Chapter 3: System Analysis

TRIGGER On completion of order system should provide order ID and

payment bill

SCENARIO From the given website,user selects choice of food item

EXCEPTION New food item does not get reflected back to the order menu

PRIORITY Essential to take user order

Table3.1.3. Description for ‘Places an Order’

USE CASE Makes Payment

PRIMARY ACTOR Customer

GOAL IN CONTEXT To make payment for the generated bill

PRECONDITION Proper bill for the user should be generated

TRIGGER On entering valid details required for the payment,the request

should be forwarded to the user’s bank

SCENARIO User selects method of payment and enters details accordingly

EXCEPTION The linkage of user id and generated bill is not valid

PRIORITY Essential to get payment from the user

Table3.1.4. Description for ‘Makes Payment’

USE CASE Google Pay

PRIMARY ACTOR Customer

GOAL IN CONTEXT Payment gateway to process transaction

PRECONDITION Makes payment should be executed

TRIGGER -

SCENARIO -

EXCEPTION -

PRIORITY -
Table 5. Description for ‘Google Pay’

USE CASE Paytm

PRIMARY ACTOR Customer

17
Chapter 3: System Analysis

GOAL IN CONTEXT Makes payment should be executed

PRECONDITION -

TRIGGER -

SCENARIO -

EXCEPTION -

PRIORITY
Table3.1.6. Description for ‘Paytm’

USE CASE Credit Card

PRIMARY ACTOR Customer

GOAL IN CONTEXT Makes payment should be executed

PRECONDITION -

TRIGGER -

SCENARIO -

EXCEPTION -

PRIORITY
Table3.1.7. Description for ‘Credit Card’

USE CASE Keeping Stock Information

PRIMARY ACTOR Admin

GOAL IN CONTEXT To provide updated stock information to user

PRECONDITION All prior manipulation to the stock should be updated in the system

TRIGGER When admin request for stock information updated details should
be displayed

SCENARIO Admin uses the system to generate reports regarding the stock
information

EXCEPTION System error while updating stock information

PRIORITY Essential as to keep track of items left in canteen

Table3.1.8. Description for ‘Keeping Stock Information’

18
Chapter 3: System Analysis

USE CASE Tracking Customer or Employee Details

PRIMARY ACTOR Admin

GOAL IN CONTEXT To keep track of the customer and employee details such as
name,phone number,address

PRECONDITION All the customer details should be collected by the person in

charge at the time of customer visit

TRIGGER When admin request for customer details,updated record of

customer details should be displayed

SCENARIO Admin uses the system to view the customer details of given day
or entire week

EXCEPTION Customer details were not taken at the time of customer visit or
error while recording details in the system

PRIORITY Essential as to rectify potential customer by their no of visit made

Table3.1.9. Description for ‘Tracking Customer or Employee Details’

USE CASE Views Payment Transaction

PRIMARY ACTOR Admin

GOAL IN CONTEXT To check whether payment done by user was successful or not

PRECONDITION User should make the payment

TRIGGER When the order is placed admin should request to check whether
the payment was done or not

SCENARIO Admin uses the system to verify whether payment was done or not

EXCEPTION Invalid entry of the payment is displayed

PRIORITY Essential as payment should be done for the order by the user
Table3.1.10. Description for ‘Views Payment Transaction’

USE CASE Responds to Queries / Feedback

PRIMARY ACTOR Admin

GOAL IN CONTEXT To collect and analyze feedback given by user

PRECONDITION User feedback should be correctly collected along with user

identity

TRIGGER When admin login into the system and request for feedback post

19
Chapter 3: System Analysis

all the new post should be displayed to the admin

SCENARIO Admin uses the system and request to display all the new feedback
and responds to all the feedback or queries of the user

EXCEPTION System fails to collect user feedback

PRIORITY Essential as user experience can help improve the system or make
essenṭail changes
Table3.1.11. Description for ‘Responds to Queries / Feedback’

USE CASE Authenticates Customer

PRIMARY ACTOR Bank

GOAL IN CONTEXT To collect customer details and check whether the customer is
authenticated to access the mentioned payment method

PRECONDITION Customer needs to have existing bank account

TRIGGER When customer makes payment by entering card details bank at

the back end should authenticate user

SCENARIO To complete order user makes payment using the payment portal
of the system

EXCEPTION User enters invalid information

PRIORITY Essential as user’s payment security is at risk

Table3.1.12. Description for ‘Authenticates Customers’

USE CASE Verifies Transactions and Notifies Admin

PRIMARY ACTOR Bank

GOAL IN CONTEXT To complete transaction as well as notify admin the status of the
transaction

PRECONDITION Bank should successfully authenticate valid user

TRIGGER Once the user is authenticated, bank proceed with next task or
action to complete in order to complete the transaction

SCENARIO Once the user enters his/her payment details,bank at the backend
processes various task to complete transaction

EXCEPTION System failure

PRIORITY Essential as user’s payment security is at risk

Table3.1.13. Description for ‘Verifies Transactions and Notifies Admin’

20
Chapter 3: System Analysis

USE CASE Processes Transactions

PRIMARY ACTOR Bank

GOAL IN CONTEXT To perform predefined task to ensure user transaction

PRECONDITION User should enter valid OTP number

TRIGGER After getting OTP bank proceed further to next set of instructions

SCENARIO Once valid OTP is received, bank checks whether enough balance
is there in user’s account and accordingly completes the
transaction and notify user

EXCEPTION User account with insufficient balance

PRIORITY Essential as user’s payment security is at risk

Table3.1.14. Description for ‘Processes Transactions’

USE CASE Checks for Placed Order

PRIMARY ACTOR Chef

GOAL IN CONTEXT To check whether any new order has come or not

PRECONDITION All the orders should be displayed within minimal amount of time

TRIGGER When Chef refreshes page or request for placed order,all the new
order list should be displayed

SCENARIO Chef uses the system and request to get details of new placed
orders

EXCEPTION Order duplication or manipulation in the order placed by the user

PRIORITY Essential as chef should know what to cook

Table3.1.15. Description for ‘Checks for Placed Order’

USE CASE Completes Order

PRIMARY ACTOR Chef

GOAL IN CONTEXT To send a message regarding completion of order

PRECONDITION Valid order entry should be displayed and user should pay for the
order

TRIGGER When chef updates the status of order as completed, notification

should be given to the user

21
Chapter 3: System Analysis

SCENARIO When the order is completed,chef uses the update order status
function of the system to mark the status as completed

EXCEPTION Valid user order is not reflected in the system and without marking
status of order as completed user gets notification

PRIORITY Essential as user should know when the order is completed

Table3.1.16. Description for ‘Completes Order’

3.2 Class diagram

Fig.3.2.1 Class Diagram

The above class diagram shows relationship among various use cases of the system shown in the
use case diagram such as customer, chef, bank and admin in the class object.

22
 Chpater 4
ANALYSIS MODELING

4.1 Activity Diagram

Fig.4.1.1. Activity Diagram

The above activity shows the interaction of the system with the user or admin at the login time.
The system asks for valid login credentials and based on that checks who is accessing the
system and proceed with relevant task.
Chapter 4: Analysis Modelling

4.2 Sequence Diagram

Fig.4.2.1 Sequence Diagram for food Ordering

The above sequence diagram is shown for the food ordering scenario where the sequence of each
task is shown.

24
Chapter 4: Analysis Modelling

4.3 TimeLine Chart and Work Breakdown Structure

25
Chapter 4: Analysis Modelling

26
 Chapter 5
DESIGN

5.1 Architectural Design (Project Flow /architecture with description)

Fig.5.1.1. Architectural Design

In our system ie Canteen Management System, there are different client software which are
used by users to interact with the system as shown in the diagram. Customer registration is
used by users to register them-selves with the system so that they can access all the features
provided by the system. Customer login is used by customer to login to the system every time
they visit again. As the system is Canteen Management system, there is a software where users
can place their required order. And to pay of their order there is a payment portal where users
can payment via credit card, debit card or via Google Pay. The order window is used by chef
to check for pending or new order. And similarly update order status is used by chef to update
the status of the order as completed so that it can be delivered to the user. The posting feedback
software is used by user to post their experience of visiting the canteen, how they like our food,
interior and if they have any queries or problems as well. System management module is used
by admin to manage the entire system functions such as customer details, employee details,
stock management and responding to user feedback.
Chapter 5: Design

5.2 User Interface Design GUI for your project

Fig.5.2.1. Home Page

Fig.5.2.2. Register Page

28
Chapter 5: Design

Fig.5.2.3. Login Page

Fig.5.2.4. Order Page

29
Chapter 5: Design

Fig.5.2.5. Chef’s Portal

Fig.5.2.6. Feedback + Logout Page

30
Chapter 5: Design

5.3 Type of Testing used

Testing types:

1. WHITE BOX TESTING (also known as Clear Box Testing, Open Box Testing, Glass
Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing) is a
software testing method in which the internal structure/design/implementation of the item
being tested is known to the tester. The tester chooses inputs to exercise paths through
the code and determines the appropriate outputs.
Types of white box testing applicable to the Bus Reservation System:
a. UNIT TESTING: Unit Testing is the first level of software testing. In this level
of software testing, individual units/ components of a software are tested. The
purpose is to validate that each unit of the software performs as designed. A unit
has one or a few inputs and usually a single output. A unit may be an individual
program, function, procedure, etc. which is further tested by software developers
or independent testers.
b. INTEGRATION TESTING: In this level of software testing, individual units are
combined and tested as a group. This testing exposes faults in the interaction
between integrated units. Test drivers and test stubs are used to assist in
Integration Testing.
c. SYSTEM TESTING : In this level of software testing, a complete and integrated
software is tested. The system’s compliance with the specified requirements is
evaluated

2. BLACK BOX TESTING, also known as Behavioral Testing, is a software testing

method in which the internal structure/design/implementation of the item being tested is
not known to the tester. These tests can be functional or non-functional, though usually
functional.
Types of black box testing applicable to the Canteen Management System:
a. EQUIVALENCE PARTITIONIONG: In this software test design technique input
values are divided into valid and invalid partitions and representative values from
each partition as test data are selected.
b. BOUNDARY VALUE ANALYSIS: In this software test design technique that
involves the determination of boundaries for input values and selecting values
that are at the boundaries and just inside/ outside of the boundaries as test data.

31
Chapter 5: Design

5.4 Test cases (conditions on which testing is done)

Fig.5.4.1. Test Case for Registration

Fig.5.4.2. Test Case for Login

32
Chapter 5: Design

Fig.5.4.3. Test Case for Ordering

Fig.5.4.4. Test Case for Chef’s Portal

33
Chapter 5: Design

Fig.5.4.5. Test Case for FeedBack

34
Chapter 6: Conclusion

Chapter 6
CONCLUSION

This software is efficient in maintaining customer’s details and can easily perform
operations on customer’s records and also works to handle the information of the
products available in a canteen. This software also reduces the workload of the
canteen. 1n future, this system can launch web site for easy online canteen
facilities.
 ACKNOWLEDGMENT

We would like to express our gratitude and respect to our Professor, Ms. Shree
Jaswal who gave us the opportunity to not only work on this project “Canteen
Management System” but also guided us well through the process. We also thank
the Director and the Principal of the college for introducing Software Engineering
as a subject in our syllabus.