Easy Approach to Requirements Syntax

L'Easy Approach to Requirements Syntax (EARS, littéralement « approche facile de la syntaxe des exigences ») est une méthode structurée de rédaction d'exigences en langage naturel reposant sur un petit ensemble de mots-clés et de patrons de phrases. Développée par Alistair Mavin et ses collègues chez Rolls-Royce plc lors de l'analyse des réglementations de navigabilité d'un système de commande de moteur à réaction, la méthode a été publiée pour la première fois lors de la conférence internationale IEEE sur l'ingénierie des exigences (RE'09) en 2009. EARS contraint modérément le langage naturel libre en imposant un ordre fixe des propositions et un vocabulaire limité de mots-clés structurels, réduisant ou éliminant les problèmes courants tels que l'ambiguïté, l'imprécision et l'incomplétude.

EARS a été adoptée par des organisations telles qu'Airbus, Bosch, Dyson, Honeywell, Intel, la NASA, Rolls-Royce et Siemens, et est enseignée dans des universités en Chine, en France, en Allemagne, en Suède, au Royaume-Uni et aux États-Unis. Depuis 2025, la notation EARS est intégrée dans des outils de développement orienté par les spécifications assistés par l'intelligence artificielle, notamment l'EDI Kiro d'Amazon.

Contexte

Les exigences système sont généralement rédigées en langage naturel non contraint, par nature imprécis. Les auteurs d'exigences sont souvent des experts métier plutôt que des ingénieurs formés à l'ingénierie des exigences, et des exigences mal formulées propagent des erreurs vers les phases ultérieures de conception, d'implémentation et de test, augmentant les coûts et les risques de retard. Si les langages de spécification formelle peuvent accroître la précision, ils imposent un effort de formation significatif et nécessitent une traduction des exigences sources, pouvant elle-même introduire des erreurs.

EARS a été conçue pour occuper une position intermédiaire : elle conserve le langage naturel afin que toutes les parties prenantes puissent lire et relire les exigences sans formation spécialisée, tout en imposant suffisamment de structure syntaxique pour éliminer les défauts les plus fréquents. L'approche est née lors de l'analyse par Mavin des réglementations de navigabilité contenues dans la base de certification d'un système de commande de moteur aéronautique Rolls-Royce, où il a observé que les exigences bien rédigées suivaient toutes une structure sous-jacente similaire.

Syntaxe

La structure générale d'une exigence EARS est :

WHILE <précondition(s) optionnelle(s)>, WHEN <déclencheur optionnel>, the <nom du système> SHALL <réponse du système>

Le jeu de règles EARS stipule qu'une exigence doit comporter :

zéro ou plusieurs préconditions ; zéro ou un déclencheur ; exactement un nom de système ; une ou plusieurs réponses du système.

Les propositions apparaissent toujours dans le même ordre temporel, et un petit nombre de mots-clés désigne les différents types de propositions. Cela produit des exigences relevant de l'un des cinq patrons de base, ou de leurs combinaisons.

Ubiquitaire (Ubiquitous)

Les exigences ubiquitaires sont toujours actives. Elles ne comportent pas de mot-clé EARS car il n'y a pas de condition de déclenchement.

The <nom du système> SHALL <réponse du système>

Exemple :

Pilotée par événement (Event-driven)

Les exigences pilotées par événement spécifient comment un système doit répondre lorsqu'un événement déclencheur survient. Elles sont marquées par le mot-clé WHEN.

WHEN <déclencheur>, the <nom du système> SHALL <réponse du système>

Exemple :

Pilotée par état (State-driven)

Les exigences pilotées par état sont actives tant qu'un état spécifié reste vrai. Elles sont marquées par le mot-clé WHILE.

WHILE <précondition(s)>, the <nom du système> SHALL <réponse du système>

Exemple :

Fonctionnalité optionnelle (Optional feature)

Les exigences de fonctionnalité optionnelle ne s'appliquent qu'aux produits ou variantes de système incluant une fonctionnalité donnée. Elles sont marquées par le mot-clé WHERE.

WHERE <fonctionnalité incluse>, the <nom du système> SHALL <réponse du système>

Exemple :

Comportement indésirable (Unwanted behaviour)

Les exigences de comportement indésirable spécifient la réponse requise du système face à des situations non souhaitées telles que des pannes, des défaillances ou des erreurs. Elles sont marquées par les mots-clés IF et THEN.

IF <déclencheur>, THEN the <nom du système> SHALL <réponse du système>

Exemple :

Exigences complexes

Les briques élémentaires ci-dessus peuvent être combinées pour spécifier des comportements système plus riches. Les exigences complexes utilisent plus d'un mot-clé EARS :

WHILE <précondition(s)>, WHEN <déclencheur>, the <nom du système> SHALL <réponse du système>

Exemple :

Avantages et limites

Avantages

EARS présente plusieurs avantages documentés par rapport aux exigences en langage naturel non contraint :

Réduction de l'ambiguïté – L'ordre fixe des propositions et le vocabulaire de mots-clés obligent les auteurs à rendre explicites les conditions de déclenchement, les préconditions et les réponses attendues. Faible barrière à l'adoption – Les mots-clés correspondent étroitement à l'usage courant de l'anglais, ce qui minimise l'effort de formation et ne nécessite aucun outillage spécialisé. Accessibilité linguistique – EARS est particulièrement efficace pour les auteurs qui rédigent des exigences en anglais sans que ce soit leur langue maternelle. Amélioration de la testabilité – La séparation structurée des conditions et des réponses facilite la dérivation de cas de test. Compatibilité avec les outils existants – Les exigences peuvent être rédigées dans n'importe quel éditeur de texte, traitement de texte ou outil de gestion des exigences.

Limites

EARS n'est pas adaptée à tous les types d'exigences. Les exigences comportant plus de trois préconditions peuvent produire des phrases trop longues, et certaines exigences sont mieux exprimées sous forme de formules mathématiques, de tables de décision ou de diagramme d'états. La notation est également moins appropriée pour les exigences non fonctionnelles qui ne peuvent pas être capturées sous forme de comportement conditionnel (par exemple, les contraintes architecturales).

Historique des publications

Année Publication Notes 2009 – RE'09 Article fondateur présentant les cinq patrons EARS. 2010 – RE'10 Expérimentations élargies sur plusieurs jeux de documents d'exigences ; patrons affinés et limites traitées. 2011 – RE'11 Article court industriel sur l'adoption rapide, par Sarah Gregory. 2016 – RE'16 Retour d'expérience après sept ans d'application industrielle. 2019 – IEEE Software Rétrospective des auteurs originaux sur une décennie d'adoption et d'évolution.

Utilisation dans le développement orienté par les spécifications

Principe

Le développement orienté par les spécifications (, SDD) est une méthodologie logicielle dans laquelle une spécification formelle ou semi-formelle — plutôt que des invites informelles ou des descriptions ad hoc — pilote la génération de code, les tests et la documentation. Dans les flux SDD, les exigences sont d'abord capturées dans un format structuré, puis utilisées pour produire une conception technique, et enfin décomposées en tâches d'implémentation. La notation EARS s'est imposée comme syntaxe privilégiée pour la phase d'exigences du SDD car son langage naturel contraint peut être interprété aussi bien par les humains que par les grands modèles de langage (LLM), comblant le fossé entre l'intention produit et les spécifications exploitables par les machines.

Amazon Kiro

Kiro est un environnement de développement intégré (EDI) à agents IA annoncé par Amazon en 2025, construit sur Code OSS. Il a adopté EARS comme notation native d'exigences. Le flux de travail orienté par les spécifications de Kiro se déroule en trois phases :

Exigences (requirements.md) : le développeur saisit une invite en langage naturel (par exemple : ). Kiro la développe en récits utilisateurs (user stories), chacun accompagné de critères d'acceptation rédigés en notation EARS. Le format structuré capture explicitement les préconditions, les déclencheurs et les réponses attendues du système, couvrant les cas limites que les développeurs découvriraient normalement lors de l'implémentation. Conception (design.md) : à partir des exigences EARS et du code existant, Kiro génère un document de conception technique comprenant l'architecture, les diagrammes de séquence et les choix de pile technologique. Tâches (tasks.md) : la conception est décomposée en tâches d'implémentation discrètes et séquencées, avec suivi des dépendances.

Chaque critère d'acceptation suivant le patron EARS WHEN <condition/événement> the system SHALL <comportement attendu>, les exigences sont directement testables et fournissent des critères de succès non ambigus pour chaque tâche générée. Les développeurs peuvent également rédiger manuellement des exigences au format EARS et utiliser la fonction « Refine » de Kiro pour les valider ou les restructurer.

Adoption élargie dans les outils assistés par IA

L'intégration d'EARS dans Kiro s'inscrit dans une tendance plus large où les patrons d'exigences structurés sont utilisés pour améliorer la prévisibilité et la qualité du code généré par les LLM. Par rapport aux invites en texte libre (parfois appelées « »), les spécifications au format EARS réduisent l'ambiguïté qui conduit les agents IA à faire des hypothèses indésirables. Des projets communautaires ont étendu l'approche à d'autres assistants de codage par IA via des greffons et des serveurs Model Context Protocol (MCP) exposant des flux de travail SDD basés sur EARS.

Comparaison avec des approches apparentées

Méthode Format Usage principal Différence clé par rapport à EARS EARS Langage naturel contraint avec mots-clés Exigences système/logiciel Patrons légers basés sur des mots-clés Récit utilisateur « En tant que <rôle>, je veux <objectif>, afin de <bénéfice> » Descriptions de fonctionnalités agiles Centré sur la valeur utilisateur, pas sur le comportement système ; pas de contrainte syntaxique sur les critères d'acceptation Gherkin (Given/When/Then) Langage de scénarios structuré Programmation pilotée par le comportement (BDD) Orienté vers des scénarios de test exécutables plutôt que vers des exigences au niveau système Patron de Rupp « Le système doit <verbe d'action> <objet> » avec extensions conditionnelles Spécification d'exigences Taxonomie de verbes plus prescriptive ; nécessite une formation plus approfondie Patrons Patrons de phrases paramétrés Exigences formelles Formalisme plus important et dépendance aux outils

En pratique, EARS et les récits utilisateurs sont fréquemment employés ensemble : les récits utilisateurs capturent les besoins de haut niveau des parties prenantes, tandis qu'EARS est utilisée pour spécifier les critères d'acceptation détaillés au sein de chaque récit — une approche formalisée par le flux de travail orienté par les spécifications de Kiro.

Notes et références

Voir aussi

Easy Approach to Requirements Syntax

Źródło i licencja