CAHIER DE CHARGE

Réalisé par :
NCIR SOULAIMAN

ABIDA YAHYA
 1. 1 Présentation du sujet

1.1.1 Problématique

De nos jours, le nombre des spécialistes de l'IT et de la technologie dans les différentes
spécialités est devenu énorme, sans qu’il existe une plate-forme qui les rassemble afin qu’ils
puissent communiquer et échanger des expériences et connaître les dernières nouvelles de l’IT.
Remarque Le consultant IT, appelé aussi consultant informatique, est spécialisé dans les
technologies de l'information et de la communication et maîtrisant tous les systèmes
d'information, qui après les avoir analyser, diagnostic à l'entreprise les différents besoins que le
système d'information nécessite.

1.1.2 Objectif du projet

Développer une application web permettra aux utilisateurs :

 Communique entre les utilisateurs.
 Poser des publication.
 Interagir avec les publications des utilisateurs.
 Faire des lives.
 Suivre les autres utilisateurs.

1.1.3 Etude fonctionnelles

Les besoins fonctionnels sont une description des fonctions d’un système en vue
de sa réalisation. Lors de la distinction des besoins par acteur on tient compte de la
nature de l’application. Ces besoins sont les suivants :

Tableau 1.1 : Les besoins fonctionnels

Acteur Fonctionnalité

Super administrateur, -Accéder à l’application

administrateur et Authentication par l’e-mail ou le nom
utilisateur d’utilisateur et le mot de
passe
-Changer ses
Gestion du profil informations
personnelles
-Modifier les paramètres
Gestion des paramètres du compte
 -Ajouter, supprimer et
Super administrateur Gestion des bloquer des
administrateurs adminisateurs, les rendre
des super
administrateurs
-Supprimer et bloquer
Gestion des utilisateurs des utilisateurs
-Supprimer et bloquer
Administrateur Gestion des utilisateurs des utilisateurs
-Bloquer un utilisateur,
Gestion des signals supprimer le
commentaire ou la
publication, ou bien ne
prendre aucune décision
-Créer un compte
Utilisateur Inscription
-Faire et supprimer des
Gestion des lives lives
-Signaler des
Gestion des signals commentaires et des
publications.
-Ajouter, supprimer et
Gestions de contenu modifier des publications

-Ajouter, supprimer et
Intéragir avec les modifier des
publications commentaires, ajouter et
supprimer des likes (like,
dislike, haha, triste..)
-Ajouter, supprimer des
Gestion de la liste des utilisateurs de la liste des
amis amis, et envoyer une
invitation à des
utilisateurs.

1.1.4 Etude non fonctionnelles

Les besoins non fonctionnels sont des contraintes internes et externes désirées
du système, sont indispensables et permettant l’amélioration de la qualité logicielle de
notre système. Ce dernier doit répondre aux exigences suivantes :

 Fiabilité : L’application doit fonctionner de manière cohérente sans erreurs et

doit être satisfaisante, les données envoyées via l’application, ou fournies par
cette dernière doivent être fiables.
  Temps de réponse : L’application doit rendre une réponse dans un temps
minimal.
 Ergonomie et bonne interface  : L’application doit être adaptée à l’utilisateur
sans qu’il ne fournisse aucun effort (utilisation claire et facile) de point de vue
navigation entre les différents pages, couleurs et mise en textes utilisés.
 Sécurité : L’application doit être sécurisée par la gestion des droits d’accès.
 Efficacité : L’application doit être fonctionnelle quelque soient les circonstances
entourant l’utilisateur.
 Maintenance : Le code doit être maintenable pour faciliter toute opération
d’amélioration ou d’optimisation.
 Extensibilité : L’application doit s’adapter aux évolutions et extensions

1.2 Conduit du projet

1.1.4.1 Élaboration du cahier des charges

Dans cette partie, nous avons détaillé les besoins pour mener à bien notre projet
et mieux comprendre la problématique. Nous avons étudié les droits de profil de chacun
des utilisateurs de l’application pour assurer la sécurité d’accès à l’information, intégrité
des informations sensibles et la disponibilité des données.

1.1.4.2 Plan de management

Cette partie consiste à élaborer un planning pour la gestion de toutes les tâ ches à
réaliser, en précisant la durée nécessaire et suffisante pour l’accomplissement de chaque
mission. Il s’agit de la phase organisationnelle pour réussir notre projet. Pour les
activités envisagées, elles sont décrites par les étapes qui constituent l’enchaînement de
la réalisation de notre projet.

1.1.4.3 Etude conceptuelle et technique

Cette partie quant à elle représente l’étude conceptuelle de notre projet, c’est une
phase très importante avant de commencer le développement de n’importe quelle
application informatique. Pour cela, nous avons choisi de travailler avec le langage de
modélisation graphique UML (Unified Modeling Language) pour fournir une méthode
normalisée afin de visualiser la conception du système.
Analyse et conception
 
 1.2 Introduction
Ce chapitre présente l’analyse et la conception du projet, qui consiste à présenter
le language UML, et les diagrammes de cas d’utilisation et diagrammes de classes.

1.3 Présentation du language UML

Le Langage de Modélisation Unifié [3], de l'anglais Unified Modeling Language (UML), est
un langage de modélisation graphique à base de pictogrammes conçu comme une
méthode normalisée de visualisation dans les domaines du développement logiciel et
en conception orientée objet.

L'UML est une synthèse de langages de modélisation objet

antérieurs : Booch, OMT, OOSE. Principalement issu des travaux de Grady Booch, James
Rumbaugh et Ivar Jacobson, UML est à présent un standard adopté par l'Object
Management Group (OMG). UML 1.0 a été normalisé en janvier 1997; UML 2.0 a été
adopté par l'OMG en juillet 20051. La dernière version de la spécification validée par
l'OMG est UML 2.5.1 (2017).

UML est destiné à faciliter la conception des documents nécessaires au développement

d'un logiciel orienté objet, comme standard de modélisation de l'architecture logicielle.
Les différents éléments représentables sont :

 Activité d'un objet/logiciel

 Acteurs
 Processus
 Schéma de base de données
 Composants logiciels
 Réutilisation de composants.

Il est également possible de générer automatiquement tout ou partie du code, par

exemple en langage Java, à partir des documents réalisés.

1.4 Diagrammes de cas d’utilisation

1.4.1 Définition
Les diagrammes de cas d’utilisation [4] sont des diagrammes UML utilisés pour
donner une vision globale du comportement fonctionnel d’un système logiciel. Ils sont
utiles à des présentations auprès de la direction ou des acteurs d’un projet, mais pour le
développement, les cas d’utilisation sont plus appropriés. Un cas d’utilisation représente
une unité discrète d’interaction entre un utilisateur (humain ou machine) et un système.
Il est une unité significative de travail. Dans un diagramme de cas d’utilisation, les
utilisateurs sont appelés acteurs, ils interagissent avec les cas d’utilisation.

1.4.2 Diagrammes

1.4.2.1 Super administrateur

Diagramme de cas d’utilisation correspondant au super administrateur.

Figure 2.1 Diagramme de cas d’utilisation du super administrateur

Ce diagramme décrit les cas d’utilisation pour le super administrateur qui a pour rô les :
la gestion des administrateurs et des utilisateurs.

1.4.2.2 Côté administrateur

Diagramme de cas d’utilisation correspondant à l’acteur administrateur.

 Figure 2.2 Diagramme de cas d’utilisation de l’administrateur

Ce diagramme décrit les cas d’utilisation pour l’administrateur qui a pour rô les : la
gestion de profil, des paramètres du compte, des utilisateurs, et la gestion des signals.
 1.4.2.3 Côté utilisateur
Figure 2.3 Diagramme de cas d’utilisation de l’utilisateur

Ce diagramme décrit les cas d’utilisation pour l’utilisateur qui a pour rô les : la gestion de
profil, du profil, des paramètres du compte, des signals, des lives, du contenu, de la liste
des amis, intéragir avec les publication et l’inscription.

1.4.1 Diagrammes

1.4.1.1 L’authentification et l’inscription

Le diagramme associé à l’authentification et l’inscription.

 Figure 2.4 Diagramme de classe de l’authentification et l’inscription

1.4.1.2 La gestion du contenu et des signals

Le diagramme associé à la gestion du contenu et des signals.

Figure 2.5 Diagramme de classe de la gestion du contenu et des signals

 1.5 Conclusion

Dans ce chapitre, j’ai procédé à l’identification et la présentation des diagrammes de

cas d’utilisation et de classes.