Meal On Wheel

Presented to the
Professor Faizan Ali Malik
University of Central Punjab
Lahore, Pakistan

In Fulfillment
of the Requirements for the Project Presentation in
Management Information System
FALL 2023
By
Zunaira Imran– L4F21UADCS064
Mehreen Iftikhar – L4F21UADCS050
Shehroz Irshad – L4F21UADCS146
Hafiz Muhammad Shehryar – L4F21UADCS046
Muhammad Nauman – L4F21UADCS0131
 Abstract

Here, a system for online food ordering that operates on the food request procedure
is suggested. The suggested framework streamlines the client's work by displaying
a user interface (UI) and updating the menu with all available options. The client
has the option of selecting several items for their request and can preview request
details before logging off. The client receives the request confirmation in the mail.
The request is added to the queue, refreshed in the data set, and constantly
returned. With the use of this framework, the team is better able to handle orders
efficiently and with few errors. The goal of the Meal On Wheel is to automate
manual processes through the use of electronic devices and computer programming
demands, thus by managing anything nearly equivalent, their key data/information
can be taken care of for a longer time period. The standard programming and
equipment are very accessible and simple to use. The above illustration of the Meal
On Wheel shows that it has a flawless, safe, reliable, and quick organizational
structure. Instead of concentrating on record-keeping, it might help the client focus
on their numerous activities. As a result, it will aid the relationship in making
better use of its resources. The association can remain informed about digital
documents without unnecessary segments. This implies that, although having the
option to attend the information, one need not be involved by irrelevant
information. In overall, the project shows how to oversee excellent execution and
better organization for the clients.
 CHAPTER NO 1

1.1 Introduction :
The digital era is the one in which we currently reside. It significantly improves
every aspect of life and alters people's lifestyles day by day. Even your home
appliances can be controlled digitally. We develop an online website for a
restaurant so that customers can easily access all of the things that belong to a
restaurant while sitting anywhere rather than going to the restaurant in order to
avoid the rush, which is a major problem in restaurants because ordering food
takes a lot of time while orders are being prepared. The online meal ordering
system is one of the newest innovations that the majority of fast food outlets in the
West are implementing. This procedure entails placing an internet meal order and
having it delivered to the customer.
It is made possible by the use of an electronic payment system. Credit card
customers can be serviced before they pay with cash or a cheque, but they usually
use credit cards to do so. As a result, customers will be able to order food online
with the help of the technology developed for this project. Anybody can order any
product online and have it delivered to their door. However, the payment system is
the main concern rather than how the goods and services are delivered. In other
words, how practical is buying goods and services online? This then triggers a
discussion on how digital currency affects the economy. What are the
implementations in terms of the economy?
Communication, of which telecommunication is a vital component, is an essential
tool for this process as the world is gradually becoming into a global village.
Perhaps the most recent tool being used by the majority of drive-through
restaurants in the west is the electronic meal ordering system. With this method,
the client learns about food-related websites. It is made feasible by adopting an
electrical part structure. consumers use their Master cards to make purchases even
though Visa consumers can be helped before they hand over cash or a cheque.
Because of this, the project's design will persuade users to look up food demand
online. In this article, we suggest a "Meal On Wheel" that intended for Fast Food
eatery, Take-Out or College Cafeterias. The framework can likewise be utilized in
any food conveyance industry. This works on the course of food requests for both
the client and the café, as the whole course of taking requests is mechanized.
1.1.2 Project Overview :
The goal of the project is to develop an online restaurant ordering system. Many
businesses are currently adopting innovations quickly. The café sector also adopts
a variety of innovations that streamline and speed up daily operations. However,
compared to other industries, the restaurant industry is less open to innovation.
Online food ordering platforms are becoming increasingly popular. This is due to
the fact that they are supporting the steadily growing interest in persuasion. Giving
customers a way to make a request at a café online is the main driver behind a
web-based requesting framework. Customers may definitely browse all of the
menu items the restaurant offers, make changes, and order food through a website
or mobile application.
1.1.3 Project Aim & Objective:
The project attempts to develop an automated web-based restaurant ordering
system. Management will also benefit from the ability to handle online orders and
verify status. The administration can add menus and take orders thanks to the
system. The system also offers a simple user interface that can be used on a range
of displays and devices and is mobile-friendly. The Facebook API will be
integrated into the app so users can log in with their Facebook accounts and like or
share menus, which can help spread the word about the service and draw in new
users. The aforementioned goal must be achieved, as well as the following
objectives: To find out about previous attempts to automate restaurant food
ordering procedures, conduct a thorough literature review. The entire system will
be created.
The whole system will be designed and developed in a systematic manner using
the appropriate methodologies.
 The backend and frontend of the system will be built using Laravel 5.4 and
Bootstrap 4.
 The system will incorporate social media. Customers can therefore login and
register using their social media accounts and then comment on the menu. To
ensure system quality, the system will undergo thorough testing.

1.2 Project Rationale :

Web-based orders from restaurants are becoming easier to complete as mobile and
web technology develops. As it is easier and quicker, food lovers would typically
request different food items through a web-based requesting framework.
According to research by QSR Web, computerised café orders are increasing 300%
faster than rush-hour traffic-related eating. In any event, the majority of restaurants
don't place much emphasis on appearing online. Therefore, 51% of all Google
mobile ventures are for restaurants, but only 5% of them have mobile-optimized
websites.
1.2.1 Feasibility of Project:
The system is currently entirely functional, with a few small issues that will
undoubtedly come to light with more extensive testing. On the website right now,
customers can register, log in, and place orders. The recovered order is completely
and precisely shown by the desktop programme. The project requires the
development of a complete web application for a restaurant that can accept online
orders. This website will be mobile-optimized so that users on both PCs and
mobile devices may access it. PHP, Bootstrap 4, and Apache Server are just a few
of the open-source technologies that will be used to construct the system. The
technologies are therefore open for use.
The proposed solution should satisfy all user needs and be sufficiently flexible to
allow for future modifications in response to new requirements. Economic
Suitability This is an important consideration while developing a project. We
selected the technology based on its potential cost savings. All hardware and
software must be purchased entirely by the organisation. Overall, our calculations
show that the benefits the business will receive from the suggested system will
unquestionably outweigh the system's initial costs and continuing operational
costs.
 Technical Feasibility :
This include investigating system functionality, performance, and constraints that
might make it more challenging to design a practical system. We investigated all of
the system's anticipated features in order to do this feasibility research, and we
evaluated the system's viability on various frontend and backend platforms.

 Operational Feasibility :
The suggested solution is without a doubt completely GUI-based, very user-
friendly, and all inputs required are self-explanatory even to a layperson.
Additionally, users have received enough training so they are familiar with the
fundamentals of the system and feel comfortable using it. Our investigation shows
that the system has lessened the clients' duties, which has made them more at ease
and satisfied.

1.3 Scope of Project :

It might help in painstakingly assembling the best management. It won't take long
before the collection is organized and sensible. It will help someone properly
comprehend the administration of the prior year. It also backs all current
programmed using the electronic meal ordering system. The administration and
collection process will be effective, and collection expenses will go down. Since
the goal of our project is business process automation, we have attempted to
computerize a number of Meal On Wheel operations. In general, a greater degree
of control has been demonstrated to encourage a higher degree of customer loyalty
and a more significant desire to use or advise recommended services.
A self-administration framework's perceived comfort also leads to an increase in
acceptance and fulfilment. The term "accommodation" in this context refers mostly
to finding comfort and swapping accommodations. Based on the client region, a
customer will browse the available items and hunt for their favorite restaurant.
Among other things, installment can be made using cash or a MasterCard. It could
aid in thoroughly gathering excellent administration. The selection will be
straightforward and sensible in a remarkably short period of time. It will let
someone understand how a year was spent in perfect administration. It also aids
with current tasks similar to Meal On Wheels. Additionally, the cost of collection
management will be reduced, and the collection system will function normally.

Our business focuses on the automation of business processes. For instance, we

have tried to automate various steps in the
• The computer system asks the user to complete a number of forms, and it is easy
to make numerous copies of each form at once.
• By printing the manifest directly from a computer system rather than having to
initially generate one, we may save time.
• To assist the staff in keeping track of the time spent on each of the task areas they
were given.
• To use resources more efficiently by increasing their productivity through
automation.
• The system creates multiple information kinds that can be applied to a variety of
situations.
• It meets the needs of the user.
• Be easy to understand for the user and operator.
• Be user-friendly.
• Possess an intuitive user interface.

1.4 Purpose of Project :

The online meal ordering system's objective is to automate the manual procedure
so that data and information can be kept utilizing computerized technologies for a
longer period of time. People can easily purchase food online using the online
ordering system without having to go to a restaurant in person. This approach is
made possible by the internet, which also serves as the conduit between the patron
and the eatery or food supplier. Online ordering is essentially a quick, dependable
platform that is created especially for businesses and takes care of everything from
collecting orders to keeping consumers informed about deliveries.
Currently, this strategy is very lucrative for owners of the food industry as
customer needs increase. The main objective of the Meal On Wheel is to govern
online fast food ordering by managing information for Item Category, Food,
Delivery Address, Order, and Shopping Cart. It enables customers to order desired
products at any time and from any location. Moreover, pay when delivery occurs.

1.5 Proposed System :

By granting each user access to a personal system where they may log in and
reserve the items they want, the offered method ensures complete user autonomy.
New data must be stored in the system. Internal staff must use the system to help
them maintain Category information and find it in answer to various inquiries.
 Quantity must be tracked by the system.
 The customer record must be kept up to date and updated by the system as
needed. The system also requires a search area.
 Data protection also necessitates the use of a security system.
 Only users who have registered with our system are able to make
reservations and make necessary cancellations.
 Under this strategy, the full task is completed online.
 Customers can make inquiries and suggestions using the website's feedback
form.

1.6 Existing System

under the current framework, tests are only run manually; however, under the
suggested framework, we must use this program to automate the tests. Information
security is lacking.
 A bigger pool of workers.
 Needs a lot of labor-intensive paring.
 Manual calculations are necessary.
 The higher ups don't now have any jobs.
 CHAPTER NO 2

2.1 Literature Review :

In various contextual investigations, the challenges faced when operating a café
have been examined.
The list of issues with the current framework that were found during the
investigation is as follows:
 The consumer visits the restaurant, peruses the available menu items,
chooses the items they require, submits the request, and then pays the tab.
 Why When a customer calls a restaurant to make a reservation, the customer
cannot see the actual menu that is served there; this method also falls short
of giving the customer the confidence that the request was made for the right
menu items.

2.1.1 Past Work On This Domain :

A mechanised café framework is a coordinated IT infrastructure that directs,
supervises, and coordinates restaurant setup tasks (Tan, 2013). Orders and
payments were physically controlled using register books and other tools until the
automated system was introduced. The point-of-sale (POS) system was first
introduced in the 1990s. After becoming widely used, the framework was adopted
by the café industry. Innovation in the online and remote sectors greatly increased
after 1990.
To improve the efficiency of the framework, cafes also began implementing the
numerous technology-based frameworks (Sullivan, 2015). Experts also began
presenting a wide range of café-related solutions. Restaurant operations have
already undergone a significant amount of computerization. Each scientist put a lot
of effort into coming up with a solution for a particular problem or point of view.
There are various categories into which the arrangements offered by scientists
might be divided. The following segments will look at these frameworks.
2.1.2 Technology for Web Application Development :
For front-end development, we used HTML, CSS, and JavaScript; for back-end
development, we used PHP and MySQL.
Hypertext Pre-processor or PHP : Itis a programming language that was
originally developed for building websites but is now used for various kinds of
purposes.
A PHP translator then starts the PHP code, which is then run in the guaranteed
request. carried executed at that point as a web server module. The web server
consolidates the output of the PHP code that has been both decoded and run.
My SQL: The board framework (RDBMS) is a social data set that is open-source.
The main component of the open-source XAMPP web application development
stack is MySQL. "Windows, Apache, MySQL, and Perl/PHP/Python" is referred to
as WAMP. MySQL's source code can be fabricated and introduced physically,
yetit is continuously introduced from a twofold bundle due to customization.
Albeit further advances are expected to alarm the security and improvement
settings.
2.2 Use Case diagram with Activity Diagram:
A textual description of behavior is frequently adequate to capture the behavior of
the system when the sequence of occurrences is linear. Activities diagrams offer a
visual way to document the order of the tasks that make up an activity. They are
particularly helpful for concurrent conditionally logical tasks and event flow. We
use textual use cases to illustrate the fundamental system capabilities, and activity
diagrams to show the appropriate task or information flow in a visual manner.
Use Case 1. Place Order
 Primary Actor: Customer
 Description: Customer places an order from the available choices after
indicating his language preference for the session.
 Pre-conditions: System is connected to a power source, display is turned on
and system is configured to accept the inputs.
 Flow of Events:
I. User selects his language preference for the session.
II. User selects from the menu.
III. User selects from the drinks menu
IV. User selects from the combo deals
V. User confirms the order
 Alternative Flow of Events:
I. User accidentally presses a wrong button and after realizing it he hits the
backspace button.
II. User enters a wrong order and wants to go back to the main menu.
Post-condition: Order has been made that goes to the kitchen for processing.
Assumption: User is familiar with how to enter values through mouse and has a
general idea why the inputs are being provided and what is expected out of system.
Activity diagram for this use case is given as below:
Use Case 2. Make Payment
 Primary Actors: customer, Credit/Debit system, cash collector.
Description: The user is asked for the mode of payment. The payment is
accepted in terms of credit/debit card or is collected by cash collector. And
the customer is given a token with their order number.
Pre-condition: The order has been confirmed and the total bill has been
displayed on the screen to the customer. Costumer decides to go ahead with
the order.
 Flow of Events:

User enters the mode of payment. (Credit/Debit/Cash)

1. User makes the payment in cash
2. Cash collector collects the money and gives back the change if required.
3. User makes the payment by credit/debit card.
4. User receives a token number and final bill.
 Alternative Flow of Events:

1. User selects the mode of payment.

Post-condition: Customer waits for the order to be processed.
Assumption: User is familiar with how the system works and what is expected out
of system.
Activity diagram for this use case is given as below:
 Figure 3. Activity Diagram for Payment Process Use Case
Use Case 3. Update Menu.
 Primary Actor: Store Manager.
Description: The menu might change according to the inventories or
add/delete items from menu and deals. The prices of each item might change
for the period of time.
Pre-condition: An order menu with their respective price already exists in
the system in some particular format.
 Flow of Events:

1. The Store manager enters the system with some password.

2. The Store manager makes the required changes.
3. The Store manager saves the changes and logs out.
 Alternative Flow of Events:

1. Some of the menu might not need any change.

2. User might enter invalid password and need to go back.
Post-condition: A menu list will be displayed when the user enters the system.
Assumption: The Store manager is given the rights and privileges to enter the
system and make the required changes.
Activity diagram for this use case is given below:

Figure 4. Activity diagram for Update Menu Use Case

Use Case 4. Monitor Inventory.
 Primary Actor: Food preparation person, Store Manager Description: This
use case triggers when an item goes out of stock.
Pre-condition: None.
 Flow of Events:

1. Food preparation person/Store manager notices an item out of stock

 2. Updates the menu accordingly.
Post-condition: A new and updated menu list will be displayed.
Assumption: The Store manager is given the rights and privileges to enter the
system and make the required changes.
Activity diagram for this use case is given below:

Figure 5. Activity Diagram for Monitor Inventory

Use Case 5. Read Order.
 Primary Actor: Food preparation person, Internal Order system.
Description: Internal order system reads the order once the customer
confirms his order and then he communicates the order to the food
preparation person.
Pre-condition: User confirms the order.
 Flow of Events:
1. Internal order system reads the order
2. Communicates the order to the food preparation person
Post-condition: The final order is being processed in the kitchen.
Assumption: Food preparation person is available to take the order and know the
sequence of processing the orders.
Activity diagram for this use case is given below:
Figure 6. Activity diagram for Read Order
2.3 Use Case Task Component Interaction:

2.4 Functionalities:
Functionalities provided by Meal On Wheel:
 Gives the looking through offices in light of different variables. Like Food Item,
Customer, Order, Confirm Order.
 Meal On Wheel additionally deals with the Payment subtleties online for Order details,
Confirm Order subtleties, and Food Item.
 It tracks all the data of Category, Payment, Order, etc. Manage the data of
CategoryShows the data and portrayal of the Food Item, Customer.
 To increment effectiveness of dealing with the Food Item, Category.
 It manages observing the data and exchanges of Order.
 Manage the data of Food Item.
 Altering, adding, and refreshing Records is further developed which results in proper
resources for the board of Food Item data.
 Manage the data of Order.
 Integration of all records of Confirm Order.
 CHAPTER NO 3

3.1 Performance Requirements:

 The system should be able to take any type of inputs, once the mouse is clicked on the
respective button.
 The system should be able to take any amount of order and display it when finished.
 The system should be able to calculate the bill and prompt the user for the mode of payment
and generate a receipt.
 The system should be able to pass on the order in the kitchen for processing.
 The system should be secured to restrict the number of people to enter the system to make
changes in the menu and its items.
 The system should be sturdy for rough usage.
 System should be able to communicate to the central database to verify the authenticity of the
credit/debit card.
 System should allow Store manager to add/delete/alter system items.

3.2 Functional and non-functional requirements:

3.2.1 Functional requirements:

Functional requirements are those that outline the tasks that a system or piece of software must
be able to complete successfully.

The project's functional needs are listed below.

Registration: A link to the Users/Client Registration is provided by the application.

Login: Directors and Clients can use the website to manage their work by logging in with their
client names and passwords.

Save data: The client enters all of its essential information by filling out specific data
frameworks and storing that data.
Requirements for change: The client is always free to modify any of their data. Food menu:
The administrator has the ability to embed, edit, and remove food items from the menu list.

Serve a menu: A list of the several foods that the organization manages the accessible subjects
is provided.

Note the order information: The right food items can be added to the truck by a customer after
selecting them from the menu. The client may submit a request and receive confirmation that the
request has been received in relation to the Order.

Provide order status: With his/her predetermined request, the client is able to examine the
situation. view order A request can be submitted, and the administrator can see it.

3.2.2 Non-functional requirements:

 This web application is worked by involving SQL as a data set instrument and PHP is
utilized as a Development device alongside HTML and CSS.
 The connection point ought to utilize terms and ideas, which are drawn from the
experience of individuals who will make the vast majority of the frameworks.
 The framework should give simple and quick access without consuming a lot of costs.
 The client ought to never be astounded by the way of behaving of the framework and it's
not difficult to recover and store information. The application will want to deal with any
kind of working framework which has a program and web association.
 Secure and dependable framework.
 The application will want to work with an adequate speed of web interface.

3.3 Features Of Project :

Simple problem creation and updating, complete issue list querying, and more thorough
reporting and charting

 User accounts for maintaining security and controlling access.

 Simple resolutions, status, and multiple-level priorities and severity ratings.
  Objectives and standards for teaching programmers Managing the menu Retrieving
database orders
 Trustworthy database backend • Reports at several levels and a variety of filter criteria
are available.
 There is greater room for storage.
 Accessing information quickly and easily.
 Well-designed reports.
 Reduce the workload for individuals engaged and improve the manual system currently
in place.
 Every person has access to every piece of information
 Work moves rapidly.

3.4 Requirements and design:

The methods used to plan the framework for the café are outlined in this section. The part tends
to the numerous kinds of framework requirements first. The framework plan is next examined,
and a description of the framework's procedures is provided. The framework's information base
mapping is then defined. The UI setup has been made, to sum up.

3.5 Modules for Meal On Wheel:

 The Food Items Management Module is used to handle the nuances of food items.
 Confirm Order Submodule: For handling the nuances of Confirm Order.
 Installation Module: Used to handle the nuances of installation.
 Module for Classification Management: Used to handle data and the nuances of class.
 Client Modules: Used to handle the complexities of the client.
 The request module is used to process the request's data.
 Login Module: Used to handle the complexities of login.
 Clients Module: Used to interact with the framework's clients.
3.6 Input data and validation of project on Meal On Wheel:

 Every field, including Food Item, Customer, and Confirm Order, has been authorized and
does not accept erroneous data.
 The structures for Food Item, Category, and Payment do not support clear value fields.
 preventing data errors.
 regulating the input's size.
 the system's integration of its comparatively large number of modules and components.
 setting up the test scenarios.
 putting together the information for a possible test with all the necessary approval checks.
The actual testing is done by hand.
 recording of the several faults that were made again. For the errors discovered during
testing, adjustments were made.
 Following the correction of the flaws, prepared the experimental outcome scripts.
 function of the entire module and forms.
 Client input validations.
 Verifying that the coding standards are being followed when coding.
 Testing the module with every test case imaginable.
 User testing, involving various estimations, etc.
 Standards for commenting in the source papers.

3.7 In the software quality plan we will use the following SQA Strategy:

In the first phase, we will choose and rank the test factors. The framework will be constructed in
accordance with the rankings of the test variables that have been selected, such as reliability,
applicability, portability, and so on. The second step is to recognise the stages of the cycle of
progress. The stage ought to remain in the matrix.Separating the business risks from the
expectations for the product is the third step. The dangers will be divided into three categories:
high, medium, and low.
3.7.1 Software requirement specification:

The most important part of the assessment work is the delivery of the Software Requirements
Specification. By outlining a complete data portrayal, an itemised practical and conduct
depiction, a demonstration of the presentation prerequisites and plan limitations, suitable
approval measures, and other information pertinent to the necessity, the ability that an exhibition
gives out to programming as a component of framework designing is filtered. The analytical task
culminates in the delivery of the software requirements specification. By laying out a complete
data portrayal, a detailed functional and social depiction, a sign of execution necessities and
design limitations, proper approval measures, and other information relevant to the prerequisites,
the capability and execution dispensed to programming as a component of system engineering
are refined.

3.7.2 Hardware Requirements:

A PC with Intel Core i3 64-bit processor also, Graphic card 1 GB RAM, and Microsoft
Windows 10 it was utilized to work framework.
 CHAPTER NO 4

4.1 System Analysis:

Framework investigation is a process that combines social interaction, reality-decoding, and the Meal On
Wheel data to recommend improvements for the framework. Serious communication between framework
clients and engineers is necessary for a critical thinking action. Any framework enhancement approach
should include a significant duration of framework analysis or study. The framework is examined in
minute detail and broken down. The framework specialist takes on the questions and maintains a deep
understanding of how the current framework operates. The framework is viewed as a whole, and the
contributions are acknowledged. The outcomes of the relationships are then followed in several cycles.
Framework research is concerned with raising awareness of the issue, identifying the crucial and deciding
variables, separating and incorporating the different factors, and deciding on an idea or possibly a
palatable arrangement or program of activity.
There should be a thorough analysis of the relationship using various techniques, such as meetings,
surveys, and so forth. To come to a conclusion, the data acquired from these sources needs to be
analyzed. Understanding the capabilities of the framework is the goal. The term "current framework"
refers to this arrangement. At this time, the current structure is being carefully examined, and issue spots
are being identified. The developer is currently employed as a problem solver and makes an effort to
identify the challenges that the venture encounters. The setups are provided as suggestions. The best
proposal is then selected after being scientifically compared to the existing framework. The client
presents the proposal to them for their consideration. The proposal is evaluated based on customer desire
and reasonable changes are made. This is a circle that closures when the client is happy with a
proposition.
The most typical method of social affairs and reality interpretation, incorporating the facts for further
framework studies, is primer review. Fundamental analysis is a critical-thinking task that necessitates
heightened communication between framework clients and engineers. It does many practicality studies
from which the decision of the steps to be taken for a fruitful framework study and investigation may be
made.

4.2 System Design:

In this phase, a stable framework that satisfies the specified requirements is created. The programming
improvement process' design phase succeeds in transforming the client's requirements into a logically
sound framework. The following two actions are often taken in conjunction with the plan:
4.2.1 Primary design phase:
The framework is being planned at this time at the block level. The foundation for the blocks is the
examination carried out during the issuance recognisable proof stage. Accentuation is put on restricting
information flow across blocks while different blocks are made for diverse capabilities. This keeps all
movements that require greater cooperation together in a single block.
4.2.2 Secondary design phase:

 Every block's itemized plan is carried out during the optional stage.
 The common duties involved in the design process are: Create several building components for
the framework procedures in general.
 In each block, plan increasingly basic, minimal, and usable modules.
 Plan various information base structures.
 Identify subtleties of projects to achieve desired functionality. Plan the types of information
sources and system outcomes. Perform design documentation.
 Framework inspections
4.3 User Interface Design:
UI Design is worried about the exchange between a client and the computer. It is worried about all that
from beginning the framework or signing into the system to the in the long run show of wanted data
sources and results. The general stream of screens and messages are known as a discourse.Various
guidelines for UI design: Following are the various guidelines for user interface design:

 The framework client should always be aware of the next step.

 The screen should be set up such that various data, instructions, and messages typically
appear in an area with a shared general presentation.
 Messages, instructions, or data should be displayed for a long enough time for the
framework client to read them. Don't overuse show ascribes.
 The client-supplied fields and responses should have default values that are defined.
 A client shouldn't be permitted to proceed after correcting a mistake. Working framework
messages or fatal errors should never be sent to the framework client.

4.4 Preliminary Product Description:

The primer investigation to determine the viability of the framework is the most important stage
in the framework enhancement life cycle. The primer examination is being conducted to
determine the project requirements. It is merely a planning study and does not provide the variety
of information necessary to accurately portray the business structure in all respects. Instead, the
information collecting aids board members in evaluating the advantages of the task request and
making a reasoned decision on the viability of the proposed project.

4.4.1 Preliminary Investigation:

Analyst working on the preliminary investigation should accomplish the following objectives:
 Comprehend and explain the work request
 Establish the project's size.
 Analyse the costs and benefits of the various choice strategies.
  Analyse the functional and specialized plausibility of alternative approaches.
 Inform the executives of the findings and make recommendations for accepting or
rejecting the proposal.

4.4.2 Initial Cost:

The basic cost of establishing the framework will include the cost of hardware, software (OS,
add-on programming, utilities), and labour (arrangement and support). The association must
carry the equivalent.

4.4.3 Benefit to the organization:

The association can clearly acquire advantages, for example, reserve funds in operating costs,
decrease in administrative work, better usage of HR, and a more presentable picture of
expanding altruism.
4.4.4 Running cost:
Besides, the underlying expense the drawn-out cost will incorporate the running expense for the
system including the AMC, fixed charges, the cost for HR, and the cost for updating/recharging
different related software.
4.4.5 Need for training:
When the framework is put into place, the clients and the executive should be ready to ensure its
smooth operation. The preparation site will be supplied by the client. We discussed the current
framework, the requirements, and the expectations from the new proposed framework with the
administration personnel who were handling the financial issues of the center, the staff who were
maintaining the records in piles of registers, and the reporting director. Then, based on their
requirements and the additional components they required to include in this system, we
conducted a framework investigation of the complete framework.
Without this suggested structure, getting accurate, precise, and reliable information was seen as a
difficult endeavors. Since there was no record to keep track of them, the Meal On Wheel
completed all the exercises on time. The organization's project will be made easier by the new
framework I suggested and later implemented. The employees will be able to use it to create the
required reports, which will help them keep track of their progress and services. As a result, it
will make management tasks easier overall because this framework automates all the necessary
major tasks.
4.5 Implementation methodology:

The product configuration design known as Model View Controller, or MVC as it is more often
known, is used to create online applications. The following three sections make up a model view
controller design:
 Model: The lowest level of the example that is responsible for staying informed.
 View: This is in charge of providing the client with all or some of the information.
 Controller: The computer programmed that manages the relationships between the Model
and View.
 Chapter 5

5.1 Generation of Specifications

5.1.1 Synthesis and Breakdown of Requirements:

Detailed model of Requirements Flow down :
The components of the system architecture are given system-level requirements, and these
components then flow down to the components of subsystems. At every stage of the system
development, the appropriate test requirements are established. Other stakeholder requirements
are considered starting at the sub-system level, possibly because the subsystem components will
be used throughout a product line.
The system-level designers receive feedback from the designers working on the sub-system
components.To ensure that each requirement specification is addressed and to better understand
the flowdown of needs, we divide our system into several tiers of requirements. You'll see that
there are system-level needs that are quite similar to higher-level requirements before we look at
requirements at the sub-system and component levels. Later on in the project, we'll see how these
requirements are examined and validated at various levels before being integrated to test the
entire system.

Detailed model of Requirement Flow down

5.2 System Level Requirements
System-level needs are assigned to system architecture components, which then trickle down to
subsystem components. Each stage of the system development generates appropriate test
requirements.

 Restaurant will be open for 16 hours and will operate in four shifts as Morning (730 AM
-1130 AM), Afternoon (1130 AM -330 PM), Evening (330 PM - 730 PM) and Night (730
PM -1130 PM).
 System should be able to serve a throughput of 50, 125, 50, 75 customers per hour
during these four shifts respectively.
 Cooks, cleaners and assemblers will be the type of employees working the restaurant.
 Cook will be paid at the rate of $5 per hour for the duration of their work.
 Assemblers will be paid at the rate of $4.75 per hour for the duration of their work.
 Cleaner will be paid at the rate of $4.5 per hour for the duration of their work.
 Customer will leave without ordering if he sees 6 or more people in the line waiting to be
served thereby causing a loss in revenue.

5.3 Sub-system Level Requirements:

Starting at the sub-system level, other stakeholder requirements are taken into account, perhaps
because the subsystem elements will be used across a product line. Designers working on the
sub-system elements provide feedback to the system-level designers.
5.3.1 Ordering and Processing System
 The system will provide queue management by passing orders sequentially to kitchen
(FIFO) by assigning order numbers to them.
 Customer should be able to order item either by name or by number (for combo deals).
 System will support native and other commonly spoken language in the country.
 An average order takes about 1 minute to complete with a variance of 10 seconds.
 Customer takes 2 minutes on an average to complete and ordering process.
 System will be equipped with a standard QWERTY keyboard for taking inputs.
5.3.2 Payment System
 This Order number will be printed on the bill that customer receives.
 System shall be able to accept cash and coins.
 System should be able to accept debit / credit cards.
 System will accept only $1, 5, 10, 20 bills and nickel, dime, quarter denomination of
coins.
 System will reject pennies & $50, $100 bills.
 System won't allow putting in $1 coin.
 Cash return will return change only in coins (up to $5 maximum)

5.4 Component Level Requirements

5.4..1 Touch Screen

 Touch screen should be able to take inputs from users when they apply a light pressure (x lb)
from their fingers corresponding to an item.
 Touch screen should be able to withstand rough use i.e. it will be scratch proof (i.e., will be
resistant to nail scratching) and will not malfunction if a pressure of (x+5) lb is applied to the
screen.
 Touch screen will colored for visual appeal and will support at least 256 colors.
 Resolution of the screen will be at least 640X480 pixels.
 Touch screen will be at least 10 in size.
 Touch screen should be able to display at least 15 rows and 60 columns of text when the font
size of the text is 10.
5.4.2 Card Acceptor/Reader

 System will be equipped with a card reader with built it keypad (containing all digits and special
function keys corresponding to CANCEL, OK, # etc).
 This card reader should be able to read the card information if swiped at a speed > 1 m/s.
 Card reader will have a vertical slot on the right hand side of the keypad.
5.4.3 Display

 System will display all the menu items in icons/graphics format for selecting.
 System will prompt the user for mode of payment.
 Order will be transferred to the kitchen touch screen instantaneously once the user does the
payment.
 System will display the order sequentially on the kitchen screen with a forward and back button
at the bottom.
 Touching an order on the kitchen screen will prompt the system that the order has been delivered
and the screen will be rolled forward.
 Any error message during such a process will be reported to the user on the touch screen
informing him to take any further action.
  There will be a high contrast between the foreground and the background of the display for easy
reading capabilities.
 Throughout the ordering process all the text displayed on the screen will be either greater than 10
or less than 18 font size so that all users (young, adult, old) can read it.
5.4.4 Modem

 Modem should be able to complete a transaction (dialing, sending information, receiving

information) in 15 seconds or less at all times.
 Once connected to the bank system will supply the card information to the bank database, will
query the card validity and will supply the amount to be charged to the card.
5.4.5 Software

 System will be secured to grant access rights only to the system administrator. For this a login ID
and a password will be assigned which could be changed. Password won't be visible to onlookers
while typing for increased security.
 System will deny access to change the contents if the login/password both are incorrect by
providing an error message
 Chapter 6

6.1 System Modeling and Analysis:

6.1.1 System Behavior:

The behavior of a system is illustrated graphically by a model that incorporates the functional model,
inputs, and outputs. System behavior describes what a system does or appears to do. Two variations of
two distinct functional models are depicted in the pictures below. The Order System is our first model,
and the Payment Activity is our second model. When you view the 622 version of the Activities, you will
note that the 621 version is the most basic version of the model and that the majority of functions are not
very clearly described.
Figure . FFBD for Pay Bill (ENSE 622 version)
 Chapter 7

7.1 System Structure:

The model of system structure has evolved through two versions.
7.1.1 Preliminary System Structure (ENSE 621 version)
In the preliminary implementation (ENSE 621), the "automated ordering system" was partitioned into
elements for input, menu, payment, system administration and output.

Figure 14. System Structure (ENSE 621 Version).

Notice that the system structure does not include the environment within which the ordering system
works and also some of the objects that are considered at lower level are not objects of the system, instead
they are attributes.

7.1.2 Revised System Structure (ENSE 622 version)

Version two of the system structure has a larger scope. The highest-level of system structure, "fast food
system" is a composition of three systems -- staff, kitchen and automated food ordering system.

Figure 15. Revised System Structure (ENSE 622 version)

Attributes and functions are assigned to classes in the system hierarchy, as shown in Figure 15.
7.2 Fragments of Behavior for the System-Level Design
Sequence diagram provides a graphical representation for how a task is accomplished by passing a
sequence of messages among objects. These interactions define behavior as implemented by the
fragments of the system structure.
Our system can be divided into two different sequence diagram as shown below:
7.2.1 Sequence Diagrams for Placing an Order (ENSE 621 version)

Figure 17. Sequence of Messages for Placing an Order

As seen in the diagram the customer enters the system by clicking begin button and selects his language
choice. He then clicks on the menu button to see the menu items and then makes a selection. He then
confirms his order by clicking on the confirm order button.

7.2.2 Sequence Diagrams for Making the Payment (ENSE 621 version)
 Figure 18. Sequence of Message for Making the Payment
Customer has been prompted for the mode of payment. If he selects cash then he has to give cash to the
cash collector and receive change, if any. He also receives a receipt from the cash collector. If the
customer selects debit/credit card payment mode, he is asked again to select from debit or credit. If he
selects debit card then he is asked a pin number or else he is asked to slide the card. After checking for the
validity of the card the payment is made and the customer receives a receipt.
 Chapter 8

8.1 Verification Traceability Matrix

The abbreviated verification traceability matrix is: