Activité: Gérer le changement des exigences
Cette activité gère les changements apportés aux exigences et évalue leur impact général.
Etend: Gérer le changement des exigences
DescriptionStructure de répartition du travailAffectation d'équipeUtilisation du produit
Objet
Le but de cette activité est d'évaluer l'impact des changements demandés par les exigences et de gérer l'impact en aval des changements approuvés à mettre en oeuvre.
Relations
Activités parentes
Description

Cette activité porte sur les points suivants :

Les changements apportés aux exigences ont un impact sur les artefacts en aval (comme les produits d'analyse, de conception et de test, les artefacts de déploiement etc.). La relation de traçabilité identifiée et documentée lors de la gestion des dépendances  définit de manière explicite la relation entre les exigences et les autres produits. Ces relations sont essentielles pour comprendre l'impact d'un changement d'exigence.

Propriétés
Commandé par les événementsYes
Plusieurs occurrences
En cours
Facultatif
Planifié
Réitérable
Affectation du personnel

Implique l'équipe étendue (parties prenantes : représentants du client, experts domaine et autres). Faites participer en tant que Réviseur technique toute personne de l'équipe logicielle dont le travail est affecté par le changement).  Veillez à gérer vos ressources de révision efficacement. Ne faites pas participer l'équipe étendue à moins d'être sûr que cela ajoute de la valeur au projet.

L'équipe étendue doit comporter des personnes connaissant bien le domaine du problème et les difficultés techniques du projet. Elles doivent aussi être compétentes dans la gestion des exigences et dans la modélisation de cas d'utilisation.

Utilisation
Conseils d'utilisation

Cette activité doit être réalisée à chaque fois que les exigences sont affinées.

Des révisons régulières ainsi que des mises à jour des attributs d'exigence et des dépendances doivent avoir lieu à chaque mise jour d'exigences.

Il est conseillé de prévoir une revue du modèle de cas d'utilisation par itération au cours des phases de création et d'élaboration, afin de contrôler le travail en cours. Généralement, les utilisateurs procèdent à cette revue avant que les cas d'utilisation soient développés en détail : il s'agit d'un jalon très important, qui évite de gaspiller des ressources pour le développement de cas d'utilisation inappropriés. Puis, à la fin de la phase d'élaboration, vous devez organiser une revue détaillée du modèle de cas d'utilisation. Notez qu'à la fin de la phase d'élaboration, vous devez disposer d'un modèle de cas d'utilisation, et parfois même d'un modèle de domaine représentant le glossaire, achevé à 80 %. Vous devez également prévoir une revue du modèle de cas d'utilisation par itération au cours de phases de construction et de transition, lorsque le modèle de cas d'utilisation est affiné. La revue doit alors se concentrer sur la partie du modèle qui a été développée dans le cadre de l'itération en question.

Considérations clés

L'équipe de développement principale doit réaliser quelques révisions internes : revues de projet pour éliminer les incohérences superflues avant une inspection et une révision plus formelle de leur travail par l'équipe étendue.

Il est conseillé de diviser le matériel pour que l'équipe ne passe pas tout en revue à la fois. Une réunion de révision ne doit pas durer plus d'une journée. Par exemple, vous pouvez effectuer des revues séparées de l'interface utilisateur et des scénarios comportementaux, ou vous pouvez réviser tous les artefacts d'exigences en rapport avec un sous-système donné.

Une autre considération importante est le suivi de l'historique des exigences. En enregistrant la nature et la raison des changements d'exigence, les réviseurs reçoivent les informations nécessaires pour répondre de manière appropriée au changement.