Food Ordering and Delivery Requirements Document

Université technique de Palestine (PTU)
Faculté d'ingénierie et de technologie

Département d'ingénierie des systèmes informatiques
Express
Document sur les exigences en matière de génie

logiciel
Système de gestion des commandes et des livraisons de nourriture
en ligne
Soumis par :
Numéro d'identification de
Nom de l'élève
l'étudiant
Fares Hatem T. Abuali 201810408
Huthaifa Jamal H. Salman 201810018
Asseel Khalid H. Al-Ali 201810232
Abdullah Awad M. Al-Wawi 201810775
Ahmad Othman A. Marei 201811346
Présenté le : 20 avril 2021
Travail n°2 : Ce document a été soumis en partie pour

répondre à l'exigence du cours "Software Engineering" , pendant l'année
académique
2020-2021 (2ème semestre).
Table des matières
CHAPTER 1 INTRODUCTION ........................................................................................................................... 1
Université technique de Palestine (PTU) Faculté d'ingénierie et de technologie Département

d'ingénierie des systèmes informatiques..................................................................................................1
Document sur les exigences en matière de génie logiciel...........................................................................1
Système de gestion des commandes et des livraisons de nourriture en ligne.........................1
Table des matières................................................................................................................................2
CHAPTER 1: INTRODUCTION..................................................................................................1
1.1 Vue d'ensemble du projet et contexte :......................................................................................1
1.2 Domaine du problème :.............................................................................................................1
1.3 Objectifs du projet :...................................................................................................................1
Comment nous proposons de résoudre les problèmes diagnostiqués:.................................................1
• Créer une archive pour les restaurants :............................................................................1
• Gagner du temps :..................................................................................................................2
• Sécurité des données :..........................................................................................................2
• Minimisation de la saisie manuelle des données :............................................................2
1.4 Portée du projet :.......................................................................................................................2
1.5 Résumé du chapitre :.................................................................................................................2
CHAPTER 2: APPROCHE DE LA COLLECTE DES BESOINS...............................................3
CHAPTER 3: DÉFINITION DES BESOINS DES UTILISATEURS..........................................3
3.1 Exigences fonctionnelles de l'utilisateur :.................................................................................3
II. CLIENT :......................................................................................................................................4
III. MANAGER (ADMIN du restaurant) :......................................................................................4
IV. PERSONNEL DE CUISINE (chefs du restaurant) :.................................................................4
3.2 Exigences non fonctionnelles de l'utilisateur :...............................................................................4
Exigences opérationnelles............................................................................................................4
Exigences de performance...........................................................................................................4
Exigences en matière de sécurité.....................................................................................................5
Exigences en matière de facilité d'utilisation.......................................................................................5
CHAPTER 4: ARCHITECTURE DU SYSTÈME........................................................................6
4.1 Ce qui est en dehors des frontières du système :.................................................................6
4.2 Diagramme de contexte :...........................................................................................................7
CHAPTER 5: LA SPÉCIFICATION DES EXIGENCES DU SYSTÈME :................................7
5.1 LES EXIGENCES FONCTIONNELLES DU SYSTÈME :.................................................................7
5.2 LES EXIGENCES NON FONCTIONNELLES DU SYSTÈME :......................................................11
1. La sécurité :.................................................................................................................................11
2. Facilité d'utilisation :...................................................................................................................11
3. Disponibilité :..............................................................................................................................11
CHAPITRE 6 : MODÈLES DE SYSTÈMES :..............................................................................12
• 6.1 : Diagrammes de cas d'utilisation :....................................................................................12
• 6.2 : Diagramme de classe :....................................................................................................14
• 6.3 : Diagramme d'activité......................................................................................................15
CHAPTER 7: L'ÉVOLUTION DU SYSTÈME :........................................................................24
LIMITATION DU SYSTÈME :.............................................................................................................24
L'AMÉLIORATION DU SYSTÈME :....................................................................................................24
CHAPTER 8: PLAN POUR LE RESTE DU TRAVAIL :..........................................................25
CHAPTER 9: CONCLUSION :..................................................................................................25
RÉFÉRENCES :.............................................................................................................................25
1.1
1.2 Résumé du chapitre ...................................................................................................................... 2
CHAPTER 2 APPROCHE DE LA COLLECTE DES EXIGENCES ............................................................................... 3
CHAPTER 3 DÉFINITION DES BESOINS DES

UTILISATEURS .......................................................................................... 3
3.1 Exigences fonctionnelles des utilisateurs .................................................................................................

3
3.1 Exigences non fonctionnelles de l'utilisateur ........................................................................................ 4
CHAPITRE 4 ARCHITECTURE DU SYSTÈME ............................................................................................................ 6
4.1 Ce qui est en dehors des frontières du système ....................................................................................

6
4.2 Diagramme de
contexte ......................................................................................................................... 7
CHAPTER 5 SPÉCIFICATION DES EXIGENCES DU SYSTÈME ............................................................................... 7
5.1 EXIGENCES FONCTIONNELLES DU SYSTÈME .................................................................................. 7
5.2 EXIGENCES NON FONCTIONNELLES DU SYSTÈME ...................................................................... 11

CHAPTER 6 MODÈLES DE SYSTÈMES ......................................................................................................................
12
6.1 Diagrammes de cas

d'utilisation ................................................................................................................... 12
6.2 Diagramme de classe ...........................................................................................................................

14
6.3 Diagrammes d'activité ..................................................................................................................... 15
6.4 Diagramme de séquence ...................................................................................................................

18
CHAPTER 7 ÉVOLUTION DU SYSTÈME ................................................................................................................ 23
CHAPTER 8 PLAN POUR LE RESTE DU TRAVAIL .......................................................................................................

24
CHAPTER 9 CONCLUSION ............................................................................................................................. 24
RÉFÉRENCES ................................................................................................................................................... 25
SYSTÈME DE GESTION DES COMMANDES ET DES
LIVRAISONS DE PRODUITS ALIMENTAIRES
CHAPTER 1: INTRODUCTION
1.1 Vue d'ensemble du projet et contexte :

À l'ère de la restauration rapide et des plats à emporter, de nombreux restaurants ont choisi de se
concentrer sur la préparation et la livraison rapides des commandes plutôt que d'offrir une expérience
gastronomique enrichissante. Jusqu'à très récemment, tous les ordres de livraison étaient passés par
téléphone, mais ce système présente de nombreux inconvénients :
• L'inconvénient pour le client d'avoir besoin d'une copie physique du menu.
• Absence de confirmation visuelle que la commande a été passée correctement.
• La nécessité pour le restaurant d'avoir un employé qui réponde au téléphone et prenne les
commandes.
Il est donc de plus en plus nécessaire de créer un système intelligent et innovant qui facilite la
communication entre les restaurants et leurs clients.
1.2 Domaine du problème :
Les difficultés rencontrées par le système de commande traditionnel existant constituent un obstacle
majeur à la réalisation de l'efficacité et de la satisfaction du client. L'expérience de la commande dans la
plupart des restaurants rapides n'est pas agréable pour les clients :
• Les clients devront faire de longues files d'attente avant de passer leur commande, surtout aux heures
de pointe.
• Le personnel chargé des commandes enregistrera ensuite manuellement les commandes des clients.
• Après avoir passé sa commande, le client doit attendre près du comptoir jusqu'à ce que sa commande
soit prête à être retirée.
• Le travail manuel nuit à l'efficacité et réduit la précision des données au cours du processus de
placement des commandes.
1.3 Objectifs du projet :
Notre projet vise à développer un système complet de commande en ligne pour l'industrie de la
restauration qui permettra aux restaurants de gérer rapidement et facilement un menu en ligne que les
clients pourront parcourir et utiliser pour passer des commandes en quelques clics seulement.
1
CHAPITRE 1
INTRODUCTION
Comment nous proposons de résoudre les problèmes diagnostiqués:
• Créer une archive pour les restaurants :

Nous visons à fournir un traitement pour les problèmes mentionnés ci-dessus en aidant les clients à
commander ce qu'ils veulent dans n'importe quel restaurant de leur choix. Pour ce faire, il est possible de
créer une base de données dédiée aux restaurants afin d'enregistrer le plus grand nombre possible de
restaurants dans les villes palestiniennes.
Et une autre base de données pour les utilisateurs afin de stocker leurs données et de faciliter le lien
entre chaque utilisateur et sa commande spécifique.
• Gagner du temps :
En proposant un service de livraison, les clients peuvent passer leur commande en quelques clics de
souris et en utilisant quelques mots-clés de recherche, ce qui leur permet de gagner un temps précieux.
Cela permettra d'accroître la satisfaction des clients en accélérant la livraison des repas.
• Sécurité des données :
Les données sont bien protégées pour un usage personnel.
• Minimisation de la saisie manuelle des données :
L'automatisation garantit l'exactitude des données au cours du processus de placement des commandes.
En résumé, nous proposons un système de commande en ligne, c'est-à-dire une technique de commande
d'aliments en ligne applicable à tout secteur de livraison de nourriture. Le principal avantage de notre
système est qu'il simplifie considérablement le processus de commande, tant pour le client que pour le
restaurant.
À la fin du projet, il améliorera la productivité, l'efficacité et la précision des restaurants. Grâce à ce

système, le travail manuel sera réduit au minimum en remplaçant le système de commande traditionnel
par un système informatique. Il éliminera les tâches manuelles telles que l'envoi physique par les
employés du bon de commande à la cuisine, le remplacement manuel de l'étiquette de prix de la
nourriture et le calcul manuel du prix de facturation.
1.4 Portée du projet :
Le système sera une plate-forme basée sur le web qui sera développée pour permettre à l'utilisateur de
consulter les informations de la carte de menu du restaurant et de passer ensuite une commande par
l'intermédiaire du système.
le système permettra au personnel de chaque restaurant de mettre à jour et de modifier les informations
relatives à leur menu de nourriture et de boissons. Ensuite, il permet également aux employés de générer
les rapports qu'ils souhaitent, tels que le rapport mensuel des ventes. La fonction la plus importante est
de permettre au personnel d'établir des relevés de facturation pour que les consommateurs puissent
effectuer leur paiement après leur commande.
2
CHAPITRE 1
INTRODUCTION
1.5 Résumé du chapitre :
Ce chapitre a examiné les difficultés liées à l'approche traditionnelle du système de commande de

nourriture dans les restaurants. En outre, nous avons mentionné les parties prenantes, c'est-à-dire les
personnes confrontées à un problème dans la situation actuelle et la manière dont elles bénéficieront du
traitement que nous proposerons.
Enfin, l'objectif et la portée du projet ont été énumérés et discutés. La structure globale du système
proposé a été justifiée et la contribution du projet est indiquée. Ensuite, nous examinerons plus en détail
le concept du système de gestion des restaurants existant.
3
CHAPITRE 1
INTRODUCTION
CHAPTER 2: APPROCHE DE LA COLLECTE DES BESOINS
Au début, nous étions perdus et confus quant au fonctionnement des systèmes de gestion des
commandes et des livraisons de nourriture ! Nous sommes donc allés sur Internet et avons visité
quelques sites de commande de nourriture populaires ici en Palestine, à titre d'exemple : http://www.pal-
eat.com/ ou ceci : https://www.doordash.com/en-US
Nous avons rassemblé quelques idées et avons ensuite entamé la phase de découverte des besoins. La
principale approche que nous avons suivie pour recueillir les besoins des utilisateurs et des systèmes a
été de surfer sur le web. Nous avons également consulté notre professeur, le Dr. Nael Salman, pour qu'il
nous donne des conseils sur la manière de découvrir les besoins.
En outre, je dois mentionner que nous avons eu un entretien avec des ingénieurs en logiciel chevronnés
qui nous ont donné des indications sur la manière de recueillir les besoins.
CHAPTER 3: DÉFINITION DES BESOINS DES UTILISATEURS
Le système sera conçu pour être convivial. La conception d'interfaces conviviales et interactives
contribue à atteindre cet objectif en permettant aux clients de parcourir facilement les menus, de passer
commande en quelques clics, et aux employés du restaurant d'examiner rapidement les commandes au
fur et à mesure qu'elles sont passées et de produire les articles nécessaires avec un minimum de retard et
de confusion. Le système sera simple à utiliser.
3.1 Exigences fonctionnelles de l'utilisateur :

Les exigences fonctionnelles définissent les capacités et les fonctions qu'un système doit être en mesure
d'exécuter avec succès. Les exigences fonctionnelles de ce système de commande en ligne sont les
suivantes :
I. ADMIN:
Gestion des utilisateurs: l'administrateur doit avoir un accès complet à la base de données des
utilisateurs :
• Ajouter un utilisateur.
• Supprimer l'utilisateur.
• Modifier un enregistrement d'utilisateur.
• Voir les informations sur l'utilisateur.
Gestion des restaurants: l'administrateur doit avoir un accès complet à la base de données des
restaurants :
• Ajouter un restaurant.
• Supprimer un restaurant.
• Modifier la fiche d'un restaurant.
• Voir toutes les informations sur les restaurants.
• Consulter les informations d'un restaurant spécifique.
4
CHAPITRE 2 RECUEIL DES BESOINS | CHAPITRE 3 DÉFINITION DES BESOINS DES
UTILISATEURS
II. CLIENT :
o [Il n'est pas nécessaire d'avoir un compte]: Le système doit permettre au client de :
• Parcourez les restaurants. Chaque restaurant doit indiquer son nom, le nom de son
propriétaire et sa localisation.
• Lorsque le client clique sur un restaurant spécifique, afficher le menu du restaurant

qui contient tous les plats et produits disponibles avec leurs prix et ingrédients.
o [Nécessité d'un compte]: Le système doit permettre au client de :

• S'inscrire au système (créer son propre compte)
• Se connecter au système après avoir créé le compte.
• Passer une commande.
• Préciser si la commande doit être livrée ou retirée par le client lui-même.
• Le système demande au client de confirmer le repas commandé.
• Le système doit fournir une confirmation visuelle du placement de la commande
III. MANAGER (ADMIN du restaurant) :

Le gérant de chaque restaurant doit être en mesure de.. :
• Créer la carte du restaurant.
• Créez de nouveaux produits alimentaires et ajoutez-les au menu du restaurant.
• Modifiez ou mettez à jour les détails de n'importe quel aliment, tels que le nom du
plat, le prix, les ingrédients,...
• Supprimer les aliments qu'ils souhaitent.
• Générer des rapports de vente pour leur restaurant (rapports hebdomadaires,
mensuels, annuels).
IV. PERSONNEL DE CUISINE (chefs du restaurant) :

Chaque chef cuisinier doit être capable de :
• Visualiser les ordres en attente (ordres qui doivent être préparés)
• Mise à jour de l'état des commandes
• Vérifier la commande pour leur indiquer qu'elle est prête à être prise ou livrée.
3.2 Exigences non fonctionnelles de l'utilisateur :
Exigences opérationnelles
• Le système devrait fonctionner correctement dans la plupart des navigateurs web.
•
Le système devrait inviter le gérant (l'administrateur de chaque restaurant) à effectuer une
sauvegarde à la fin de la journée de travail.
Exigences de performance
• Le système doit permettre à l'utilisateur de passer une commande dans un court laps de
temps. (moins d'une minute de délai de chargement)
• Toutes les tables de la base de données doivent être normalisées au moins jusqu'à latroisième
forme normale. L'extraction des données de la base de données ne doit donc pas dépasser 5
à 10 secondes dans le pire des cas.
5
CHAPITRE 3 DÉFINITION DES BESOINS DES
UTILISATEURS
Exigences en matière de sécurité
• Le système valide le nom d'utilisateur et le mot de passe afin de pouvoir se connecter et

apporter des modifications au système.
• Le système demande le mot de passe actuel de l'utilisateur afin de lui permettre d'en
changer.
• Les mots de passe doivent être cryptés.
Exigences en matière de facilité d'utilisation

• Le système doit avoir une interface graphique simple et facile à apprendre.
• Un nouveau client devrait pouvoir utiliser la plupart des fonctionnalités du système en

moins d'une demi-heure de formation.
6
CHAPITRE 3 DÉFINITION DES BESOINS DES
UTILISATEURS
CHAPTER 4: ARCHITECTURE DU SYSTÈME
Ce chapitre présente une vue d'ensemble de l'architecture du système prévu, montrant la répartition des
fonctions entre les modules du système. Les éléments architecturaux réutilisés doivent être mis en
évidence.
Figure 1 : Aperçu général de l'architecture de notre système
4.1 Ce qui est en dehors des frontières du système :

Les frontières du système sont établies pour définir ce qui est à l'intérieur et ce qui est à l'extérieur du
système :
Traitement des modes de paiement :

Nous essayons de garder notre système simple, donc nous ne nous impliquerons pas dans le système de
paiement en détail, car il nécessite l'intégration de notre système avec un système externe qui est
responsable de la gestion des paiements et des méthodes de paiement (comme la carte Visa).
7
CHAPITRE 4 ARCHITECTURE DU
SYSTÈME
4.2 Diagramme de contexte :
Il s'agit d'une autre structure brève qui décrit l'environnement dans lequel un système logiciel existe et
aide à communiquer sur ce qui se trouve en dehors des limites du système.
Figure 2 : Diagramme de contexte de l'architecture de notre système
CHAPTER 5: LA SPÉCIFICATION DES EXIGENCES DU SYSTÈME :

Je vais maintenant essayer de décrire plus en détail certaines exigences fonctionnelles et non
fonctionnelles énoncées au chapitre 3.
5.1 LES EXIGENCES FONCTIONNELLES DU SYSTÈME :

Le système dispose d'un écran d'accueil qui permet à tout utilisateur ayant créé un compte de se
connecter au système à l'aide de son nom d'utilisateur et de son mot de passe.
8
CHAPITRE 5 SPÉCIFICATION DES EXIGENCES DU
SYSTÈME
Tableau 1 : <<Exigences fonctionnelles du système>> Connexion de l'utilisateur
Connexion de l'utilisateur
Brève description Le cas d'utilisation "connexion" permet à l'utilisateur de se

connecter au système.
Acteur(s) Un utilisateur, peut-être :
• Un administrateur.
• Le restaurant gestionnaire.
• Un personnel de cuisine (un chef).
• Un client.
Note : Je pense qu'il y aura un formulaire de connexion différent
pour chaque type d'utilisateur mentionné ci-dessus, car chaque type
sera stocké dans sa propre base de données.
Déroulement des Sur la page d'accueil ➔ Formulaire de connexion ;
événements
1. Le système demande à l'utilisateur son nom d'utilisateur
et son mot de passe.
2. L'utilisateur saisit son nom d'utilisateur et son mot de
passe.
3. Le système valide les informations saisies et s'assure
que les données saisies existent réellement dans la base
de données de l'utilisateur.
4. L'utilisateur est connecté.
Conditions Avoir un compte auparavant.
Sécurité Connexion sécurisée à la base de données
Conditions a
posteriori
Succès Les données saisies par l'utilisateur sont stockées dans le
compte utilisateur.
9
SYSTÈME
Tableau 2 : <<Exigences fonctionnelles du système>> Gestionnaire du restaurant
Création du menu du restaurant par le gérant/propriétaire du restaurant
Brève description Permet au gérant du restaurant de créer le menu de son établissement,
puis d'y insérer des plats.
Acteur(s) Le gérant/propriétaire du restaurant (chaque nouveau restaurant ajouté sera

attribué à un gérant qui sera responsable de ce restaurant).
Déroulement des Une fois que le gérant s'est connecté avec succès, il peut aller dans la
événements barre de navigation en haut ➔ Créer le menu du restaurant.
1. Le gérant du restaurant peut créer un seul menu pour son restaurant.
2. Après avoir créé le menu, le gestionnaire peut ajouter des plats ou des
produits alimentaires en spécifiant le nom/titre du plat, le prix, les
ingrédients, la description du plat et la taille du plat (petit - moyen - grand).
3. Cliquez ensuite sur "enregistrer le plat" et le plat sera inséré dans la

base de données du menu, avec une clé étrangère connexe :
"restaurantID" pour indiquer que ces produits alimentaires sont liés à ce
restaurant spécifique.
Le gestionnaire peut modifier n'importe quel aliment du menu quand il le

souhaite. Par exemple, ils peuvent modifier le nom du plat, le prix
(augmentation ou réduction), les ingrédients ou la description du plat.
Le gestionnaire peut supprimer n'importe quel aliment du menu quand il le

souhaite. Par exemple, si le restaurant ne sert plus ce plat ou s'il souhaite
le retirer temporairement de la carte.
Le gestionnaire peut ensuite générer des rapports (hebdomadaires,

mensuels, annuels) qui lui présentent des détails tels que
• le nombre de commandes effectuées par les clients.
• le bénéfice total.
Conditions préalables Le gestionnaire du restaurant doit s'être connecté avec succès à son
compte
Sécurité Connexion sécurisée à la base de données.
Seul le gérant/propriétaire du restaurant peut accéder au menu du restaurant et

y apporter des modifications (insertion, mise à jour ou suppression).
D'autres personnes, comme les clients, peuvent seulement consulter et parcourir

le menu, mais n'ont pas le droit d'insérer, de mettre à jour ou de supprimer un
Conditions a posteriori Ilélément.
est recommandé au gérant du restaurant de faire une copie de sauvegarde de
son menu après chaque changement.
Succès Le gérant du restaurant a créé la carte de son établissement et y a ajouté

des plats.

SYSTÈME
Tableau 3 : <<Exigences fonctionnelles du système>> Fonctions du client
CLIENT
Brève description Laissez le client visualiser et parcourir le menu de n'importe quel restaurant qu'il
désire, puis donnez-lui la possibilité de passer une commande et de choisir la
manière dont il souhaite la recevoir.
Acteur(s) Le client (l'utilisateur qui souhaite passer une commande)
Déroulement des Le client en tant qu'invité :

événements 1. Tout client invité peut consulter les restaurants. Chaque restaurant doit
indiquer son nom, le nom de son propriétaire et sa localisation.
2. Lorsque le client clique sur un restaurant spécifique, afficher le menu du

restaurant qui contient tous les plats et produits disponibles avec leurs prix et
ingrédients.
Client après connexion :
1. Une fois que le client a créé un compte et s'est connecté avec succès, un
bouton "Ajouter cette commande au panier" sera activé à côté de chaque
produit alimentaire dans le menu.
2. Le client peut désormais consulter le menu du restaurant de son choix. Ils

peuvent cliquer sur le bouton "ajouter cette commande au panier" pour
commander tous les produits alimentaires qu'ils souhaitent.
3. Le client peut bien sûr commander plus d'un produit alimentaire. Lorsque le
client a terminé sa commande, il doit cliquer sur le bouton "Soumettre la
commande".
4. Tous les plats/articles alimentaires sélectionnés seront alors ajoutés à la base

de données des commandes, avec l'identifiant du client et d'autres informations
connexes indiquant que ce plat a été commandé par ce client spécifique.
5. Le rôle du client est désormais terminé. Le client doit maintenant attendre les
chefs qui recevront sa commande, la prépareront et la vérifieront.
6. Une fois que les chefs ont changé le statut de la commande de "en attente" à
"prête", le client peut voir le statut de sa commande comme étant "prête" et se
préparer à aller chercher la commande ou à attendre le livreur.
Conditions La navigation en tant qu'invité ne requiert aucune condition.
préalables
Pour passer une commande, le client doit se connecter avec succès.

SYSTÈME
Sécurité Connexion sécurisée à la base de données.
Une fois que le client a passé sa commande, une notification est envoyée
directement à son adresse électronique.
Si la commande n'a pas été passée par le client ! Il peut signaler la commande,
ce qui l'arrêtera et invitera le client à modifier son mot de passe.
Conditions a Après réception de la commande par le client. Il lui sera demandé d'attribuer
posteriori une note au service.
Succès Le client a reçu sa commande exactement comme il le souhaitait.
5.2 LES EXIGENCES NON FONCTIONNELLES DU SYSTÈME :

Dans l'ingénierie des systèmes, une exigence non fonctionnelle spécifie comment le système doit
se comporter et précise les contraintes qui pèsent sur le comportement du système. On peut
également considérer les exigences non fonctionnelles comme des attributs de qualité d'un
système.
1. La sécurité :
• Le système comporte des pages de connexion et d'inscription.
• Pour s'inscrire, l'utilisateur doit saisir son adresse électronique et son mot de passe qui doit
comporter au moins 7 caractères, dont : 1 lettre minuscule, 1 lettre majuscule, des chiffres
et l'un des caractères suivants (#, $, *, !).
• Le système protégera ces informations en utilisant l'identité dans Asp.net qui est fait
par .net qui a
• En outre, l'utilisateur ne peut pas terminer l'enregistrement sans entrer un code que le
système lui envoie par courrier électronique.
2. Facilité d'utilisation :
• Le système doit avoir une interface graphique simple et facile à apprendre.
• Un nouveau client devrait pouvoir utiliser la plupart des fonctionnalités du système en

moins d'une demi-heure de formation.
•valides.
Fournit un cadre d'aide tel que des messages d'erreur lors de la saisie de données non
3. Disponibilité :
- Chaque restaurant peut spécifier ses jours et heures de travail, et le menu de son
restaurant sur notre système sera alors disponible pour les clients afin qu'ils puissent
passer des commandes pendant ces heures.
1
CHAPITRE 5 SPÉCIFICATION DES EXIGENCES DU 1
SYSTÈME
CHAPITRE 6 : MODÈLES DE
SYSTÈMES :
• 6.1 : Diagrammes de cas
d'utilisation :
Figure 3 : Diagramme du cas

d'utilisation de l'administrateur
1
CHAPITRE 6 MODÈLES DE 2
SYSTÈMES
Livreur de repas
Figure 5 : Diagramme de cas d'utilisation du livreur de repas
Figure 6 : Diagramme de cas d'utilisation du personnel de cuisine
1
SYSTÈMES
Figure 7 : Diagramme du cas d'utilisation du gérant du restaurant
• 6.2 : Diagramme de classe :
Figure 8 : Diagramme de classes du système

de commande et de livraison de nourriture
1
SYSTÈMES
• 6.3 : Diagramme
d'activité
Figure 9 : Diagramme d'activité général d'un client qui commande pour la première fois un
plat dans un menu.
1
SYSTÈMES
Figure 10 : Modèle d'activité montrant le flux d'événements entre un client (utilisateur) et un

coursier (livreur de repas)
1
SYSTÈMES
Figure 11 : Le diagramme d'activité montre le flux d'événements que le gérant d'un

restaurant doit suivre pour créer le menu de son restaurant et ajouter des produits
1
SYSTÈMES
alimentaires.
1
SYSTÈMES
• 6.4 : Diagramme de séquence
Figure 12 : Diagramme de séquence de connexion de

l'administrateur
1
SYSTÈMES
Figure 13 : L'opinion du gérant du restaurant sur les informations relatives à ses

chefs
2
SYSTÈMES
2.Menu de
demande
4. Menu d'affichage 3. Menu retour
5Choisir le repas
6Cliquez sur le panier
d'achat
_______bouton_______
/Afficher la page de
commande
8Cliquez sur le bouton
9Demande de
connexion
10. Saisir le nom du
11. vérifier le
compte et le
compte
12.Compte valide
13. renvoyer l'adresse
enregistrée du membre
14.Display adresse de
livraison et paiement
________page________
15. cliquer sur le bouton
de confirmation
16. demande d'
introduction du numéro de
carte de crédit et du code
de sécurité
17
Saisir le numéro de la
18 Vérifier la carte de
crédit
20 Afficher le détail de la commande 19 Carte de crédit en

21 Cliquez sur le bouton "Terminer".
22 Affichage de l'état de la livraison
Figure 14 : Diagramme de séquence complet montrant presque toutes les relations entre
Customer et les objets du système.
2
SYSTÈMES
reducestock (product, qty)
Figure 15 : Client en train de passer une commande (processus de

passation d'une commande)
2
SYSTÈMES
Figure 16 : Diagramme de séquence pour la cuisine lors de la réception de la

commande
2
SYSTÈMES
Figure 17 : Le livreur de repas reçoit la commande
CHAPTER 7: L'ÉVOLUTION DU SYSTÈME :

LIMITATION DU SYSTÈME :
L'intégration de notre système avec un système de paiement tel que la carte Visa n'est pas
encore possible, en raison de notre manque de connaissances en matière d'API. Pour l'instant,
nous allons donc mettre en place le système en supposant que le client ne paiera qu'en
espèces.
L'AMÉLIORATION DU SYSTÈME :
Nous donnerons à chaque client enregistré la possibilité d'évaluer un restaurant uniquement
après avoir passé une commande auprès de celui-ci.
À l'avenir, nous envisageons de développer une application mobile pour notre système de
commande de nourriture en utilisant la plateforme Android.
2
CHAPITRE 7 ÉVOLUTION DU 4
SYSTÈME
Le système d'application mobile peut mettre en œuvre une fonction de notification en temps
réel de l'application de téléphonie mobile au service d'assistance. Cette fonction permet au
client de demander un service après-vente en utilisant l'application mobile.
L'application mobile peut proposer des mini-jeux pour divertir les clients pendant qu'ils
attendent d'être servis.
CHAPTER 8: PLAN POUR LE RESTE DU TRAVAIL :

sur la base des nouvelles informations que nous avons déjà apprises, nous avons affiné notre
plan initial que nous avons présenté dans la proposition de projet. Notre plan n'a pas changé,
nous sommes donc toujours en phase avec le plan initial.
NOM DE L'AUTEUR] 20
CHAPTER 9: CONCLUSION :
Le travail sur ce projet a été très utile. Au début, nous avons eu quelques difficultés à trouver
l'idée du projet, puis à rassembler les besoins des utilisateurs et du système.
Je pense que notre projet n'est pas aussi simple qu'il n'y paraît. Il faut beaucoup de travail pour
s'y attaquer. Nous nous considérons tous comme des juniors ou des débutants dans le domaine
du développement web. Nous ne sommes pas très expérimentés en matière de technologies
web. Ce sera le premier grand projet auquel nous serons confrontés. Nous prévoyons donc de
travailler en coopération et de bénéficier les uns des autres.
RÉFÉRENCES :
• Food Ordering System Using Mobile Phone Par LEONG WAI HONG, Faculté des technologies
de l'information et de la communication (Campus Perak), Jan 2016 :
http://eprints.utar.edu.my/1943/1/IA-2016-1203135-1.pdf
• Proposition de projet sur le système de commande en ligne par KAPCHNAGA ROGERS

WAFULA, Kabarak Ubiversity, School of Science Engineering & Technology,
Department of Mathematics and Computing Sciences :
https://www.coursehero.com/file/16277265/ONLINE-ORDERING-SYSTEM-
PROJET-PROPOSITION/
• Architecture et principes de conception pour un système de livraison de nourriture en

ligne, écrit par : Sandesh Deshmane, le : Aug 12 2020 :
2
5
https://sandesh-deshmane.medium.com/architecture-and-design-principles-for-online-
food-delivery-system-33bfda73785d
• Conception d'une application mobile de commande de nourriture - une étude de cas

UX, écrit par : Andrey Herasymenko, le : Dec 20, 2018 :
https://uxdesign.cc/ui-ux-case-study-feedme-mobile-app-for-ordering-food-
ef0e7f8c82ba
• Qu'est-ce qu'un diagramme de séquence ?

https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-
diagramme-séquence/
• LucidChart & Draw.io Outils pour dessiner des diagrammes UML.
2
CHAPITRE 8 PLAN POUR LE RESTE DU TRAVAIL | CHAPITRE 9 6
CONCLUSION

Food Ordering and Delivery Requirements Document

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Food Ordering and Delivery Requirements Document

Transféré par

Droits d'auteur :

Formats disponibles

Université technique de Palestine (PTU)

Faculté d'ingénierie et de technologie

Document sur les exigences en matière de génie

Travail n°2 : Ce document a été soumis en partie pour

Table des matières

CHAPTER 1 INTRODUCTION ........................................................................................................................... 1

Université technique de Palestine (PTU) Faculté d'ingénierie et de technologie Département

1.2 Résumé du chapitre ...................................................................................................................... 2

CHAPTER 2 APPROCHE DE LA COLLECTE DES EXIGENCES ............................................................................... 3

CHAPTER 3 DÉFINITION DES BESOINS DES

3.1 Exigences fonctionnelles des utilisateurs .................................................................................................

3.1 Exigences non fonctionnelles de l'utilisateur ........................................................................................ 4

CHAPITRE 4 ARCHITECTURE DU SYSTÈME ............................................................................................................ 6

4.1 Ce qui est en dehors des frontières du système ....................................................................................

CHAPTER 5 SPÉCIFICATION DES EXIGENCES DU SYSTÈME ............................................................................... 7

5.1 EXIGENCES FONCTIONNELLES DU SYSTÈME .................................................................................. 7

5.2 EXIGENCES NON FONCTIONNELLES DU SYSTÈME ...................................................................... 11

6.1 Diagrammes de cas

6.2 Diagramme de classe ...........................................................................................................................

6.3 Diagrammes d'activité ..................................................................................................................... 15

6.4 Diagramme de séquence ...................................................................................................................

CHAPTER 7 ÉVOLUTION DU SYSTÈME ................................................................................................................ 23

CHAPTER 8 PLAN POUR LE RESTE DU TRAVAIL .......................................................................................................

CHAPTER 9 CONCLUSION ............................................................................................................................. 24

1.1 Vue d'ensemble du projet et contexte :

1.3 Objectifs du projet :

• Créer une archive pour les restaurants :

À la fin du projet, il améliorera la productivité, l'efficacité et la précision des restaurants. Grâce à ce

1.4 Portée du projet :

Ce chapitre a examiné les difficultés liées à l'approche traditionnelle du système de commande de

CHAPTER 3: DÉFINITION DES BESOINS DES UTILISATEURS

3.1 Exigences fonctionnelles de l'utilisateur :

• Lorsque le client clique sur un restaurant spécifique, afficher le menu du restaurant

o [Nécessité d'un compte]: Le système doit permettre au client de :

III. MANAGER (ADMIN du restaurant) :

IV. PERSONNEL DE CUISINE (chefs du restaurant) :

3.2 Exigences non fonctionnelles de l'utilisateur :

• Le système devrait fonctionner correctement dans la plupart des navigateurs web.

• Le système valide le nom d'utilisateur et le mot de passe afin de pouvoir se connecter et

• Les mots de passe doivent être cryptés.

Exigences en matière de facilité d'utilisation

• Un nouveau client devrait pouvoir utiliser la plupart des fonctionnalités du système en

Figure 1 : Aperçu général de l'architecture de notre système

4.1 Ce qui est en dehors des frontières du système :

Traitement des modes de paiement :

Figure 2 : Diagramme de contexte de l'architecture de notre système

CHAPTER 5: LA SPÉCIFICATION DES EXIGENCES DU SYSTÈME :

5.1 LES EXIGENCES FONCTIONNELLES DU SYSTÈME :

Brève description Le cas d'utilisation "connexion" permet à l'utilisateur de se

Acteur(s) Le gérant/propriétaire du restaurant (chaque nouveau restaurant ajouté sera

1. Le gérant du restaurant peut créer un seul menu pour son restaurant.

3. Cliquez ensuite sur "enregistrer le plat" et le plat sera inséré dans la

Le gestionnaire peut modifier n'importe quel aliment du menu quand il le

Le gestionnaire peut supprimer n'importe quel aliment du menu quand il le

Le gestionnaire peut ensuite générer des rapports (hebdomadaires,

Seul le gérant/propriétaire du restaurant peut accéder au menu du restaurant et

D'autres personnes, comme les clients, peuvent seulement consulter et parcourir

Succès Le gérant du restaurant a créé la carte de son établissement et y a ajouté

CHAPITRE 5 SPÉCIFICATION DES EXIGENCES DU

Acteur(s) Le client (l'utilisateur qui souhaite passer une commande)

Déroulement des Le client en tant qu'invité :

2. Lorsque le client clique sur un restaurant spécifique, afficher le menu du

Client après connexion :