Première chose à faire, prioriser les exigences

Auteur : Karl E. Wiegers
Source : First Things First: Prioritizing Requirements (Process Impact)
Date : septembre 1999

---

Traducteur : Fabrice Aimetti
Merci à : Mike Cohn (The Problems with estimating Business Value, traduit en français)
Date : 04/07/2012

---

Traduction :

Les clients ne sont jamais heureux de découvrir qu'ils ne pourront pas obtenir toutes les fonctionnalités qu'ils désiraient dans la version 1.0 d'un nouveau produit logiciel (en tout cas, pas s'ils veulent que les fonctionnalités soient opérationnelles). Cependant, si l'équipe de développement ne peut pas livrer toutes les fonctionnalités d'ici la date de livraison initialement planifiée, les parties prenantes du projet doivent se mettre d'accord sur un sous-ensemble à implémenter en premier. Tout projet avec des ressources limitées doit établir les priorités relatives des fonctionnalités, cas d'utilisation, exigences nécessaires. La priorisation aide le chef de projet à résoudre les conflits, planifier des livraisons intermédiaires et négocier les compromis nécessaires.
Pourquoi prioriser les exigences ?
Une caractéristique d'exigences excellentes est qu'elles sont explicitement priorisées. Lorsque les attentes des clients sont grandes, que les délais sont courts et que les ressources sont limitées, vous voulez vous assurer que le produit contient les fonctionnalités les plus importantes. Établir l'importance relative de chacune des fonctionnalités vous permet d'ordonner la fabrication pour fournir la plus grande valeur du produit au moindre coût. Les clients et les développeurs doivent collaborer sur la priorisation des exigences. Les développeurs ne savent pas toujours quelles exigences sont les plus importantes pour les clients, et les clients ne peuvent pas juger du coût et de la difficulté technique associés à une exigence donnée.
Un chef de projet doit contrebalancer le périmètre du projet avec les contraintes de délai, de budget, de ressources pour les équipes et d'objectifs de qualité. Une stratégie possible est de laisser tomber ou de reporter les exigences de faible priorité à une version ultérieure lorsque vous acceptez de nouvelles exigences de plus haute priorité ou d'autres changements dans le projet. Si les clients n'arrivent pas à distinguer leurs exigences par ordre d'importance et d'urgence, le chef de projet doit alors trouver les compromis nécessaires. Puisque les clients ne seront peut-être pas d'accord avec les décisions prises par le chef de projet, ils devront indiquer quelles exigences sont critiques et celles qui peuvent attendre. Établissez les priorités très tôt dans le projet, lorsque vous avez le plus d'alternatives à disposition pour atteindre avec succès le résultat du projet.
C'est assez difficile d'obtenir de la part d'un client qu'il se décide à dire quelles exigences sont plus importantes que d'autres ; obtenir l'accord de plusieurs clients avec des attentes diverses est encore plus difficile. Les gens ont généralement des intérêts qui leur tiennent à coeur et ils ne sont pas toujours disposés à faire des compromis pour le bénéfice de quelqu'un d'autre. Pourtant, décider des priorités est une des responsabilités des clients dans la relation de partenariat client / développeur.
Au début, les clients priorisent les exigences en tenant uniquement compte de la valeur que chacune d'entre elles leur apportent. Une fois qu'un développeur met en avant le coût, le risque technique ou tout autre compromis lié à une exigence donnée, les clients peuvent éventuellement se dire que l'exigence n'est finalement pas aussi importante qu'ils le pensaient initialement. Les développeurs peuvent aussi déterminer que certaines exigences de faible priorité devraient être implémentées plus tôt en raison de leur impact sur l'architecture du produit. Lorsque vous définissez les priorités, vous devez comparer le bénéfice métier que chaque exigence apporte, par rapport à son coût et toutes les implications que celle-ci peut avoir sur l'évolution future de l'architecture socle du produit.
Le jeu difficile des priorités
Le réflexe qu'ont les clients lorsqu'on leur demande de prioriser : "J'ai besoin de toutes ces fonctionnalités, faites que ça passe". Ça n'aide pas beaucoup. Cela peut être difficile de persuader les clients de définir des priorités s'ils savent que vous n'allez jamais implémenter les exigences de priorité faible. Une fois, un développeur m'a dit que les priorités n'étaient pas nécessaires, parce que si nous écrivons quelque chose dans le document de spécifications fonctionnelles, c'est que nous avons bien l'intention de le fabriquer. Cependant, on n'aborde pas le problème qui consiste à savoir quand vous allez implémenter chaque fonctionnalité. Les développeurs ne souhaitent peut-être pas s'embêter avec les priorités, parce que cela rentre en conflit avec leur attitude habituelle "on peut tout faire" qu'ils adoptent face à leurs clients et leurs managers.
La réalité c'est que certaines fonctionnalités sont plus importantes que d'autres. Cela devient évident lors de la trop classique "étape rapide de réduction du périmètre" en fin de projet, lorsque les fonctionnalités de faible priorités sont sacrifiées pour assurer la livraison du produit à la bonne date. Définir des priorités tôt dans le projet vous aide à négocier ces compromis tout au long, plutôt qu'en toute urgence à la fin. Disposer d'une fonctionnalité déjà à moitié développée lorsque vous venez de déterminer que sa priorité est faible, c'est du gaspillage et de la frustration.
Si on les laisse faire, les clients diront que 85% des exigences sont de priorité haute, 10% de priorité moyenne et 5% de priorité faible. Ça n'aide pas beaucoup le chef de projet. Steve McConnell avait identifié une phase de nettoyage-élimination de ces exigences qui ne sont pas nécessaires et de simplification de celles qui sont inutilement compliquées, qui est devenue une bonne pratique du développement rapide d'applications (voir Rapid Development, Microsoft Press, 1996).
Sur un projet que je connais bien, le management, qui pilotait l'équipe, s'est impatienté lorsqu'un analyste a insisté sur la priorisation des exigences. Les managers ont souligné qu'ils pouvaient souvent se passer d'une fonctionnalité donnée, mais qu'il fallait du coup peut-être renforcer une autre fonctionnalité pour compenser celles qui avaient été négligées. Leur raisonnement était basé sur le fait que si l'on reportait trop d'exigences, le système obtenu ne générerait pas le chiffre d'affaires promis dans le business plan. Lorsque vous évaluez les priorités, jetez un coup d'oeil aux connexions et interdépendances entre les différentes exigences et leur alignement avec les besoins du métier.
Échelles de priorisation
Généralement, la priorisation consiste à regrouper les exigences en trois catégories. Le tableau 1 montre les trois niveaux associés à deux échelles de priorisation habituelles. Toutes les échelles de ce type sont subjectives et imprécises, si bien que les personnes impliquées doivent se mettre d'accord sur la signification de chaque niveau de l'échelle avant de l'utiliser. La priorité est un attribut-clé de chaque exigence, elle devrait être présente dans tout document de spécifications fonctionnelles ou base d'exigences. Établissez une règle de rédactions du document de spécifications fonctionnelles de telle façon que le lecteur sache si la priorité assignée à une exigence de plus haut niveau, est automatiquement héritée par ses exigences filles ou dérivées, ou alors si chaque exigence se voit individuellement attribuée sa propre priorité.
Une autre problématique concerne la granularité à laquelle vous prioriser les exigences. Même un projet de taille moyenne peut avoir des centaines ou des milliers d'exigences fonctionnelles détaillées, trop pour les analyser et les classer de façon cohérente. Vous devez choisir un niveau d'abstraction approprié pour la priorisation. Cela peut être au niveau du cas d'utilisation, de l'exigence fonctionnelle détaillée, ce qui paraît logique dans votre situation.
Tableau 1 : deux échelles de priorisation des exigences

Noms	Significations
Haute	exigence critique ; doit être présente dans la prochaine livraison
Moyenne	support des opérations nécessaires au système ; obligatoire mais peut éventuellement faire partie d'une livraison ultérieure
Faible	une amélioration fonctionnelle ou de la qualité ; ce serait bien de l'avoir un jour si les ressources le permettent
Essentiel	le produit ne peut-être accepté sans que ces exigences soient satisfaites
Conditionnel	améliorerait le produit, mais on peut accepter le produit sans ça
Optionnel	fonctionnalités dignes d'intérêt, ou pas

Conservez une priorisation qui soit la plus simple possible pour vous aider à faire les choix de développement nécessaires. Vous allez peut-être décider de prioriser au niveau de la fonctionnalité puis de prioriser séparément les exigences fonctionnelles au sein d'une fonctionnalité spécifique de haute priorité. Ce qui vous permettra de distinguer le coeur de la fonctionnalité qui doit être présent avant de travailler sur les perfectionnements que vous pourriez ajouter dans une version ultérieure. Intégrez aussi vos exigences de priorité faible dans votre document de spécifications fonctionnelles. Leur priorité pourrait changer dans le temps et les connaître à l'instant t peut vous aider à planifier de futures améliorations.
Priorisation basée sur la Valeur, le Coût et le Risque
Sur un petit projet, les parties prenantes peuvent sûrement se mettre d'accord sur les priorités de façon plus ou moins informelle. Mais des projets de plus grande taille ou plus controversés, nécessitent une approche plus structurée, qui supprime toute émotion, politique et conjecture sur l'activité de priorisation.
Des analystes de l'industrie ont proposé plusieurs techniques qui impliquent l'estimation de la valeur relative et du coût relatif de chaque exigence, de telle manière que les exigences de plus haute priorité fournissent la part maximale de la valeur totale du produit pour une part minimale des coûts. Dans le fond, vous essayez d'identifier ces exigences qui maximiseront la valeur du produit compte tenu des contraintes de coûts existantes. Estimer subjectivement le coût et la valeur en comparant deux à deux les exigences est impraticable lorsqu'on dépasse la vingtaine d'exigences.
Autre possibilité, le Déploiement des fonctionnalités de qualité (QFD), qui fournit une méthode globale robuste pour mettre en relation la valeur client et les fonctionnalités proposées dans le produit. Un troisième approche basée sur la Gestion de la Qualité Totale (TQM) évalue chaque exigence par rapport à plusieurs critères spécifiques et pondérés de succès du projet, et calcule un score pour classer la priorité des exigences. Cependant, d'après mon expérience, peu d'entreprises logicielles sont prêtes à assumer la rigueur des méthodes QFD et TQM.
Dans cet article, je décris une approche analytique semi-quantitative pour prioriser les exigences. A titre d'exemple, nous considérerons un produit baptisé Système de traçabilité des produits chimiques. Ce système permettra aux chercheurs scientifiques de commander des conteneurs de produits chimiques qui seront fournis par des magasins d'entreprises de produits chimiques ou par des fournisseurs dans le commerce de produits chimiques. Le système mémorisera l'emplacement de chaque conteneur de produits chimiques au sein de la société, la quantité restante du produit, et l'historique complet de l'emplacement et l'utilisation de ces conteneurs. Le Système de traçabilité des produits chimiques devra également se conformer à la réglementation de l'Etat qui exige des rapports trimestriels sur l'usage, le stockage et l'élimination des produits chimiques.
Le Tableau 2 illustre une simple feuille de calcul pour vous aider à estimer les priorités relatives d'un ensemble de fonctionnalités d'un produit comme le Système de traçabilité des produits chimiques. Vous pouvez télécharger cette feuille Excel sur la page http://www.processimpact.com/goodies.shtml. Cette approche répartit en continu un ensemble de priorités estimées plutôt que d'essayer de les regrouper au sein de quelques niveaux de priorité. Vous pouvez également appliquer ce modèle pour prioriser des cas d'utilisation ou des exigences fonctionnelles individuelles. Ce mécanisme de priorisation emprunte à la méthode QFD le concept de valeur client dépendant aussi bien du bénéfice client apporté par la présence dans le produit d'une fonctionnalité donnée que de la pénalité payée si celle-ci en est absente. L'attractivité d'une fonctionnalité est directement proportionnelle à la valeur qu'elle fournit et inversement proportionnelle à son coût et au risque technique liés à son implémentation. Toutes choses étant égales par ailleurs, ces fonctionnalités qui ont le plus haut ratio valeur/coût pondéré par le risque, devraient avoir une priorité haute. Bien sûr, ce ne sont pas les seuls facteurs qui influent sur la priorisation, donc n'utilisez pas ce mécanisme comme la seule méthode pour définir les priorités.
Appliquez juste ce mécanisme de priorisation aux fonctionnalités négociables, celles qui ne sont pas en top priorité. Par exemple, vous n’inclurez pas dans cette analyse des priorités les éléments qui implémentent les fonctionnalités coeurs du métier dans le produit, que vous considérez comme des différenciateurs clés du produit, ou qui sont obligatoires pour se conformer aux réglementations gouvernementales. Vous allez inclure ces fonctionnalités, quoiqu'il arrive.
Les participants classiques dans un processus de priorisation sont :

• le chef de projet, qui pilote le processus, arbitre les conflits et ajuste les contributions des autres participants si nécessaire
• les représentants-clés des clients, qui donne les ratios de bénéfice et de pénalité
• les représentants du développement, tels que des experts techniques de l'équipe, qui donne les ratios de coût et de risque.

Suivez les huit étapes suivantes pour utiliser le modèle de priorisation :
Etape 1 - Listez toutes les exigences, fonctionnalités, cas d'utilisation que vous souhaitez prioriser dans une feuille de calcul ; nous utiliserons ces fonctionnalités dans cet exemple. Tous les éléments doivent être au même niveau d'abstraction. Par exemple, ne mélangez pas exigences individuelles et fonctionnalités du produit. Si certaines fonctionnalités sont logiquement liées (c'est-à-dire que vous ne pourrez uniquement implémenter la fonctionnalité B que si la fonctionnalité A est aussi incluse), prenez uniquement en compte les fonctionnalités maîtresses dans l'analyse. Ce modèle fonctionnera avec plusieurs dizaines de fonctionnalités avant qu'il ne devienne difficile à manier. Si vous avez davantage d'éléments, augmentez le niveau d'abstraction des fonctionnalités liées pour créer une liste plus facile à gérer. Vous pourrez faire un second tour d'analyse avec une granularité plus fine des exigences si c'est nécessaire.
Etape 2 - Estimez le bénéfice relatif que chaque fonctionnalité apporte au client ou au métier sur une échelle de 1 à 9, 1 indiquant un faible bénéfice et 9 indiquant le bénéfice maximum. Les bénéfices indiquent un alignement avec les exigences du métier sur le produit. Vos représentants du client sont les meilleures personnes pour juger des bénéfices.

Etape 3 - Estimez la pénalité relative dont le client ou le métier auront à souffrir si la fonctionnalité n'est pas incluse. De la même manière, utiliser une échelle de 1 à 9, 1 indiquant aucune pénalité et 9 indiquant un inconvénient très grave. Par exemple, ne pas réussir à être conforme à une réglementation gouvernementale peut générer une grande pénalité même si le bénéfice du client est faible, comme ce serait d'ailleurs le cas pour une fonctionnalité omise que tout client raisonnable s'attendrait à avoir, qu'il l'ait ou non demandée explicitement. Les exigences qui ont à la fois un faible bénéfice et une faible pénalité génèrent un coût et peu de valeur. Ce sont des exemples en or plaqué.

Etape 4 - La colonne Valeur Totale est la somme du bénéfice relatif et de la pénalité relative. Par défaut, le bénéfice et la pénalité ont la même pondération. Si vous ressentez le besoin d'affiner, vous pouvez changer le poids de ces deux facteurs. Dans le Tableau 2, tous les bénéfices pèsent deux fois plus que les pénalités. La feuille de calcul totalise les valeurs des fonctionnalités et calcule la répartition de la valeur produit pour chacune des fonctionnalités.

Etape 5 - Estimez le coût relatif d’implémentation de chaque fonctionnalité, également sur une échelle de 1 à 9. La feuille de calcul établira la répartition des coûts pour chaque fonctionnalité. Les développeurs estiment les coûts en se basant sur des critères comme la complexité de l'exigence, l'effort d'implémentation de l''interface utilisateur, la capacité potentielle à réutiliser une conception ou du code existant, le niveau de tests et de documentation nécessaires.

Etape 6 - Les développeurs estiment le degré relatif de risque technique ou autre associé à chaque fonctionnalité sur une échelle de 1 à 9. Une échelle de 1 indique que vous pouvez programmer en dormant, alors que 9 indique un sérieux doute sur la faisabilité, la disponibilité des personnes avec la bonne expertise, ou l'utilisation d'outils et de technologies qui ne leur sont pas familières ou qui restent à prouver. La feuille de calcul calculera la répartition du risque sur chacune des fonctionnalités.
Par défaut, le coût et le risque ont la même pondération et chacun porte le même poids en termes de bénéfice et de pénalité. Vous pouvez ajuster les poids du coût et du risque dans la feuille de calcul. Dans le Tableau 2, le risque pèse moitié moins que le coût, qui lui-même a le même poids que la pénalité. Si vous ne souhaitez pas prendre en considération le risque dans le modèle, il vous suffit de pondérer le risque à zéro.
Etape 7 - Une fois que vous avez saisi les valeurs dans la feuille de calcul, une priorité numérique est calculée pour chaque fonctionnalité. La formule pour la colonne Priorité est la suivante : Priorité = Valeur % / (Coût % * Poids Coût + Risque % * Poids Risque).
Etape 8 - Triez la liste des fonctionnalités par ordre descendant de la priorité calculée. Les fonctionnalités qui figurent en haut de la liste ont le rapport valeur / coût / risque le plus favorable et devraient donc avoir la priorité d'implémentation la plus haute. Les représentants-clés des clients et des développeurs doivent examiner la feuille de calcul complète et se mettre d'accord sur les répartitions et sur le résultat.
Cette méthode semi-quantitative n'est pas mathématiquement rigoureuse, et est limitée par votre capacité à évaluer le bénéfice, la pénalité, le coût et le risque de chaque élément. Par conséquent, n'utilisez ce mécanisme de calcul de la priorité que pour vous aider. Cela vous prendra un certain temps avant de calibrer correctement vos échelles de notation pour un groupe de fonctionnalités donné, donc itérez sur la liste après avoir noté chaque fonctionnalité et faites tous les ajustements nécessaires. calibrez ce modèle pour votre usage personnel avec un ensemble complet d'exigences ou de fonctionnalités d'un ancien produit. Ajustez les pondérations jusqu'à ce que les priorités calculées correspondent à votre évaluation après-coup de l’importance réelle des exigences issues de votre jeu de tests.
Ce modèle peut également vous aider à négocier des compromis lorsque vous évaluez de nouvelles exigences proposées. Estimez leurs priorités en utilisant le modèle pour vous dire comment elles se classent par rapport aux exigences existantes, ce qui vous aidera à choisir un ordre d'implémentation approprié. Toutes les actions que vous pourrez prendre pour déplacer la priorisation des exigences de la scène politique vers un cadre objectif et analytique améliorera la capacité du projet à livrer les fonctionnalités les plus importantes dans l'ordre le plus approprié.

Tableau 2 : échantillon d'une matrice de priorisation pour un Système de traçabilité des produits chimiques

Poids relatifs :	2	1			1		0,5
Fonctionnalité	Bénéfice Relatif	Pénalité Relative	Valeur Totale	Valeur %	Coût Relatif	Coût %	Risque Relatif	Risque %	Priorité
1. Interroger l'état d'une commande fournisseur	5	3	13	8,4	2	4,8	1	3,0	1,345
2. Générer un rapport d'inventaire du magasin de produits chimiques	9	7	25	16,2	5	11,9	3	9,1	0,987
3. Consulter l'historique d'un conteneur chimique spécifique	5	5	15	9,7	3	7,1	2	6,1	0,957
4. Imprimer un rapport sur la sécurité des produits chimiques	2	1	5	3,2	1	2,4	1	3,0	0,833
5. Maintenir une liste des produits chimiques dangereux	4	9	17	11,0	4	9,5	4	12,1	0,708
6. Modifier une commande de produits chimiques en attente	4	3	11	7,1	3	7,1	2	6,1	0,702
7. Générer un rapport d'inventaire par laboratoire	6	2	14	9,1	4	9,5	3	9,1	0,646
8. Rechercher un produit chimique dans les catalogues fournisseurs	9	8	26	16,9	7	16,7	8	24,2	0,586
9. Vérifier la base de formation pour une formation sur les produits chimiques dangereux	3	4	10	6,5	4	9,5	2	6,1	0,517
10. Importer les structures chimiques à partir des outils associés	7	4	18	11,7	9	21,4	7	21,2	0,365
Totaux	54	46	154	100	42	100	33	100	--

Cet article a été initialement publié dans la revue Software Development en septembre 1999. Il a été modifié et à nouveau publié avec la permission du magazine Software Development.