Revue du rapport de faisabilité, spécifications et critères d'acceptation

Objectifs de cette séance

• Soumettre un rapport de faisabilité à une revue critique et le corriger
• Traduire des besoins validés en spécifications fonctionnelles
• Rédiger des critères d'acceptation vérifiables
• Assurer la traçabilité entre besoin, exigence et critère d'acceptation

Première heure : revue croisée et remise du livrable 2. Ensuite : 2 heures de cours, avec deux ateliers.

Où nous en sommes

Plan de la séance : revue croisée et remise (60 min), pause (10 min), des besoins aux exigences (50 min), critères d'acceptation et traçabilité (60 min).

Dix-huit jours ont passé. À avoir en tête : deux demandes du président, comité de décision le 30 novembre, seuil de criticité à 12. Pour un Go sous conditions : un test, un responsable et une date par condition.

TD : revue croisée des rapports

Un rapport se juge mieux par un lecteur qui ne l'a pas écrit : vous relisez un autre groupe, puis vous corrigez le vôtre.

Durée : 60 min | Modalité : groupe, cas Zinc Média

1. 8 min. Relisez votre recommandation, lisez la grille et le barème, transmettez votre rapport au groupe qui vous relit
2. 22 min. Relisez le rapport reçu avec la grille, une preuve par critère
3. 5 min. Deux membres vont expliquer vos 2 corrections prioritaires au groupe relu, les autres écoutent le groupe qui vous a relus
4. 20 min. Corrigez votre rapport, confirmez ou révisez votre recommandation, écrivez en une ligne ce que vous spécifierez demain
5. 5 min. Remettez le livrable 2

Pour un No-Go : ce que vous proposez à la place figure parmi vos scénarios comparés.

La grille de revue croisée

Pour chaque critère : oui, en partie ou non, avec la page ou le tableau qui le prouve.

Exemple de ligne remplie : critère 6, en partie. Tableau de la page 5 : le risque coté 16 a une action et un responsable, mais pas d'échéance.

En bas de grille : 2 points forts, et les 2 corrections à faire en priorité.

Livrable 2 : ce qui est noté

Remise : un seul PDF par groupe, nommé L2_nom-du-cabinet.pdf, la grille reçue en dernière page, remis au formateur avant la fin du TD.

La note est une note de groupe. C'est la version remise, donc corrigée après la revue, qui est notée.

Vue d'ensemble : de la décision aux spécifications

Votre rapport dit s'il faut y aller. Le cours qui commence répond à la question suivante : que faut-il construire, exactement ?

• On repart de vos besoins priorisés et de ce que votre recommandation retient
• Les étapes 1 à 4 écrivent l'exigence, l'étape 5 écrit son critère d'acceptation, l'étape 6 vérifie qu'il ne manque rien
• Demain, vous déroulerez ces six étapes sur Zinc Média : c'est le livrable 3

Le repère en haut de chaque slide indique l'étape en cours.

Six étapes, six questions

Tous les exemples suivent le projet de la séance 2 : le portail de réservation des médiathèques. Vous appliquerez la démarche à Zinc Média demain.

Le fil de la séance : besoin, exigence, critère

Trois mots reviennent à chaque étape. Ils forment une chaîne : chaque maillon répond au précédent.

Le rapport de faisabilité dit s'il faut le faire. Les spécifications disent quoi faire, assez précisément pour qu'on puisse le vérifier.

Exigence fonctionnelle ou non fonctionnelle

Première étape : traduire chaque besoin en exigences. Il en existe deux sortes, et la seconde est celle qu'on oublie.

Familles courantes d'exigences non fonctionnelles : performance, disponibilité, sécurité et confidentialité, accessibilité, compatibilité, conformité, maintenabilité, facilité d'utilisation.

Rappel de la séance 1 : les besoins implicites (« le site marche sur téléphone », « mon historique de lecture reste confidentiel ») deviennent souvent des exigences non fonctionnelles. Si personne ne les écrit, personne ne les teste.

Le récit utilisateur

Une exigence fonctionnelle s'écrit du point de vue de celui qui s'en sert. Le récit utilisateur impose trois informations : qui, quoi, pour quoi faire.

En tant que [acteur], je veux [action], afin de [résultat attendu].

• En tant qu'usager inscrit, je veux réserver un document d'une autre médiathèque du réseau, afin de le retirer près de chez moi
• En tant que bibliothécaire, je veux voir les réservations à préparer pour le lendemain, afin de sortir les documents avant l'ouverture

Le « afin de » n'est pas décoratif : il rattache l'exigence au besoin, et permet d'écarter une solution qui ne le sert pas.

Récit utilisateur ou « le système doit »

Tout ne se raconte pas du point de vue d'un acteur. Une contrainte n'a pas d'« afin de » : on l'écrit à la troisième personne.

Pour choisir : peut-on nommer l'acteur qui fait l'action ? Si oui, récit utilisateur. Sinon, « le système doit ».

Les deux formes produisent des exigences : elles seront numérotées, contrôlées et testées de la même façon dans la suite.

Les règles de gestion

Le récit dit ce que l'usager veut faire. Il ne dit pas dans quelles limites : c'est le rôle des règles de gestion.

Règle de gestion : une règle du métier que la solution doit appliquer, quelle que soit la technologie.

• Elle est précise : un seuil, un délai ou une condition qui ne se discute pas
• Elle est décidée par le métier, pas par l'équipe technique
• Une règle manquante se découvre en recette, au pire moment

Règle ratée : « Le nombre de réservations est limité. » Il manque le seuil : limité à combien ?

Périmètre, plus tard, hors périmètre

Les exigences disent ce que la solution fera. Reste à écrire ce qu'elle ne fera pas : c'est ce qui évite le désaccord à la livraison.

• Plus tard : le « pas cette fois » de MoSCoW, reporté à une autre version
• Hors périmètre : ce que le projet ne fera pas, quelle que soit la version
• Les deux s'écrivent, avec une raison : budget, délai, risque, faible valeur

Exemple de raison écrite : « Application mobile native : plus tard, car son financement dépend d'une subvention qui n'est pas acquise. »

Ce qui n'est écrit nulle part sera supposé inclus par le commanditaire. On le découvre à la livraison.

Atelier 1 : d'un besoin à ses exigences

Vous avez vu les étapes 1 à 3 sur le besoin « réserver ». À vous de les refaire sur un autre besoin du même projet.

Durée : 10 min | Modalité : binôme, projet des médiathèques

Le besoin, classé « important » : être prévenu quand le document réservé est disponible.

À rédiger

1. 3 min. Un récit utilisateur
2. 3 min. Deux règles de gestion, dont une au moins chiffrée
3. 2 min. Une exigence non fonctionnelle que l'on peut vérifier
4. 2 min. Un élément que vous reportez à plus tard ou placez hors périmètre, avec sa raison

Livrable attendu : 5 lignes (récit, règle 1, règle 2, exigence non fonctionnelle, report), comparées à l'oral.

Atelier 1 : réponses possibles

Voici les 5 lignes attendues, remplies. Comparez-les aux vôtres rubrique par rubrique.

D'autres réponses sont valables, à deux conditions : la règle ne laisse aucune marge d'interprétation, et l'exigence peut se vérifier.

Sept qualités d'une bonne exigence

Avant d'écrire les tests, on relit chaque exigence avec sept questions. Une exigence mal écrite donnera un test impossible à écrire.

Mots à bannir : rapide, simple, convivial, moderne, optimisé, « si possible », « etc. ».

ISO/IEC/IEEE 29148 est la norme internationale de l'ingénierie des exigences. Ces sept qualités s'inspirent des caractéristiques qu'elle décrit.

Réécrire une exigence

Trouver le défaut ne suffit pas : il faut réécrire. Voici quatre exigences de la slide précédente, corrigées.

Comment le lire : la colonne « Après » contient à chaque fois un chiffre, une condition ou un découpage. C'est ce qui rend le test possible.

Le quatrième cas est le plus fréquent : une solution glissée parmi les exigences. Le réflexe est celui de la séance 1 : quel besoin sert-elle ?

Le critère d'acceptation

Une exigence bien écrite ne suffit pas : à la livraison, il faudra dire si elle est tenue. Le critère d'acceptation est ce test, écrit en trois temps.

Étant donné [une situation de départ], quand [une action], alors [un résultat observable].

Pour l'exigence « Réserver un document d'une autre médiathèque » :

Étant donné un usager connecté, sans document en retard, ayant 2 réservations actives, quand il réserve un document disponible dans une autre médiathèque, alors la réservation est enregistrée et la confirmation indique la médiathèque de retrait.

• Une situation de départ précise, avec des valeurs
• Une seule action
• Un résultat que n'importe qui peut constater
• Aucun mot sur la façon de le programmer

Critère raté : « La réservation fonctionne correctement. » Ni situation de départ, ni action, ni résultat que l'on peut constater.

En bref : un critère d'acceptation est un test écrit avant le développement.

Nominal, limite, erreur

Un seul critère ne teste que le cas où tout va bien. Pour chaque exigence, on en écrit au moins trois.

• Nominal : aucune règle ne s'oppose à l'action
• Limite : on se place au seuil d'une règle chiffrée, des deux côtés
• Erreur : une condition préalable manque, ou l'action échoue

RG1 : au plus 5 réservations actives | RG3 : un document en retard bloque toute nouvelle réservation

À retenir : chaque règle de gestion citée produit au moins un critère limite ou d'erreur.

Le critère d'une exigence non fonctionnelle

Une exigence non fonctionnelle se vérifie aussi, mais par une mesure plutôt que par l'action d'un usager.

La règle : une mesure, ses conditions, un seuil.

• La mesure dit ce qu'on compte ou ce qu'on chronomètre
• Les conditions disent sur quoi et à quel moment on mesure
• Le seuil dit à partir de quand c'est accepté

Lecture de la première ligne : mesure, l'heure d'envoi. Conditions, 200 mises de côté un samedi matin. Seuil, 190 sur 200, soit 95 %.

Atelier 2 : trois critères pour une exigence

Vous avez vu les trois cas sur « réserver ». À vous de les écrire pour une autre exigence, avec ses deux règles.

Durée : 15 min | Modalité : groupe, projet des médiathèques

L'exigence : un usager peut prolonger un prêt en ligne.

À rédiger

1. 4 min. Un critère nominal
2. 4 min. Un critère limite
3. 4 min. Un critère d'erreur
4. 3 min. Relecture : des valeurs précises, une seule action, un résultat observable

Livrable attendu : trois critères au format « étant donné, quand, alors ».

Atelier 2 : réponses possibles

RG4 : une seule prolongation, de 14 jours | RG5 : pas de prolongation si un autre usager a réservé le document

À discuter : que se passe-t-il si le prêt est déjà en retard ? Aucune règle ne le dit. C'est une règle manquante, à demander au commanditaire.

Matrice de traçabilité : trouvez les anomalies

Dernière étape : vérifier que la chaîne est complète. La matrice de traçabilité met sur une même ligne un besoin, ses exigences et leurs critères.

Durée : 2 min | Modalité : seul

B : besoin | EX : exigence | CA : critère d'acceptation

Comment la lire : une ligne saine va du besoin au critère sans trou, comme B1 et B2. Cette matrice contient 3 anomalies.

Livrable attendu : les 3 lignes fautives, et ce qui manque à chacune.

Matrice de traçabilité : corrigé

Chaque anomalie est un maillon manquant de la chaîne besoin, exigence, critère.

Que faire de chacune ?

• Besoin sans exigence : écrire l'exigence qui manque
• Exigence sans critère : écrire ses critères
• Exigence sans besoin : retrouver le besoin et l'acteur, sinon la retirer en l'écrivant

La matrice ne sert pas à faire joli : c'est le seul document qui montre un besoin oublié.

Gabarit : la fiche d'exigence

La fiche rassemble, pour une exigence, tout ce que les six étapes ont produit. La matrice n'en est que le sommaire.

C'est le gabarit que vous utiliserez demain pour le cas Zinc Média.

Points clés à retenir

• Le rapport dit s'il faut le faire, les spécifications disent quoi faire
• Un besoin implicite s'écrit comme une exigence, souvent non fonctionnelle, ou il est oublié
• Une règle de gestion est précise et vient du métier. Si elle manque, on la demande
• Une exigence vaut par ses critères d'acceptation : nominal, limite, erreur
• La matrice de traçabilité révèle le besoin oublié, l'exigence orpheline et l'exigence invérifiable

Pour demain : votre livrable 1 (besoins priorisés), votre rapport corrigé, et un ordinateur par personne.

Changelog