Lorsque l’IEEE s’est intéressée à l’ingénierie des exigences, elle a publié la définition suivante dans son standard IEEE Std 610.12.-1990: «Une exigence est : (1) Une condition ou une aptitude nécessaire à un utilisateur pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une aptitude qui doit être remplie ou possédée par un système ou un composant du système pour respecter un contrat, une norme ou d’autres documents formellement imposées.(3) Une représentation documentée de cette condition ou de cette aptitude telle que définie dans (1) ou (2).
RUP et les autres approches de développement de logiciels utilisent cette définition.
l’IIBA dans le BABOK 2,0 prend un court-circuit et élargit le périmètre de la définition de l’IEEE grâce au mot partie-prenante : « une exigence est (1) Une condition ou une aptitude nécessaire à une partie prenante pour résoudre un problème ou atteindre un objectif. (2) Une condition ou une aptitude qui doit être remplie ou possédée par un système ou un composant du système pour respecter un contrat, une norme ou d’autres documents formellement imposées. (3) Une représentation documentée de cette condition ou de cette aptitude telle que définie dans (1) ou (2).
(1) concerne les exigences organisationnelles et métier tandis que (2) concerne les exigences de solution.
Pour le BABOK 2.0 (1) est découpé entre exigences d’entreprises classifient les objectifs globaux d’une organisation et les exigences des parties prenantes qui classifient les besoins des intervenants en particulier. (2) concerne les exigences fonctionnelles et non fonctionnelles.
Il est étonnant de voir comment l’IIBA a ignoré les initiatives d’Architecture d’Entreprise qui visent à renouveler la gestion des exigences au sein du cycle de vie de la transformation de l’entreprise.
Malgré tout, les exigences continuent à être collectées au travers des modèles que nous connaissons depuis les temps immémoriaux: IDEF0 , SADT , UML , BPMN , … avec quelques améliorations sur les exigences non fonctionnelles.
Alors qu’il y -t-il à la table de jeu?
BABOK 2,0 décrit en détail le processus de gestion des exigences, l’Architecture d’Entreprise décrit le cycle de vie des exigences et la gestion des modèles au sein de la transformation de l’entreprise, BISL guide l’organisation pour gérer les exigences du point de vue du métier.
La gestion des exigences est aujourd’hui un enjeu important pour rendre les entreprises agiles, car, au fur et à mesure qu’elles se transforment, leurs exigences changent encore plus vite. C’est pourquoi elles ont besoin de savoir gérer ces changements pour réussir.
Je me demande qui va commencer à travailler sur une vision intégrée, non seulement pour spécifier un nouveau cadre de travail, mais pour alimenter des outils logiciels qui soutiennent le cycle de vie complet des exigences d’entreprise afin de faire émerger une véritable transformation d’entreprise conduite par les modèles.
En effet, les logiciels de gestion d’exigences d’entreprises sont mal intégrés aux logiciels de conception. Cela ne contribue pas à combler le fossé entre architecture d’entreprise et architecture pour régir les programmes et les projets de grande envergure.
Un autre point devant être couvert par les logiciels, est de savoir créer et maintenir les liens entre cibles, existant, écarts, et construire des feuilles de route et des projets, autorisant de multiples scénarios métier et gérant les versions.
Ces 2 points contribueraient grandement à améliorer l’agilité des entreprises et leur capacité à se transformer. Ainsi, quel éditeur de logiciels va se décider à les prendre en compte et à les inscrire sur sa feuille de route ?
Bonjour,
En tant que Vice-président d’IIBA-France, je vous félicite de votre lecture attentive du Babok (Business Analysis Book of Knowledge). Néanmoins, je n’en tire pas les mêmes interprétations que vous, et nos conclusions divergent totalement.
Si je suis d’accord avec vous que « la gestion des exigences est un enjeu important », votre conclusion selon laquelle il faudrait attendre qu’un éditeur se décide à réaliser un logiciel intégré me semble un peu « technocratique » et me choque profondément.
Au sein d’IIBA, nous sommes convaincus qu’une meilleure gestion des exigences est une urgence et qu’elle passe d’abord par la compétence des acteurs et des organisations. Il s’agit d’un sujet de management de l’entreprise, avant d’être celui d’un éditeur de logiciel de modélisation.
Pendant la phase d’élicitation des exigences, il semble préférable de parler de « parties prenantes » car l’appellation « utilisateurs » procède déjà d’un choix de conception du système : on n’est « utilisateur » que d’une solution !
Cela permet aussi au Business Analyst d’intégrer d’autres types d’exigences, comme celles des Architectes d’Entreprise qui vous préoccupent particulièrement. Savoir relier un projet aux autres composantes de l’entreprise et à leurs objectifs stratégiques de création de valeur est une des missions du Business Analyst.
Ne soyez pas étonné qu’IIBA ne travaille pas activement sur ce sujet : nous n’ignorons aucune initiative liée à notre périmètre d’intérêt. Mais comme ce dernier est vaste, vous comprendrez qu’il y a des priorités. Nous travaillons par exemple actuellement avec d’autres associations françaises à la clarification des rôles et fonctions des acteurs qui interviennent dans les domaines de l’organisation et des SI.
Toutefois, le premier groupe de travail créé au sein d’IIBA-France a été consacré à l’Architecture d’Entreprise. Il se réunit régulièrement à Paris depuis maintenant plus de 6 mois.
Salutations,
Alain Guercio, Vice-président d’IIBA-France
Bonjour,
Je vous remercie de l’attention que vous avez porté à mon billet un peu bref pour un sujet si important.
Si vous avez compris que le premier facteur de succès pour l’élicitation des exigences n’est pas la compétence des analystes métier ou celle des Architectes, c’est que je me suis mal exprimé. C’est un élément essentiel qui, de ce point de vue, reste à parfaire par la formation, le coaching, la formalisation des bonnes pratiques, telle que vous la faites pour le bien de la communauté.
Le cadre d’exigences, lorsqu’il est bien construit est fait pour durer : s’étoffer, évoluer, se transformer. Les entreprises, outre le contrôle et la cohérence d’activités de plus en plus complexes, doivent aussi rechercher l’agilité, Ce qui peut être contraire au premier objectif.
L’outillage sur la base de méthodes éprouvées et maîtrisées par des praticiens compétents peut permettre d’automatiser le contrôle et la gestion de la cohérence, et accroître en même temps l’agilité.
Le dernières roadmaps des éditeurs semblent aller dans ce sens. Cependant, je crois qu’il y a matière à progrès pour ce qui est de l’Architecture métier.
Bien cordialement
Jérôme Capirossi