Section 2 : Spécification des besoins
2.1.
Besoins fonctionnels
Les besoins fonctionnels expriment une action qui doit
être menée sur l'infrastructure à définir en
réponse à une demande. C'est le besoin exprimé par le
client.
Pour cela, nous aurons ;
· Besoin de segmenter le réseau en créant
un VLAN. Deux raisons sont à la base de cette segmentation du
réseau. La première a pour but d'isoler le trafic entre les
segments. La seconde a pour but de fournir davantage de bande passante par
utilisateur et par groupe de serveur par la création de domaine de
collision de petite taille ;
Ø Besoin de mettre en place une sécurité
qui permettra à tous le VLAN de ne pas communiquer.
Ø Besoin de réduction des protocoles des PC.
L'une des méthodes les plus efficaces pour réduire le trafic sur
le réseau est de diminuer le nombre de protocoles utilisés.
Lorsqu'un ordinateur Microsoft Windows doit envoyer des informations à
un autre ordinateur, il les envoie en utilisant chaque protocole
chargé.
Ø Par exemple, si un ordinateur est configuré
avec TCP/IP, NetBEUI et IPX/SPX, il envoie les mêmes informations
à trois reprises, une pour chaque protocole. Imaginez maintenant
l'impact si ces trois protocoles sont chargés sur chaque ordinateur du
réseau.
2.1.
Etude du métier
a)
Description du métier
Le métier est definie comme etant un rassemblement
d'activités permettant de repondre au besoin de l'utilisateur.
b)
Description textuelle du métier
Elle se déroule de manière suivante : le
secrétariat de l'administration gère tous les mails en rapport
avec l'administration et accède aux ressources (imprimante, photocopie,
la saisi de documents et fait rapport au Directeur de l'Administration. Toutes
les impressions, photocopie se passent au niveau du pool informatique moyennant
un support, le Bureau consulte les mails et fait la saisie et l'impression des
documents, le secrétariat de commission imprime et consulte les mails
donc il accède presque a toutes les ressources de l'Institution.
2.1.3. Identification des acteurs
1.
capture des besoins fonctionnels :
Cette section traite du rôle que tient UML pour
compléter la capture des besoins fonctionnels ébauchés
durant l'étude préliminaire. La technique des cas d'utilisation
est la pierre angulaire de cette étape. Elle nous permettra de
préciser l'étude du contexte fonctionnel du système, en
décrivant les différentes façons qu'auront les acteurs
d'utiliser le futur système.
2.1.
2.LE DIAGRAMME DE CAS D'UTILISATION
Il s'agit de la solution UML pour représenter le
modèle conceptuel. Le digramme de cas d'utilisation montre les
interactions fonctionnelles entre les acteurs et le système à
l'étude. Il est utilisé dans l'activité de
spécification des besoins.
Scenario : Un scenario est une séquence
d'évènement se déroulant dans le temps pour un cas
d'utilisation du système.
Système administration réseau
Figure 10 : Diagramme deCAS
d'utilisateur système
Source : donne de terrain
b. Cas d'utilisation : Est une abstraction de plusieurs
chemins d'exécution. Les cas d'utilisation sont justement des outils
construits pour définir les besoins, développant de surcroit le
point de vue des utilisateurs.
Notons cependant qu'en ce qui concerne notre cas nous aurons a
analyse un seul cas d'utilisation et qui affectera automatiquement un seul
scenario avant de passer au diagramme de collaboration.
Cas d'utilisation « Gérersystème »
Objectifs :
1. L'Administrateur réseau peut créer, modifier,
ajouter, et supprimer un compte et mot de passe. Le compte et mot passe est
valide, initialise et enregistre par l'administrateur réseau ;
1. cas d'utilisation : gère l'huissier
| 
