Rubriques

Relation à d'autres plans Haut de la page

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

Organisation, responsabilité et interfaces Haut de la page

Comme décrit dans le ../../papers/apprmuc.htm -- This hyperlink in not present in this generated websiteLivres blancs : Application de la gestion des exigences dans les cas d'utilisation, la gestion des exigences est importante pour garantir le succès du projet.  Les causes d'échec d'un projet les plus fréquemment citées incluent :

  • 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 artefacts de projet par les parties prenantes : Tous les artefacts doivent-ils leur être ouverts ? Seulement à des jalons du calendrier ?

Identification des éléments de traçabilité Haut de la page

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

Spécification de la traçabilité Haut de la page

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 ../../papers/traceability.htm -- This hyperlink in not present in this generated websiteStratégies de traçabilité pour la gestion des exigences avec les cas d'utilisation.

Exemples d'attributs Haut de la page

Vous pouvez opérer une sélection d'après les exemples d'attributs ci-dessous.

Besoin de la partie prenante Haut de la page

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 (de 0 à 100 %). La somme de toutes les contributions ne doit pas dépasser 100 %. L'exemple de ../workguid/wg_paret.htm -- This hyperlink in not present in this generated websitediagramme de Paretoillustre la contribution de divers besoins de parties prenantes.

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 Haut de la page

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 parties prenantes.

  • 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ù 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 en interne sur un seul site
  • Géographique : Equipe géographiquement dispersée
  • 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 du logiciel.

  • 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égligible : Ne peut pas entraîner de blessures graves ou de dommages significatifs aux équipements.
  • Marginal: Peut être maitrisé 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 sérieuses, 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 Haut de la page

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 révision. Toutes les préconditions et les postconditions ont été complètement spécifiées.
  • 100 %: Revu et approuvé.

Scénario de test Haut de la page

Statut : Indique la progression du développement du scénario de 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 Haut de la page

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 Haut de la page

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 Haut de la page

Des exemples d'états et de mesure concernant les exigences figurent ci-dessous. En sélectionnant l'ensemble 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 attributs. Utilisé pour : Activité : 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.
 - classifié par : Version cible  - suivi du progrès version par version
 - pondéré par : Effort  - fournit une mesure plus précise du progrès.
Fonctionnalités 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 cas d'utilisation triées par : Stabilité  - utilisées pour déterminer quelles sections ont besoin d'être stabilisées.
 - pondérées par : Incidence 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écification des exigences logicielles utilise cet état pour vérifier l'existence de tels 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é Point 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 interessé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 artefacts des modifications et en identifiant l'ensemble d'artefacts 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.

Etablissement d'un canal unique de contrôle des modifications Haut de la page

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 pour revue par le comité de contrôle des changements.

Conservation d'un historique des modifications Haut de la page

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 révision et à une approbation).



RUP (Rational Unified Process)   2003.06.15