1.1.2. Les besoins fonctionnels de notre
système
Les besoins fonctionnels ou besoins métiers
représentent les actions que le système doit exécuter, il
ne devient opérationnel que s'il satisfait les besoins réels du
demandeur.
Notre logiciel doit couvrir principalement les besoins
fonctionnels suivants :
· Gestion d'Administration ;
· Gérer les inscriptions des élèves
;
· Gérer le paiement des frais scolaires ;
· Avoir une base de données pour le stockage et
enregistré tous les élèves ;
· Manipulation et mise à jour de la base de
données ;
· Application conçue devra fonctionner en mode 3 -
tiers (client, serveur de données, serveur d'application) :
· Chaque utilisateur possède un login et un mot de
passe unique pour accéder à cette application ;
· Administrateur où gérant peut ajouter,
supprimer, modifier ses données, gérer ses élèves,
les corps administratifs et les groupes tandis que l'agent le secrétaire
n'as que le droit de les consulter.
40
1.1.3. Capture de besoin non fonctionnels
Les besoins non fonctionnels sont des exigences qui ne
concernent pas spécifiquement le comportement du système
plutôt identifient les contraintes internes ou externes du
système. Les principaux besoins non fonctionnels de notre logiciel se
résument dans les points suivants :
· Le code doit être clair pour permettre des futures
évolutions ou améliorations ;
· La sécurité : l'application doit respecter
la confidentialité des données ;
· Un temps de réponse minime dans l'exécution
des tâches ;
· Un système disponible est accessible aux
utilisateurs 7 jours sur 7 et 24h sur 24 à n'importe quel moment ;
· L'ergonomie : l'application offre une interface
conviviale et facile à utiliser ;
· La Garantie de l'intégrité et la
cohérence des données à chaque mise à jour et
à chaque insertion ;
· Les interfaces de l'application doivent être
conviviales.
I.2. Diagramme de cas d'utilisation
Un cas d'utilisation est une manière spécifique
d'utiliser un système. Les acteurs sont à l'extérieur du
système ; ils modélisent tout ce qui interagit avec lui. Un cas
d'utilisation réalise un service de bout en bout, avec un
déclenchement, un déroulement et une fin, pour l'acteur qui
l'initie125. D'une manière générale le
maître d'ouvrage et les utilisateurs ne sont pas des informaticiens. Il
leur faut donc un moyen simple d'exprimer leurs besoins. C'est
précisément le rôle des diagrammes de cas d'utilisation qui
permettent de recueillir, d'analyser et d'organiser les besoins des
utilisateurs, et de recenser les grandes fonctionnalités d'un
système.
Bien souvent, le maître d'ouvrage et les utilisateurs ne
sont pas des informaticiens. Il leur faut donc un moyen simple d'exprimer leurs
besoins. C'est précisément le rôle des diagrammes de cas
d'utilisation qui permettent de recueillir, d'analyser et d'organiser les
besoins, et de recenser les grandes fonctionnalités d'un système.
Il s'agit donc de la première étape UML d'analyse d'un
système.
Un diagramme de cas d'utilisation capture le comportement d'un
système, d'un sous-système, d'une classe ou d'un composant tel
qu'un utilisateur extérieur le voit. Il scinde la fonctionnalité
du système en unités cohérentes, les cas d'utilisation,
ayant un sens pour les acteurs. Les cas d'utilisation permettent d'exprimer le
besoin des utilisateurs d'un système, ils sont donc une vision
orientée utilisateur de ce besoin au contraire d'une vision
informatique26.
25 BENOIT CHARROUX, AOMAR OSMANI, YANN THIERRY-MIEG,
(c) 2010 Pearson Education France - UML2, 3e édition.
26 MUSANGU LUKA, Analyse et conception des
applications objets avec Le Processus Unifié, Kinshasa, Editions de
l'Université Protestante au Congo, Juillet 2017, p47
41
| 
