Note : 7 ; Les exigences selon RUP, avec beaucoup d’éléments sur les pratiques, mais aussi un manque de matière sur la mise en œuvre.

Ce livre traite de la gestion des exigences vue par Rational Unified Process. Les auteurs ont d’ailleurs travaillé sur l’outil Requisit Pro. La lecture en est plaisante, le découpage en nombreux chapitres assez découplés bien que complémentaires y aide beaucoup. Comptez 385 pages pour ce volume qui comprend en sus près de 90 pages d’annexes ! Les 35 chapitres que les auteurs ont concoctés sont divisés, non en parties mais en 8 « skills », une petite subtilité, mais assez intelligente !

En une trentaine de pages comptant quand même 3 chapitres, la première partie fort opportunément appelée « introduction » est vite passée ! Si on s’intéresse aux grands classiques du « pourquoi » des exigences, c’est à dire le coût des exigences erronées, on arrive vite à la définition de ce qu’est une exigence au chapitre 2. C’est ici aussi que l’on introduit la pyramide problème / besoin / solution que j’aime tant ! L’auteur n’oublie pas que le développement logiciel, même dans l’ingénierie des exigences, est une affaire d’hommes et de femmes, il consacre le chapitre 3 à l’équipe et aux compétences. Bref, une première partie tout à fait sympathique.

Ce sont 3 chapitres (sur environ 40 pages) qui sont également consacrés à la seconde partie « Analyser le problème » qui est le premier « team skill » du livre. Nous voilà rentrés dans la matière. L’auteur nous propose 5 étapes pour définir le problème. Les choses sont rarement aussi simples que l’on puisse suivre une telle séquence de manière immuable, mais nombre d’analystes devraient s’inspirer de ce que l’on trouve ici : identification des acteurs, définition du périmètre du système et de ses contraintes et surtout, surtout : l’analyse causale ! La matière proposée concernant l’analyse métier est bien moins convaincante, mais on peut bien excuser de petites faiblesses… Le dernier chapitre de cette partie met surtout en musique ce que nous avons vu avec l’étude de cas du livre : HOLIS. Fort intelligemment, il ne se contente pas de reprendre la matière du chapitre 4, on y ajoute quelques petits éléments comme l’elevator statement.

La 3ème partie, comprendre les besoins utilisateurs, c’est vraiment du sérieux : pas moins de 9 chapitres ici ! De petits chapitres toutefois, car ils totalisent moins de 80 pages. Identifier les besoins utilisateur, ce n’est pas si simple et le chapitre 7 est consacré à ce challenge, même si c’est seulement sur quelques pages. Quelle est la différence entre « feature » et « requirement » ? La plupart du temps, on s’arrête à une bonne zone de flou. Dean Leffingwell nous propose une articulation claire entre besoin / feature et requirement. Savoir questionner est un art essentiel dans l’ingénierie des exigences. Si le sujet n’est pas aussi puissamment investigué que dans « exploring requirements » de Weinberg et Gauge, au moins est-il évoqué de manière non anecdotique. Les workshops sont un complément naturel à cette activité et là encore une matière intéressante et exploitable nous est proposée. Le chapitre qui suit sur le storyboarding est là pour servir d’introduction à celui sur les Use Cases qui va suivre. Il est vrai qu’aujourd’hui, en ingénierie agile, on s’appuiera d’avantage sur le Story Mapping. Oui, bien sûr les cas d’utilisation sont évoqués, c’est forcé ! En fait, ils le sont plusieurs fois dans l’ouvrage, ici on s’arrêtera à la vision d’ensemble. On ne peut évoquer les cas d’utilisation sans parler de rôles, l’occasion pour l’auteur pour évoquer brièvement les cartes CRC, une brièveté certainement frustrante mais il est certainement possible de se reporter sur l’ouvrage de Bellin et Simone si le cœur vous en dit… On termine cette partie très riche par l’évocation des prototypes, à titre d’introduction.

La « team skill 3 », c’est définir le système, on a 3 chapitres pour cela. Comptez 3 chapitres et un peu moins de 30 pages. Oui, un moment, on parle documents et organisation de ceux-ci. Ce n’est pas le plus passionnant, mais au moins le sujet est-il abordé avec une certaine intelligence. Un chapitre est même consacré au document de Vision (avec un template, s’il vous plait), si cher à Philippe Kruchten. Retour à l’aspect humain pour clore le chapitre, avec le Product Champion. Ce qu’on y évoques recoupe pas mal ce qu’aujourd’hui on appelle un Product Owner.

Gérer le périmètre, c’est le sujet de « team skill 4 », qui couvre 4 chapitres sur un peu plus de 40 pages. On commence par le « pourquoi » de cette problématique de périmètre : en quoi est-ce important et dimensionnant. Pour aborder cette question du périmètre, Leffingwell s’adosse aux dimensions suivantes : des priorités qui se ventilent sur des releases, une gestion des risques et de l’effort, le tout illustré avec HOLIS. On trouve là les prémices de SAFe… L’engagement des utilisateurs dans cette gestion de périmètre est évoqué, mais guère convaincante. Personnellement j’ai bien aimé le chapitre 22, non pas parce qu’il évoque RUP (dans lequel l’approche de l’auteur s’inscrit), mais parce qu’il évoque aussi comment la gestion du périmètre a évolué entre le modèle en cascade, le modèle en spirale de Boehm et finalement le modèle itératif.

La partie consacrée au raffinement des spécifications est l’autre grosse partie du livre : 6 chapitres sur un peu plus de 80 pages. On commence par évoquer en profondeur la nature des exigences : comment on différencie le domaine du problème de celui de la solution, ou encore les différents types d’exigence. Le chapitre 23 est particulièrement affuté sur le sujet. S’en suit une introduction sur la spécification des cas d’utilisation. Bel exercice, même s’il ne saurait concurrencer les livres dédiés au sujet (je pense particulièrement à celui de Géri Schneider. Quand on parle de requirements à l’ancienne, on parle souvent de SRS et du fameux IEEE 830-1998. Le sujet n’est pas esquivé. Ambiguïtés et précision font parties des pratiques que doit développer tout analyste. Le sujet n’est qu’effleuré, même s’il l’est plutôt bien. Mais « exploring requirements » ou Tom Gilbs avec Planguage vont au moins un cran plus loin. La question des critères et de la mesure de qualité des spécifications est la mesure de la rigueur de l’analyste. Leffingwell aborde honorablement le sujet, même si je préfère la prose des Robertson dans « Mastering Requirements » à cet égard. On referme cette partie avec une revue des formalisations plus ou moins funkies des exigences : pseudo-code, diagrammes d’état-transition, etc.

La dernière partie « building the right system » reste imposante avec 6 chapitre et plus de 70 pages. Le chapitre consacré à la transition des exigences à la réalisation n’est pas mon préféré et apporte je pense assez peu. La traçabilité est un grand classique. S’il a cessé d’être un centre d’intérêt pour moi, le sujet existe, dommage qu’il soit abordé sous l’angle des outils, tout comme le sera le volet sur le change management. Par contre le test et la validation sont des points d’importance. Ils ne sont peut-être pas traités avec l’importance qu’ils devraient mais ils sont là. J’aurais par contre du mal à cautionner l’approche d’effort de validation par le ROI…

Le point fort de cet ouvrage est l’importance du tour d’horizon qu’il nous imprime sur l’activité d’ingénierie des exigences. C’est probablement l’ouvrage le plus complet à cet égard, et il faut bien avouer que l’on ne s’ennuie jamais. Nombre sinon tous les sujets peuvent nous amener sur des textes plus complets, et c’est très bien.

Au delà de ceci, on regrettera toutefois que le livre se cantonne souvent à la présentation des techniques de capture d’exigences, et que les véritables “guidelines” soient par trop absents, de même qu’un véritable processus de gestion d’exigences capable de cimenter l’ensemble des techniques présentées. Ceci fait que je préfère l’ouvrage de Suzanne et James Robertson, et que je considère celui-ci à la fois comme un complément et un texte embrassant plus large sur les différents volets de l’ingénierie des exigences.
Ce texte a connu deux éditions depuis celle-ci, dont la dernière markettée en agile.

Référence complète : Managing Software Requirements, a unified approach – Dean Leffingwell & Don Widrig – Addison Wesley / O.T. series 1999 – ISBN: 0-201-61593-2