Module
Module 3 sur 5Leçon 2 sur 2~16 min

Cas limites et exigences non fonctionnelles

Les incidents en production viennent souvent d'un cas que personne n'avait écrit ou d'une exigence de performance restée implicite. La leçon vous aide à repérer de façon méthodique les situations aux marges d'une fonctionnalité et à formuler ses exigences non fonctionnelles de manière testable, pour que ni l'équipe ni un agent de code n'aient à les deviner.

Suivre cette leçon : première formation offerteVoir le programme complet

Objectif de la leçon

À la fin de cette leçon, vous serez capable de trouver méthodiquement les cas limites d'une fonctionnalité avec une grille de questions, et d'écrire ses exigences non fonctionnelles (performance, fiabilité, sécurité, accessibilité, données personnelles) sous une forme chiffrée et testable.

Thèmes abordés

  • cas limites
  • exigences non fonctionnelles
  • NFR
  • exigences d'accessibilité
  • performance et fiabilité

Dans quel module

Critères, cas limites et exigences

Comment écrire des critères qu'on peut vérifier, et ne pas oublier ce qui arrive quand tout ne se passe pas comme prévu ?

Leçons du module

  1. Écrire des critères Given / When / Then vérifiables
  2. Cas limites et exigences non fonctionnelles (cette leçon)

Ce que vous apprendrez dans la formation

Cette leçon fait partie de la formation Écrire des specs que les développeurs et les agents IA comprennent

  • Choisir le niveau de spec adapté à la décision à prendre (PRD, spec de fonctionnalité, ticket) et savoir ce que chacun doit contenir.
  • Formuler l'intention d'une fonctionnalité (problème, résultat visé, contraintes, non-objectifs) séparément de la solution, pour laisser la bonne marge à l'équipe et à l'agent.
  • Écrire des critères d'acceptation Given/When/Then vérifiables, déclaratifs et sans ambiguïté, y compris sous forme de tableaux d'exemples.
  • Identifier les cas limites et les exigences non fonctionnelles (performance, sécurité, accessibilité, données personnelles) et les rendre testables.
  • Rédiger une spec et un fichier d'intention exploitables par un agent de code (contexte, contraintes, fichiers concernés, hors périmètre, définition de terminé vérifiable).
  • Relire le plan d'un agent de code contre la spec, repérer les écarts avant qu'il code, puis vérifier les preuves de ce qui a été livré.
  • Garder une spec vivante (versions, décisions, mises à jour quand le code révèle un cas) et repérer les anti-patterns qui la rendent inutile.

Formations liées