Expression des besoins

2 Comments

Quelques rapides éléments de réflexion sur ce thème.

Style des spécifications fonctionnelles

Aujourd’hui coexistent deux grands types d’expression de besoin :

  1. classique, essentiellement spécifications textuelles en langage naturel, éventuellement « rigidifiée » par des structures de tableaux ou de renvois (si possible appareils de lecture automatiques) ;
  2. avancé, avec tentative de formalisation pour assurer une meilleure qualité de spécification (réduction du volume, élimination des ambiguïtés, preuve de couverture…).

Ce deuxième style tire profit de la notation UML. Dans ce cas, la spécification se centre sur la notion de cas d’utilisation, qui reste marquée par l’approche fonctionnelle.
Certains dossiers d’expression de besoins se situent à cheval entre ces deux styles : ils adoptent une partie du vocabulaire UML (use-case) mais délaissent la notation et trahissent l’inspiration.

Les pratiques avancées structurent les dossiers d’expression de besoin, du moins la partie « fonctionnelle », en termes de cas d’utilisation, détaillés en scénarios et structurés par un vrai diagramme des cas d’utilisation.

Posture

Ce dernier point soulève une difficulté : dès que l’on introduit une technique de modélisation (ici, le seul diagramme des cas d’utilisation) pour relayer ou structurer l’expression textuelle, le rédacteur se trouve mis en demeure d’opter pour une des postures d’analyse ou de conception.

Traditionnellement, l’expression de besoins ressortit à l’analyse, uniquement : le rédacteur a pour tâche de décrire une réalité ainsi que des attentes. Mais, s’il se met en tête d’utiliser son outil de modélisation pour bien structurer son dossier, il commence à changer la structure du problème posé, en vue d’évacuer la redondance, d’augmenter l’agilité, etc. Ce travail l’amène à entrer dans la conception et donc, à s’écarter de la fidélité aux acteurs « métier ».
Cette frontière est déjà franchie quand on introduit, dans le dossier, des maquettes d’écrans – fussent-elles serviles et collées à l’existant.

Cette hésitation entre analyse et conception doit faire l’objet de toutes les attentions car la posture adoptée détermine le rôle du livrable dans la chaîne de transformation.

Place dans la chaîne de transformation

Ainsi, on ne peut pas élaborer le procédé d’expression des besoins en faisant abstraction de la chaîne de transformation dans laquelle il s’insère.
Le template même de Business Requirement dépend de ce qui se passe en amont et en aval.
Par exemple, un dossier peut mentionner les données (ce qui est un peu réducteur, soit dit au passage). Si la rédaction des exigences est précédée d’un effort de modélisation des objets « métier » (objets auxquels sont reportés les règles de gestion, les cycles de vie, etc.), le contenu du dossier de spécification s’en trouvera allégé.
De même, si le dossier est clairement perçu comme une expression d’analyse, le diagramme des cas d’utilisation qui s’y trouve sera considéré comme tel, ni plus ni moins. On prendra soin de ne pas considérer ce diagramme comme la structure de la solution. Il faudra, avant la réalisation, prévoir l’effort de conception, lequel produira un nouveau dossier des cas d’utilisation. Dans ce dossier de conception, on verra apparaître sur le diagramme des cas d’utilisation les relations qui permettront une bien meilleure structure.

Pour y voir clair dans la définition des livrables, le mieux est de croiser les deux critères :

  1. Visibilité : externe (ce qui est perçu par les « utilisateurs » du système) versus interne (la solution, derrière la vitrine) ;
  2. Posture : analyse (description du réel, sans intervention ; le rédacteur est à l’écoute des acteurs du système et en retranscrit les pratiques et les attentes) versus conception (imagination, invention d’une solution, y compris sur les aspects « métier »).

This entry is filed under méthodologie. And tagged with , , , , , , , , , , . You can follow any responses to this entry through RSS 2.0. You can skip to the end and leave a response. Pinging is currently not allowed.

2 Responses to “Expression des besoins”


  1. Fabien Villard

    Tres interessante distinction entre les postures.
    Comment situer les methodes de dev “agiles” (qui se targuent de gerer a la fois l’analyse
    et la conception) ? On pourrait imaginer que chaque iteration comporte les deux activites
    enchainees mais separees ?
    Fab.

  2. DVAU

    Pour en savoir plus sur la “posture”, voir par exemple le Livre blanc : http://www.praxeme.org/DocumentsGeneraux/Praxime-LivreBlanc_v2.SLB02.pdf (version française) ou http://www.praxeme.org/DocumentsEnAnglais/SLB02-wp_EN.pdf (version anglaise).
    La distinction des deux moments est un vrai problème dans le développement agile.
    Plus largement, je pense qu’il faut revenir sur cette distinction qui paraît un peu trop évidente. Pour réactiver la réflexion, disons-nous, par exemple, que nous ne pouvons pas nous contenter d’écouter les représentants du métier. D’abord, ils n’ont pas toujours la connaissance exacte et complète du métier ; ils n’en ont souvent qu’une vue tronquée, coupée des orientations stratégiques et biaisée par les intérêts locaux. Ensuite, une fidélité servile à l’expression des besoins conduit à stériliser l’imagination et évacue toute possibilité d’innovation.
    La méthode doit donc encourager un nouvel équilibre, une véritable dialectique entre écoute et proposition, entre analyse et conception.
    Il va de soi que la conception dont il s’agit ici ne se réduit pas à la conception du logiciel (ou des interfaces homme-machine). Les postures d’analyse et conception se transportent sur tous les aspects du Système Entreprise, à commencer par le métier.
    A une époque où les dirigeants d’entreprise insistent sur la nécessité d’innover, il est temps de réactiver les puissances de l’imagination. Pourtant, les mêmes – les dirigeants – adoptent des comportements qui vont exactement à l’encontre de la capacité d’innovation, obnubilés qu’ils sont par l’évitement des risques et encerclés par les coteries.

You must login to post a comment.