3.1.3 Diagramme de cas d'utilisation
général
Figure 3: Diagramme de cas d'utilisation
général
|
|
Chapitre II : Spécification et analyse des
besoins
|
3.1.4 Affectation des priorités
Les cas d'utilisation peuvent être classés selon
leur ordre d'importance pour chacun des acteurs. Ce classement donne lieu
à la définition d'un ordre de priorité pour les cas
d'utilisation.
Dans notre cas, les cas d'utilisation qui s'avèrent les
plus prioritaires ont la priorité la plus forte « 1 » et les
moins prioritaires ont la priorité « 2 ».
Ceci est représenté dans le tableau ci-dessous :
Cas Utilisation 6'ar,hLQ,ifiLI
|
Acteur
Tous les utilisateurs
|
Priorité 1
|
Gérer Marché
|
L'opérateur Service Marché
|
1
|
Gérer Commission
|
L'opérateur Service Marché
|
1
|
Gérer soumissionnaire
|
L'opérateur Service Marché
|
1
|
Consulter situation marché
|
Direction initiatrice
|
1
|
Initialiser marché
|
Direction initiatrice
|
1
|
Valider cahier des charges
|
Direction Initiatrice
Direction administrative et juridique
|
2
|
Valider contrat
|
Direction administrative et juridique
|
2
|
Proposer membre de la commission
|
Direction administrative et juridique
|
2
|
Ajouter plis
|
Responsable bureau ordre central
|
1
|
Tableau 2:Affectation des priorités des cas
d'utilisations
|
|
Chapitre II : Spécification et analyse des
besoins
|
3.1.5 Raffinement des cas utilisation prioritaire
a Raffinement du cas d'utilisation « S'authentifier
»
Figure 4: Raffinement CU S'authentifier
Cas Utilisation : « S'authentifier Acteur
principal
|
»
bous les utilisateurs du système
|
Pré-condition
|
L'utilisateur est connecté au serveur
|
Post-condition
|
L'utilisateur est connecté au système, et
redirigé vers la section qui lui convient
|
Scénario nominal
|
1) L'utilisateur saisit son login et mot de passe
2) L'utilisateur valide
3) Le système vérifie les données
saisies
|
Exception
|
Un message d'erreur est affiché le cas d'essais
échéant
|
Tableau 3:Description textuelle du CU
S'authentifier
|
|
Chapitre II : Spécification et analyse des
besoins
|
b Raffinement du cas d'utilisation « Gérer
Marché »
Figure 5: Raffinement CU « Gérer
marché »
Acteur principal
|
Cas Utilisation : « Gérer marché
» L'opérateur Service Marché
|
Pré-condition
|
L'opérateur service marché doit être
connecté au serveur et identifié
|
Post-condition
|
S'il y a des modifications concernant un marché elles sont
enregistrées dans la base de données
|
Scénario nominal
|
1) Le système affiche une liste de marchés
2) L'opérateur Service Marché peut ajouter un
nouvel marché
3) L'opérateur Service Marché choisit un
marché
L'opérateur Service Marché peut modifier un
marché L'opérateur Service Marché saisit les nouvelles
données
L'opérateur Service Marché confirme la
modification Le système enregistre les nouvelles données
4) L'opérateur Service Marché peut supprimer le
marché sélectionné
Le système demande une confirmation de suppression
L'opérateur Service Marché confirme
Le système enregistre la suppression
5) L'opérateur Service Marché peut faire ainsi les
différentes opérations de gestion sur les offres (Consultation
des offres existantes, Ajout de nouvelle offre, suppression d'une offre ou bien
mise à jour d'une offre) concernant un marché
sélectionné
|
Exception
|
Un message d'erreur est affiché le cas
échéant
|
Tableau 4:Description textuelle du CU Gérer
marché
|
|
Chapitre II : Spécification et analyse des
besoins
|
c Raffinement du cas d'utilisation « Gérer
Commission »
Figure 6:Raffinement CU « Gérer commission
»
Acteur principal
|
Cas Utilisation : « Gérer commission »
L'opérateur Service Marché
|
Pré-condition
|
L'opérateur service marché doit être
connecté au serveur et identifié
|
Post-condition
|
S'il y a des modifications concernant une commission elles sont
enregistrées dans la base de données
|
Scénario nominal
|
1) Le système affiche une liste des commissions
2) L'opérateur Service Marché peut ajouter une
nouvelle commission
3) L'opérateur Service Marché choisit une
commission L'opérateur Service Marché peut modifier la commission
L'opérateur Service Marché saisie les nouvelles données
L'opérateur Service Marché confirme la modification Le
système enregistre les nouvelles données
4) L'opérateur Service Marché peut supprimer la
commission sélectionnée
Le système demande une confirmation de suppression
L'opérateur Service Marché confirme
Le système enregistre la suppression
5) L'opérateur Service Marché peut affecter la
commission a un marché
|
Exception
|
Un message d'erreur est affiché le cas
échéant
|
Tableau 5:Description textuelle du CU Gérer
commission
|
|
Chapitre II : Spécification et analyse des
besoins
|
d Raffinement du cas d'utilisation « Gérer
Soumissionnaire »
Figure 7:Raffinement CU « Gérer
Soumissionnaire »
Acteur principal
|
Cas Utilisation : « Gérer soumissionnaire
» L'opérateur Service Marché
|
Pré-condition
|
L'opérateur service marché doit être
connecté au serveur et identifié
|
Post-condition
|
S'il y a des modifications concernant un ou plusieurs
soumissionnaires elles sont enregistrées dans la base de
données
|
Scénario nominal 1
|
1) Le système affiche une liste de soumissionnaires
2) L'opérateur Service Marché choisit un
soumissionnaire
2.1) L'opérateur Service Marché peut modifier les
données du
soumissionnaire sélectionné
2.1.1) L'opérateur Service Marché saisit les
nouvelles données Confirme la modification
2.1.2) Le système enregistre les nouvelles
données
2.2) L'opérateur Service Marché peut supprimer le
soumissionnaire
sélectionné
2.2.1) Le système demande une confirmation de
suppression
2.2.2) L'opérateur Service Marché confirme
2.2.3) Le système enregistre la suppression
3) L'opérateur Service Marché peut ajouter un
nouvel soumissionnaire
|
Exception
|
Un message d'erreur est affiché le cas
échéant
|
Tableau 6:Description textuelle du CU Gérer
soumissionnaire
|
|
Chapitre II : Spécification et analyse des
besoins
|
e Raffinement du cas d'utilisation « Consulter
situation marché»
Figure 8: Raffinement CU « Consulter situation
marché »
Acteur principal
|
Cas Utilisation : « Consulter situation
marché » Direction initiatrice
|
Pré-condition
|
L'utilisateur doit être connecté au serveur et
identifié
|
Post-condition
|
Les détails concernant la situation actuelle du
marché sont affichés
|
Scénario nominal
|
1) Le système affiche la situation du dernier
marché lancé par la direction
2) Le système affiche une liste de tous les
marchés lancé par la direction
3) L'utilisateur choisit un marché
4) Le système affiche la situation du marché
sélectionné
|
Exception
|
Si la direction n'a lancé aucun marché, un message
d'information est affiché
|
Tableau 7:Description textuelle du CU Consulter situation
marché
f Raffinement du cas d'utilisation « Initialiser
marché»
Figure 9: Raffinement CU « Initialiser marché
»
Acteur principal
|
Cas Utilisation : « Initialiser marché »
Direction initiatrice
|
Pré-condition
|
L'utilisateur doit être connecté au serveur et
identifié
|
Post-condition
|
Les données concernant le nouvel marché
initié sont enregistrées
Et un mail de notification est envoyé vers le service
marché, ainsi que la direction juridique et administrative
|
Scénario nominal
|
1) L'utilisateur saisit les données du nouveau
marché
2) L'utilisateur valide
3) Le système enregistre le nouveau marché
|
Exception
|
Un message d'erreur est affiché dans le cas marché
déjà initié
|
Tableau 8:Decription textuelle du CU Initialiser
marché
|
|
Chapitre II : Spécification et analyse des
besoins
|
Cas Utilisation :« Ajouter pli»
Acteur principal Bureau ordre central
Pré-condition L'utilisateur doit etre
connecté au serveur et identifié
Post-condition Le pli est enregistré dans
la base de données
Scénario nominal 1) Le système
affiche une liste de marché en phase de réception de plis
2) L'agent du Bureau Ordre Centrale choisit un marché
3) L'utilisateur saisit les données du no
4) L'utilisateur valide
5) Le système enregistre le pli
Exception Si un pli déjà.
ajouté un message d'en-eur est affiché
g Raffineme17 du caM3utilisation « Ajouter
plis»
Figure 10: Raffinement CU « Ajouter plis
» Tableau 9:Description textuelle du CU Ajouter plis
|