Découvrir et comprendre l'ingénierie des exigences
Si je vous demande ce qu’est l’ingénierie des exigences, il est fort possible que vous ne puissiez pas me répondre. Et pourtant, je suis presque sûr que vous avez déjà travaillé avec.
Peut-être que “Spécification” ou “user stories” sont des termes qui vous sont tout de suite plus familier ? Eh bien sachez que ce genre de documents, que vous avez peut-être déjà rédigé ou qui vous ont servi de base pour le développement de votre projet, font partie intégrante de ce qui est appelé “l’ingénierie des exigences”.
Cet article et là pour vous montrer ce que représente l’ingénierie des exigences dans le déroulement d’un projet, vous permettre de comprendre son utilité et vous aider à remarquer les moments où vous êtes amené à travailler avec.
Commençons par le début, qu’est-ce qu’une exigence ? Selon l’IREB (International Requirements Engineering Board), qui est un organisme de certification dans le domaine de l’ingénierie des exigences, une exigence est :
-
Une condition ou une capacité dont un utilisateur a besoin pour résoudre un problème ou atteindre un objectif.
-
Une condition ou une capacité que doit posséder un système ou un composant de système pour satisfaire un contrat, une norme, une spécification ou tout autre document imposé formellement
Qu’est-ce que l’ingénierie des exigences ?
Avant d’en donner une définition, essayons de comprendre à quoi correspond l’ingénierie des exigences en utilisant la construction d’un bâtiment. Il est possible de faire une maison soi-même. Encore faut-il qu’elle soit de taille raisonnable, qu’on s'y connaisse déjà un petit peu et qu’on ne soit pas sur un terrain trop contraignant.
Vous voyez peut-être déjà les problèmes de s’attaquer à une telle tâche sans préparation. Certaines parties de la maison risquent de ne pas vous plaire, d’autres ne seront peut-être pas dans les normes actuelles et, pour finir, vous risquez même de dépasser le budget que vous vous étiez fixé au début.
Maintenant, imaginez la construction d’un immeuble de 30 étages avec plusieurs entreprises qui travaillent sur le même chantier. Là, on a besoin d’une bonne élaboration de plan, qui comprendra des contraintes comme le prix, les normes et le terrain. Cela nous permettra d’appréhender les problèmes en avance, de coordonner les différentes équipes et de pouvoir vérifier si la construction correspond bien à ce qui a été décidé.
Dans toute cette histoire, le plan représente nos documents avec nos exigences et tout le travail lié à ce plan représente alors l’ingénierie des exigences.
L'ingénierie des exigences est donc une démarche méthodologique qui regroupe l’ensemble des activités permettant d’établir et de maintenir un référentiel d’exigences dans le temps. En gros le but de l’ingénierie des exigences c’est d’éviter ce genre de montage :
Les avantages de l’ingénierie des exigences :
Maintenant, nous savons que l’ingénierie des exigences comprend une description exhaustive et précise du produit à développer, via l’utilisation d’exigences qui sont des phrases simples qui décrivent une action ou une caractéristique du produit.
Cela permet d'assurer une couverture et une compréhension du projet dans son ensemble. Cette approche documentée nous amène également d’autres avantages tels que :
-
La diminution des risques : En permettant une anticipation des problèmes liés aux exigences.
-
La confiance dans le projet : Avec une documentation précise et simple on s’assure que les parties prenantes se comprennent et qu’elles puissent s’accorder avant le développement.
-
Le pilotage du projet : En facilitant la fixation et la réalisation d'objectifs clairs et mesurables.
-
La qualité des livrables : On peut facilement déterminer les priorités à livrer et ensuite les tester en se basant sur la documentation liée.
-
Une diminution des coûts : En identifiant les problèmes lors de la rédaction de la spécification et non lors des phases en avales, mais aussi en cadrant le développement du projet.
-
Une fluidité dans les échanges : Grâce à une base commune lors des échanges.
Les 4 grandes phases de l’ingénierie des exigences :
On identifie 4 phases distinctes de l’ingénierie des exigences. Et pour les illustrer, nous avons besoin d’un beau projet. Disons que nous sommes dans une entreprise qui travaille sur le son et que nous partons sur le développement d’un baladeur audio.
1. Élucider :
Avant toute phase de développement, il est nécessaire de définir les besoins de notre projet. Dans notre cas, nous allons d’abord chercher un maximum d’informations sur le domaine d’application du produit : la musique, les supports physiques d’écoute (casques, écouteurs, enceintes), etc.
Il est nécessaire de connaître l’environnement sur lequel on va travailler et de le renseigner. Même si cela peut vous paraître simple, vous serez peut-être amené à travailler avec des personnes qui ne connaissent pas du tout ce domaine ou vous devrez tout simplement rappeler des principes simples qui peuvent s’oublier.
Ensuite, vient le contexte de notre activité : où notre produit se place dans l’environnement déjà existant de l’entreprise. Il n’est pas nécessaire de développer un produit trop proche d’un produit déjà existant, par exemple.
Il faut donc définir le problème à résoudre. Dans notre cas, il est plutôt simple : notre entreprise n’a aucun baladeur audio moyen de gamme. Il faut donc se renseigner auprès des différentes parties prenantes liées au problème et les identifier (clients, entreprises de certification, fournisseurs, chefs de projet, équipes de développement et d’autres encore). Il faut ensuite comprendre les attentes et les contraintes de ces différentes parties.
2. Analyser :
Sur la base des travaux précédents, on peut commencer une phase d’analyse qui est là pour raffiner le travail effectué. Nous allons définir clairement les parties prenantes, leur rôle, leur participation et ensuite leurs souhaits quant au projet. De ce travail, on peut définir nos premières exigences.
On retrouve alors des exigences utilisateur dites fonctionnelles, qui décrivent comment le produit fonctionne. Par exemple : le produit doit nous permettre d’écouter de la musique.
Et on retrouve aussi des exigences non-fonctionnelles comme des normes à respecter ou des certifications à passer. Par exemple : Le produit doit pouvoir être certifié IPX7 (waterproof).
Cette phase comprend une grosse partie de négociation. En effet, il est quasiment certain que les différentes parties prenantes peuvent avoir des souhaits qui rentrent en conflits. On peut également avoir le cas contraire, où deux parties prenantes formulent des exigences complémentaires. Dans ce cas, il convient de les « fusionner » en une seule exigence. Voici deux autres exemples :
Les codecs Bluethooth :
-
Équipe de développement : le produit doit implémenter les codecs Bluetooth audio SBC, AAC, l’aptX et LDAC.
-
Équipe marché : le coût de production du produit ne doit pas dépasser 80 €.
-
Après négociation entre les deux équipes, il s’avère que l’implémentation de tous les codecs audio augmente le coût de fabrication de façon significative. Il est donc décidé de réduire le nombre de codecs supportés.
-
Exigence finale : le produit doit implémenter les codecs Bluetooth audio SBC et AAC.
L’allumage de l’appareil :
-
Équipe marché : le produit pouvoir s’allumer facilement.
-
Équipe de développement : L’allumage du produit se fait par bouton physique.
-
Ici, les deux exigences peuvent se compléter en une seule.
-
Exigence finale : le produit doit implémenter un bouton d’allumage.
3. Spécifier :
Dans la partie précédente, nous avons pu mettre en évidence les besoins des différentes parties prenantes. Il est maintenant temps de s’atteler à la description de la solution. Le travail se fait sur des exigences de niveau système. Ici, on peut aborder les règles que doivent respecter les exigences : Elles doivent être atomiques (c’est-à-dire qu’elles sont non décomposables) concises, claires, sans ambiguïté, vérifiables et traçables.
-
Si le bouton de veille est pressé 3 secondes, alors le baladeur doit s’allumer.
Sur cet exemple, on constate un manque de précision. Que se passe-t-il si l‘utilisateur appuie sur le bouton alors que l’appareil est déjà allumé ? Il y a aussi une ambiguïté sur le temps. Que se passe-t-il si l’utilisateur appuie 4 secondes et non 3 ? Pour le reste l’exigence est concise et claire, on pourrait donc reformuler de cette façon :
-
Si le bouton de veille est pressé plus de 3 secondes et que le produit est éteint, alors le baladeur doit s’allumer.
4. Valider :
La validation se sépare en deux sous-parties. La première est la vérification. Ici, on parle uniquement des exigences qui ont été produites. Pour une vérification complète, il convient de faire relire les exigences produites par le plus de parties prenantes possible. Si une exigence système est produite, les développeurs et les testeurs seront alors invités à relire cette exigence pour être sûr qu’elle est bien développable et testable. On vérifie aussi la traçabilité de l’exigence (si on peut remonter au besoin qui ont permis cette exigence) et sa cohérence avec les autres exigences (conflits, doublons).
La deuxième sous-partie est la validation, qui est souvent opérée par une équipe de test. À ce moment-là, on vérifie que nos différentes exigences sont bien implémentées sur le produit. Sinon, cela signifie un travail supplémentaire soit du côté logiciel pour corriger le tir et s’aligner sur les exigences, soit du côté spécification, qui s’avère erroné.
Et voilà le déroulement global des différents process d’ingénierie des exigences d’un projet. C'est un domaine très large et qui englobe plein de métiers à des niveaux complètement différents. J’espère qu’avec cet article vous parviendrez à mieux appréhender les objectifs et les enjeux de l’ingénierie des exigences et le rôle que vous pouvez y jouer.