Réussissez vos projets logiciels grâce à un document d’exigences solide. Ce guide pratique montre comment rédiger des spécifications claires et testables.
Un document d’exigences logicielles (SRS) est le contrat testable du projet. Il définit exactement ce que le logiciel doit faire, et chaque ligne doit tenir dans un test de recette. Commencez tout de suite : prenez votre principal objectif métier et convertissez-le en une exigence atomique et testable formulée avec « doit ».
Les organismes de normalisation ont déjà fait le gros du travail de réflexion. IEEE Std 830 et son successeur, l’ISO/CEI/IEEE 29148, en posent la structure. Le SWEHB de la NASA y ajoute une rigueur pratique en matière de vérification et de traçabilité. Ce guide suit les deux.
Votre premier brouillon n’a pas besoin d’être parfait. Il doit être :
Un document d’exigences logicielles ne fonctionne que si chaque exigence est testable, traçable jusqu’à un objectif métier et relue par des parties prenantes techniques et non techniques avant le début du développement.
| Point | Détails |
|---|---|
| Définition et enchaînement | Le SRS répond au « quoi », entre le BRD (le « pourquoi ») et le SDD (le « comment »). |
| Utiliser des formulations en « doit » | La voix active assortie de critères d’acceptation mesurables rend les exigences testables par la QA. |
| Construire une matrice de traçabilité | Reliez chaque identifiant d’exigence à un cas de test et à un objectif métier pour éviter la dérive du périmètre. |
| Dimensionner le document | Les petits projets peuvent fusionner BRD et SRS ; les projets réglementés ou multi-équipes ont besoin de les séparer. |
| Attribuer des méthodes de vérification | Chaque exigence a besoin d’une méthode déclarée : test, inspection, analyse ou démonstration. |
Une spécification d’exigences logicielles décrit les comportements fonctionnels et non fonctionnels précis que le logiciel doit présenter. C’est l’accord formel entre les parties prenantes et l’équipe de développement, et il devient la base de la conception, des tests et de l’estimation des coûts.
La confusion vient généralement de la soupe d’acronymes qui l’entoure. Voici la distinction qui compte : le document d’exigences métier (BRD) répond au pourquoi le projet existe et au résultat métier qu’il vise. Le SRS répond au quoi le logiciel doit faire pour y arriver. Le document de conception logicielle (SDD), rédigé ensuite, répond au comment les ingénieurs vont le construire. Sautez le SRS et vous obtenez une équipe qui travaille sur une hypothèse partagée plutôt que sur une spécification partagée, ce qui est une façon plus lente et plus coûteuse de découvrir que vous n’étiez pas d’accord.
Plusieurs publics dépendent d’un SRS qui fait bien son travail :
Suivre les conventions de l’IEEE et de la NASA n’est pas une case bureaucratique à cocher. C’est ce qui rend le document vérifiable par quelqu’un qui n’était pas dans la pièce au moment de sa rédaction, ce qui est toute la raison d’être de l’écrire.
La rédaction est rarement une affaire individuelle. Sur la plupart des projets, un product owner ou un analyste métier rédige les exigences, un architecte de solutions les relit pour en vérifier la faisabilité technique, et un rédacteur technique en nettoie souvent la langue pour la clarté et la cohérence. Dans les petites équipes, une seule personne porte les trois casquettes. C’est très bien, tant que l’étape de relecture a lieu.
Chez Kreante, notre approche de la communication avec les parties prenantes considère cette étape de recueil comme la partie du document où l’effet de levier est le plus fort. Trompez-vous ici, et tout ce qui suit hérite de l’erreur.
Voici un squelette section par section que vous pouvez copier directement dans un document et commencer à remplir. Cette structure emprunte largement au plan recommandé par l’IEEE Std 830 et aux exigences de contenu minimal SWE-109 de la NASA, adaptées aux équipes qui n’ont pas besoin d’un formalisme de niveau aérospatial.
1. Introduction
Objet, périmètre, public visé, définitions et acronymes, et références aux documents liés comme le BRD. Tenez en une page. Personne ne lit une introduction de dix pages, et si quelqu’un doit le faire, c’est qu’autre chose a échoué dans le document.
2. Vue d’ensemble du système
Un court récit décrivant ce que fait le système, qui l’utilise et comment il s’insère dans l’environnement existant. Incluez les besoins des parties prenantes au niveau du résumé ; le détail viendra plus tard.
3. Exigences spécifiques
C’est le cœur du document, divisé en deux :
4. Exigences d’interface
Interfaces avec les systèmes externes, API, formats d’échange de données et contraintes au niveau de l’interface utilisateur. Si votre produit couvre un développement web et mobile, c’est dans cette section que doivent figurer les contraintes propres à chaque plateforme (comportement hors ligne, limites des notifications push, permissions des appareils), et non enfouies dans une exigence fonctionnelle.
5. Modèles de données et contraintes
Relations entre entités, règles de conservation des données, contraintes réglementaires (HIPAA, RGPD, PCI DSS le cas échéant) et toutes les limites des systèmes hérités que le nouveau développement doit respecter.
6. Hypothèses et dépendances
Ce que vous tenez pour vrai et qui, s’il s’avère faux, change l’exigence. La disponibilité d’une API tierce. Les fenêtres de compatibilité navigateur. Les hypothèses de staffing pour un déploiement par étapes.
7. Champs de traçabilité par exigence
Chaque exigence individuelle doit porter au minimum : un identifiant unique, le texte de l’exigence lui-même, sa justification (pourquoi elle existe), sa priorité et sa méthode de vérification.
8. Annexes
Glossaire, dictionnaire de données, schémas et journal des modifications.
| Section du SRS | Public principal | Ce qui déraille si on la saute |
|---|---|---|
| Introduction et périmètre | Toutes les parties prenantes | Dérive du périmètre, aucune définition partagée de « terminé » |
| Exigences fonctionnelles | Développeurs, QA | Développements ambigus, reprises après livraison |
| Exigences non fonctionnelles | Architectes, QA, ops | Problèmes de performance et de sécurité découverts en production |
| Exigences d’interface | Intégrateurs, équipes mobile/web | Passages de relais cassés entre systèmes ou plateformes |
| Champs de traçabilité | Chef de projet, QA, auditeurs | Aucun moyen de prouver qu’une exigence a été testée ou justifiée |
La testabilité est le nerf de la guerre. Une exigence qu’on ne peut pas prouver vraie ou fausse dans un cas de test n’est pas une exigence. C’est un souhait.
Voici un avant/après :
Vague : « Le système devrait gérer beaucoup d’utilisateurs. »
Testable : « Le système doit prendre en charge des utilisateurs authentifiés simultanés avec des temps de chargement de page inférieurs à deux secondes la plupart du temps. »
Une exigence qu’on ne peut pas tester n’est pas une spécification. C’est un espoir déguisé en spécification, et la QA le découvrira à la dure, généralement pendant le sprint qui précède le lancement.
Conseil de pro : Écrivez chaque exigence non fonctionnelle avec un chiffre dedans. « Rapide », « sécurisé » et « convivial » sont des opinions. « Moins de 800 ms », « chiffré en AES-256 » et « tâche accomplie en moins de trois clics » sont des exigences.
Le dimensionnement compte aussi. Une start-up de trois personnes qui construit un MVP n’a pas besoin d’un SRS de 40 pages avec une matrice de traçabilité digne de la NASA. Une plateforme de santé réglementée, si.
Chaque exigence a besoin d’une méthode de vérification attribuée : test, inspection, analyse ou démonstration. Toutes les exigences ne se vérifient pas de la même façon. Un seuil de performance se teste. Une décision d’architecture de sécurité se vérifie souvent par inspection ou par analyse.
Une matrice de traçabilité des exigences (RTM) est l’outil qui relie le tout. C’est un simple tableau qui associe chaque identifiant d’exigence à son cas de test et à l’objectif métier qu’il sert.
Le SWEHB de la NASA désigne ce type de traçabilité bidirectionnelle, vers l’avant jusqu’aux tests et vers l’arrière jusqu’aux objectifs métier, comme la pratique qui réduit le plus les reprises sur les projets complexes. Elle stoppe aussi la dérive du périmètre, car toute exigence qui ne peut se rattacher à un objectif réel est vite démasquée.
Quelques habitudes rendent tout cela maintenable :
Copiez ce squelette directement. Chaque entrée d’exigence a besoin au minimum de ces champs :
Trois exemples dont s’inspirer :
Pour les petits projets, un simple tableur partagé ou un document Notion avec ces champs suffit. Pour les projets multi-équipes ou réglementés, hébergez le SRS dans un véritable système de gestion documentaire ou un outil de gestion des exigences où l’historique des versions et les validations sont imposés automatiquement, et non suivis de mémoire.
Le travail sur les exigences n’a rien de théorique chez Kreante. C’est le premier vrai livrable de la plupart des missions, avant qu’une seule ligne de code ne soit écrite.
La plupart des conseils qu’on trouve en ligne sur le SRS traitent la documentation comme un exercice de conformité : remplir chaque section de l’IEEE parce que la norme le dit, en espérant que l’exhaustivité remplace la clarté. Ce n’est pas le cas. Un SRS de 60 pages que personne ne lit au-delà de la page 12 vaut moins qu’un document serré de 8 pages où chaque exigence est testable.
Ce qui est surestimé dans les conseils habituels, c’est l’exhaustivité pour elle-même. Ce qui est sous-estimé, c’est la traçabilité. Une exigence sans justification documentée est une exigence que personne ne peut défendre six mois plus tard, quand quelqu’un demande « mais pourquoi fait-on ça ? ». Les équipes qui sautent les champs de traçabilité pour gagner du temps le paient presque toujours plus tard, dans une réunion de cadrage qui dure trois heures de trop.
Si vous ne retenez qu’une chose de ce guide, privilégiez l’énoncé en « doit » et le critère d’acceptation plutôt que les titres de sections. Des normes comme l’IEEE 830 et le SWEHB de la NASA vous donnent une structure, mais une structure sans testabilité n’est que de la mise en forme. Rédigez l’exigence de telle sorte qu’un inconnu puisse la tester sans vous poser de question, et le reste du document tend à s’organiser autour.
Un exemple bien formé se lit ainsi : « Le système doit verrouiller un compte utilisateur après cinq tentatives de connexion échouées consécutives en dix minutes », assorti d’une méthode de vérification déclarée (test) et d’une étiquette de priorité (Must).
Commencez par rédiger les exigences fonctionnelles et non fonctionnelles sous forme d’énoncés en « doit », attribuez à chacune une méthode de vérification et une justification, puis faites passer le brouillon par une relecture technique et une validation des parties prenantes avant le début du développement.
Un product owner ou un analyste métier le rédige généralement, un architecte de solutions le relit pour en vérifier la faisabilité, et un groupe restreint de parties prenantes (responsables produit, ingénierie et QA) le valide avant le démarrage des travaux.
Utilisez le squelette section par section de ce guide, qui suit la structure de l’IEEE 830 et du SWEHB de la NASA, et adaptez la liste de champs (identifiant, texte de l’exigence, justification, priorité, méthode de vérification) à un tableur ou à l’outil documentaire de votre équipe.
Pour aller plus loin
Ne laissez pas votre veille s'arrêter ici. Explorez nos autres ressources pour maîtriser votre stack technologique.
ToolsDécouvrez les principaux risques de sécurité liés à l’IA que les dirigeants doivent traiter. Apprenez à protéger vos données et vos modèles des attaques par prompt.
ToolsDécouvrez les modèles de tarification SaaS adaptés aux fondateurs et aux product managers. Apprenez à optimiser vos revenus selon les besoins de votre produit.
ToolsDécouvrez comment l’automatisation du traitement documentaire peut fluidifier vos opérations, améliorer la précision et livrer un prototype en quelques semaines.
