Il y a longtemps
Cela fait un bon moment que j'ai passé ma certification IREB CPRE niveau Fondation, en 2007 (année de fondation de l'International Requirements Engineering Board – IREB). À cette époque, l'ingénierie des exigences (IE) était en plein essor. L'agilité était davantage associée à la forme physique et mentale d'un retraité qu'au développement logiciel.
Ingénierie des exigences vs. Agilité ?
Ces dernières années, la tendance s'est inversée. La réussite passe par l'agilité. Les entreprises entreprennent des transformations agiles. Le développement logiciel s'appuie sur des méthodologies agiles telles que Scrum ou Kanban. L'agilité est donc devenue synonyme de jeunesse et de dynamisme. Parallèlement, j'ai le sentiment que l'ingénierie des exigences (IE) a perdu de son attrait. Aujourd'hui, les utilisateurs rédigent des récits utilisateurs, et non plus des cas d'utilisation. Au lieu de spécifications, on crée des cartographies des récits utilisateurs.
Il y a quelques semaines, un autre Product Owner m'a demandé si nous pouvions organiser une formation IREB CPRE en mode normal. Une question m'a alors taraudé : à l'ère de l'agilité et des user stories, les connaissances en ingénierie des exigences acquises grâce à la certification CPRE ont-elles encore une réelle valeur ? Ou est-ce tout le contraire ?
« RE est mort, vive le récit utilisateur ? »
La recherche d'une réponse
Pour trouver la réponse à la question que je m'étais posée, je suis retourné aux fondamentaux. Quelque part entre « Scrum pour les Nuls », « Holacratie », « Kanban » et « Bitcoin », j'ai retrouvé sur mon étagère « Basic Knowledge of Requirements Engineering » de Klaus Pohl et Chris Rupp. C'est le manuel officiel de l'examen CPRE niveau Fondation.
J'ai commencé à parcourir les pages. Plus j'avançais, plus je me rendais compte que, même après cinq ans de projets agiles, j'applique toujours les principes fondamentaux de l'ingénierie des exigences que j'ai appris à l'époque. Que ce soit pour définir le contexte du système à développer ou pour enrichir les user stories avec du contenu pertinent pour l'équipe de développement. La documentation produit est également bien plus simple grâce aux méthodes de l'ingénierie des exigences.
L'ingénierie des exigences dans le quotidien d'un Product Owner
J'ai récemment utilisé avec succès le modèle de Kano suite à un excellent atelier de cartographie des récits utilisateurs. Nous avons priorisé les récits utilisateurs développés avec les parties prenantes. Il en a résulté une compréhension partagée du Produit Minimum Viable (MVP).
Grâce à la grande variété de techniques de collecte de données, je peux me familiariser rapidement avec de nouveaux domaines. Elles m'aident également à identifier les scénarios utilisateurs potentiels, tout comme elles aident à déterminer les exigences traditionnelles.
Les cas d'utilisation, les diagrammes de séquence et d'activité sont d'excellents outils pour documenter le système pendant son développement.
Les modèles de concepts d'entreprise aident également, dans un monde agile, à construire un glossaire pour un langage technique commun (qui n'est pas familier avec les discussions interminables sur la question de savoir si, par exemple, le « partenaire contractuel » et le « client » sont la même chose ou des choses différentes).
Sans oublier mon outil préféré : le modèle de phrase. Je l’utilise encore aujourd’hui pour formuler des règles métier et parfois même des critères d’acceptation.
En y regardant de plus près, avec un petit ajout, le modèle de phrase pourrait même être utilisé comme un nouveau modèle de récit utilisateur :
Entre les deux options :
«Le système de gestion de contenu doit permettre au gestionnaire de contenu de supprimer les articles de blog afin que les articles obsolètes n'apparaissent plus sur la page d'accueil. » et
«En tant que gestionnaire de contenu, je souhaite pouvoir supprimer les articles de blog afin que les articles obsolètes n'apparaissent plus sur la page d'accueil. »
La différence est désormais minime. On peut donc commencer à débattre de l'opportunité de supprimer ou plutôt de désactiver ces blogs, ou encore de supprimer automatiquement les articles datant de plus de x années.
Je pourrais citer bien d'autres exemples. Mais je pense que ma question a trouvé sa réponse.
Ma réponse
L'ingénierie des exigences est bel et bien vivante !
Les connaissances de base acquises constituent également une valeur ajoutée significative dans les projets agiles. L'ingénierie des exigences et les méthodes enseignées au niveau Fondation CPRE contribuent à développer d'excellents logiciels, quel que soit le modèle de développement.
Bonne chance!
Bien à vous, Benjamin Wyss
Académie
Vous souhaitez apprendre les bases de l'ingénierie des exigences ou actualiser vos connaissances ? Nous vous invitons donc cordialement à rejoindre notre Académie.
