Note : 6 ; Il échoue à se mettre au goût du jour et déçoit sur sa prise en compte de l’agilité

J’avais adoré la 1ère et la seconde édition, c’est avec un plaisir par anticipation que j’abordais ce 3ème opus. J’ai l’habitude de faire perdre un point de note à une édition qui ne fait que se maintenir par rapport à l’édition précédente. Las, ce n’est pas 1 mais 3 points qu’a perdu cette édition-là ! J’avais gardé un excellent souvenir de la seconde édition et m’attendais à une modernisation conséquente du texte, plus particulièrement sur la convergence avec le mouvement et les pratiques agiles. Sur ce dernier point plus particulièrement les auteurs ne sont pas dans le coup et la déception est grande. Le texte reste un ouvrage majeur toutefois dans l’ingénierie des exigences. Voyons cela.

Ce sont 550 pages que compte ce 3ème opus, structurées sur 5 parties pour un total de 32 chapitres, hors annexes. Et ces dernières sont conséquentes. Ce n’est pas ce que l’on peut appeler une lecture légère, ni par le volume ni hélas non plus par le style. La première partie est forte de 4 chapitres sur 75 pages et va nous camper le décor de l’ingénierie des exigences. Le premier chapitre est fort bien fait, il donne la big picture des exigences, avec les différents types (dont les fameux NFR, Non functional Requirements), et comment ils s’articulent sur 3 niveaux. On y a un aperçu quoique superficiel du cycle de vie des exigences et des enjeux de leur bonne gestion. Le second chapitre est consacré aux exigences du point de vue des utilisateurs. On apprend donc à les distinguer et à identifier le décisionnaire. Le point réellement intéressant de ce chapitre sont les « bill of rights / bill of responsibilities » des utilisateurs.

Le chapitre 3 nous sert les « bonnes pratiques » du développement et de la gestion des exigences. Il y en a vraiment beaucoup. De fait, c’est un peu la table des matières de la seconde partie de l’ouvrage. Un chapitre pas spécialement sympathique à lire. Cette première partie se referme sur l’analyste : sa vie, son œuvre et ses compétences. Un chapitre bien fait, très clair sur ce qu’on attend d’un bon analyste.

La seconde partie est de loin la plus volumineuse de l’ouvrage. Et pour cause : elle traite du développement des exigences. Ce sont près de 310 pages qui constitue cette partie pour un total de 15 chapitres. Le chapitre 5 ouvre le bal avec les exigences métier. Celles-ci sont guidées par le document de vision qui forme la trame du chapitre. Celui-ci est honnête en nous guidant sur la manière d’en construire les différentes parties. La voix de l’utilisateur au chapitre 6 fait écho au chapitre 2. Si les persona modernisent un peu le propos mais ne sont que sommairement abordées, c’est surtout le ou les Product Champion(s) qui sont au centre de ce chapitre. Là aussi honnête mais sans plus. Pour le « requirements elicitation » abordé au chapitre 7, les auteurs nous proposent un processus qui structure le propos de ce chapitre. J’ai trouvé celui-ci particulièrement pénible à lire, le texte étant plus centré sur le processus que sur les pratiques.

Le chapitre 8 est consacré aux exigences utilisateur, c’est une partie presqu’entièrement consacrée aux cas d’utilisation où la déclinaison agile avec les User Stories est fort maladroitement évoquée également. Un chapitre convenable. Plus intéressant et original, le chapitre 9 fait le tour de la question des règles métiers, leurs différents types et la manière de les capturer. Très bien fait. C’est moins passionnant au chapitre 10, mais hélas incontournable : documenter nos exigences. Eh oui, on n’échappe pas au template SRS ! Dans la foulée le chapitre 10 évoque l’écriture elle-même, les qualités qu’elle doit porter, le style et des trucs et astuces d’écriture. Un peu indigeste mais absolument indispensable. Et comme c’est indigeste, le chapitre 12 se rattrape avec les représentations graphiques ! En fait il s’agit surtout de diagrammes. Sans être un ratage, ce n’est pas le meilleur chapitre et UML y est assez curieusement absent !

Au chapitre 13 il est question d’exigences liées aux données. Le début du chapitre sur la modélisation et le dictionnaire de données n’apporte pas grand-chose. La seconde partie dédiée aux reports apporte un peu plus, bien que la prose ne soit pas palpitante. Le chapitre 14 dédié aux exigences non-fonctionnelles est conséquent et le traitement sérieux. Une mention spéciale pour l’évocation du PLanguage, même si j’aurais aimé en avoir plus. J’ai trouvé le chapitre 15 consacré au prototypage un peu old school. Il réussit la performance de na pas évoquer la perspective agile dans le propos, mais comme la vision de l’agilité des auteurs semble en grand partie être guidée par Dean Leffingwell…

La priorisation est au menu du chapitre 16. Si les auteurs évoquent différentes approches, celle qui retiennent est intellectuellement intéressante mais fort compliquée en pratique. La validation des exigences au chapitre 17 nous emmène au cœur du old school. Un chapitre fort peu sympathique n’était-ce l’évocation des tests d’acceptation dans la partie « agile ». Je suis fort circonspect sur la réutilisation des exigences évoquée au chapitre 18, mais il m’a quand même donné envie de m’intéresser de près aux requirements patterns de Withall. Cette seconde partie se referme sur un « beyond requirements » qui aurait pu être meilleur qu’il n’est. L’articulation sur le project management, les tests et la conception n’a pas la profondeur escomptée.

La troisième partie évoque la pratique des exigences dans différents contextes, 7 pour être précis, représentés par autant de chapitres. 70 pages sont dévolues à cette odyssée. On commence vaillamment au chapitre 20 par l’évocation des projets agiles ! Enfin, c’est une façon de dire. Il s’agit surtout de souligner qu’il y a des trous dans la raquette des pratiques agiles pour proposer une transposition des pratiques existantes. Fort peu convaincant. Le remplacement de projets est aussi un raté, à mon avis. Alors que le propos aurait pu être développé sur le reverse engineering de spécifications, le propos est plutôt focalisé sur le fait qu’un remplacement de système n’est jamais « un pour un » et qu’il y a de nouvelles exigences à développer…

L’expression des exigences au niveau des progiciels, sujet du chapitre 22 est une nouvelle source de déception. Les challenges sont parfaitement identifiés, mais le sujet central, le « gap analysis » est à peine évoqué ! Le chapitre 23 consacré aux projets outsourcé ou offshore n’est couvert que sur quelques pages et c’est dommage car l’introduction est prometteuse. Mais il faut bien dire que ce n’est pas le sujet du livre, et il en faudrait un spécifiquement sur ce sujet. Introduction, c’est aussi le qualificatif qui convient pour le chapitre 24 couvrant l’automatisation de processus. Un sujet que je n’aurais pas identifié, je dois l’avouer.

Les analytics sont au menu du chapitre 25. C’est à la fois une bonne et une mauvaise surprise ! Bonne surprise car le sujet est clairement abordé, structurant même le sujet de manière particulièrement pertinente. Mauvaise surprise car on parle d’analytics à l’ancienne et pas de Big Data ! Cette 3ème partie se referme sur un chapitre consacré aux systèmes RT et embarqués. Autant dire qu’il est question de spécification système. Ainsi UML est évoqué, mail quel choc de voir qu’il n’est nul faite mention de SysML. Pour moi, c’est un gros « fail » !

La 4ème partie couvre le management des exigences. 4 chapitres sont consacrés à ce sujet pour un total de 60 pages. Le chapitre 27 qui ouvre le bal aborde les pratiques de gestion des exigences. Il a l’intérêt de présenter de manière exhaustive les activités que l’on place sous cette étiquette, mais le propos n’est guère palpitant. Le chapitre 28 est en quelque sorte celui du sordide : il traite de la gestion du changement et du très honnis CCB. Évidement c’est très orienté processus et templates. C’est lourd, très lourd et au final pas vraiment sympathique à lire.

La traçabilité fut un de mes sujets fétiches, il y a un moment de cela. Le chapitre 29 se montre un peu décevant pour moi à cet égard, mais pourra satisfaire ceux qui sont moins affutés sur le sujet. La rubrique outillage qui clôt cette partie est un incontournable. Je dois dire que je l’attendais aussi. Ce chapitre 30 fait un bon boulot à dresser le paysage des fonctionnalités, sans rentrer dans le détail, ce qui est aussi bien.

La dernière partie de l’ouvrage consacre ses deux chapitres à la mise en place d’une ingénierie des exigences. Ce sont une trentaine de pages qui sont dédiées au sujet. Le chapitre 31 est dévolu à l’amélioration de la gestion des exigences. Oui, c’est bien de gestion de changements dont il est question. On y parle courbe d’adoption de changement et un peu trop de processus à mon goût. Le livre se referme sur un chapitre 32 dédié à la gestion des risques. En quelques pages, les auteurs brossent les réponses typiques aux risques afférents aux différentes activités de gestion des exigences.

Le livre présente une substance solide. Mais il ne me fait plus vibrer comme avant. Sans doute est-ce moi qui ait changé. Je ne m’accommode plus aussi bien avec cette vision des spécification et nombre de points de vue me semblent aujourd’hui ne plus s’accoster avec une vision agile. L’agilité, parlons-en ! Contrairement au « mastering the requirements process », le texte n’a pas bien abordé un virage où l’approche agile est devenu un acteur majeur. Elle est mal comprise, mal abordée et le texte n’en apparait que plus sclérosé. Bref, je suis déçu.

Référence complète : Software Requirements, 3rd edition – Karl E. Wiegers & Joy Beatty – Microsoft Press 2013 – ISBN : 978 0 7356 7966 5