Cet article est une ébauche concernant l’informatique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

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^[1]. 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^[2].

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^[2]. 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^[3].

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^[4].

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^[1].

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>

Les mots-clés EARS sont en anglais et conservés tels quels dans toutes les langues, car ils constituent la syntaxe formelle de la notation.

Le jeu de règles EARS stipule qu'une exigence doit comporter^[2] :

• 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.

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 : « The mobile phone SHALL have a mass of less than 150 grams. »

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 : « WHEN 'mute' is selected, the laptop SHALL suppress all audio output. »

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 : « WHILE there is no card in the ATM, the ATM SHALL display 'insert card to begin'. »

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 : « WHERE the car has a sunroof, the car SHALL have a sunroof control panel on the driver door. »

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 : « IF an invalid credit card number is entered, THEN the website SHALL display 'please re-enter credit card details'. »

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^[2] :

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

Exemple : « WHILE the aircraft is on ground, WHEN reverse thrust is commanded, the engine control system SHALL enable reverse thrust. »

EARS présente plusieurs avantages documentés par rapport aux exigences en langage naturel non contraint^[1],[4] :

• 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.

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 diagrammes d'états^[5]. 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).

Le développement orienté par les spécifications (anglais : spec-driven development, 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^[9].

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^[3]. Le flux de travail orienté par les spécifications de Kiro se déroule en trois phases :

1. Exigences (requirements.md) : le développeur saisit une invite en langage naturel (par exemple : « Ajouter un système d'avis sur les produits »). 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^[10].
2. 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.
3. 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^[11].

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 « anglais : vibe coding »), les spécifications au format EARS réduisent l'ambiguïté qui conduit les agents IA à faire des hypothèses indésirables^[9]. 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^[12].

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^[10].

• Ingénierie des exigences
• Développement orienté par les spécifications
• Langage naturel contrôlé
• Analyse des exigences
• Programmation pilotée par le comportement
• Ingénierie des systèmes

• (en) EARS – Page officielle d'Alistair Mavin
• (en) Article original EARS sur IEEE Xplore
• (en) Documentation Kiro – Concepts des spécifications
• (en) QRA – The Easy Approach to Requirements Syntax: The Definitive Guide
• (en) Jama Software – Adopting EARS Notation for Requirements Engineering

• Portail de l’informatique
Modèle:Portail génie logiciel