Dedication

I Dedicate this modest work:

To my beloved Mother,
who is not only the reason for my existence but also the guiding light that
brightens my path, showering me with affection and love.

To my dearest father,
whose unwavering presence by my side, countless sacrifices, and
invaluable advice have shown me the way.

To my cherished Brother,
with whom I have shared and continue to share countless moments of joy
and happiness.

To my Teachers at Ecole Poly Technique Sousse,

who have imparted their knowledge and wisdom to me.

To all those who hold a special place in my heart, and to those who
deserve my heartfelt gratitude.

I express my sincerest appreciation to each and every one of you. Your

unwavering support and encouragement provide me with the strength to
persevere.

Yahya

i
Acknowledgements

Upon the completion of my work, I would like to express my gratitude to all those indi-
viduals whose invaluable assistance made this project possible.

First and foremost, I extend my heartfelt appreciation to Mr. Salah Gontara, my

academic supervisor, for his dedicated guidance throughout my project. his keen interest
in my work, insightful advice, and continuous support have been truly invaluable.

I am also indebted to Mr. Aymen Dimassi, my technical supervisor at SW Con-

sulting, for his exceptional supervision, warm reception, and professional collaboration
over the course of these months.

I extend my sincere thanks to the entire staff at SW Consulting, as well as the Ecole
Polytechnique Sousse team, for their unwavering support and contribution to my training.

Lastly, I would like to express my gratitude to the members of the jury for their
honorable evaluation of my project. I hope that this report reflects the qualities of clarity
and motivation that they seek.

ii
Contents

List of Figures vi

List of Tables viii

List of Acronyms ix

GENERAL INTRODUCTION 1

I General Presentation of the Project 3

I.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I.2 Company introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I.2.1 Technical data sheet . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I.2.2 Activity Sectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
I.2.3 SW Consulting organigram . . . . . . . . . . . . . . . . . . . . . . . 4
I.3 Project Presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I.3.1 Project context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I.3.2 Study of the current solution . . . . . . . . . . . . . . . . . . . . . . 5
I.3.3 Limits of the current situation . . . . . . . . . . . . . . . . . . . . . 5
I.3.4 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
I.4 Methodology of work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
I.5 AGILE Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
I.5.1 Why Scrum? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.6 Architectural conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.6.1 3-tier physical architecture . . . . . . . . . . . . . . . . . . . . . . 7
I.6.2 Logical MVC architecture . . . . . . . . . . . . . . . . . . . . . . . 8
I.7 Forecast organization chart . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
I.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

II Specification of requirements 11
II.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
II.2 Requirements Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . 12
II.2.1 Identification of the actors . . . . . . . . . . . . . . . . . . . . . . . 12
II.2.2 Functional Requirements Specifications . . . . . . . . . . . . . . . . 12
II.2.3 Non-Functional Requirements Specification . . . . . . . . . . . . . . 13
II.3 Project management with Scrum . . . . . . . . . . . . . . . . . . . . . . . 14
II.3.1 Team and role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
II.3.2 Scrum Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
II.4 The Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
II.5 Overall use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

iii
Contents Contents

II.6 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

II.7 Work environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
II.7.1 Software environment . . . . . . . . . . . . . . . . . . . . . . . . . . 18

III Sprint 1: Authentication, Manage accounts manager, View statistics 22

III.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
III.2 Sprint 1 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
III.3 Functional specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
III.3.1 Use case diagram for the «administrator» actor: . . . . . . . . . . . 23
III.3.2 Text description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
III.4 Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
III.4.1 “Authenticate” sequence diagram . . . . . . . . . . . . . . . . . . . 27
III.4.2 “Add Manager” Sequence Diagram . . . . . . . . . . . . . . . . . . 28
III.5 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
III.6 Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
III.6.1 Interface authenticate as Administrator . . . . . . . . . . . . . . . . 29
III.6.2 Interface "Dashboard" as Administrator . . . . . . . . . . . . . . . . 29
III.6.3 Interface "view statistics" as Administrator . . . . . . . . . . . . . . 30
III.6.4 Interface "Add manager" as Administrator . . . . . . . . . . . . . . 30
III.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

IV Sprint 2: Authentication, generate QR code, generate item 32

IV.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
IV.2 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
IV.3 Functional specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
IV.3.1 Use case diagram for the «Manager» actor: . . . . . . . . . . . . . . 34
IV.3.2 Use case diagram «authenticate» . . . . . . . . . . . . . . . . . . . 34
IV.3.3 Text descriptions of the Use Case diagrams . . . . . . . . . . . . . . 35
IV.4 Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
IV.4.1 “Add QR code ” sequence diagram . . . . . . . . . . . . . . . . . . 38
IV.4.2 “Delete menu items ” sequence diagram . . . . . . . . . . . . . . . 39
IV.5 Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
IV.5.1 Interface list of orders . . . . . . . . . . . . . . . . . . . . . . . . . 40
IV.5.2 Interface "Change order status " as manager . . . . . . . . . . . . . 40
IV.5.3 Interface "Add QR code " as Manager . . . . . . . . . . . . . . . . 41
IV.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

V Sprint 3: Create account, Scan QR code, make order 43

V.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
V.2 Sprint 3 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
V.3 Functional specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
V.3.1 Use case diagram for the «User» actor: . . . . . . . . . . . . . . . . 44
V.3.2 Use case diagram «authenticate» . . . . . . . . . . . . . . . . . . . 45
V.3.3 Text description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
V.4 Sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
V.4.1 “Authenticate ” sequence diagram . . . . . . . . . . . . . . . . . . 48
V.4.2 “Create account ” sequence diagram . . . . . . . . . . . . . . . . . 49
V.4.3 “Add Order ” sequence diagram . . . . . . . . . . . . . . . . . . . 50
V.5 Realization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

iv
Contents Contents

V.5.1 Interface authenticate as a USER . . . . . . . . . . . . . . . . . . . 51

V.5.2 Interface "Registration" as a USER . . . . . . . . . . . . . . . . . . 51
V.5.3 Interface "Welcome" as a USER . . . . . . . . . . . . . . . . . . . . 52
V.5.4 Interface "Order informations " as a USER . . . . . . . . . . . . . . 52
V.5.5 Interface "Payment online " as a USER . . . . . . . . . . . . . . . . 53
V.5.6 Interface "list of menu " as a USER . . . . . . . . . . . . . . . . . . 53
V.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

GENERAL CONCLUSION 55

PERSPECTIVES 57

Bibliography 58

v
List of Figures

I.1 SW Consulting organigram . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

I.2 Scrum process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
I.3 3-tier physical architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
I.4 Logical MVC architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
I.5 GANTT diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

II.1 Identification of the actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

II.2 Overall use case diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
II.3 Class diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
II.4 Node.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
II.5 React.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
II.6 Docker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
II.7 Stripe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
II.8 Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
II.9 Visual Studio Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
II.10 Git . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
II.11 Postman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
II.12 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
II.13 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
II.14 Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

III.1 Use case diagram for the «administrator» . . . . . . . . . . . . . . . . . . . 23

III.2 Use case diagram “manage manager” . . . . . . . . . . . . . . . . . . . . . 25
III.3 “Authenticate” sequence diagram . . . . . . . . . . . . . . . . . . . . . . . 27
III.4 “Add Manager” Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . 28
III.5 Interface "authenticate" as Administrator . . . . . . . . . . . . . . . . . . . 29
III.6 Interface "Dashboard" as Administrator . . . . . . . . . . . . . . . . . . . . 30
III.7 Interface "view statistics" . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
III.8 Interface "Add manager" as Administrator . . . . . . . . . . . . . . . . . . 31

IV.1 Use case diagram for the «Manager» actor: . . . . . . . . . . . . . . . . . . 34

IV.2 Use case «authenticate» for the«Manager» actor . . . . . . . . . . . . . . 34
IV.3 Use case diagram “Generate QR code ” . . . . . . . . . . . . . . . . . . . . 35
IV.4 Use case diagram “Generate items ” . . . . . . . . . . . . . . . . . . . . . . 36
IV.5 “Add QR code ” sequence diagram . . . . . . . . . . . . . . . . . . . . . . 38
IV.6 “Delete menu items” sequence diagram . . . . . . . . . . . . . . . . . . . . 39
IV.7 Interface list of orders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
IV.8 Interface "Change order status " as manager . . . . . . . . . . . . . . . . . 41
IV.9 Interface "Add QR code " as Manager . . . . . . . . . . . . . . . . . . . . . 41

vi
List of Figures List of Figures

V.1 Use case diagram for the «User» actor: . . . . . . . . . . . . . . . . . . . . 45

V.2 Use case «authenticate» for the«User» actor . . . . . . . . . . . . . . . . . 45
V.3 Use case diagram “View menu ” . . . . . . . . . . . . . . . . . . . . . . . . 46
V.4 “Authenticate ” sequence diagram . . . . . . . . . . . . . . . . . . . . . . . 48
V.5 “Create account ” sequence diagram . . . . . . . . . . . . . . . . . . . . . . 49
V.6 “Add Order ” sequence diagram . . . . . . . . . . . . . . . . . . . . . . . . 50
V.7 Interface "authenticate" as a USER . . . . . . . . . . . . . . . . . . . . . . 51
V.8 Interface "Registration" as a USER . . . . . . . . . . . . . . . . . . . . . . 51
V.9 Interface "Registration" as a USER . . . . . . . . . . . . . . . . . . . . . . 52
V.10 Interface "Order informations " as a USER . . . . . . . . . . . . . . . . . . 52
V.11 Interface "Payment online " as a USER . . . . . . . . . . . . . . . . . . . . 53
V.12 Interface "list of menu " as a USER . . . . . . . . . . . . . . . . . . . . . . 54

vii
List of Tables

II.1 Non-Functional Requirements Specifications . . . . . . . . . . . . . . . . . 14

II.2 Product Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

III.1 Sprint 1 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

III.2 Textual Description of the Use Case "Authenticate" . . . . . . . . . . . . . 24
III.3 Textual Description of the Use Case "Manage Managers" . . . . . . . . . . 25
III.4 Textual Description of the Use Case "View Statistics" . . . . . . . . . . . . 26

IV.1 Sprint 2 Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

IV.2 Textual Description of the Use Case "Authenticate" . . . . . . . . . . . . . 35
IV.3 Textual Description of «Add / Delete QR cod» . . . . . . . . . . . . . . . 36
IV.4 Text description of the “Generate item” use case . . . . . . . . . . . . . . . 37

V.1 Textual Description of the Use Case "Authenticate" . . . . . . . . . . . . . 46

V.2 Textual description of the use case "View menu" . . . . . . . . . . . . . . 47
V.3 Textual description of the use case "Scan QR code" as a manager . . . . . 47

viii
Acronyms

• RPM : restaurant management platform

ix
GENERAL INTRODUCTION

In the realm of dining establishments, the landscape is dynamic and fiercely competitive.
Modern restaurants must do more than merely adopt the latest culinary trends; they must
navigate intricate operational challenges to thrive. Efficiency, quality, and profitability
are paramount in this landscape, necessitating a nuanced understanding of restaurant
operations and a keen insight into critical processes.

Enter the Restaurant Management Platform, a digital solution poised to revolutionize

the way restaurants operate. This platform, often abbreviated as RMP, serves as the
cornerstone for streamlining operations, enhancing customer experiences, and maximizing
profits. By digitizing key facets of restaurant management, such as menu customization,
order processing, and payment handling, RMP empowers restaurant owners and managers
to optimize efficiency and elevate service quality.

At the heart of the RMP lies a suite of features designed to simplify and automate
various aspects of restaurant management. From menu creation and inventory tracking
to table allocation and staff scheduling, every facet of restaurant operations is metic-
ulously addressed. Real-time analytics further bolster decision-making capabilities, en-
abling restaurant stakeholders to make informed choices that drive business growth.

In the context of this endeavor, our end-of-studies project embarks on a journey to

enhance the capabilities of the Restaurant Management Platform. This project, conducted
as part of an internship at [Restaurant Management Platform Company], seeks to refine
and expand the functionalities of the platform to align with the demands of the modern
restaurant industry.

1
GENERAL INTRODUCTION

Aligned with the principles of Agile methodology, particularly the Scrum framework,
this project unfolds across multiple chapters. Each chapter delves into a distinct aspect
of the project, from the analysis phase and technology stack selection to sprint planning
and module development. Through a systematic approach guided by Agile principles, we
aim to deliver a robust and user-centric Restaurant Management Platform tailored to the
needs of today’s restaurateurs

In the subsequent chapters, we will embark on a detailed exploration of each sprint,

focusing on the development and integration of essential modules such as menu customiza-
tion, order management, and customer feedback. By leveraging the power of digital
technology and strategic planning, we endeavor to propel the Restaurant Management
Platform towards greater efficiency, profitability, and sustainability in the ever-evolving
restaurant landscape.

2
Chapter I

General Presentation of the Project

3
General Presentation of the Project

I.1 Introduction
The aim of this chapter is to put the project in its general framework, namely the
welcoming company. Subsequently, we will continue to study the existing by specifying
these limits and then we will propose the appropriate solution to deal with these limits.
Finally, we will present the used development methodology.

I.2 Company introduction

SW CONSULTING is a leading Tunisian IT service provider, renowned for its four years
of expertise. With a team of 12 developers, they excel in web and mobile app development,
CRM implementation, and SEO optimization. Serving mainly European clients, they
prioritize tailored solutions and transparent billing practices, setting a benchmark for
excellence in the industry

I.2.1 Technical data sheet

Website : www.swconsultings.com

I.2.2 Activity Sectors

• Information Technology (IT)

• Digital Marketing and SEO

• Consulting Services

I.2.3 SW Consulting organigram

Figure I.1: SW Consulting organigram

Page 4
General Presentation of the Project

I.3 Project Presentation

I.3.1 Project context
The project encompasses the development of a web application aimed at revolutioniz-
ing restaurant management. Originating as a final year academic endeavor (PFE), this
technological venture is rapidly expanding. The application introduces QR code menus
to streamline the dining experience, offering enhanced menu management, ordering, and
payment functionalities. Its core features include the digitization of dining experiences,
tracking user behavior for continuous improvement, simplifying order management to fa-
cilitate better table turnover, and providing a feedback mechanism for instant user input.
Moreover, it empowers managers with comprehensive control over staff, enabling efficient
supervision and dish delivery coordination for optimal operational management within
the restaurant. Overall, the project’s objective is to deliver a mobile application that not
only simplifies customer ordering but also optimizes internal workflows, thereby enhancing
the overall efficiency and profitability of restaurant operations.

I.3.2 Study of the current solution

Currently, restaurant management largely relies on traditional methods, such as phys-
ical menus and manual order-taking processes. This approach is often time-consuming
and prone to errors, leading to inefficiencies in both customer service and internal oper-
ations. Moreover, the absence of real-time data tracking limits the restaurant’s ability
to understand customer preferences and tailor offerings accordingly. In this context, the
proposed mobile application presents a disruptive solution by leveraging QR code menus
and digital ordering capabilities to streamline operations and enhance the dining expe-
rience. By digitizing menu management and implementing user behavior tracking, the
application aims to provide valuable insights for continuous improvement while offering
customers a more convenient and personalized dining experience.

I.3.3 Limits of the current situation

Despite the widespread adoption of technology in various industries, many restaurants
still lag behind in terms of digitalization. The reliance on traditional methods not only
hampers operational efficiency but also inhibits the ability to adapt to changing consumer
preferences and market dynamics. Manual order-taking processes are prone to errors and
delays, leading to customer dissatisfaction and lost revenue opportunities. Additionally,
the lack of real-time data tracking limits the restaurant’s ability to optimize menu offerings
and pricing strategies, resulting in missed opportunities for revenue growth. Moreover,
the absence of a feedback mechanism makes it challenging for restaurants to gather ac-
tionable insights for improvement. In this regard, the current situation highlights the
need for innovative solutions, such as the proposed mobile application, to address these
limitations and drive the industry towards a more efficient and customer-centric approach
to restaurant management.

I.3.4 Proposed Solution

Our proposed solution is an innovative restaurant management platform designed to trans-
form both operational efficiency and customer experience in the restaurant industry. This

Page 5
General Presentation of the Project

platform features a user-friendly interface that allows customers to place orders seamlessly
through QR menus, complete with advanced filtering options for maximum customization.

• User-Friendly Interface:

• QR Menu Ordering:
Customers can easily access the menu and place orders by scanning QR codes at
their tables.

• Advanced Filtering Options:

Customers can customize their orders based on dietary preferences, ingredients, and
other criteria.

• Secure Payment System:

Provides a seamless and secure payment process directly through the platform,
ensuring customer convenience and data security.

• Feedback Mechanism:
Enables customers to provide feedback on their dining experience, facilitating con-
tinuous improvement and enhanced customer satisfaction.

• Flow Control of Dishes and Meals:

Enhances operational management by allowing managers to control the preparation
and delivery process of dishes, ensuring timely service and high food quality.

The innovative restaurant management platform is designed to revolutionize the dining

experience for both customers and managers. With its comprehensive features and agile
development process, it addresses critical operational challenges and elevates customer
satisfaction, setting a new standard in the restaurant industry.
The platform was developed using an agile methodology, which allowed for contin-
uous adaptation to market needs and fostered effective collaboration within the project
team. This approach ensured that the platform remains responsive to changing customer
demands and industry trends.

I.4 Methodology of work

We have employed an agile project methodology to optimize the functionality of our
information management system and to satisfy customer demands in a time and cost-
effective manner.

I.5 AGILE Methodology

An agile method is an iterative and incremental approach, which is conducted in a col-
laborative spirit.
Agile development methods include:

• Dynamics System Développement Méthode (DSDM, 1995)

Page 6
General Presentation of the Project

• Scrum (1996)
• Rapid Application Développent (RAD, 1991)
• Adaptive Software Développement (ASD, 2000)
• Test Drivent Développement (TDD, 2002)
• Crystal Clédar(2004)

I.5.1 Why Scrum?

We have chosen to use the Scrum agile method for the design and development of our
system within the parameters of our project for very specific reasons, ensuring the seamless
execution of the project’s various phases.Actually, the Scrum process—which is predicated
on the following benefits—is ideally suited to the breakdown of our end-of-study project.
• More flexibility and reactivity.
• Great capacity to adapt to change thanks to short iterations.
• To satisfy the customer’s needs as best as possible.
• Scrum: Is an agile methodology that consists of having a close-knit team guiding the
project as it proceeds progress in order to reach a goal. This approach is both dynamic and
productive, it generates the realization of the functionalities by iteration the participation
of the customer. Each iteration can last from two to four weeks, at the end of each sprint
a at the end of each sprint a functional product must be delivered.

Figure I.2: Scrum process

I.6 Architectural conception

In this section, we will present the architectural and logical architecture of our project.

I.6.1 3-tier physical architecture

The 3-tier architecture is a logical model of application architecture that aims to clearly
separate three software layers within a single application or system, to model and present
this system, to model and present this application as a stack of three layers, stages or
levels whose role is clearly defined:

Page 7
General Presentation of the Project

• Client part: consists in the realization of the various interfaces of the application
and their display.

• Server part: it allows the insertion, the consultation of data and the update of
the client application.

• Client-server: interconnection part: allows to match the interaction between the

different participants of the application and ensures the communication between
them.

Figure I.3: 3-tier physical architecture

I.6.2 Logical MVC architecture

We have decided to implement the MVC architecture (model, view, and controller) in the
development of our application. The division of data (model), display (view), and actions
(controller) is its primary area of interest.

• Model:
This is a collection of operations and interactions with the database that illustrates
how the application behaves. It contains all of the access methods and classes that
explain the data that the application manipulates.

• View:
This describes the user interface that the user works with. Although there is no
presentation in the returned results, the views do support the findings. The infor-
mation of a single model can be shown in multiple views. The view only shows the
outcomes of the processing carried out by the model, doing no additional processing,
giving the user

• Controller:
Managing synchronization events to update the model or view is the responsibility
of the controller. It examines the client’s request, makes no modifications to any
data, and just makes the necessary calls.
model and gives the request’s corresponding view back.

Page 8
General Presentation of the Project

Figure I.4: Logical MVC architecture

I.7 Forecast organization chart

The goal of planning is to divide the work and identify the tasks that need to be completed.
It also ensures that the final date of our work completion is approximated and provides a
clear estimate with good time management for each of the component tasks.

Figure I.5: GANTT diagram

I.8 Conclusion
In conclusion, the development of the innovative restaurant management platform rep-
resents a significant step forward in addressing the challenges faced by the restaurant
industry. By leveraging technology to streamline operations and enhance customer expe-
rience, the platform offers a modern solution that prioritizes efficiency, convenience, and
customization. Through features such as QR menu ordering, advanced filtering options,
secure payment systems, and feedback mechanisms, the platform not only improves op-
erational efficiency but also fosters continuous improvement and customer satisfaction.
Furthermore, the agile development methodology ensures adaptability to evolving market

Page 9
General Presentation of the Project

needs and effective collaboration within the project team. Overall, this project marks
a milestone in the evolution of restaurant management, providing a blueprint for fu-
ture technological solutions that aim to transform the industry towards a more efficient,
customer-centric, and digitally-driven landscape.

Page 10
Chapter II

Specification of requirements

11
Specification of requirements

II.1 Introduction
In the previous chapter, we chose to adopt Scrum as the working methodology for our
program. In fact, the first phase is preparing the plan and the architecture. This step is
the most important one in the Scrum development cycle since it directly influences the
success of the sprints. The work done in this period of time leads to build a good vision,
identify the users’ roles and define the main features in order to produce the initial backlog
and an initial sprint. In addition, we will define the tools chosen for the realization of
the application. At this level, we specify the context of our application. We identify
the working platforms, the technologies used and the different application components
developed

II.2 Requirements Specifications

Capturing the needs is an essential step in the development cycle of a product or service
of a product or a service. This specification phase is the translation of user needs into
into conceptual and technical documentation

II.2.1 Identification of the actors

Figure II.1: Identification of the actors

II.2.2 Functional Requirements Specifications

Interface Client

• Prior Authentication: Users log in with their personal credentials before access-
ing the client interface for a personalized and secure experience.

• QR Code Scanning and Dynamic Menu Viewing: Clients activate the ap-
plication by scanning the QR code at the restaurant entrance. They interactively
view the menu, with an AI chatbot providing recommendations.

• Order Placement with Advanced Features and Detailed Filtering: Users

select dishes and beverages, adding specific details (preferences, modifications). A
dedicated button requests assistance, with notification including the table number.

Page 12
Specification of requirements

• Payment Interface with Advanced Options: Selected items and total are dis-
played. Users choose the payment method (cash, credit card, online).

Interface Admin

• Required Authentication: Admin log in with personal credentials to access the

dashboard and perform control functions.

• Dashboard Access and Control Functions: Admin have access to a comprehen-

sive dashboard displaying statistics, performance metrics, and manager management
options.

• View statistics: Admin can see reports and analytics

• Manage accounts manager :adding new manager accounts, updating existing

account information, assigning roles and permissions, and deactivating or removing
manager accounts as needed. It empowers administrators to efficiently manage
the managerial team, ensuring smooth operations and adherence to organizational
policies.

Interface Manager

• Required Authentication: Manager log in with personal credentials to receive

and process orders.

• Order Reception and Processing: The manager receives orders on his interface,
processes payments, and manages table assignments. He has access to order details,
payment options, and table status updates. Additionally, the manager can add QR
codes to each table, enhancing the dining experience by allowing customers to place
orders and make payments directly from their devices.

• Generate Qr code :As manager,adding new QR code or deleted.

These are the functionalities of the system. These are the requirements specifying the
input/output behavior of the system. The functional requirements of the application are
represented as follows in the table

II.2.3 Non-Functional Requirements Specification

Once the functional requirements are well defined, the non-functional requirements must
be taken into account be taken into account throughout the development process of the
application:

• Performance: The response time must be as short as possible and the application
must be always functional

• Usability: We need simple, uncluttered, responsive interfaces, understandable and

representative from a design point of view.

• Security: Ensure the level of reliability of the software through authenticated access
by entering a login and password

Page 13
Specification of requirements

• Maintenance: The application code must be readable and understandable to

ensure its scalable and extensible state

• Adaptability: Is defined as the ability of a software system to adapt to a change

in an change in an environment without modifying its behavior.

Table II.1: Non-Functional Requirements Specifications

Requirement Description
Required Authentication Cashiers log in with personal credentials to
receive and process orders.
Order Reception and Processing Cashiers receive orders on their interface,
process payments, and manage table assign-
ments. They have access to order details,
payment options, and table status updates.
The Product The system should be compatible with the
latest operating systems and hardware con-
figurations. It should provide seamless in-
tegration with third-party software and ser-
vices.

II.3 Project management with Scrum

Scrum is an Agile framework used to develop, deliver, and maintain complex products. It
is based on short development cycles called Sprints, typically lasting two to four weeks.
Each Sprint produces a potentially shippable product increment.

II.3.1 Team and role

In Scrum, there are three main roles:

• Product Owner:
Responsible for maximizing the value of the product resulting from the work of the
development team. Manages the product backlog by prioritizing features, enhance-
ments, and bug fixes based on stakeholder needs and the product vision.

• Scrum Master:
Acts as a facilitator for the Scrum team. Ensures that the team follows Scrum
practices and values. Helps resolve obstacles that may prevent the team from pro-
gressing. Facilitates Scrum events such as Sprint planning meetings, daily stand-ups,
Sprint reviews, and retrospectives.

• Development Team:
Composed of professionals who work together to deliver product increments. Self-
organizing and cross-functional, including developers, testers, designers, and other
technical experts. Responsible for self-organizing and completing the work needed
to achieve the Sprint goals.

Page 14
Specification of requirements

II.3.2 Scrum Events

1. Sprint Planning: A meeting at the beginning of each Sprint to plan the work to
be done. The team decides which product backlog items to include in the Sprint
and creates a plan to deliver them.

2. Daily Stand-up (Daily Scrum):

A short (15-minute) meeting each day where the team discusses what was done the
previous day, what will be done today, and any potential obstacles.

3. Sprint Review:
A meeting at the end of each Sprint where the team presents what has been accom-
plished during the Sprint to stakeholders and gathers feedback.

4. Sprint Retrospective:
A meeting at the end of each Sprint to reflect on the team’s process and identify
improvements for the next Sprint.

II.4 The Product Backlog

The Product Backlog is a dynamic and prioritized list of all the features, functionalities,
enhancements, and fixes required for the product. It serves as the single source of require-
ments for any changes to be made to the product. Managed by the Product Owner, the
backlog is continuously updated based on stakeholder feedback, market conditions, and
team insights.

ID Role Description Priority Acceptance Criteria

1 Admin Create manager account High Manager accounts can be created
Admin can view, edit, and delete ac-
2 Admin Manage accounts Medium
counts
3 Admin Visualize data Medium Admin can see reports and analytics
Manager can add and update menu
4 Manager Add/update menu items High
items
5 Manager View orders High Manager can see all incoming orders
Manager can update the status of or-
6 Manager Change order status High
ders
Manager can view table layouts and
7 Manager Visualize tables Medium
statuses
Manager can create and manage
8 Manager Create voucher codes Medium
voucher codes
Users can scan QR codes to access the
9 User Scan QR code High
menu
Users can view the menu after scanning
10 User View menu High
the QR code
11 User Login High Users can log in to their account

Page 15
Specification of requirements

ID Role Description Priority Acceptance Criteria

12 User Make order High Users can place orders
13 User Choose items High Users can select items from the menu
Users can add notes or special instruc-
14 User Add order information Medium
tions to their orders
15 User Online payment High Users can pay for their orders online
Users are notified when their food is
16 User Wait for food Medium
ready

Table II.2: Product Backlog

II.5 Overall use case diagram

Figure II.2: Overall use case diagram

Page 16
Specification of requirements

II.6 Class diagram

A class diagram shown in figure II.6 is a visual way of describing the internal configuration
of a system. This static representation highlights the classes and their interrelations, such
as illustrated in the diagram

Figure II.3: Class diagram

Page 17
Specification of requirements

II.7 Work environment

II.7.1 Software environment
The application is developed using a modern and efficient software stack to ensure
robustness and flexibility. The key components of the software environment include:

• Backend Framework: Node.js with Express.js is utilized as the backend frame-

work. Express.js provides a minimal and flexible framework for building web appli-
cations and APIs, making it well-suited for RESTful services. Express.js simplifies
the process of handling HTTP requests, routing, and middleware integration, en-
abling rapid development of backend services[2].

Figure II.4: Node.js

• Frontend Framework: React.js is chosen as the frontend framework for this

project. It provides a component-based architecture, facilitating the development
of dynamic and interactive user interfaces. React.js is widely adopted for its perfor-
mance optimizations, virtual DOM implementation, and strong community support
[1].

Figure II.5: React.js

• Containerization: Docker is employed for containerization, providing a consistent

environment for development, testing, and deployment. Docker containers encapsu-
late the application and its dependencies, ensuring portability and scalability across
different environments. Docker simplifies the process of managing dependencies,
scaling applications, and ensuring consistency between development and produc-
tion environments [3].

Page 18
Specification of requirements

Figure II.6: Docker

• Payment Integration: Stripe is integrated into the application for payment pro-
cessing. It enables secure and seamless payment transactions, allowing users to
make payments using credit cards or other supported payment methods. Stripe’s
robust API, developer-friendly documentation, and support for various currencies
and payment methods make it a popular choice for handling online payments[4].

Figure II.7: Stripe

• Operating System: The development environment primarily operates on Win-

dows 10, providing a stable and widely compatible platform for software develop-
ment. Windows 10 offers a user-friendly interface and extensive hardware support,
making it suitable for a wide range of development tasks [5].

Figure II.8: Operating System

• Code Editor: Visual Studio Code (VS Code) is the primary code editor used for
this project. It offers a rich set of features, including syntax highlighting, code
completion, and debugging capabilities, making it an ideal choice for efficient devel-
opment. VS Code also supports a wide range of extensions, allowing developers to
customize their development environment according to their needs [6].

Page 19
Specification of requirements

Figure II.9: Visual Studio Code

• Version Control: Git is utilized for version control, enabling collaborative devel-
opment and allowing developers to track changes, manage branches, and coordinate
work effectively. Git provides robust branching and merging capabilities, facilitating
parallel development and code collaboration among team members[7].

Figure II.10: Git

• API Testing: Postman is utilized for API testing, allowing developers to test
API endpoints and ensure they function as expected. It provides a user-friendly
interface for sending requests, inspecting responses, and debugging API interactions.
Postman’s collection feature enables the organization and sharing of API requests,
facilitating collaboration among team members and stakeholders[8].

Figure II.11: Postman

• Database: MongoDB is chosen as the database solution for this project, offering a
flexible and scalable NoSQL database. It stores data in JSON-like documents, pro-
viding flexibility in schema design and scalability for large-scale applications. Mon-
goDB’s document-oriented nature and support for sharding and replication make it
suitable for handling diverse data types and high volumes of data [9].

Page 20
Specification of requirements

Figure II.12: MongoDB

• Deployment: Microsoft Azure is utilized for deployment, offering a scalable and

reliable cloud platform for hosting the application. Azure Container Registry (ACR)
and Azure Kubernetes Service (AKS) may be utilized for container orchestration and
management, ensuring high availability and scalability of the deployed application.
Azure’s global network of data centers, robust security features, and integration with
other Azure services make it a preferred choice for cloud hosting and deployment[10].

Figure II.13: Deployment

• Web Browsers: Microsoft Edge is used for web browser testing. Testing in Edge
ensures that the application works seamlessly in this widely used browser, providing
a consistent user experience. Edge’s developer tools assist in debugging, profiling,
and optimizing the web application, helping to identify and resolve issues related to
layout, rendering, and performance[?].

Figure II.14: Web Browsers

Page 21
Chapter III

Sprint 1: Authentication, Manage

accounts manager, View statistics

22
Sprint 1: Authentication, Manage accounts manager, View statistics

III.1 Introduction
This chapter consists in studying the first sprint focused on authentication, manager
management and client management. We will explore the functional specification,
the design and finally, we will begin the implementation by presenting some inter-
faces linked to this sprint.

III.2 Sprint 1 Backlog

Below we present the organization of the first sprint:
All tasks identified by the Scrum Team in Table below must be delivered at the end
of Sprint 1.

Sprint Feature User stories Priority

As an administrator, I want to authenticate
my identity when accessing the restaurant
1 Authenticate management platform so that I can securely 1
manage operational activities and
ensure efficient restaurant management.
Manage accounts As an Administrator, I would like add,modify
1 1
manager and delete account manager
As an administrator, I want to view real-time
1 Viewing statistics statistics so that I can monitor restaurant 1
performance and make informed decisions.

Table III.1: Sprint 1 Backlog

III.3 Functional specification

III.3.1 Use case diagram for the «administrator» actor:

Figure III.1: Use case diagram for the «administrator»

Page 23
Sprint 1: Authentication, Manage accounts manager, View statistics

The «administrator» actor represents the user with administrative privileges who
can perform a range of management functions. The use case diagram will show the
administrator’s interactions with different use cases within the system.

III.3.2 Text description

1 Text description of the “Authenticate” use case

Use Case Authenticate

Actors Admin
Precondition Already registered and logged in
Postcondition Authentication validated and successful access
1. The system displays the login page
2. The actor enters their login and password.
3. The actor clicks the "login" button
4. The system verifies the validity of the provided information, if
Nominal Scenario
the information is incorrect then trigger exception "E1".
5. The default system assigns the role "user"
6. The system grants access to the actor and displays
the appropriate page according to their role.
E1: Login and/or password are incorrect.
The sequence starts at point 3.
Exception The system displays an error message
informing the user that their login
or password is incorrect and the scenario resumes at action 1.

Table III.2: Textual Description of the Use Case "Authenticate"

Page 24
Sprint 1: Authentication, Manage accounts manager, View statistics

2.Use case diagram “manage manager”

Figure III.2: Use case diagram “manage manager”

3.Text description of the “manage manager” use case

Use Case Manage Managers

Actors
- Admin
Precondition Authenticated actors
Postcondition Manager successfully added
1. The system displays the list of registered managers.
2. The Admin clicks on a manager.
3. The system displays all manager information.
Nominal Scenario 4. The Admin clicks on the "add" button.
5. The system displays the manager addition form.
6. The Admin enters the information and validates the addition.
7. The system verifies the validity of the fields, if a field is empty then "E1".
1. The system displays the list of managers.
2. The Admin clicks on the "delete" button.
Alternative Scenario
3. The system displays a deletion confirmation dialog box, if the Admin
Delete
clicks no then "E2".
4. The Admin confirms the deletion.
1. The system displays the list of managers.
2. The Admin selects a manager and modifies their role.
Alternative Scenario
3. The system verifies the authorization right, if the Admin
Modify State
. has no right then "E3".
4. The system modifies the manager’s state.
E1: empty fields. The system displays an error message.
Exception E2: deletion not completed.
E3: manager state not modified.

Table III.3: Textual Description of the Use Case "Manage Managers"

Page 25
Sprint 1: Authentication, Manage accounts manager, View statistics

Use Case View Statistics

Actor Administrator
– The administrator is authenticated.
Precondition – Statistical data is available in the database.

Post condition – Statistics are successfully displayed.

– The administrator opens the dashboard interface.

– The system displays the dashboard interface.
– The administrator clicks on the "View Statistics"
button.
Main Scenario
Description – The system retrieves the relevant statistical data.
– The system displays the statistics in a graphical
format.
– The administrator reviews the displayed statistics.

– Filter Statistics:
∗ The administrator selects a filter option (e.g.,
date range, category).
Alternative Sce-
narios ∗ The system retrieves the filtered data.
∗ The system updates the displayed statistics ac-
cordingly.

– E1: Data retrieval error. The system displays

Exception an error message and prompts the administrator to
retry.

Table III.4: Textual Description of the Use Case "View Statistics"

III.4 Sequence diagram

A sequence diagram is a type of interaction diagram in Unified Modeling Language
(UML) that visually represents the sequence of messages or actions exchanged be-
tween different components or actors within a system over time. It highlights the
flow of interactions, showing how processes operate and interact, making it useful
for understanding the dynamic behavior of a system.

Page 26
Sprint 1: Authentication, Manage accounts manager, View statistics

III.4.1 “Authenticate” sequence diagram

This diagram presents the different possible authentication scenarios.shown in figure
IV.5 To access the system, the administrator must first identify himself using his
login and password. pass. The controller is responsible for verifying this information
and consults the database for this purpose. If accepted, the user is authorized to
access to the system. Otherwise, an error message is displayed, prompting the user
to correct their data. Once the data has been rectified, the user can log in by
generating an access token and is redirected to their personal space.

Figure III.3: “Authenticate” sequence diagram

Page 27
Sprint 1: Authentication, Manage accounts manager, View statistics

III.4.2 “Add Manager” Sequence Diagram

The figure shown in figure III.4 makes it easier for the administrator to manage
managers by enabling the creation of new manager account by capturing the nec-
essary data. This use case ensures that new manager can seamlessly integrate into
the system while maintaining data coherence and security.

Figure III.4: “Add Manager” Sequence Diagram

Page 28
Sprint 1: Authentication, Manage accounts manager, View statistics

III.5 Class diagram

The class diagram is a main element of software design, it is a model representing
the structure of the system to be designed. The class diagram is a diagram used to
present classes and different relationships. This diagram belongs to the static part
of UML.

III.6 Realization

III.6.1 Interface authenticate as Administrator

The "Interface authenticate as Administrator" shown in figure III.5represents the
user interface through which an individual can authenticate themselves specifically
as an administrator within the system. This interface typically prompts the user
to provide the necessary credentials or undergo the required authentication process
to verify their administrative privileges before granting access to administrative
functionalities.

Figure III.5: Interface "authenticate" as Administrator

III.6.2 Interface "Dashboard" as Administrator

Interface "Dashboard": As an Administrator,shown in figure III.6 the dashboard
provides a comprehensive overview of system statistics, user activities, and key
performance metrics in a graphical format.

Page 29
Sprint 1: Authentication, Manage accounts manager, View statistics

Figure III.6: Interface "Dashboard" as Administrator

III.6.3 Interface "view statistics" as Administrator

The "Interface view statistics as Administrator", shown in figure III.7represents the
user interface specifically designed for administrators to access statistical data or
analytics within the system. This interface provides administrators with insights
into various metrics, performance indicators, or data trends relevant to the system’s
operation or user activity. It allows administrators to make informed decisions based
on the presented statistical information.

Figure III.7: Interface "view statistics"

III.6.4 Interface "Add manager" as Administrator

The "Interface Add manager as Administrator",shown in figure III.8 depicts the user
interface designed for administrators to add new managers to the system. This in-
terface typically includes input fields for relevant manager details such as name, con-
tact information, and role assignment. It provides administrators with a form-based
method to input and submit new manager information, facilitating the expansion
of the managerial hierarchy within the system.

Page 30
Sprint 1: Authentication, Manage accounts manager, View statistics

Figure III.8: Interface "Add manager" as Administrator

III.7 Conclusion
In this Sprint, we presented the design and implementation of image management,
stock reception and messages. After several iterations, the Sprint was validated by
the SCRUM Master with all users. We will now move on to the next chapter which
is devoted to Sprint 2.

Page 31
Chapter IV

Sprint 2: Authentication, generate

QR code, generate item

32
Sprint 2: Authentication, generate QR code, generate item

IV.1 Introduction
This chapter consists of studying the secand sprint focused on authentication, man-
age QR code , manage items. We will explore the functional specification, the design
and finally, we will begin the implementation by presenting some interfaces linked
to this sprint.

IV.2 Sprint 2 Backlog

The second sprint’s organizational structure is shown below:
By the end of Sprint 2, all tasks listed in the table below, which was created by the
Scrum Team, have to be completed.

Sprint Feature User stories Priority

As a manager, I want to authenticate
my identity when accessing the restaurant
2 Authenticate management platform so that I can securely 2
manage operational activities and
ensure efficient restaurant management.
2 Generate QR code As manager, I would like add,modify QR code 2
2 add/update menu items As manager, I would like add,modify menu items 2
As manager , I want to view real-time
2 View orders 2
orders so that I can monitor restaurant.
2 Visualize tables As manager , I want to view tables . 2
As manager ,i want to changes the
command status in the command system.
2 Change order status 2
The possible statuses include “Attend”,
“Preparation”, “Prête”, “Livrée”, “Annulée”.

Table IV.1: Sprint 2 Backlog

IV.3 Functional specification

Use case diagrams are UML diagrams that provide an overview of a software system’s
functional behavior. an overview of a software system’s functional behavior. The
description of a series of steps a system takes to give an actor an observable result
is called a use case.

Page 33
Sprint 2: Authentication, generate QR code, generate item

IV.3.1 Use case diagram for the «Manager» actor:

The «Manager» actor shown in figure IV.1 represents the user with administrative
privileges who can perform a range of management functions. The use case diagram
will show the manager’s interactions with different use cases within the system.

Figure IV.1: Use case diagram for the «Manager» actor:

IV.3.2 Use case diagram «authenticate»

The «authenticate» use case shown in figure V.2 represents the process of verifying
the identity of a user attempting to access the system. It involves authentication
mechanisms such as username/password authentication.

Figure IV.2: Use case «authenticate» for the«Manager» actor

Page 34
Sprint 2: Authentication, generate QR code, generate item

IV.3.3 Text descriptions of the Use Case diagrams

Text description of the “Authenticate” use case

Use Case Authenticate

Actors -Manager
Precondition Already registered and logged in
Postcondition Authentication validated and successful access
1. The system displays the login page
2. The actor enters their login and password.
3. The actor clicks the "login" button
4. The system verifies the validity of the provided information, if
Nominal Scenario
the information is incorrect then trigger exception "E1".
5. The default system assigns the role "user"
6. The system grants access to the actor and displays
the appropriate page according to their role.
E1: Login and/or password are incorrect.
The sequence starts at point 3.
Exception The system displays an error message
informing the user that their login
or password is incorrect and the scenario resumes at action 1.

Table IV.2: Textual Description of the Use Case "Authenticate"

Use case diagram “Generate QR code ”

Figure IV.3: Use case diagram “Generate QR code ”

Page 35
Sprint 2: Authentication, generate QR code, generate item

Text description of the “Add Delete QR code ” use case

Use Case “Add Delete QR code ”

Actors
- Manager
Precondition Authenticated actors
Postcondition QR code added deleted successfully added
1. The system displays the list of registered QR codes.
2. The Manager clicks on a QR code .
3. The system displays all QR code information.
Nominal Scenario 4. The Manager clicks on the "add" button.
5. The system displays the QR code addition form.
6. The Manager enters the information and validates the addition.
7. The system verifies the validity of the fields, if a field is empty then "E1".
1. The system displays the list of QR codes.
2. The Manager clicks on the "delete" button.
Alternative Scenario
3. The system displays a deletion confirmation dialog box, if the Manager
Delete
clicks no then "E2".
4. The Managerconfirms the deletion.
E1: empty fields. The system displays an error message.
Exception
E2: deletion not completed.

Table IV.3: Textual Description of «Add / Delete QR cod»

Use case diagram “Generate items ”

Figure IV.4: Use case diagram “Generate items ”

Page 36
Sprint 2: Authentication, generate QR code, generate item

Text description of the “Generate item” use case

Use Case Generate item

Actors
- Manager
Precondition Authenticated actors
Postcondition items generated successfully
1. The system displays the list of registered managers.
2. The Manager clicks on a item menu.
3. The system displays all items menu information.
Nominal Scenario 4. The Manager clicks on the "add" button.
5. The system displays the item menu addition form.
6. The Manager enters the information and validates the addition.
7. The system verifies the validity of the fields, if a field is empty then "E1".
1. The system displays the list of items menu.
2. The Manager clicks on the "delete" button.
Alternative Scenario
3. The system displays a deletion confirmation dialog box, if the Manager
Delete
clicks no then "E2".
4. The Manager confirms the deletion.
1. The system displays the list of items menu.
2. The Manage selects a item menu and modifies their information.
Alternative Scenario
3. The system verifies the authorization right, if the manage
Modify State
. has no right then "E3".
4. The system modifies the item’s menu state.
E1: empty fields. The system displays an error message.
Exception E2: deletion not completed.
E3: item menu state not modified.

Table IV.4: Text description of the “Generate item” use case

IV.4 Sequence diagram

A sequence diagram is a type of interaction diagram in Unified Modeling Language
(UML) that shows how objects interact in a particular sequence of time. It captures
the sequence of messages exchanged between objects to perform a specific task or
process. The diagram includes objects represented by lifelines, messages shown as
arrows, and the order of interactions depicted vertically. Sequence diagrams are
particularly useful for modeling the dynamic behavior of systems, understanding
object interactions, and visualizing the flow of control.

Page 37
Sprint 2: Authentication, generate QR code, generate item

IV.4.1 “Add QR code ” sequence diagram

The "Add QR Code" sequence diagram shown in figure IV.5depicts the process where
a manager interacts with a system to add a QR code. The manager initiates the
request via the user interface (UI), which prompts for the necessary QR code details.
Once the manager provides the details, the UI forwards them to the controller. The
controller processes the information and sends it to the QR code generator, which
creates the QR code and returns it to the controller. The controller then saves the
QR code data to the database and confirms the successful addition. Finally, the UI
displays a confirmation message to the user, completing the process. This sequence
ensures a smooth flow of information and actions from the manager’s request to the
final confirmation.

Figure IV.5: “Add QR code ” sequence diagram

Page 38
Sprint 2: Authentication, generate QR code, generate item

IV.4.2 “Delete menu items ” sequence diagram

This diagram shown in figure IV.6represents the sequence of deletion of menu items
When the manager activates the deletion option, the system requests confirmation
from him. Once this confirmation obtained, the modifications are saved in the
database, then the administrator is automatically redirected to his items menu list.

Figure IV.6: “Delete menu items” sequence diagram

Page 39
Sprint 2: Authentication, generate QR code, generate item

IV.5 Realization

IV.5.1 Interface list of orders

The "List of Orders" interface for a manager shown in figure IV.7 is designed to
provide a comprehensive overview of all orders within the system. Upon accessing
this interface, the manager is presented with a detailed list that includes order IDs,
customer names, order dates, statuses, and total amounts. This interface allows
the manager to filter and sort orders based on various criteria, such as date range
or order status, and to search for specific orders using keywords. Additionally, the
manager can select individual orders to view more detailed information, including
items purchased, quantities, and delivery details. This centralized interface enhances
the manager’s ability to monitor, manage, and analyze orders efficiently, ensuring
smooth operations and timely fulfillment.

Figure IV.7: Interface list of orders

IV.5.2 Interface "Change order status " as manager

The "Change Order Status" interface for a manager shown in figure IV.8provides
a streamlined way to update the status of customer orders. Upon accessing this
interface, the manager is presented with a list of all orders, each showing key details
such as order ID, customer name, current status, and order date. The manager can
select an order from the list to view its detailed information.
For changing the status, the interface offers a dropdown menu or a set of status
buttons (e.g., "Processing," "Shipped," "Delivered," "Cancelled") next to each order.
Once the manager selects the desired new status, they can confirm the change with a
single click. The system then updates the order status in the database and refreshes
the interface to reflect the new status. Additionally, this interface may include op-
tions to add notes or reasons for the status change, ensuring clear communication
and record-keeping. The "Change Order Status" interface enhances order manage-
ment efficiency, providing managers with the tools to keep order statuses accurate
and up-to-date.

Page 40
Sprint 2: Authentication, generate QR code, generate item

Figure IV.8: Interface "Change order status " as manager

IV.5.3 Interface "Add QR code " as Manager

The "Add QR Code" interface for a manager shown in figure IV.9 enables the efficient
creation and integration of QR codes into the system. Upon accessing this interface,
the manager is presented with a form to input the necessary details for generating
a QR code.

Figure IV.9: Interface "Add QR code " as Manager

Page 41
Sprint 2: Authentication, generate QR code, generate item

IV.6 Conclusion
In this Sprint, we presented the design and implementation of image management,
stock reception and messages. After several iterations, the Sprint was validated by
the SCRUM Master with all users. We will now move on to the next chapter which
is devoted to Sprint 3.

Page 42
Chapter V

Sprint 3: Create account, Scan

QR code, make order

43
Sprint 3: Create account, Scan QR code, make order

V.1 Introduction
This chapter consists of studying the final sprint focused on create account , scan
QR code and make orders . We will explore the functional specification, the design
and finally, we will begin the implementation by presenting some interfaces linked
to this sprint.

V.2 Sprint 3 Backlog

The third sprint’s organizational structure is shown below:
By the end of Sprint 3, all tasks listed in the table below, which was created by the
Scrum Team, have to be completed.
Sprint Feature User Story Priority
3 Scan QR Code As a manager, I want to scan a QR code to High
quickly access related information.
3 View Menu As a manager, I want to view the menu to Medium
see available items.
3 Make Order As a manager, I want to create a new order High
to place customer requests.
3 Choose Item As a manager, I want to choose items from High
the menu to add them to an order.
3 Add Order Informa- As a manager, I want to add additional infor- Medium
tion mation to an order for special instructions.
3 Online Payment As a manager, I want to make an online pay- High
ment for an order to complete the transac-
tion.
3 Create Account As a manager, I want to create a new user Medium
account for system access.

V.3 Functional specification

Use case diagrams are UML diagrams that provide an overview of a software system’s
functional behavior. an overview of a software system’s functional behavior. The
description of a series of steps a system takes to give an actor an observable result
is called a use case.

V.3.1 Use case diagram for the «User» actor:

The «Manager» actor shown in figure V.1 represents the user with privileges who
can perform a range of management functions. The use case diagram will show the
manager’s interactions with different use cases within the system.

Page 44
Sprint 3: Create account, Scan QR code, make order

Figure V.1: Use case diagram for the «User» actor:

V.3.2 Use case diagram «authenticate»

The «authenticate» use case represents the process of verifying the identity of a
user attempting to access the system. It involves authentication mechanisms such
as username/password authentication.

Figure V.2: Use case «authenticate» for the«User» actor

V.3.3 Text description

1 Text description of the “Authenticate” use case

Page 45
Sprint 3: Create account, Scan QR code, make order

Use Case Authenticate

Actors -User
Precondition Already registered and logged in
Postcondition Authentication validated and successful access
1. The system displays the login page
2. The actor enters their login and password.
3. The actor clicks the "login" button
4. The system verifies the validity of the provided information, if
Nominal Scenario
the information is incorrect then trigger exception "E1".
5. The default system assigns the role "user"
6. The system grants access to the actor and displays
the appropriate page according to their role.
E1: Login and/or password are incorrect.
The sequence starts at point 3.
Exception The system displays an error message
informing the user that their login
or password is incorrect and the scenario resumes at action 1.

Table V.1: Textual Description of the Use Case "Authenticate"

2.Use case diagram “View menu ”

The "View Menu" use case allows the user to access and view the list of available
menu items. The user interacts with the system to display the menu, which is
fetched from the database where it has been previously registered.

Figure V.3: Use case diagram “View menu ”

Page 46
Sprint 3: Create account, Scan QR code, make order

3.Text description of the “View menu ” use case

Use Case View menu

Actor User
– Addition of menu information to the list.
Precondition – List of registered menu in the database.

Postcondition – List of item menu is displayed.

– The user opens the account creation interface.

Main Scenario – The system displays the menu interface.
Description
– The user views the displayed list of menu .

Exception Display error.

Table V.2: Textual description of the use case "View menu"

4. Text description of the “Scan QR code” use case

Use Case Scan QR code

Actor Manager
– Manager is logged into the system.
Precondition – QR code is available.

Postcondition – Information from the QR code is displayed.

– Manager opens the QR code scanner.

Main Scenario – Manager scans the QR code.
Description
– System displays the information.

Exception Invalid or unreadable QR code.

Table V.3: Textual description of the use case "Scan QR code" as a manager

Page 47
Sprint 3: Create account, Scan QR code, make order

V.4 Sequence diagram

A sequence diagram is a type of interaction diagram in Unified Modeling Language
(UML) that shows how objects interact in a particular sequence of time.

V.4.1 “Authenticate ” sequence diagram

This diagram shown in figure V.4 presents the different possible authentication sce-
narios. To access the system, the administrator must first identify himself using his
login and password. pass. The controller is responsible for verifying this informa-
tion and consults the database for this purpose. If accepted, the user is authorized
to access to the system. Otherwise, an error message is displayed, prompting the
user to correct their data. Once the data has been rectified, the user can log in by
generating an access token and is redirected to their personal space.

Figure V.4: “Authenticate ” sequence diagram

Page 48
Sprint 3: Create account, Scan QR code, make order

V.4.2 “Create account ” sequence diagram

The "Create Account" sequence diagram shown in figure V.5 the process a user
follows to create a new account in a system. The user starts by selecting the option
to create an account on the user interface (UI), which then displays a form requesting
necessary details (such as username, password, and email). The user fills out the
form and submits it. The UI forwards the submitted data to the controller, which
validates the information (checking for existing usernames or emails). If validation
is successful, the controller sends the data to the database to store the new account
information. The database confirms the successful storage, and this confirmation
is relayed back to the UI by the controller. Finally, the UI displays a confirmation
message to the user, completing the account creation process.

Figure V.5: “Create account ” sequence diagram

Page 49
Sprint 3: Create account, Scan QR code, make order

V.4.3 “Add Order ” sequence diagram

The "Add Order" sequence diagram depicts the process shown in figure V.6where a
manager interacts with a system to add order. The manager initiates the request
via the user interface (UI), which prompts for the necessary order details. Once the
manager provides the details, the UI forwards them to the controller. The controller
processes the information and sends it to the order generator, which creates the or-
der and returns it to the controller. The controller then saves the order data to the
database and confirms the successful addition. Finally, the UI displays a confirma-
tion message to the user, completing the process. This sequence ensures a smooth
flow of information and actions from the user’s request to the final confirmation.

Figure V.6: “Add Order ” sequence diagram

Page 50
Sprint 3: Create account, Scan QR code, make order

V.5 Realization

V.5.1 Interface authenticate as a USER

The "Interface authenticate as a USER", shown in figure V.7, represents the user
interface through which an individual can authenticate themselves specifically as a
user within the system. This interface typically prompts the user to provide the
necessary credentials or undergo the required authentication process to verify their
managerial privileges before granting access to managerial functionalities.

Figure V.7: Interface "authenticate" as a USER

V.5.2 Interface "Registration" as a USER

The "Registration" interface for a User, shown in figure V.8 allows an individual to
register as a manager within the system. This interface typically requires the user
to enter essential information, such as personal details, contact information, and rel-
evant credentials. Upon submission, the system validates the provided information
and, once approved, grants the individual managerial access and privileges within
the system.

Figure V.8: Interface "Registration" as a USER

Page 51
Sprint 3: Create account, Scan QR code, make order

V.5.3 Interface "Welcome" as a USER

The "Registration" interface for a User ,shown in figure V.9, allows an individual to
register as a manager within the system. This interface typically requires the user
to enter essential information, such as personal details, contact information, and rel-
evant credentials. Upon submission, the system validates the provided information
and, once approved, grants the individual managerial access and privileges within
the system.

Figure V.9: Interface "Registration" as a USER

V.5.4 Interface "Order informations " as a USER

The "Order Information" interface for a USER ,shown in figure V.10 provides a
concise summary of their recent orders within the system. It typically displays
essential details such as order number, items purchased, order status, and delivery
information, allowing users to track their purchases easily. This interface aims
to enhance user experience by offering quick access to pertinent order details and
facilitating seamless order management.

Figure V.10: Interface "Order informations " as a USER

Page 52
Sprint 3: Create account, Scan QR code, make order

V.5.5 Interface "Payment online " as a USER

The "Payment Online" interface for a USER ,shown in figure V.11facilitates secure
online transactions for purchases made within the system. It typically presents
various payment options, such as credit/debit cards, digital wallets, or other pay-
ment gateways. Users can securely enter their payment details and confirm the
transaction, ensuring a seamless and convenient shopping experience. This inter-
face prioritizes user privacy and security, employing encryption and authentication
measures to safeguard sensitive financial information during the payment process.

Figure V.11: Interface "Payment online " as a USER

V.5.6 Interface "list of menu " as a USER

The "List of Menu" interface for a USER,shown in figure V.12 displays the available
menu options within the system, typically organized by categories such as appetizers,
main courses, desserts, etc. Users can browse through the list to view detailed
descriptions, prices, and possibly images of each menu item. This interface enables
users to easily explore and select their desired dishes, enhancing their overall dining
experience.

Page 53
Sprint 3: Create account, Scan QR code, make order

Figure V.12: Interface "list of menu " as a USER

V.6 Conclusion
In this Sprint, we presented the design and implementation of image management,
stock reception and messages. After several iterations, the Sprint was validated by
the SCRUM Master with all users.

Page 54
GENERAL CONCLUSION

Our innovative restaurant management platform is poised to revolutionize the

restaurant industry by enhancing both operational efficiency and customer experi-
ence. With a user-friendly interface, customers can effortlessly place orders through
QR menus, benefiting from advanced filtering options for personalized customiza-
tion. This modern approach allows diners to scan QR codes at their tables, view
digital menus, and tailor their orders based on dietary preferences, specific ingredi-
ents, and other criteria, providing a seamless and intuitive ordering process.

The platform’s secure payment system ensures that transactions are both con-
venient and safe, enhancing the overall dining experience by integrating a smooth,
end-to-end payment solution. Customers can pay directly through the platform,
confident in the knowledge that their data is protected by robust security measures.

Additionally, the feedback mechanism built into the platform allows customers to
share their dining experiences directly with the restaurant. This feature facilitates
continuous improvement by enabling managers to gather valuable insights and make
data-driven decisions to enhance service quality and customer satisfaction.

For managers, the platform offers an array of robust tools designed to optimize
restaurant operations. Real-time staff activity monitoring ensures that managers
can oversee tasks and allocate resources efficiently, promoting effective workforce
management. The flow control of dishes and meals feature further enhances oper-
ational management by allowing managers to oversee the preparation and delivery
processes, ensuring that dishes are served timely and maintaining high food quality.

The comprehensive feature set of our platform addresses critical operational chal-
lenges and sets a new standard in restaurant management. By integrating advanced
technology and user-centric design, the platform not only improves efficiency but
also significantly enhances the dining experience for customers.

Developed using agile methodology, our platform remains highly adaptable to

market needs and responsive to evolving customer demands and industry trends.
This approach has facilitated effective collaboration within the project team, ensur-
ing the delivery of a dynamic and customer-centric solution. Regular iterations and
continuous feedback have allowed us to refine and enhance the platform, ensuring
it meets the highest standards of functionality and usability.

55
Sprint 3: Create account, Scan QR code, make order

In conclusion, our restaurant management platform is not just a tool but a strate-
gic asset that redefines the dining experience. By addressing the key challenges faced
by the industry and leveraging cutting-edge technology, we have created a solution
that drives continuous improvement and excellence in restaurant operations, setting
a new benchmark for the industry.

Page 56
PERSPECTIVES

Looking ahead, our restaurant management platform is set to transform the in-
dustry by integrating advanced digital solutions and customer-centric features. As
digitalization and personalization in dining experiences continue to grow, the plat-
form’s QR code menu ordering, advanced filtering options, and secure payment
systems will meet evolving customer demands for convenience and customization.
For managers, real-time staff monitoring and flow control of dishes will enhance
operational efficiency and service quality. The platform’s adaptability to emerging
technologies like AI and IoT will further boost its capabilities. Overall, our platform
is poised to drive industry-wide innovation, setting new benchmarks for efficiency
and customer satisfaction.

57
Bibliography

[1] React Framework. Retrieved from https://react.dev/learn.

[2] Node.js ,Retrieved from https://nodejs.org/en .
[3] Docker,Retrieved from https://www.docker.com/.
[4] Stripe ,Retrieved from https://stripe.com/fr.
[5] Operating System ,Retrieved from
https://www.techtarget.com/whatis/definition/operating-system-OS
[6] Visual Studio Code,Retrieved from https://code.visualstudio.com/
[7] Git,Retrieved from https://www.git-scm.com/
[8] Postman,Retrieved from https://www.postman.com/.
[9] MongoDB,Retrieved from https://www.mongodb.com/.
[10] Microsoft Azure,Retrieved from https://azure.microsoft.com/

58