Exigences & architecture

Écrire une bonne exigence : règles, exemples et pièges

Exigences & architecture · Publié le 2026-10-07

Une exigence mal écrite coûte cher, et rarement au moment où on l'écrit. Elle coûte au moment où deux équipes l'interprètent différemment, où un essai ne peut pas conclure, où un client conteste une livraison. Écrire de bonnes exigences n'est pas une affaire de style : c'est une compétence d'ingénieur, avec des règles connues et des pièges bien identifiés.

Qu'est-ce qu'une exigence ?

Une exigence est un énoncé qui exprime un besoin, avec les contraintes et conditions qui l'accompagnent, sous une forme que l'on peut vérifier. Elle dit ce que le système doit faire ou être, pas comment il le fait. Dans un projet d'ingénierie système, on distingue habituellement plusieurs niveaux :

• les besoins des parties prenantes, exprimés dans leur langage (utilisateurs, exploitants, autorités, mainteneurs) ;
• les exigences système, qui traduisent ces besoins en termes techniques vérifiables ;
• les exigences des sous-systèmes et des composants, obtenues par décomposition et allocation lors de la conception de l'architecture.

La norme ISO/IEC/IEEE 15288 consacre deux de ses processus techniques à ces activités : la définition des besoins et des exigences des parties prenantes, et la définition des exigences système. Nous les replaçons dans l'ensemble du cycle de vie dans notre article sur les processus de la norme 15288. La norme ISO/IEC/IEEE 29148:2018, consacrée à l'ingénierie des exigences, précise comment les formuler.

Les qualités d'une exigence

La norme ISO/IEC/IEEE 29148 énumère les caractéristiques d'une exigence bien formée. On peut les résumer en quelques questions à se poser devant chaque énoncé :

Nécessaire

Si on la retire, manque-t-il quelque chose ? Une exigence qui ne correspond à aucun besoin ajoute du coût sans valeur.

Appropriée

Est-elle au bon niveau ? Une exigence système ne devrait pas imposer un choix de composant, sauf contrainte réelle.

Non ambiguë

Peut-elle être comprise d'une seule façon ?

Complète

Contient-elle tout ce qu'il faut pour être comprise et vérifiée, y compris les conditions d'application ?

Singulière

N'exprime-t-elle qu'une seule chose ? Deux exigences dans une phrase se vérifient mal et se tracent mal.

Réalisable

Peut-elle être satisfaite avec les techniques, le budget et le délai disponibles ?

Vérifiable

Existe-t-il un moyen objectif (essai, analyse, inspection, démonstration) de montrer qu'elle est satisfaite ?

Correcte et conforme

Traduit-elle fidèlement le besoin d'origine, et respecte-t-elle les conventions de rédaction du projet ?

La norme ajoute des qualités qui portent sur l'ensemble des exigences : complétude, cohérence (pas de contradiction), faisabilité globale, compréhensibilité, et possibilité de valider l'ensemble par rapport aux besoins.

Un gabarit de phrase

Beaucoup d'organisations imposent une structure de phrase. La plus répandue ressemble à ceci :

[Condition], le [système] doit [action ou propriété] [objet] [critère de performance].

Par exemple : « En cas de perte de l'alimentation principale, le calculateur doit basculer sur l'alimentation de secours en moins de 50 millisecondes. » Chaque élément a sa place : la condition (perte de l'alimentation), le sujet (le calculateur), l'action (basculer), l'objet (l'alimentation de secours), le critère (moins de 50 ms).

D'autres gabarits ont été proposés pour réduire l'ambiguïté des exigences en langue naturelle. L'approche EARS (Easy Approach to Requirements Syntax), présentée à la fin des années 2000 lors de la conférence internationale de l'IEEE sur l'ingénierie des exigences, distingue ainsi quelques formes types selon que l'exigence s'applique en permanence, lors d'un événement, dans un état donné, en présence d'une fonction optionnelle ou face à une situation indésirable.

Avant, après : cinq réécritures

Les valeurs numériques de ces exemples sont illustratives : dans un projet réel, elles viennent de l'analyse du besoin et des normes applicables, pas de l'intuition du rédacteur.

Les mots à surveiller

Certains mots signalent presque toujours un problème. Les guides de rédaction, dont celui de l'INCOSE consacré à l'écriture des exigences, en dressent des listes. Les plus courants :

• Les adjectifs subjectifs : rapide, facile, convivial, robuste, suffisant, adapté, optimal.
• Les échappatoires : si possible, autant que possible, le cas échéant, sauf si nécessaire.
• Les quantificateurs flous : quelques, plusieurs, la plupart, généralement, environ.
• Les conjonctions « et », « ou », « et/ou », qui signalent souvent deux exigences en une.
• Les pronoms sans antécédent clair : il, celui-ci, ce dernier.
• Les négations invérifiables : « ne doit jamais » sans condition ni durée.
• Le verbe : dans beaucoup de projets, « doit » marque une obligation, « devrait » une recommandation, et les deux ne se mélangent pas.

Exigences et modèle

Dans une démarche basée sur les modèles, l'exigence devient un élément du modèle, avec un identifiant unique et des relations : elle est dérivée d'une exigence parente, satisfaite par un élément d'architecture, vérifiée par un cas de test. Ces relations rendent possible la traçabilité des exigences de bout en bout. Le texte de l'exigence reste cependant essentiel : c'est lui qui engage contractuellement, et un modèle ne corrige pas une phrase ambiguë.

Chaque exigence devrait d'ailleurs indiquer, dès sa rédaction, la méthode de vérification envisagée : essai, analyse, inspection ou démonstration. Cette réflexion précoce fait souvent apparaître les exigences invérifiables avant qu'elles ne deviennent un problème. Nous détaillons ces méthodes dans l'article sur la vérification et la validation.

Une revue en dix minutes

Pour relire rapidement un lot d'exigences, une grille simple suffit souvent :

1. Chaque exigence a-t-elle un identifiant unique et stable ?
2. Ne contient-elle qu'un seul « doit » ?
3. Le critère d'acceptation est-il mesurable ?
4. Les conditions d'application (mode, environnement, phase) sont-elles précisées ?
5. Exprime-t-elle un besoin plutôt qu'une solution ?
6. La méthode de vérification est-elle identifiée ?
7. Est-elle reliée à un besoin ou à une exigence parente ?

À lire ensuite

Plus dans Exigences & architecture

Exigences & architecture

La traçabilité des exigences

Dérivation, satisfaction, vérification : les liens à établir et l'usage qu'on en fait pour l'analyse d'impact.

Exigences & architecture

Vérification et validation

« Le produit est-il bien fait ? » et « est-ce le bon produit ? » : deux questions, deux démarches.

Exigences & architecture

Les processus de la norme 15288

Quatre groupes, trente processus : la carte de référence de l'ingénierie système, et ce qu'elle n'impose pas.