Depuis la nuit des temps, notre terre n’a cessé de tourner, notre monde n’a cessé d’évoluer, et l’IREB n’a cessé d’améliorer sa formation pour traiter la problématique d’ingénierie des exigences.

Un nouveau syllabus v3.0 a vu le jour depuis le 1^er avril 2021, sa traduction en français a été effectuée par le CFTL dans le cadre de la collaboration de ce dernier avec l’IREB.

Pour découvrir le contenu détaillé de ce syllabus, rendez-vous sur le site de l’IREB. Si vous voulez connaitre les usages qui peuvent être réalisés avec cette méthodologie, je vous recommande l’article de blog Formation « IREB fondation », pour quoi faire ? sur le site web de KEREVAL.

Dans cet article, nous allons parcourir, de manière globale, les nouveautés du syllabus IREB V3.

Pourquoi IREB V3 ?                                                    

Les retours d’information d’une enquête, faite par l’IREB en 2017, ont montré que le syllabus IREB V2 répond aux besoins les plus importants du marché ; cependant, plusieurs techniques décrites sont obsolètes dans la pratique et d’autres font défaut. Par exemple, il n’y a pas suffisamment d’informations sur les aspects itératifs et adaptatifs liés à l’agilité.

La décision prise alors est de procéder à une révision majeure du syllabus afin de couvrir à la fois les approches agiles et planifiées de la spécification et la gestion des exigences.

Qu’est-ce qui est nouveau ou différent dans ce programme ? 

La répartition des chapitres : Différent

Un syllabus est composé de chapitres principaux qui couvrent chacun une unité d’enseignement (UE). La figure suivante présente les nouveaux chapitres et la correspondance entre les chapitres des syllabus V2 et V3 :

                                               Figure 1- Synthèse des nouvelles unités d’enseignement

La classification des exigences : Différent

Les exigences sont classées suivant trois types (anciennement catégories) : les exigences fonctionnelles, les exigences qualité et les contraintes, et suivant trois niveaux d’abstraction : les exigences « métier », les exigences « système » et les exigences « composant ».

L’IREB v3 décrit une nouvelle classification d’exigences à laquelle le produit final doit répondre :

Figure 2- La nouvelle classification d’exigences

Les 9 principes : Nouveau

Tout comme le syllabus fondation ISTQB (Chapitre 1.3), l’IREB dans cette nouvelle version a mis en place un chapitre dédié pour les principes :

Principe 1 – Orientation vers la valeur : Les exigences sont un moyen d’atteindre une fin, et non une fin en soi.

Principe 2 – Parties prenantes : L’ingénierie des exigences (IE)  consiste à satisfaire les désirs et les besoins des parties prenantes 

Principe 3 – Compréhension partagée : Le développement réussi des systèmes est impossible sans une base commune

Ce principe considère que la bonne connaissance du domaine, la réussite d’une collaboration antérieure, la culture et les valeurs communes et la confiance mutuelle sont des facteurs favorables à une compréhension commune, tandis que la distance géographique, l’externalisation ou les grandes équipes à forte rotation sont des obstacles.

Principe 4 – Contexte : Les systèmes ne peuvent être compris isolément

Exemple : si le bateau est un système, les caractéristiques de la mer vont aider à comprendre la forme de la carène.

Principe 5 – Problème – Exigence – Solution : Un triple entrelacement inévitable

Les ingénieurs des exigences visent souvent à séparer les préoccupations « Problème – Exigence – Solution » afin de rendre la gestion des tâches de l’ingénierie des exigences plus faciles même si les trois notions doivent être considérées.

Principe 6 – Validation : Les exigences non validées sont inutiles

La validation des exigences doit commencer dès le début du processus de l’ingénierie des exigences, afin de contrôler le risque d’insatisfaction des parties prenantes dès le début. Ce principe comprend également des lignes directives afin de vérifier la validation des exigences.

Principe 7 – Évolution : L’évolution des exigences n’est pas un accident, mais le cas normal

Les systèmes sont sujets à évolution (modifications de processus métier, changements de technologie, de lois ou autres), ce qui engendre des demandes de changement d’une exigence ou d’un ensemble d’exigences pour un système.

Dans ce principe se trouve l’un des défis de l’ingénieur des exigences, qui est de poursuivre deux objectifs apparemment contradictoires :

• Permettre des changements d’exigences
• Maintenir la stabilité des exigences

Principe 8 – Innovation : Il ne suffit pas d’en faire plus

Au-delà de la satisfaction des parties prenantes, le fait de favoriser l’innovation dans l’ingénierie des exigences rend le client heureux !

Principe 9 – Un travail systématique et discipliné : On ne peut pas s’en passer dans l’IE

Il est nécessaire de s’appuyer sur des processus et des pratiques appropriées pour élucider, documenter, valider et gérer systématiquement les exigences en les adaptant au contexte du projet.

Caractéristiques des produits d’activités : Nouveau

Un produit d’activités est un résultat intermédiaire ou final enregistré et généré dans un processus de travail. Chaque produit d’activité est caractérisé par son type, sa catégorie et sa forme.

Figure 3- Les caractéristiques d’un produit d’activité

Cette nouvelle version introduit la durée de vie et la taille des produits d’activités. Quant aux formes, qui existaient déjà dans la version précédente, ont eu que certaines modifications.

Durée de vie des produits d’activités :

Dans sa nouvelle version, l’IREB a proposé trois catégories de produits d’activités pour définir leurs durées de vie :

• Produits d’activités temporaires : créés pour soutenir la communication et créer une compréhension commune.
• Produits d’activités évolutifs : se développent en plusieurs itérations au fil du temps ; ont besoin de certaines métadonnées, le contrôle du changement peut s’appliquer.
• Produits d’activités durables : ont été établis ou publiés ; nécessitent un ensemble complet de métadonnées ; le processus de changement doit être suivi.

Un produit d’activités temporaire peut être converti en un produit d’activités évolutif (en le conservant et en y ajoutant des métadonnées). De même, un produit d’activités temporaire ou évolutif peut devenir durable en étant associé à une baseline ou livré.

Formes des produits d’activités :

Les produits d’activités peuvent être représentés sous différentes formes, en se basant sur le langage naturel, les templates, les modèles et les prototypes. Les nouveautés du syllabus IREB fondation version 3.0 portent sur les prototypes et les modèles.

Les prototypes :

On ajoute les prototypes à la liste des nouvelles formes des produits d’activités, ce sont des moyens de spécifier et valider les exigences par l’exemple. On distingue deux types de prototypes, exploratoires et évolutifs :

– Les prototypes évolutifs sont des systèmes pilotes qui forment le noyau d’un système à développer.

– Les prototypes exploratoiresqui servent qu’à apporter une compréhension commune, clarifier des exigences ou valider des exigences à trois niveaux de fidélité :

• Prototypes basse-fidélité, comme les wireframes, qui servent principalement à discuter et à valider des idées de conception et les concepts d’interface utilisateur à travers des simples outils construits.
• Prototypes moyenne-fidélité, comme les maquettes, qui servent principalement à spécifier et à valider les interfaces utilisateurs à l’aide des écrans et des flux de clics réels, mais sans réelle fonctionnalité.
• Prototypes haute-fidélités ou prototypes natifs, qui servent à implémenter une vraie partie prototypée pour voir si le système fonctionnera et se comportera comme prévu.

Selon le degré de fidélité, les prototypes exploratoires peuvent être un produit d’activités coûteux, de sorte qu’il y a toujours un compromis entre le coût et la valeur acquise.

Les modèles :

Le syllabus v.3 invite le lecteur à découvrir de nouveaux diagrammes (cf. en gras dans le schéma ci-dessous) pour modéliser les exigences.

Figure 4 – Les principales modèles utilisés dans l’IREB v.3

Les processus d’ingénierie des exigences : Nouveau

Le 5ème chapitre du nouveau syllabus IREB fondation est complètement nouveau, il concerne les ingénieurs des exigences qui veulent mettre en place un processus d’ingénierie des exigences afin d’expliquer comment les exigences doivent être élucider, documenter, valider et gérer au sein d’une organisation.

Afin d’aider à la configuration d’un processus, l’IREB a mis en place trois aspects décisifs à prendre en compte.

Facette temporelle : linéaire ou itératif ?

Est-ce que le processus du développement du système est planifié et linéaire ou itératif et agile ?

Est-ce que les parties prenantes connaissent leurs exigences et peuvent les spécifier dès le départ ou bien ces exigences apparaitront et évolueront au cours du développement du système ?

Facette de l’objectif : prescriptif ou exploratoire ?

Est-ce que la fonctionnalité et la portée ont la priorité sur le coût et les délais (prescriptif) ou le contraire (exploratoire) ?

Facette cible : spécifique au client ou orientée marché ?

Est-ce que le système est commandé par un client spécifique ou il est développé comme un produit ou un service pour un marché ?

On remarque que, contrairement à la version 2.2.1 du syllabus IREB qui était plus concentrée sur le cycle en V, ce nouveau syllabus dans sa troisième version se focalise sur une approche plus généraliste de l’ingénierie des exigences qui s’appliquera sur plusieurs projets et pour s’adapter aux nouvelles façons de produire les logiciels, donc il a pour but d’élargir le périmètre des projets qui vont pouvoir mettre en œuvre les méthodologies itératives ou linéaires.  

En guise de conclusion, cet article de blog met en avant, d’une façon synthétique, les principales nouveautés apportées par l’IREB pour qu’il répond aux attentes des utilisateurs tout en prenant en considération leurs retours d’information.