Il y a dix ans, je sortais du monde industriel et partais faire un DESS en Qualité et Sureté de Fonctionnement des Systèmes Informatiques à l’ISTIA d’Angers, école d’ingénieurs connue pour sa spécialité en Qualité. Après avoir rencontré tous ces intervenants passionnants qui pour beaucoup travaillaient dans de grandes compagnies industrielles (automobile, ascenseurs, avionique), je débutais dans le monde de la SSII.

Pour moi, définir et gérer des exigences allait de soi !

Mais mon directeur de projet, Albert, me dit « Surtout ne parle pas d’exigences aux clients, cela fait peur ! ».
C’est vrai qu’il y a 10 ans, les différences de maturité entre le monde industriel et les SSII, et entre les SSII elles-mêmes étaient importantes. Tout comme ce qui concernait la définition du besoin. Et tout comme la qualité des développements et du produit final.
Pourtant, quand vous achetez une voiture, vous vous attendez à ce qu’elle fonctionne comme vous le voulez, avec en plus d’autres critères comme le bruit que fait une portière quand on la ferme, ou le bruit du moteur, ou le toucher du tableau de bord. Quand vous achetez une chaine HIFI, vous vous attendez à l’utiliser sans lire le manuel 😉 De même quand vous achetez une maison, vous définissez ce que vous attendez avec le fabriquant.
Mais pour le logiciel, il semblait que cela soit différent. L’exigence semblait être qu’il y ait un minimum de bugs en fonctionnement. Et c’est même encore ce que l’on peut trouver dans certains contrats !

Alors parler d’exigences pouvait faire peur effectivement. Pourtant ce mot existait dans des logiciels comme Quality Center, même si très peu des testeurs utilisaient cet onglet et y voyaient une utilité.
Peut-être cela venait-il du mot en lui-même ? « Requirement » en anglais.
C’est ce qui est « requis » plus qu’exigé.
Ou alors cela venait-il du passé où une seule personne faisait l’analyse du besoin, la conception, le développement et donc pensait à tord ou à raison que tous les critères qualité avaient été traités.
Mais aujourd’hui, la définition du besoin du client, l’analyse fonctionnelle, (la vraie, pas celle qui consiste à demander à quelqu’un ce qu’il veut), l’analyse des contraintes de production ou de conception, la traçabilité entre le besoin Métier et la conception informatique, le découpage de tout cela en unités appelées Exigences et leur maintenance est quand même plus courant.

Ce qui est surprenant, c’est que l’Agilité a permis de faire avancer ce concept d’exigences. Avec les User Stories, les cas d’exemple, on retrouve une seule entité travaillant comme un seul homme pour définir le besoin, concevoir et développer, et prendre en compte le changement…
Sauf qu’après plusieurs itérations, on se retrouve avec beaucoup de User Stories, beaucoup d’exemples…et la plupart du temps, Fonctionnels. On parle maintenant également de Devops et de prendre en compte les exigences de déploiement et de faire des tests automatisés afin de livrer en continu.
Mais où est le regard critique sur ce qui a été réalisé ? Le client et l’équipe n’ont-ils pas la tête dans le guidon ? Où est la vision extérieure neutre ? Et n’est-il pas difficile de trouver de l’information dans la somme de tous les backlogs de tâches et de User Stories ? Certes il y a les EPIC qui sont des exigences de haut niveau, mais là encore souvent trop fonctionnelles.

Donc ici certaines pratiques Agile peuvent devenir des freins à la communication avec l’extérieur.
Le modèle en V, souvent confondu avec le modèle en cascade, a beaucoup de défauts, surtout en termes de réactivité. Mais tout n’est pas à jeter. En effet, dans les grandes organisations, l’équipe où les équipes Agile ne sont pas toutes seules à définir le besoin, concevoir, développer, mettre en production. Et comme il y a de nombreuses parties prenantes qui ont des responsabilités différentes, avoir des « exigences » aide bien à chaque niveau du modèle.

De quoi parle-t-on quand on parle d’exigences ?

Exigences Métier, exigences liées au Produit lui-même bien sur, la pertinence des fonctionnalités mais en lien avec les exigences d’urbanisation. Dans ce type d’exigences, on retrouve non seulement le fonctionnel, mais également la facilité d’utilisation, de compréhension, d’apprentissage, dont l’ergonomie (pas le look comme certaines marques de téléphones ou systèmes d’exploitation qui cultivent surtout les exigences liées au pouvoir d’attraction), la sécurité, l’interopérabilité (vous êtes contents quand cliquer sur une icône lance l’application par exemple), la performance.

  • Les exigences de conception et d’intégration. En effet le concepteur doit expliquer au développeur comment le code devra être fait, en fonction des langages, de l’architecture, SOA, EDI, ETL par exemple. On y retrouve également l’interopérabilité (entre le logiciel et la machine virtuelle Java par exemple ou entre les interfaces des webservices).

  • Les exigences de production. Et oui, il ne suffit pas de développer et de tester, il faut également déployer en production, et que cela soit « facile » à faire. Connaissez-vous beaucoup de sociétés qui n’ont pas plusieurs versions de bases de données en production car les développeurs ont créé leur logiciel pour des versions différentes ?

  • Les exigences liées à la stabilité, à tolérance aux pannes et la facilité de récupération qui peut bien aider à rendre les systèmes d’information disponibles.

Toutes ces éléments sont appelés des caractéristiques Qualité attendues et sont classifiées dans ISO9126 puis ses descendantes ISO25000.

L’ingénierie des exigences, c’est quoi ?

Et bien savoir structurer et gérer toutes ces exigences. Ce qui n’est pas une simple affaire (dans l’industrie logicielle).
Prenons pour exemple les exigences de test … Et pourtant, c’est si simple, en face des exigences listées ci-dessus, il faut associer des tests. Il y a donc des exigences de tests pour les Métiers, pour la production, pour le développement, pour l’intégration… Mais le test c’est encore une autre histoire. Allez, j’espère Albert, que tu n’auras plus peur des exigences !