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.
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 ?
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.
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.
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.
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
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.
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.
|
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
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).
|