Un peu de théorie…

Vue générale du processus

Le processus de recueil des besoins se décompose en sept sous-processus, eux-mêmes découpés en activités. Ces sept sous-processus sont : l’élicitation et la capture, la modélisation et la spécification, la priorisation, la gestion des dépendances, l’évaluation de l’impact, la phase de négociation et enfin l’assurance qualité.

L’élicitation et la capture : cette phase va permettre de chercher le plus de besoins. Il sera nécessaire dans un premier temps de permettre à toutes les parties prenantes et toutes les sources d’émettre des envies. L’analyste s’évertuera à capturer le plus fidèlement possible les besoins.

La modélisation : durant cette phase, on articulera les différents "morceaux" du besoin (chunk en anglais) afin d’obtenir un ensemble cohérent. Pour cela, on utilisera souvent des modèles de données. Cela peut facilement être réalisé avec des arbres de buts.

Ensuite, durant la phase de spécification, on s’assurera que les besoins sont spécifiés. Ils doivent être assez précis pour être implémentés et actionnables. Il faut alors s’assurer de minimiser les ambiguïtés linguistiques....

Élicitation et capture

Cette première étape consiste à formuler la "liste du père Noël". En anglais, on parle de chalutage : c’est une pratique qui consiste à ratisser le fond de la mer et à tout ramasser : coraux, poissons sans distinction d’espèces…

On listera ici toutes les envies des parties prenantes, peu importe si elles seront satisfaites ou non. C’est donc l’étape des hyperboles et des solutions rêvées.

Pourquoi cette étape est-elle importante ? Il s’agit de bien écouter vos parties prenantes. Même si les besoins listés ne figurent pas tous dans le scope final, cela donnera une idée des attentes initiales des utilisateurs, des déceptions qu’il faudra gérer. Cette phase peut aussi être une phase très importante pour comprendre les besoins stratégiques en plus des besoins inclus dans le scope. Vous pourrez alors avoir une petite idée des prochaines phases du projet.

Le processus d’élicitation et de capture se décompose en cinq activités : comprendre le domaine d’application, identifier les sources, analyser les parties prenantes, sélectionner les techniques et les outils, éliciter le besoin à partir des parties prenantes et des autres sources.

Process d’élicitation

Modélisation

Ensuite viennent les phases de modélisation et de spécification des besoins.

La modélisation va permettra de formaliser le besoin à un niveau conceptuel. Cela peut être grâce à un ou plusieurs modèles. Le ou les modèles permettront alors d’articuler les différents besoins dans une visualisation permettant de conceptualiser le système ou les systèmes à créer ou modifier.

La phase de spécification permettra de rendre le modèle tangible. Il s’agit d’adopter un langage uniforme qui minimisera les ambiguïtés garantissant son implémentation.

Il existe de nombreuses formes de modélisations. Tout dépend de ce que vous avez besoin de modéliser. Vous choisirez des représentations différentes si vous souhaitez représenter un processus, un modèle de données ou une interface utilisateur. La liste ci-dessous est non exhaustive, mais regroupe les principales modélisations qui pourront vous être utiles.

Spécification

Une fois que la ou les techniques de modélisation sont choisies, il faut maintenant modéliser le système. Quel que soit le modèle, il faudra alors faire attention au langage utilisé, à la gestion de la complexité et à la gestion de la continuité.

Priorisation

La priorisation est une phase importante, elle va permettre de déterminer ce qui sera dans le scope du projet et les exigences qui ne seront pas satisfaites. On va maintenant effectuer les arbitrages entre les désirs des parties prenantes et les contraintes (besoins non fonctionnels, temps, budget…). C’est dans cette phase que l’on tentera de maximiser la satisfaction des parties prenantes tout en minimisant le travail redondant. Il faudra également gérer les besoins contradictoires et surtout garder la motivation de toutes les parties prenantes aussi bien techniques que fonctionnelles. Autant dire que c’est la phase la plus politique du processus de recueil des besoins. La phase de priorisation peut être vue comme la sélection du "bon" besoin parmi un ensemble de candidats, celui qui remplira à la fois les intérêts de parties prenantes, les contraintes techniques et les préférences des utilisateurs tout en maximisant la valeur du produit et pour le business. Un vaste programme !

Il existe de nombreuses techniques pour approcher cette phase. Elles peuvent être quantitatives ou/et qualitatives (la négociation). Il s’agit dans tous les cas de ne pas se contenter de demander à toutes les parties prenantes "Quels sont les besoins les plus importants de votre point de vue ?". Même si les parties prenantes devraient théoriquement défendre leur point de vue dans l’intérêt de l’organisation et en fonction de leur rôle. La réalité veut qu’elles soient également des personnes avec des personnalités et souvent des objectifs personnels. De plus, dans un environnement changeant rapidement, vos parties prenantes auront tendance à privilégier le court terme au détriment des bénéfices à long terme.

Ignorer cette phase est le plus souvent une erreur stratégique. Si elle est facile, cela ne prendra guère de temps. Si elle est longue, vous augmenterez drastiquement les risques d’échec de votre projet en l’oubliant.

Une priorité peut être attribée en fonction de plusieurs critères : l’importance, l’opportunité pour les utilisateurs, les pénalités, les coûts, le temps d’implémentation...

Traçabilité et dépendances

La gestion de la traçabilité et des dépendances est importante pour plusieurs raisons.

Lors d’un changement dans les exigences du projet, une mauvaise gestion des dépendances entraînera une diminution de la qualité de la solution, causera des révisions, augmentera le coût du projet et ses délais de livraison. Cela augmentera aussi la méconnaissance du système dans son intégralité et mettra en péril son intégrité. Nous appellerons cette partie la traçabilité du besoin.

Dans la gestion du scope, il est important de ne pas exclure des exigences qui ont des dépendances incluses dans le scope. Par exemple, il ne faudra pas exclure l’alimentation de l’entrepôt de données et inclure la visualisation de ces mêmes données. Nous appellerons cette partie les dépendances du besoin.

C’est souvent après une mauvaise gestion des dépendances qu’on entend : "ce système est une usine à gaz".

Évaluation de l’impact

Il existe de nombreuses méthodes pour évaluer l’impact. Plus ou moins précises en fonction de l’information nécessaire et de la technique utilisée. L’enjeu est ici que cette analyse ne soit pas trop coûteuse et que l’implémentation soit estimée de façon acceptable.

Négociations (définition du scope)

La phase de négociation des besoins est toujours une phase critique, mais encore plus dans un projet décisionnel. L’étape de négociation est en général une phase de discussions. Elle sera facilitée par l’utilisation des techniques de gestion de conflits traditionnelles, mais c’est également un domaine qui touche de nombreux sujets : les sciences sociales, la théorie du jeu, celle du management, la théorie de la prise de décision, la psychologie… Ce chapitre ne couvrira que superficiellement ce domaine. En effet, il existe une littérature exhaustive concernant les techniques de négociation, mais cela est hors du champ de ce livre.

C’est un processus en trois étapes : la prénégociation, la négociation et la postnégociation.

Assurance qualité

Traditionnellement, on ne parle de l’assurance qualité que dans la phase d’implémentation du projet. Nous ne considérerons pas ici l’assurance qualité des développements (scripts, installations des plateformes…), autrement dit "les tests", mais l’assurance qualité des besoins. Il est très rare de faire de l’assurance qualité sur les exigences, mais finalement c’est un peu comme faire une mise en production d’un code qui n’aurait même pas été compilé.

Des études montrent qu’une correction de bug durant la phase d’implémentation est cent fois plus coûteuse que le même bug corrigé durant la phase d’élicitation des besoins. Les déficiences dans le recueil des besoins sont la principale source d’échec des projets : 40 % des problèmes des développements de logiciels sont imputables à une mauvaise ou insuffisante qualité du recueil des besoins.

Les problèmes d’élicitation des besoins peuvent avoir des impacts très divers qui peuvent être des problèmes d’architecture, de design, de code de test ou de même de maintenance (cf. Importance du recueil des besoins - Du côté de la recherche de l’ingénierie des besoins).