Editions ENI Livres | Vidéos | e-Formations
Limitations
Introduction
Les limitations du processus de recueils sont nombreuses. Vous avez maintenant pleinement conscience que les notions parcourues dans les différents chapitres ne vous permettront pas d’avoir une et une seule manière d’approcher cette étape et de garantir votre succès. Ici, pas de check-list menant au succès.
La complexité du recueil des besoins en fait une étape très intéressante et riche. Elle est à la fois créative et pleine d’apprentissages. Il vous faudra naviguer entre les différents écueils et limitations afin de mettre tout le monde d’accord sur la solution à livrer. Voici les principaux facteurs limitant la portée ou l’exactitude du recueil des besoins.
Les limitations sociales
La formation des parties prenantes est cruciale pour le succès. L’analyste doit être formé, mais aussi motivé. Il est important d’être conscient que le diable se cache dans les détails, mais qu’il faut être réaliste sur l’effort à fournir et la précision nécessaire.
La formation des parties prenantes fonctionnelles
Elles doivent être pleinement conscientes de l’intérêt du recueil des besoins pour que leur participation soit fructueuse. Il y a deux extrêmes à éviter. D’un côté, vos utilisateurs vous font confiance et les équipes pensent pouvoir se mettre à la place de l’utilisateur, provoquant un effet tunnel dont l’issue peut être très décevante. De l’autre, des parties prenantes très/trop impliquées. Elles auront tendance à surqualifié le besoin, voir à qualifier le besoin technique. Les équipes techniques n’auront alors plus la latitude pour être force de proposition et supporter pleinement le business.
La formation des équipes techniques
Il arrive que des erreurs soient commises car les équipes techniques sont peu formées aux nouvelles plateformes. Il en résulte des problèmes d’architecture, de développement, de qualité des données....
Les limitations techniques et fonctionnelles
Le coût et le temps
Il arrive que, par manque de temps et/ou de budget, l’étape de recueil des besoins soit sacrifiée. C’est notamment le cas lors de projets avec de forts enjeux où les parties prenantes veulent tout de suite "faire" quelque chose pour être rassurées. L’étape de recueil des besoins peut être alors perçue comme non productive.
Les domaines fonctionnels et techniques peuvent être sujets à d’importants changements. Ainsi, il sera difficile de les documenter ; il arrive aussi que les informations soient manquantes (par exemple : anticipation sur de nouvelles législations).
La définition d’un besoin suffisamment décrit peut se montrer très différente en fonction des points de vue. Les acteurs fonctionnels auront souvent tendance à décrire grossièrement alors que les développeurs préféreront des exigences très détaillées. Il faudra alors trouver le bon compromis entre un besoin décrit sur un coin de table et une documentation permettant d’automatiser complètement les développements. La qualité attendue dépendra également du domaine fonctionnel et du type des gains souhaités dans le domaine. Des prévisions de ventes d’une petite...