Note : 8 ; Toujours une référence incontournable sur la gestion des exigences.
Quel meilleur moment pour faire la note de lecture de la seconde édition d’un livre, que la parution de sa troisième édition ? Je connais la réponse : n’importe quel moment tant qu’il précède la sortie de ladite troisième édition ! Toutefois c’est bien maintenant que je la livre. J’avais fait de la première édition mon « book of the year » 1999, voyons ce qu’il en est de celle-ci (la note de lecture de la troisième édition viendra bien un jour, mais plus tard).
Par rapport à la première édition, il est passé de 400 pages à 550 ! C’est une inflation importante pour moi qui apprécie la brièveté du propos, même si il est de qualité. Le grammage supérieur du papier augmente même cette impression de volume supérieur. Sur ces 150 pages supplémentaires, 80 vont au texte principal, mais 70 viennent grossir encore plus les annexes. Je trouvais déjà les annexes de la première édition conséquentes, mais nous avons désormais deux parties dans ce livre : le texte principal long de 365 pages en 15 chapitres et les annexes au nombre de 4 qui couvrent près de 200 pages. Idéalement il aurait fallu faire deux livres mais le second ne se serait probablement pas ou peu vendu. Quoi qu’il en soit je ne rentrerais pas dans le « manuel de référence Volere » dont j’avoue qu’il ne m’intéresse guère.
J’ai toujours trouvé qu’une manufacture de qualité associée à une mise en page soignée augmentait le plaisir de la lecture. Cela se démontre ici. Outre le texte de qualité, les auteurs utilisent intelligemment et sans excès les marges pour des citations, de l’iconographie ou des références bibliographiques.
Cette seconde édition se démarque de la première par la prise en compte de l’approche agile. Tout d’abord cela se traduit par des paragraphes dédiés à trois profils de projets en introduction de chaque chapitre :
- Les projets « rabbit » : traduisez, les projets agiles.
- Les projets « horse » : ce sont les projets standard de l’industrie, itératifs ou « en V », s’appuyant sur une certaine dose de documentation.
- Les projets « éléphant » : ce sont les projets lourds, impliquant généralement de grosses équipes sur de longues durée de temps et s’appuyant sur une documentation lourde.
L’approche et le point de vue des auteurs par rapport à l’agilité est particulièrement pertinent. Ils se félicitent de l’arrivée d’une approche mettant l’emphase sur le produit plutôt que sur les artefacts, et apprécient l’idée d ‘éliminer une documentation quand elle n’est pas nécessaire. Toutefois cela ne doit pas exclure de procéder avec intelligence par rapport à la compréhension du besoin, ni de réfléchir avant d’implémenter ! Voici un ouvrage qui devrait prendre place sur l’étagère du product owner et même en fait du développeur agile ! Pourtant, si les auteurs considèrent que Volere ne dit pas être suivi comme un processus prescriptif, mais plutôt comme une « check list », lire le texte et l’appliquer avec ce point de vue en tête demande pas mal de maturité.
Venons-en à la matière première : le livre, constitué de 15 chapitres couvrant 360 pages (pour le partie principale). En moyenne, les chapitres sont un petit peu plus long que ce que j’apprécie généralement. Mais la prose est agréable, donc ça va.
Passons rapidement sur le premier chapitre introductif qui balaye rapidement la problématique de la capture des exigences et ce que sont les exigences fonctionnelles et non fonctionnelles. C’est une bonne mise en bouche et le sujet est bien traité. Le second chapitre est quand à lui une introduction à Volere, le processus imaginé par les auteurs. On balaye en diagonale la « big picture », c’est en quelque sorte la table des matières de ce qui suit.
Le « project blastoff » proposé par les auteurs n’est probablement pas l’approche de démarrage de projets que je préfère. Elle ne met pas tellement l’accent sur la vision et le positionnement markéting. Mais de nombreux démarrage de projets sont simplement bâclés. En suivant ce guide qui couvre honnêtement les différentes facettes de ce démarrage, vous avez toutes les chances de faire un travail tout à fait honorable, alors…
L’une des particularité de l’approche Volere est la façon dont elle articule la capture du besoin sur les cas d’utilisation métier et les évènements métier. Le chapitre 4 est consacré à ce sujet. J’aime bien la façon dont cela est abordé ici. Un chapitre à ne pas rater car il conditionne la compréhension de nombreux autres.
James et Suzanne Robertson ne parlent pas de capturer les exigences, mais d’aller à leur pêche. C’est l’objet du chapitre 5. Il y a des techniques pour cela, les auteurs n’en évoquent pas moins de 16 (certaines mieux détaillées plus tard). Autant pour ceux qui pensent qu’aller se promener avec son calepin sous le bras est tout ce qu’il est nécessaire de savoir. En fait les techniques évoquées, brièvement mais efficacement, sont des invitations à creuser ces sujets via les références proposées. Le chapitre le plus riche du livre, sinon le meilleurs.
Le chapitre 6 complète le précédent en évoquant les scénarios. Si cela vous semble rappeler les cas d’utilisation, c’est normal. Mais ce n’est pas un mal. Le chapitre 7 complète les deux précédents en clarifiant la notion d’exigence fonctionnelle et surtout en s’appliquant à différencier le besoin de la solution.
Les exigences non fonctionnelles sont abordées au chapitre 8. Les auteurs en proposent une taxonomie. Celle-ci en vaut bien une autre. Quoi qu’il en soit le sujet est bien couvert.
Avant même que TDD ne soit à la mode, Volere évoquait la notion de « Fit criterion » pour les exigences. Le chapitre 9 expose cet aspect et explique comment ces « fit criterion » aident à préciser et lever les ambigüités des spécifications.
Le chapitre 10 aborde la question de la chose écrite. Volere propose un Template de rédaction du besoin, ainsi que le « Shell » qui conviendra mieux aux agiliste. Pas le chapitre le plus passionnât du livre, à l’exception de la partie consacrée au « Shell ».
Ecrire les exigences ne suffit pas. Elles peuvent et doivent être revues (même si elles ne sont pas écrites). Le « quality Gateway » du chapitre 11 traite cet aspect. A ne pas rater.
Le prototypage des exigences abordé au chapitre 12 n’est probablement pas le texte de référence sur le sujet. Mais au moins est-il abordé. A contrario, le chapitre 13 sur la réutilisation des exigences est le moins convainquant du livre. Je ne l’étais déjà pas beaucoup en 1999. Je le suis moins encore maintenant. Mais peut-être que je manque encore de maturité…
Le chapitre sur la revue des exigences complète le « quality Gateway » du chapitre 11, il aurait dû le prolonger dans le plan du livre.
Le livre se conclut par un chapitre 15 qui fait une sorte de « wrap up » du livre, de manière un peu désordonnée je dois dire. J’ai cependant bien aimé la référence aux rétrospectives.
Même si la note du livre baisse un peu, celui-ci reste une de mes références principales sur le sujet. La qualité du contenu et de la rédaction, la richesse de la matière en font une référence que je recommande très fortement. La prose a été modernisée à plusieurs égard. Pour celui ou celle qui désire faire de l’analyse son métier, ce sont là d’excellentes fondations, d’autant que ce livre ouvre sur de nombreuses autres références.
Référence complète: Mastering the Requirements Process, 2nd edition – Suzanne Robertson & James Robertson – Addison Wesley 2006 – ISBN : 0-321-41949-9
Software Freethinker 
