Réponse.

Historique de la question :

Avec l'augmentation de la complexité des projets informatiques et du nombre de spécialistes impliqués, un problème est apparu : les parties prenantes commerciales exigent une description compréhensible, tandis que l'équipe technique a besoin d'une description détaillée et techniquement précise. Il n'existe pas de norme universelle, et historiquement, l'analyste système est devenu un "traducteur" entre les mondes, adaptant le niveau de formalisation des exigences au public ciblé.

Problème :

Les entreprises lisent mal les diagrammes et les spécifications, ne comprennent pas la terminologie UML/BPMN. Les développeurs, quant à eux, ne se contentent pas d'histoires d'utilisateurs et d'une vision générale — ils ont besoin de critères clairs, de schémas, de schémas d'API, de formats de données. Si l'analyste choisit un format d'exigence incorrect, les risques de malentendus, d'incohérence fonctionnelle et de retards sont élevés.

Solution :

Identifier les rôles/personnes clés parmi les parties intéressées et mener une série d'interviews ou de questionnaires pour étudier leur expérience, leurs attentes et leurs besoins.
Pour le client commercial : utiliser des scénarios (user stories), des diagrammes BPMN, des glossaires de termes, des maquettes interactives et des wireframes. Éviter au maximum une surcharge de détails.
Pour le développement : préparer des spécifications techniques structurées (SRS, diagrammes de classes, diagrammes ER, descriptions d'API, critères d'acceptation), garantissant une interprétation sans ambiguïté.
Pour les intégrateurs et les testeurs : des listes de contrôle distinctes, des critères d'acceptation, des cas de test et des schémas d'interaction.

Clé : Formaliser le même ensemble d'exigences dans un format pratique pour chaque public cible, sans ambiguïté.

Caractéristiques clés :

Adaptation du format des exigences aux compétences et aux attentes du public
Utilisation de plusieurs représentations convenues pour les mêmes exigences
Choix d'un "juste milieu" entre exhaustivité et surcharge de détails

Questions pièges.

Peut-on prendre un modèle SRS (Software Requirements Specification) et le transmettre à tous les participants du projet sans modifications ?

Non. Un même document n'est pas efficace pour différents rôles — le SRS est peu compréhensible pour le client commercial, tandis que l'équipe d'intégration peut manquer de détails nécessaires. Les exigences doivent être adaptées à chaque public cible.

On entend souvent dire : "Les diagrammes BPMN et UML remplacent complètement la description écrite des exigences — est-ce vrai ?"

Non. Les diagrammes sont un puissant complément visuel, mais ils doivent toujours être accompagnés d'explications, car de nombreuses parties prenantes (en particulier dans le secteur professionnel) ne connaissent pas les notations. Sans un bloc descriptif, de nombreuses nuances demeurent incomprises.

Peut-on mélanger les exigences commerciales et techniques dans une même section ?

Non recommandé. Cela complique la recherche et la compréhension de l'information pour différents rôles et conduit à des erreurs lors de la mise en œuvre. Il est nécessaire de structurer la documentation de manière claire, en distinguant les exigences commerciales, les spécifications techniques, les attentes non fonctionnelles et les critères d'acceptation.

Erreurs typiques et anti-modèles

Utilisation d'un seul format d'exigences pour tous les rôles
Surcharge de détails là où cela n'est pas nécessaire ("des tonnes de schémas" pour les entreprises)
Abus du jargon professionnel
Absence de glossaire de termes, ce qui entraîne des ambiguïtés

Exemple de la vie réelle

Cas négatif

L'analyste a préparé un immense document SRS de plusieurs pages en anglais, contenant des diagrammes UML complexes. Les parties prenantes commerciales ne l'ont même pas ouvert, l'équipe d'intégration a tiré des conclusions à partir d'une vue d'ensemble, et des défauts sont apparus lors des intégrations.

Avantages :

Formuellement, toute la documentation était présente

Inconvénients :

Les entreprises n'ont pas compris les fonctionnalités
Nombreuses rétroactions et retouches
Les développeurs ont ignoré une partie des exigences

Cas positif

Pour les entreprises, une présentation avec des prototypes interactifs et des termes commerciaux clés a été créée, pour l'équipe technique — une spécification technique distincte et un pipeline API. La documentation était mise à jour dans Confluence avec des statuts de discussion.