Instructions: Plan de gestion des exigences
Un plan de gestion des exigences définit principalement les relations des parties prenantes et leurs responsabilités, les éléments de traçabilité, la gestion de modification des exigences et les mesures et rapports liés aux exigences. Ces instructions vous assistent dans le développement d'un plan de gestion des exigences complet et efficace.
Relations
Description principale

Relation à d'autres plans

Le plan des gestion des exigences contient des informations qui peuvent être couvertes à des niveaux divers par d'autres plans.

Voir Produit : Plan de gestion des exigences, personnalisation pour plus d'informations.

Organisation, responsabilités et interfaces

Comme décrit dans le Livre blanc : Application de la gestion des exigences dans les cas d'utilisation, la gestion des exigences est un des facteurs clés du succès d'un projet. Les causes d'échec d'un projet les plus fréquentes sont :

  • Absence de participation de l'utilisateur
  • Exigences incomplètes
  • Changement des exigences

Les erreurs concernant les exigences sont aussi la catégorie la plus répandue et la plus onéreuse à corriger.

Des relations adéquates avec les parties prenantes peuvent aider à prévenir ces problèmes.  Les parties prenantes sont une source d'information clé pour la définition des exigences et la détermination de leurs priorités.  Cependant, ils ne perçoivent pas toujours l'impact des fonctionnalités demandées sur les coûts et le calendrier et l'organisation chargée du développement doit, par conséquent, gérer leurs attentes.

La mise en place de relations avec les parties prenantes nécessite aussi de définir :

  • Les responsabilités des parties prenantes ; le personnel sera-t-il disponible sur site pour consultation ? A des périodes convenues d'avance ?
  • La visibilité des produits du projet par les parties prenantes : tous les produits doivent-ils leur être ouverts ? Seulement à des jalons du calendrier ?

Identification des éléments de traçabilité

Décrivez les éléments de traçabilité et définissez comment les nommer, les marquer et les numéroter. Voir Concept : types d'exigences et Concept : Traçabilité.

Les éléments de traçabilité les plus importants sont repris dans Tâche : développer un plan de gestion des exigences.

Spécification de la traçabilité

Une traçabilité type, portant sur un nombre restreint d'artefacts essentiels, est décrite dans la section Tâche : développer un plan de gestion des exigences.

Outre l'identification des liens de traçabilité, vous devez spécifier leur cardinalité. Parmi les contraintes courantes, on peut noter les suivantes :

  • Chaque fonctionnalité produit approuvée doit être liée à une ou plusieurs exigences supplémentaires, ou à un ou plusieurs cas d'utilisation, ou aux deux.
  • Chaque exigence supplémentaire et chaque section de cas d'utilisation doit être liée à un ou plusieurs cas d'utilisation.

Une discussion plus approfondie de la traçabilité est fournie dans le livre blanc Stratégies de traçabilité pour la gestion des exigences avec les cas d'utilisation.

Exemples d'attributs

Vous pouvez opérer une sélection d'après les exemples d'attributs ci-dessous, organisés à l'aide des types d'exigences identifiés dans Tâche : développer un plan de gestion des exigences.

Demandes des parties prenantes

Source : La partie prenante à l'origine de l'exigence (peut aussi être implémentée en tant que traçabilité d'un élément Partie prenante).

Contribution : Indique la contribution du problème soulevé à l'occasion d'affaires ou au problème global abordés dans le projet. Pourcentage (0 à 100%). La somme de toutes les contributions ne doit pas dépasser 100%. L'exemple de diagramme de Pareto illustre la contribution de divers besoins d'intervenants.

Graphique présentant l'incidence relative de 5 problèmes sur les opportunités commerciales globales

Fonctionnalités, exigences supplémentaires et cas d'utilisation

Statut : indique si l'exigence a été examinée et acceptée par la "voie officielle". Exemples de valeurs possibles : Proposée, Rejetée, Approuvée.

Ce statut peut être contractuel ou défini par un groupe de travail habilité à prendre des décisions exécutoires.

Avantage : Importance du point de vue des intervenants.

  • Critique (ou primaire). En rapport avec les tâches principales du système, sa fonction de base, les fonctions pour lesquelles il est développé. Si elles sont absentes, le système ne remplit pas sa vocation première. Dirigent l'architecture du système et tendent à représenter les cas d'utilisation les plus fréquents.
  • Important (ou secondaire). Concernent le support des fonctions du système, comme la compilation de données statistiques, la génération d'états, la supervision du système et ses tests fonctionnels. En leur absence, le système peut continuer à remplir (temporairement) sa mission fondamentale mais avec une dégradation de la qualité du service. Lors de la modélisation, moins d'importance leur est consacrée qu'aux cas d'utilisation critiques
  • Utile (bon à avoir). Il s'agit ici de caractéristiques de convivialité qui ne sont pas liées à la mission principale du système mais facilitent son utilisation ou son positionnement marketing.

Effort: Efforts évalués en jours pour implémenter l'exigence.

Par exemple, regroupement en catégories comme Léger, Moyen et Lourd où E.g. Léger = <1 journée, Moyen = 1-20 jours, Lourd = >20 jours.

Lors de la définition de l'effort, les coûts généraux associés(gestion, tests, exigences) inclus dans l'estimation doivent être clairement mentionnés.

Taille : Estimation du nombre de lignes de code source (hors commentaires), à l'exclusion du code de test.

Pour mieux évaluer ces coûts, vous pouvez distinguer entre lignes de code nouvelles et lignes de code réutilisés.

Risque : pourcentage de probabilité que l'implémentation de l'exigence s'accompagne de phénomènes indésirables significatifs, comme débordement du calendrier, inflation des coûts ou annulation.

Par exemple, regroupement en catégories comme Faible, Moyen et Fort où Faible = <10%, Moyen = 10-50%, Fort = >50%.

Une autre option consiste à isoler le risque technologique - pourcentage de probabilité de difficultés sérieuses à implémenter l'exigence en raison d'un manque d'expérience dans le domaine et/ou des technologies requises.  Le risque global peut ensuite être calculé comme une somme pondérée en fonction d'autres attributs, dont la taille, l'effort, la stabilité, le risque technologique, l'impact sur l'architecture et la complexité organisationnelle.

Complexité organisationnelle : catégorisation de la maîtrise de l'organisation chargée du développement de l'exigence.

  • Interne : développement interne sur un seul site
  • Géographique : équipe dispersée géographiquement
  • Externe : Organisme externe au sein de l'entreprise.  
  • Fournisseur : sous-traitance ou acquisition d'un logiciel développé à l'extérieur.

Impact sur l'architecture : Indique l'impact de cette exigence sur l'architecture logicielle.

  • Aucun : n'affecte pas l'architecture existante.
  • Extension : requiert une extension de l'architecture existante.
  • Modification : L'architecture existante doit être modifiée pour se conformer à cette exigence.  

Stabilité : Probabilité que cette exigence ait à être modifiée ou que l'interprétation de cette exigence par l'équipe de développement évolue : (>50% = Elevée, 10..50% = Moyenne, <10% = Faible)

Version cible : Version cible du produit pour intégration de l'exigence (Version 1, Version 1.1, Version 2, ...)

Danger / Niveau de criticité : possibilité d'effets sur la santé, le bien-être ou conséquences économiques, généralement en raison du logiciel n'opérant pas comme requis.

  • Négligeable : Ne peut pas entraîner de blessures graves ou des dommages significatifs aux équipements.
  • Marginal: Peut être maîtrisé sans blessures du personnel ou dommages majeurs au système.
  • Critique : Peut causer des blessures au personnel ou des dommages majeurs au système, ou nécessitera une action corrective immédiate pour assurer la survie du personnel ou du système.
  • Catastrophique : Peut causer des blessures graves, voire fatales, ou la perte totale du système.

Les dangers peuvent aussi être identifiés sous forme de types d'exigences distincts et liés aux cas d'utilisation associés.  Vous pouvez aussi effectuer un suivi des probabilités de concrétisation des dangers, des actions correctives et/ou des mesures préventives.

Interprétation : Lorsque les exigences sont rédigées sous forme de contrat formel, il peut être difficile et coûteux de modifier cette formulation.  Une fois que l'organisation chargée de son développement acquiert une plus grande compréhension de l'exigence, il peut être judicieux de lui adjoindre un texte interprétatif plutôt que de changer la formulation officielle de l'exigence.

Cas d'utilisation

Outre les éléments mentionnés plus haut, il peut être utile de prêter attention à l'attribut suivant de cas d'utilisation :

Niveau de description : niveau de détail du cas d'utilisation :

  • 10% : description de base fournie.
  • 50% : Flux principaux documentés.
  • 80% : Terminé mais sans revue. Toutes les préconditions et les postconditions ont été complètement spécifiées.
  • 100% : revu et approuvé.

Cas de test

Statut : indique la progression lors du développement du test.

  • Aucune activité : Aucun travail de développement de ce scénario de test n'a encore été accompli.
  • Manuel : Un script manuel a été rédigé et validé comme capable de vérifier la conformité aux exigences associées.
  • Automatisé : Un script automatisé a été rédigé et validé comme capable de vérifier la conformité aux exigences associées.

Attributs généraux

D'autres attributs des exigences ont une applicabilité plus générale, comme :

  • Itération planifiée
  • Itération effective
  • Interlocuteur responsable

Sélection des attributs

Les attributs sont utilisés pour le suivi d'informations associées à un élément de traçabilité, habituellement pour déterminer leur statut et générer des états. Chaque organisation peut requérir un suivi d'informations spécifiques.Avant d'affecter un attribut, déterminez :

  • Qui sera chargé de fournir les informations ?
  • Qui utilisera ces informations et à quelles fins ?
  • Si le contenu de l'information justifie le coût du suivi ?

Les principaux attributs à suivre sont : risque, bénéfice, effort, stabilité et impact sur l'architecture, afin de hiérarchiser les exigences pour la gestion de la portée du projet et d'affecter les exigences appropriées aux différentes itérations. Leur suivi doit s'effectuer initialement dans le cadre de l'activité Fonctionnalités, puis dans celle de tous les cas d'utilisation et des exigences supplémentaires.

Evaluation d'informations dérivées

Outre l'utilisation directe des attributs d'exigences, vous pouvez dériver des informations via la traçabilité vers d'autres types d'exigences. Ci-dessous figurent quelques modes de dérivation classiques :

  • Dérivation descendante - Compte tenu de la traçabilité ci-dessus, supposez qu'une fonctionnalité produit comporte un attribut "Version cible". Il est possible de déduire que chaque section de cas d'utilisation à laquelle conduit cette fonctionnalité doit aussi être disponible dans la version cible spécifiée, ou auparavant.
  • Dérivation ascendante - Compte tenu de la traçabilité ci-dessus, supposez qu'une section de cas d'utilisation comporte un attribut "Effort estimé". Le coût d'une fonctionnalité produit peut être évalué en additionnant l'effort estimé de toutes les sections de cas d'utilisation auxquelles elle conduit. Vous devez néanmoins précéder avec circonspection car plusieurs fonctionnalités produit peuvent mener à une même section de cas d'utilisation.

Par conséquent, pour affecter des attributs à des types d'exigences, vous devez évaluer :

  • Quelles informations dérivées et quels états veut-on générer à partir de cet attribut ?
  • A quel niveau de hiérarchie de traçabilité doit-on sonder cet attribut ?

Dépendances des attributs

Certains attributs peuvent ne s'appliquer qu'à un niveau donné du développement. par exemple, un attribut 'effort estimé' relatif à un cas d'utilisation peut être remplacé par 'estimation des efforts pour les éléments de conception' une fois que ce cas d'utilisation est dûment représenté dans la conception.

Etats et mesures

Des exemples d'états et de mesure concernant les exigences figurent ci-dessous. En sélectionnant le jeu d'états et de mesures requis ou souhaité pour votre projet, vous pouvez décliner les attributs nécessaires pour le Plan de gestion des exigences.

Description de l'état ou de la mesure Utilisation
Priorité de développement des cas d'utilisation (liste des cas d'utilisation triés par : Risque, Bénéfice, Effort, Stabilité et Impact sur l'architecture). Ces listes peuvent être triées séparément ou sous une liste unique triée à l'aide d'une combinaison pondérée de ces attribut. Utilisé pour Tâche : hiérarchisation des cas d'utilisation.
Pourcentage de fonctionnalités sous chaque catégorie de statut. Suivi du progrès lors de la définition de la version de référence du projet.
 - classé par version cible  - suivi du progrès version par version
 - pondéré par l'effort  - fournit une mesure plus précise du progrès.
Fonctions triées par risque  - identifie les fonctionnalités vulnérables.  Utile pour la gestion de la portée du projet et l'affectation de fonctionnalités aux itérations.
 - classifiées par Version cible, avec récapitulatif des risques pour le développement pour chaque version  - utile pour évaluer si des fonctionnalités vulnérables ont été planifiées pour des phases trop précoces ou trop tardives du projet.
Sections des cas d'utilisation triées par stabilité  - utilisées pour déterminer quelles sections ont besoin d'être stabilisées.
 - pondérées ou triées par l'impact sur l'architecture  - utile pour établir la priorité de stabilisation des cas d'utilisation avec impact sur l'architecture ou impliquant un effort important.
Exigences avec attributs non définis Lorsque des exigences sont initialement formulées, vous pouvez ne pas leur affecter immédiatement tous leurs attributs (par exemple, en utilisant une valeur par défaut "Indéfinie").  L'activité Points de contrôle : spécifications des exigences logicielles utilise cet état pour vérifier l'existence de ces attributs indéfinis.
Eléments de traçabilité avec liens de traçabilité incomplets Un état des liens avec traçabilité incorrecte ou incomplète est utilisé dans l'activité Points de contrôle : spécification des exigences logicielles.

Gestion des modifications des exigences Haut de la page

Les modifications sont inévitables et doivent être factorisées dans la planification. Elles peuvent survenir dans diverses circonstances :

  • Modification du problème à résoudre. Ceci peut être du à de nouveaux règlements, à des pressions économiques, à des évolutions technologiques, etc.
  • Changement d'avis des intéressés sur leurs attentes du système, ou de leurs perceptions. Diverses raisons peuvent être en cause, comme le remplacement des responsables, une meilleure compréhension des problèmes, etc.
  • Omission d'une partie des intéressés ou de questions pertinentes lors de la définition des exigences initiales.

Les stratégies de gestion de modification des exigences comprennent :

  • Le référencement des exigences fondamentales
  • L'établissement d'un canal unique de contrôle des modifications
  • La conservation d'un historique des modifications

Référencement des exigences fondamentales Haut de la page

Vers la fin de la phase d'élaboration, l'analyste système doit référencer toutes les exigences fondamentales identifiées. Ceci est généralement obtenu en assurant un contrôle de version sur les produits des modifications et en identifiant le jeu de produits et les versions correspondantes qui représentent les exigences fondamentales.

Le but recherché n'est pas le gel des exigences, mais plutôt de permettre l'identification, la communication, l'estimation et le contrôle des nouvelles exigences ou d'exigences modifiées.

Voir aussi Guide d'utilisation de l'outil : Référencement d'un projet Rational RequisitePro.

L'établissement d'un canal unique de contrôle des modifications

Une simple demande de modification par une partie prenante ne suffit pas à changer le budget et le calendrier officiels. Généralement, un processus de négociation et de rapprochement budgétaire doit être déclenché avant qu'une modification ne soit approuvée. Fréquemment, les modifications doivent être contrebalancées entre elles.

Il est essentiel que chaque modification passe par un unique canal, le comité de contrôle des changements, pour déterminer son impact sur le système et obtenir son approbation officielle. Le mécanisme de proposition d'un changement consiste à soumettre une demande de changement, qui est revue par le comité de contrôle des changements.

Pour plus d'informations, voir Tâche : mise en place du processus de contrôle de modifications.

La conservation d'un historique des modifications

Il est souhaitable de conserver les traces des modifications des exigences individuelles. cet historique vous permet de consulter toutes les modifications antérieures de l'exigence, de ses valeurs d'attributs, et les motivations avancées. Ceci peut être utile pour l'évaluation de la stabilité actuelle des exigences et l'identification de cas où le processus de contrôle des modifications ne fonctionne pas (par exemple, identification de demandes de changement n'ayant pas été soumises à une revue et à une approbation).