Your SlideShare is downloading. ×
Modèle cas d'utilisation
Modèle cas d'utilisation
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Modèle cas d'utilisation

122

Published on

Un modèle de cas d'utilisation à utiliser pour l'analyse fonctionnelle d'une solution logicielle. Un exemple de formulation d'exigences est également disponible

Un modèle de cas d'utilisation à utiliser pour l'analyse fonctionnelle d'une solution logicielle. Un exemple de formulation d'exigences est également disponible

Published in: Software
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
122
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. cc-by-nd Jean-Paul Carmona 1.1. DOMAINE FONCTIONNEL « X » 1.1.1. Description générale [Décrire de manière synthétique le domaine fonctionnel « X », les acteurs et leur cas d’utilisation Illustrer avec un diagramme de cas d’utilisation : ] 1.1.2. Cas d’utilisation « X » [Décrire le cas d’utilisation en détail à travers une fiche descriptive.] Objectif <Décrire de manière plus détaillée l’objectif poursuivi par l’utilisateur> Acteur principal <Décrire l’acteur principal> Acteur(s) secondaire(s) <Décrire les éventuels acteurs secondaires> Déclencheur <Décrire l’événement (décision utilisateur ou événement système) qui déclenche le cas d’utilisation> Pré-conditions <Décrire dans une liste les conditions nécessaires à l’exécution du cas d’utilisation : disponibilité ou état de certaines informations, état d’un processus métier. Les conditions les plus complexes peuvent être extraites en tant que règles organisationnelles.> Scénario nominal <Décrire dans une liste les étapes à réaliser par l’utilisateur ou par le système pour atteindre l’objectif poursuivi, un sous-chapitre avec un diagramme de séquence UML peut être dédié à chaque scénario complexe> Scénario(s) alternatif(s) <Décrire avec une liste d’étapes chaque alternative offerte à l’utilisateur pour atteindre le même objectif, un sous-chapitre avec un diagramme de séquence UML peut être dédié à chaque scénario complexe> Scénario(s) d’erreur <Décrire avec une liste d’étapes,un sous-chapitre avec un diagramme de séquence UML peut être dédié à chaque scénario complexe> Post-conditions <Décrire l’état du système après l’exécution avec succès du cas d’utilisation, si nécessaire. Au cas où l’atteinte de l’objectif poursuivi décrit complètement l’état du système, la saisie de ces informations est inutile> <Acteur> <Nom du cas d’utilisation> <Nom du cas d’utilisation><Acteur2> <ActeurSecondaire3>
  • 2. cc-by-nd Jean-Paul Carmona 1.1.2.1. Maquettes d’IHM [Insérer ici les maquettes commentées des IHM mise en œuvre par le cas d’utilisation] 1.1.2.2. Exigences fonctionnelles du cas d’utilisation X [Lister sous forme d’exigence l’ensemble des règles de gestion fonctionnelles liées au cas d’utilisation (à l’acteur et à la fonction utilisée] 1.1.2.1. Exigences non fonctionnelles du cas d’utilisation X [Lister sous forme d’exigence l’ensemble des besoins techniques ou autre liés au cas d’utilisation, les exigences transverses doivent être regroupées dans un chapitre à part] [A propos des exigences Identifier chaque exigence avec un numéro unique,par exemple les chiffres du chapitre puis de 10 en 10. Format “<categorie>_<numero>” Exemple de catégories: IHM Interface Homme Machine;FON Fonctionel PER Performance; DES Design; CU Cas d’Utilisation IMP Implementation; LIV Livraison; ORG Organisation projet Une exigence doit être :  Mesurable : il doit y avoir un moyen de vérifier l'exigence  Utile : ne porterque sur les éléments nécessaires au système  Simple : une seule exigence à la fois  Traçable : ne pas changerde numéro, historiser les modifications  Non ambiguës: susceptible de n'avoir qu'une seule interprétation  Cohérente : ne pascontredire une autre exigence, utiliser le même vocabulaire  Réalisable : réaliste quant aux moyens mis en œuvre pour le projet  Exprimée en une phrase : un sujet + « doit » + verbe + complément, avec utilisation de la formulation affirmative plutôt que négative,  Justifiée et précisée parun narratif complémentaire Exemple : FON_1122010 chaque processus métier doit être décris en BPMN Le formalisme conseillé pour décrire les processus est BPMN. Les processus métiers existants et cibles sont normalement fournis par l'AMOA, dans le cas contraire il est possible de les modéliser avec Bonitasoft, ou Modelio, ou Microsoft Visio et le stencil BPMN ]

×