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

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
]