Grille d`inspection des cas d`utilisation, version 1.4
publicité
Grille d'inspection des cas d'utilisation version 1.4 Grille d'inspection des cas d'utilisation, version 1.4 # RUC1 RUC2 RUC3 RUC4 RUC5 RUC6 RUC7 Chaque question doit être répondue positivement. Règle Est-ce que le titre commence par un verbe, forme active et temps présent? Est-ce que le titre décrit bien l'objectif du cas d'utilisation? Est-ce que l'acteur principal est bien identifié et est spécifique? Est-ce que l'objectif est bien défini, représente un succès du scénario principal? Est-ce que les pré-conditions / préalables sont pertinents et particuliers à ce cas d'utilisation.? Est-ce que les pré-conditions / préalables sont vraiment obligatoires? Le déclencheur est présent et n'est pas contenu dans les pré-conditions / préalables? RUC8 RUC9 RUC10 RUC11 RUC12 RUC13 RUC14 RUC15 RUC16 RUC17 Est-ce bien l'acteur principal qui déclenche le scénario principal ? Est-ce que le scénario principal se déroule jusqu'à l'atteinte de l'objectif de l'acteur? Est-ce que l'acteur ou le système a clairement l'initiative, dans chaque étape des scénarios,? Est-ce que le scénario principal possède entre 3 et 20 alternatives acteur-système? Est-ce que chaque étape utilise la forme active et le temps présent ? Est-ce que le cas d'utilisation ne décrit pas l'interface utilisateur ou une solution technique ? Est-ce que l'on voit clairement et explicitement les informations transmises? Est-ce que le déclencheur de chaque scénario alternatif bien identifié? Est-ce que la numérotation des scénarios alternatifs est claire? Est-ce que la fin de chaque scénario alternatif est clairement exprimée? RUC18 RUC19 RUC20 RUC21 Est-ce que tout le texte du cas d'utilisation est lisible et compréhensible par les utilisateurs? Est-ce que tout le texte du cas d'utilisation est limité au vocabulaire du domaine du client? Est-ce que les questions ouvertes sont complètes ? Est-ce que le cas d'utilisation est complet et correct? Oui / Non / Commentaires Il s'agit d'une grille permettant d'améliorer la qualité des cas d'utilisation, spécifiquement dans le cadre du cours LOG220. Il ne s'agit pas d'une liste exhaustive. Adapté par Bernard Baraby, amélioré par JF Couturier, d’après « Rédiger des cas d’utilisation efficaces », Alistair Cockburn, Eyrolles. Grille d'inspection des cas d'utilisation version 1.4 Explications des règles RUC1 Est-ce que le titre commence par un verbe, forme active et temps présent? Un cas d'utilisation représente une action. La forme active aide à identifier qui est l'acteur principal d'un cas d'utilisation. Le temps présent tend simplement à uniformiser les noms de cas d'utilisation est à les simplifier. RUC2 Est-ce que le titre décrit bien l'objectif du cas d'utilisation? Au départ, seul le titre d'un cas d'utilisation est connu. Ce titre doit donc être particulièrement explicite. RUC3 Est-ce que l'acteur principal est bien identifié et est spécifique? Éviter les noms d'acteur vague. Un commis peut faire n'importe quoi. Un commis aux ventes est plus explicite. RUC4 Est-ce que l'objectif est bien défini, représente un succès pour l'acteur? Il doit s'agir de ce que l'acteur principal obtient si le scénario principal se déroule jusqu'à la fin. RUC5 Est-ce que les préalables sont pertinents et particuliers à ce cas d'utilisation.? Éviter les préalables applicables à tous les cas d'utilisation du système, comme "l'utilisateur doit avoir les droits d'accès" ou " le système est démarré. RUC6 Est-ce que les préalables sont vraiment obligatoires? Il ne doit pas avoir de vérifications des préalables dans le cas d'utilisation RUC7 Le déclencheur est présent et n'est pas contenu dans les préalables? Le scénario doit commencer par un déclencheur. Rare exception: une étape qui explique la suite, par exemple: "un client arrive à la caisse… la caissière démarre une nouvelle vente". RUC8 Est-ce bien l'acteur principal qui déclenche le scénario principal ? RUC9 Est-ce que le scénario principal se déroule jusqu'à l'atteinte de l'objectif de l'acteur? RUC10 Est-ce que l'acteur ou le système a clairement l'initiative, dans chaque étape des scénarios,? Chaque étape doit être amorcé par: "le système action …" ou par "la caissière action…". RUC11 Est-ce que le scénario principal possède entre 3 et 20 alternatives acteur-système? Pour éviter les cas d'utilisation trop courts (généralement, signe qu'il devra être intégré à un autre cas d'utilisation) ou trop longs (très difficile à implanter). Adapté par Bernard Baraby, amélioré par JF Couturier, d’après « Rédiger des cas d’utilisation efficaces », Alistair Cockburn, Eyrolles. Grille d'inspection des cas d'utilisation version 1.4 RUC12 Est-ce que chaque étape utilise la forme active et le temps présent ? La forme active tend à rendre difficile l'identification de celui qui fait l'action. Le temps présent est le plus simple et uniformise le style littéral des cas d'utilisation. RUC13 Est-ce que le cas d'utilisation ne décrit pas l'interface utilisateur ou une solution technique ? Les éléments de l'interface utilisateur seront déterminés plus tard (par un ergonome ou un graphiste). Les éléments techniques peuvent faire partie des spécifications non fonctionnelles ou seront déterminés par l'équipe de développement, plus tard. Ne pas parler de base de données, de fichier, etc. RUC14 Est-ce que l'on voit clairement et explicitement les informations transmises? Il ne suffit pas d'indiquer que l'usager entre l'en-tête d'une facture. Il faut indiquer les informations (champs) requises. Cette information peut être définie en terme de modèle du domaine. Pour éviter de surcharger le scénario, il est possible d'avoir un ajout à la fin du cas d'utilisation, définissant explicitement les informations requises. RUC15 Est-ce que le déclencheur de chaque scénario alternatif bien identifié? Très important. Un scénario alternatif ne doit pas commencer par une action de traitement, mais par une condition. RUC16 Est-ce que la numérotation des scénarios alternatifs est claire? Différentes méthodes existent. La plus simple est de commencer par le numéro de l'étape, dans le scénario principal et de terminer par une lettre. C'est la lettre qui indique la condition. Les étapes suivantes (exécutantes) sont alors numérotées avec le même préfixe. Exemple: … scénario principal … 5 – La caissière indique le montant du paiement comptant …. …. Scénario alternatif … 5a La caissière a indiqué un paiement par carte de crédit 5a1 Le système demande le numéro de carte de crédit. … RUC17 Est-ce que la fin de chaque scénario alternatif est clairement exprimée? Il faut explicitement indiquer si le scénario principal s'arrête ici, s’il continue à l'étape 6, … RUC18 Est-ce que tout le texte du cas d'utilisation est lisible et compréhensible par les utilisateurs? Le cas d'utilisation doit pouvoir être lu, compris et approuvé par les utilisateurs éventuels du système. Il faut être cohérent avec le modèle du domaine et le glossaire. RUC19 Est-ce que tout le texte du cas d'utilisation est limité au du vocabulaire du domaine du client? Il faut être cohérent avec le modèle du domaine et le glossaire. RUC20 Est-ce que les questions ouvertes sont complètes ? Des cas particuliers, des erreurs possibles, etc. RUC21 Est-ce que le cas d'utilisation est complet et correct? Complet: il ne manque pas d'élément. Correct: corresponds bien aux attentes des clients. Adapté par Bernard Baraby, amélioré par JF Couturier, d’après « Rédiger des cas d’utilisation efficaces », Alistair Cockburn, Eyrolles.
