Note : 7 ; Pour capturer et écrire plus efficacement des exigences.

Le moins que l’on puisse dire est que ce livre ne date pas d’hier ! Il attire toutefois l’attention par au moins deux aspects : le premier est la cosignature de Gerald Weinberg. Le second se situe dans le titre car il y est question non pas de gérer, de collecter ou de capturer des exigences, mais de les explorer. C’est sans doute pour cela qu’il va être moins questions de processus que de pratiques centrées sur l’humain et l’aspect psychologique de cette exploration. Par certains côtés, on y côtoie l’agilité avant l’heure !

L’ouvrage en lui-même n’est pas anodin : il totalise près de 300 pages structurés en 25 chapitres, eux-mêmes regroupés en 5 parties. Toutefois l’ensemble se lit bien. La première partie compte un peu moins de 50 pages pour 4 chapitres et son thème attire tout de suite l’attention, car il y est question de négocier une compréhension commune ! Le premier chapitre prend le contrepied des méthodologies, mais en fait c’est des notations qu’il s’agit. Et les auteurs, à l’aide d’exemples très simples mettent en évidence à la fois la difficulté sous-estimée de compréhension des notations et introduisent la notion d’ambiguïté des exigences, qui sera particulièrement le sujet du second chapitre. Ce second chapitre est plutôt court et va se limiter à définir cette notion d’ambiguïté dans le domaine du recueil des besoins, et ses conséquences. Mais ce thème reviendra au long de l’ouvrage.

D’ambiguïtés, il est toujours question au chapitre 3, qui va adresser les sources d’ambiguïté : observation, interprétations dans lesquelles le facteur humain vient s’insérer. Les recherches de Daniel Kahneman n’étaient pas encore popularisées mais elles auraient pu être citées ici. Les auteurs mettent néanmoins en relief ces biais au travers d’exercices pratiqués en séminaire. Pour refermer cette première partie, les auteurs s’attaquent à la pratique des questions directes au travers d’arbres de décision. Sans citer les biais cognitifs, ils mettent en question le postulat sous-jacent : la nécessité de s’adresser à des « êtres humains parfaits ». S’ils ne sont pas opposés à leur emploi, le verdict est que cette pratique ne suffit pas.

La seconde partie, « ways to get started » compte également une cinquantaine de pages pour 5 chapitres. Et justement, le chapitre 5 qui figure en ouverture évoque les points de départ. Le chapitre est peu convaincant, en évoquant les différentes racines desquelles nous pouvons partir (solution, technologie, métaphore, etc.), il échoue à donner un sens à cette notion de départ. Le chapitre 6 nous plonge dans le questionnement. Plus précisément dans le questionnement initial avec les « context-free questions » qui n’ont pas d’ancrage donc pas de biais par rapport au contexte du futur produit. C’est un bon chapitre, non seulement parce qu’il rentre dans le concret de ces questions et de la manière de les amener, mais aussi parce qu’il les complète des « méta-questions » au-dessus de celles-ci.

Au chapitre 7, il est question d’impliquer les bonnes personnes au sein du projet. Si la finalité semble bonne, il me parait difficile d’avoir une lecture de l’approche proposée, pour autant qu’il y en ait une. Dommage. Pour le meilleur ou pour le pire, les réunions sont un outil incontournable dans l’activité de recueil des exigences. Le chapitre 8 a pour objet d’en clarifier les finalités, les règles de participation et d’interaction et de manière générale, l’établissement d’un cadre. Le propos est clair et met le doigt sur les bons éléments, tout en étant peu différenciant par rapport aux autres (bonnes) lectures sur le sujet. Cette seconde partie se referme sur un chapitre 9 consacré aux heuristiques de réduction d’ambiguïtés ! Ce n’est pas le chapitre le plus simple à lire du livre. Il s’articule autour de dialogue qu’il analyse et déconstruit en proposant des alternatives d’expression. Il y a pas mal de subtilités d’expression en langue anglaise qui sont très faciles à rater.

La 3ème partie a pour thème l’exploration des possibilités. Il est fort d’une quarantaine de pages sur 4 chapitres. Il s’ouvre sur un chapitre 10 dédié aux réunions pour générer des idées, en l’occurrence ici : le brainstorming. Ici, contrairement à leur habitude, les auteurs nous proposent un véritable déroulé de ce type de réunion. Avouons qu’il est clair et sensé. La notion de « cerveau droit » a aujourd’hui du plomb dans l’aile, le chapitre 11 lui octroie néanmoins une place privilégiée. Ce court chapitre évoque quelques outils, mais c’est surtout le sketching qui en est le centre. La pratique n’est abordée que de manière disons, introductive.

L’heuristique du nommage est au menu du chapitre 12. Plus précisément, nous parlons ici du nom du projet ! Ce court chapitre nous propose un processus de nommage en 3 étapes assez peu convaincant. D’un côté, l’idée que le pouvoir évocateur du nom ne soit pas ignoré est assez novateur pour l’époque. D’un autre côté, la réflexion est un peu embryonnaire et limitée hélas au nom du projet. Cette troisième partie se referme sur un chapitre 13 consacré aux conflits, inévitables sur tous projets. Au-delà de l’analyse de ces conflits, le propos met l’accent sur la nécessité d’une activité de facilitation de bonne qualité.

La 4ème partie est dévolue à la clarification des attentes. Elle occupe environ 70 pages réparties sur 5 chapitres. Nous entrons tout de suite au cœur du sujet des exigences au chapitre 14 avec les fonctions. La pratique se démarque de la famille IEEE 830, mais n’en reste pas moins classique. L’emphase est particulièrement mise sur les fonctions cachées ou « volantes » afin d’élaborer progressivement une liste de plus en plus complète. Une approche qui, l’un dans l’autre, reste classique. Le chapitre 15 va compléter ce panorama avec l’exploration des attributs. L’accent est mis sur les attributs implicites versus explicites, toujours dans cette recherche d’élimination des ambiguïtés. Le propos est plus riche que celui du chapitre précédent et pourra même être mis à profit au sein d’approches différentes.

Avec le chapitre 16, nous abordons les contraintes. C’est un chapitre assez élaboré qui nous invite à regarder les contraintes certes comme un cadre et des limites, mais aussi comme des opportunités et un contexte libérateur de créativité. Le propos s’écarte résolument ici de la formalisation classique des contraintes. Le chapitre 17 aborde un sujet plutôt original dans l’univers des exigences : les préférences. Il faut entendre ici « préférences » au sens d’options. Mais les auteurs vont plus loin : ils cherchent à redéfinir la notion de contrainte en termes de préférences, donc de contraintes « molles » ou du moins négociables. Cette quatrième partie se referme sur un chapitre 18 consacré aux attentes. Il s’agit plus d’une discussion que de guides : les attentes sont-elles l’expression de biais ? Sont-elles logiques ? Doivent-elles être limitées à priori ou rester ouvertes ? Point de réponses tranchées ici, mais de nouvelles perspectives.

La dernière partie de l’ouvrage compte 7 chapitres sur 70 pages avec comme promesse : augmenter grandement nos chances de succès ! Le chapitre 19 revient sur la notion d’ambiguïté, avec l’idée de la mesurer : la « sonder » serait plus juste. L’idée est intéressante, mais le propos ne rentre pas assez dans le vif du sujet à mon goût. Le chapitre 20 évoque la revue technique, de manière assez aride il faut l’avouer. Les amateurs de processus et de reportings en seront en tout cas ravis. Au chapitre 21, c’est la satisfaction utilisateur que l’on va chercher à mesurer, que ce soit par le biais de sondages ou de prototypes. On ne saurait se plaindre que le sujet soit évoqué, mais on a aussi un peu l’impression qu’il l’est à la façon d’une pièce rapportée.

Au chapitre 22, il va être question de cas de tests. Il ne s’agit pas d’une démarche de test en tant que tel mais d’un plaidoyer pour leur mise en place. Le propos évoque bien qu’il s’agit de tests « boite noire », mais difficile de comprendre si l’on parle de tests d’acceptation ou de tests exploratoires. Il s’agit un peu des deux, me semble-t-il. Le chapitre 23 évoque l’étude de produits existants. Plus précisément il s’agit de « gap analysis » pour identifier ce qui manquerait au produit comparativement à un autre produit semblable. Là encore, il ne faut pas s’attendre à une réelle démarche mais d’une discussion qui nous met aussi en garde contre la surcharge fonctionnelle. Le chapitre 24 s’articule autour des décisions et validations, mais ouvre le sujet sur les hypothèses sous-jacentes et d’autres biais qui entachent ces décisions. Sans doute le sujet aurait-il mérité tout un pan de l’ouvrage ! Le livre se referme sur un chapitre 25 justement intitulé « ending ». Il ouvre la porte à l’angoissante question : que se passe-t-il quand la formulation des exigences est terminée ? N’est-elle jamais terminée ? Comment aborder la question du changement ? Ces questions sont trop complexes pour tenir en un seul chapitre, hélas.

Même s’il est ancien, ce texte s’avère intemporel, précurseur même de thème qui prendront de l’importance plus tard : réflexion sur la gestion des ambiguïtés et les biais cognitifs. Le livre est agréable à lire, et le fait qu’il soit illustré de ce que l’on peut littéralement appeler des gravures et une surprise. Mais attention, le style est très littéraire, et l’anglais beaucoup plus riche que celui des ouvrages techniques que j’ai l’habitude de lire, cela posera beaucoup de difficultés à quiconque n’est pas très à l’aise avec la VO.

Référence complète : Exploring Requirements: Quality before design – Donald C. Gause & Gerald M. Weinberg – Dorset House 1989 – ISBN: 0-932633-13-7