2
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>

Modèle cas d'utilisation

Embed Size (px)

Citation preview

Page 1: Modèle cas d'utilisation

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>

Page 2: Modèle cas d'utilisation

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 porter que sur les éléments nécessaires au système

Simple : une seule exigence à la fois

Traçable : ne pas changer de numéro, historiser les modifications

Non ambiguës : susceptible de n'avoir qu'une seule interprétation

Cohérente : ne pas contredire 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 par un 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

]