Chapitre I.

Analyse

et spcifications des besoins

Introduction
Dans tout systme, les fonctionnalits doivent tre mises en relation avec un ensemble de besoins utilisateurs. Ces besoins dfinissent les services que les utilisateurs attendent de la part de l'application. Dans ce chapitre, nous allons commencer par la dfinition des besoins fonctionnels et non fonctionnels. Puis partir de cette spcification, nous allons identifier les acteurs ainsi que les cas d'utilisation de l'application.

I.

Etudes des besoins

Dans cette premire partie, nous allons noncer et analyser les diffrents besoins fonctionnels et non fonctionnels de notre application.

I.1

Besoins fonctionnels

Les utilisateurs arrivent, au sein de ce projet, interagir avec le systme qui propose divers services distingus suivant le rle que jouit l'acteur.

1-Gestion des agences abonnes Lapplication, partir du son back-office, doit fournir la socit Intercom-consulting, qui va hberger ce back et le prsente comme un service, les fonctionnalits ncessaires pour la gestion et le suivi de ses clients (les agences abonnes). Pour chaque agence abonne lapplication doit fournir les fonctionnalits suivantes : Gestion des personnels Lapplication doit permettre ladministrateur de grer les succursales, les personnels et leurs droits daccs.

Gestion des Clients Ladministrateur peut grer les clients, leurs oprations et leurs avis via lapplication. Gestion des htels Lapplication doit sauvegarder les coordonnes des htels, leurs contacts, les thmes, les types darrangements et les rductions quils prsentent. Gestion des circuits et des excursions Ladministrateur peut organiser des circuits et des excursions, en spcifiant leurs dtails et leurs conditions. Gestion de billetterie Lapplication doit permettre au chef de production de grer les pays destinations, les horaires et les dtails des vols dans le cas de processus traductionnel de rservation dans les vols et de dfinir les donnes rcuprer partir des web services fournis par Amadeus dans le cas o on a une synchronisation immdiate avec Amadeus via le front office. Gestions des voitures Lapplication doit permettre au chef de production de grer les voitures disponibles louer, les agence de location des voitures avec lesquelles il travail. Gestions des promotions Le chef de production peut, travers lapplication, ajouter, modifier ou supprimer une promotion en lui donner la possibilit de saisir tous ses dtails. Gestion des rservations Tout personnel a le droit de saisit les rservations pour les clients qui se prsentent dans lune des succursales de lagence. Dlivrer une facture et un reu pour chaque rservation saisie soit travers le back-office soit travers le service quil offre le front-office. Gestions de front-office Lapplication, travers son front-office, doit fournir au chef de production la possibilit de grer laperu du front-office en slectionnant les htels, les promotions, les circuits, les excursions et les voiture et les promotions afficher dans chaque bloque du front office. Rserver distant Lapplication fournit aux clients, travers les critres de recherche prdfinis, de choisir et saisit les dtails de son rservation.

I.2

Besoins non fonctionnels

Fiabilit
La premire exigence de notre application est la fiabilit : c'est--dire qu'elle doit effectuer les tches prvues dans les conditions normales d'utilisations. En effet, le fonctionnement de toutes les fonctionnalits de l'application doit tre sr quel que soit la squence ou le scnario tabli par l'utilisateur.

Scurit
Accs contrl des URL suivant les rles et le statut des utilisateurs connects. Le plus important est de sassurer de scuriser les donnes des agences : Chaque agence naccde ses propres donnes.

L'ergonomie
Lapplication doit prsenter des interfaces conviviales et ergonomiques afin de faciliter laccs aux donnes nimporte quel utilisateur.

Schma de base de donnes et migration des donnes

Le schma de la base de donnes MySQL du back office doit tre gnrique pour tre capable de couvrir les exigences des agences de voyages. Ceci donne la possibilit de migrer aisment des autres donnes vers ce schma et de garantir une aisance dans lcriture des Scripts. Migrer les donnes existantes dans la base de donnes Access vers une base MySQL aprs une phase doptimisation. Cette migration rsultera en des Scripts de migration (SQL, Batchs, autres ) qui devront migrer de faon automatique les donnes dAccess vers MySQL et sans pnibilit pour loprateur.

II. Les diagrammes des cas dutilisation

Lobjectif fondamental de cette tape est didentifier les principaux cas dutilisations. Nous nous intressons donc, la ralisation des diagrammes des cas dutilisation. Ces diagrammes dcrivent prcisment les besoins du client final et spcifient le comportement attendu par le systme dvelopper.

II.1

Identification des acteurs

Les acteurs dun systme sont les entits externes ce systme qui interagissent avec lui par lenvoi des vnements et la rception des informations de la part du systme. En se basant sur cette dfinition, notre application qui est compose par deux sous applications : Un back office commun pour toutes les agences qui est en interaction avec des acteurs principaux qui sont : -Ladministrateur de la part dIntercom-consulting

- Le directeur administratif et financier -Le chef de production - Le conseiller agence Un front office spcifique la premire agence cliente qui est en interaction avec deux principaux acteurs qui sont le client et le chef de production.

II.2

Diagramme de cas dutilisation du back office II.2.1 Diagramme de cas dutilisation global du back office

Pour mieux dcrire les besoins fonctionnels du back office, nous avons utilis un diagramme de cas dutilisation gnralis qui contient le systme et les acteurs prsent par la figure ci-dessous.

Figure- Diagramme de cas dutilisation global du back office

II.2.2 Diagramme de cas dutilisation de ladministrateur-Intercom

Le back office doit offrir les fonctionnalits ncessaires la socit Intercom-consulting, qui va soccuper de son hbergement et son maintenance, pour la gestion des agences abonnes aux services offerts par ce back. Le diagramme ci-dessous prsente les fonctionnalits ncessaires pour ladministrateur de la part dIntercom-consulting pour la gestion des agences abonnes.

Figure- Diagramme de cas dutilisation gestion des abonns

II.2.3 Diagramme de cas dutilisation du conseiller agence

A partir du back office, le conseiller dagence peut ajout une rservation, modifier, supprimer ou consulter les rservations fait par le client et de confirmer une rservation par la livraison dun reu au

client et une facture pour lhtel dans le cas dune rservation dans un htel et pour la direction de lagence dans les autres cas. Ces fonctionnalits doivent tre offertes au chef de production et au directeur administratif et financier comme le montre le diagramme ci-dessous.

Figure- Diagramme de cas dutilisation gestion de rservations

II.2.4 Diagrammes de cas dutilisation du chef de production

Le chef de production dans une agence de voyage soccupe de la gestion des offres dans les diffrentes fonctionnalits offertes par son agence. Le directeur administratif et financier accde aux fonctionnalits offertes au chef de production. II.2.4.1 Diagramme de cas dutilisation de gestion des htels Le chef de production doit avoir les fonctions ncessaires pour la gestion des htels avec lesquels son agence travaille. La figure ci-dessous spcifie les fonctionnalits quelle englobe la gestion des htels.

Figure Diagramme de cas dutilisation gestion des htels

II.2.4.2 Diagramme de cas dutilisation de gestion des voitures La figure ci-dessus montre les fonctionnalits ncessaires pour la gestion des voitures louer.

Figure Diagramme de cas dutilisation gestion des voitures

II.2.4.3 Diagramme de cas dutilisation de gestion des voitures Le chef de production peut programmer, consulter, modifier, supprimer un vnement spcial qui peut tre soit un circuit ou une excursion. Ces besoins sont spcifis dans la figure ci-dessous

Figure- Diagramme de cas dutilisation gestion des circuits et des excursions

II.2.4.4 Diagramme de cas dutilisation de gestion de billetterie On a deux possibilits pour la gestion des vols : -Le processus traditionnel : dans lequel les dtails des vols ne sont pas jours, une telle application nest pas lie directement Amadeus, qui est le fournisseur leader de service consternant les dtails des vols. Le conseiller doit vrifier la disponibilit de demande saisie par le client par rapport aux dernires mises jour en utilisant la version desktop dAmadeus.

-Le processus avanc : A laide des web services fournis par Amadeus, les dtails des vols sont jours. Le client peut payer directement en ligne. Notre application, tant destine tous les types des agences, doit tre capable de satisfaire les deux types de gestion des vols. On va sintresser au cas le plus dlicat qui est le premier ou le processus se fait dune manire traditionnelle, le deuxime cas est garantie en invoquant les web services dAmadeus dans le front office. La figure ci-dessous montre en dtails le use case gestion des vols.

Figure- Diagramme de cas dutilisation gestion des vols

II.2.4.5 Diagramme de cas dutilisation de gestion de promotions Les promotions couvrent toutes les fonctionnalits prcdemment dcrites. Le chef de production doit tre capable de grer les promotions dans les diffrents services fournis par son agence. La figure cidessous montre en dtail le cas dutilisation gestion des promotions.

Figure- Diagramme de cas dutilisation gestion des promotions

II.2.5 Diagramme de cas dutilisation du directeur administratif et financier

En plus des fonctionnalits dcrites, le directeur administratif et financier gre et suivre son agence travers les fonctionnalits dcrites par la figure ci-dessous.

Figure- Diagramme de cas dutilisation gestion de lagence

II.3 Diagramme de cas dutilisation de front office

II.3.1 Diagramme de cas dutilisation globale du front office La figure ci-dessous prsente le cas dutilisation gnralis pour mieux dcrire les besoins fonctionnels du front office.

Figure Diagramme de cas utilisation gnrale de front office

II.3.2 Diagramme de cas dutilisation gestion de front office La gestion de contenu du front office est un besoin indispensable pour les applications web. La figure cidessous prsente les fonctionnalits ncessaires pour la gestion de front office.

Figure-Diagramme de cas dutilisation gestion de front office

II.3.3 Diagramme de cas dutilisation gestion de rservation Le client tant lutilisateur principal du front office. Lapplication doit lui fournir les fonctionnalits ncessaires pour ajouter et manipuler ses rservations. La figure ci-dessous montre en dtail les besoins du client pour grer ses rservations.

Figure- Diagramme de cas dutilisation gestion de rservations

III. Les diagrammes de squences

III.1 Diagrammes de squences gestion de rservation Dans cette section nous allons prsenter les diagrammes de squences pour dtailler le processus de rservation effectue par le client travers le front office. Les fonctionnalits offertes au conseiller dagence partir du back office sont les mmes offertes aux clients travers le front office. III.1.1 Diagramme de squences de location voiture Vu que les processus de rservations (rservation vol, rservation htel, rservation circuit, rservation excursion, location voiture) seffectuent de la mme faon nous avons choisi de prsenter un entre eux, la figure ci-dessous prsente le diagramme de squence de location voiture.

Figure-Diagramme des squences location voiture

III.2 Diagrammes de squences gestion de front office A partir de front office le chef de production grer les blocs qui le constituent (publicit, promotion.). Ce cas dutilisation est dtaill par le diagramme de squence prsent par la figure ci-dessous

Figure-Diagramme des squences gestion de front office

Conclusion
La spcification des besoins nous a permis de dterminer les principales fonctionnalits de notre systme travers la prsentation des besoins fonctionnels et non fonctionnels, les diagrammes de cas dutilisation et de squences. Par la suite, il est indispensable de passer ltape de conception.