II.6.2. Recensement des besoins
La spécification des besoins du système futur
dépend de la solution imposée. A ce propos, pour le
présent travail nous seront à même de spécifier au
recenser les différents besoins fonctionnels et non fonctionnels requis
pour l'implémentation de la solution finale.
A. Les besoins fonctionnels
C'est une étape d'étude générale
et détaillée (ou spécification). Le but de cette phase est
de concevoir ou spécifier ce qui doit être réalisé
pour atteindre l'objectif. Les fonctionnalités qui seront
réalisées peuvent être décrites de la manière
suivante :
- Faciliter les fouilles des livres dans les
étagères ;
- Ajouter, Modifier, Supprimer des livres dans un
rayon ;
- Ajouter, Modifier, Supprimer des étagères dans
la bibliothèque.
B. Les besoins non fonctionnels
Les besoins non fonctionnels sont indispensables et permettent
à l'amélioration de la qualité du logiciel du
système. Ces besoins non fonctionnels seront pris en
considération au cours du développement de
l'application :
- Ergonomie et convivialité : l'application doit
fournir aux différents utilisateurs une interface (espace des
utilisateurs). ;
- La latence (délai de réponse) doit être
raisonnable ;
- Portabilité : l'application doit être portable,
c'est-à-dire fonctionnelle sur n'importe quel machine
(ordinateurs) ;
- Restauration des valeurs par défaut ;
- Sécurité : l'application doit assurer un
niveau minimum de sécurité pour les informations
traitées.
II.6.3. Identification des acteurs
Un acteur représente un rôle joué
par une entité externe (utilisateur humain, dispositif
matériel ou autre système) qui interagit directement ou
indirectement avec le système. Il peut consulter et/ou modifier
directement l'état du système. Les acteurs qui interagissent avec
le système sont les suivant :
1. Chercheurs : c'est une personne
physique qui vient consulter les livres et/ou travaux ;
2. Gestionnaire : il s'occupe de la
gestion des livres ;
3. Réceptionniste : chargé
de la réception de chercheurs et de les guidés ;
4. L'administrateur : le coordonnateur
en chef de la bibliothèque.
II.6.4. Le diagramme de contexte
Ce diagramme permet de limiter le périmètre du
système et montre quel acteur interagit directement avec le
système
II.6.5 Identification des cas d'utilisations
Un cas d'utilisation représente l'ensemble de
séquences d'actions réalisées par le système et
produisant un résultat observable intéressant pour un acteur
particulier. Un cas d'utilisation modélise un service rendu par le
système. Il exprime les interactions acteur/système et apporte
une valeur ajoutée « notable » à l'acteur
concerné. (Frederick, DIGALLO, 2007).
CAS D'UTILISATION
|
ACTEUR
|
INTENTION
|
ACTION
|
Consulter livre
|
réceptionniste (principal) Chercheur (secondaire)
|
Le chercheur se présente pour consulter un livre
|
Identifier le chercheur, consulter catalogue, paiement
caution, présenter carte abonnement
|
Gérer livre
|
Gestionnaire (principal) Administrateur (secondaire)
|
La gestion des livres et travaux afin de le retrouvés
facilement
|
Ajouter, supprimer, les livres et les classés dans les
rayons
|
Reclassement livre
|
Réceptionniste (principal) chercheur (secondaire)
|
Reclasser les livres dans raisons après consultation
|
Livre consulté, livre trouvé.
|
Enregistrer chercheur
|
Gestionnaire (principal) Chercheur (secondaire)
|
Enregistrer le chercheur dans la base des données afin
de l'identifier
|
Paiement caution, dépôt photo passeport,
abonnement effectué
|
Mettre à jour de la base des données des
abonnés
|
Gestionnaire (principal) Chercheur (secondaire)
|
Mettre à jour la base des données lorsque la
carte expire
|
Ajout, Suppression abonnés, péremption carte
|
|