Système d'informations sportives par messagerie de poche

Plan de gestion des exigences
 
 

Version 1.0


 



 
 

Historique de révision


Date
Version
Description
Auteur
2 juillet 2000
1.0
Edition initiale
Context Integration


Sommaire
 
 

1. Introduction

1.1 Objet

1.2 Portée

1.3 Définitions, acronymes et abréviations

1.4 Références

2. Gestion des exigences

2.1 Organisation, responsabilités et interfaces

2.2 Outils, environnement et infrastructure

3. Programme de gestion des exigences

3.1 Identification des exigences

3.2 Traçabilité

Critères de FONCT

Critères de BESOIN

Critères de CU

Critères de SUPP

3.3Attributs

Attributs de FONCT

Attributs de BESOIN

Attributs de CU

Attributs de SUPP

3.4 Rapports et mesures

3.5 Gestion des changements apportés aux exigences

3.6 Enchaînements d'activités et activités

4. Jalons

5. Formation et ressources
 


Plan de gestion des exigences

1.  Introduction

1.1  Objet

Ce document décrit les instructions utilisées dans le cadre du projet Système d'informations sportives par messagerie de poche (SISMP) pour établir les documents liés aux exigences, les types d'exigence, les attributs relatifs aux exigences et la traçabilité à des fins de gestion des exigences en termes de projet logiciel. Ce document servira également de document de configuration pour l'outil de gestion des exigences ExigencePro Rational.

1.2  Portée

Ce plan concerne toutes les phases du projet.

1.3  Définitions, acronymes et abréviations

1.4  Références

Plan de développement logiciel du SISMP
Plan de développement du SISMP 

Plan de mesure du SISMP 

Plan de gestion de configuration du SISMP

2.  Gestion des exigences

2.1  Organisation, responsabilités et interfaces

Voir le plan de développement logiciel du SISMP.

2.2  Outils, environnement et infrastructure

L'outil ExigencePro Rational sera utilisé pour gérer les exigences.  Pour obtenir des informations supplémentaires sur l'infrastructure et l'environnement, se reporter au plan de développement logiciel du SISMP.

3.  Programme de gestion des exigences

3.1  Identification des exigences

 
Artefact (type de document)
Type d'exigence
Description
Vision (VIS)
Besoin des parties prenantes (BESOIN)
Besoin principal des parties prenantes ou de l'utilisateur.
Vision (VIS)
Fonctionnalité (FONCT)
Conditions ou fonctions de cette édition du système.
Modèle de cas d'utilisation
Cas d'utilisation (CU)
Cas d'utilisation pour cette édition, documentés dans Rational Rose, détaillés dans l'outil ExigencePro Rational.
Spécification supplémentaire (SS)
Exigence supplémentaire (SUPP)
Exigences non fonctionnelles, non collectées dans le modèle de cas d'utilisation.
Tableau 3.1-1 Artefacts et types d'exigence

3.2  Traçabilité

Libellé dans le contenu ci-dessous

Figure -1 - Diagramme de traçabilité

Critères de FONCT

Les fonctionnalités seront établies d'après les cas d'utilisation.

Critères de BESOIN

Les besoins de l'utilisateur seront établis d'après les fonctionnalités (FONCT).  Tout besoin qui n'a pas été établi d'après une FONCT ne sera pas implémenté.

Critères de CU

Les cas d'utilisation seront établis d'après les cas de test.

Critères de SUPP

Les spécifications supplémentaires seront établies d'après les cas de test.

3.3 Attributs

Attributs de FONCT

Etat
Défini après la négociation et la revue par l'équipe responsable du projet. Suit l'avancement au cours de la définition de la version de référence du projet.

 
Proposée
Utilisé pour décrire les fonctionnalités en cours d'étude, mais qui n'ont été ni révisées ni acceptées "officiellement", par exemple par un groupe de travail constitué des représentants de l'équipe de projet, les responsables produit et la communauté des utilisateurs et de clients.
Approuvée
Fonctionnalités reconnues comme utiles et réalisables et dont l'implémentation a été approuvée officiellement.
Intégrée
Fonctionnalités intégrées dans la version de référence du produit à un moment donné.

Avantage

Défini par le marketing, le responsable produit ou l'analyste du marché. Les exigences ne sont pas toutes égales et les classer en fonction de l'avantage relatif apporté au client ouvre une discussion avec les clients, les analystes et les membres de l'équipe de développement. Utilisé dans la gestion du périmètre et la détermination de la priorité de développement.
 
Critique
Fonctionnalités essentielles. Si l'implémentation n'aboutit pas, le système ne répondra pas aux besoins du client. Toutes les fonctionnalités critiques doivent être implémentées dans l'édition et le calendrier doit être décalé, si besoin est.
Importante
Fonctionnalités importantes en termes d'efficacité du système pour la plupart des applications. La fonctionnalité ne peut pas facilement être apportée par un autre moyen. Si une fonctionnalité importante vient à manquer, cela peut influer sur la satisfaction du client ou même les recettes, mais l'absence d'une fonctionnalité importante n'a aucune répercussion sur le calendrier établi pour l'édition.
Utile
Fonctionnalités utiles dans des applications moins courantes, qui seront utilisées moins fréquemment ou pour lesquelles des solutions efficaces et raisonnables pourront être apportées. L'intégration d'un tel élément dans une édition n'influera pas sur les recettes ou la satisfaction du client de manière significative.

Effort

Défini par l'équipe de développement. Etant donné que certaines fonctionnalités requièrent plus de temps et de ressources que d'autres, estimer les semaines-homme ou les semaines-équipe, les lignes de code nécessaires ou les points fonctionnels, par exemple, constitue le meilleur moyen pour évaluer la complexité et pour prévoir ce qui peut ou ne peut pas accompli dans un laps de temps déterminé. Utilisé dans la gestion du périmètre et la détermination de la priorité de développement. 

Risque

Défini par l'équipe de développement selon la probabilité que des événements non souhaités, tels qu'un dépassement des coûts, un retard de calendrier ou même l'abandon du projet, surviennent au cours du projet. Les responsables de projet estiment pour la plupart qu'il est suffisant de classer les risques en trois catégories (élevé, moyen, faible), même s'il est possible de définir des degrés plus fins. Le risque peut souvent être évalué indirectement en mesurant l'incertitude (plage) quant à l'estimation du calendrier de l'équipe projet. 

Stabilité

Définie par l'analyste et l'équipe de développement en fonction de la probabilité que la fonctionnalité ou que la compréhension de la fonctionnalité par l'équipe change. Utilisé pour faciliter l'élaboration des priorités de développement et pour déterminer les éléments pour lesquels des explications supplémentaires constituent l'action suivante appropriée. 

Edition cible

Contient la version du produit prévue dans laquelle la fonctionnalité apparaîtra pour la première fois. Cette zone peut être utilisée pour attribuer des fonctionnalités mentionnées dans un document Vision à une édition de référence particulière. Lorsque cette zone est combinée avec la zone d'état, votre équipe peut proposer, enregistrer et traiter les diverses fonctionnalités de l'édition, sans qu'elles passent pour autant en phase de développement. Seules les fonctionnalités présentant l'état Intégrée et pour lesquelles l'édition cible est définie seront implémentées. Lorsque la gestion du périmètre a lieu, le numéro de version de l'édition cible peut être incrémenté, pour que l'élément continue d'apparaître dans le document Vision, mais que son intégration soit planifiée pour une édition ultérieure. 

Attribuée à

Dans de nombreux projets, les fonctionnalités seront attribuées aux "équipes chargées des fonctionnalités", responsables des explications supplémentaires, de la rédaction des exigences logicielles et de l'implémentation. Cette liste déroulante simple aidera toute personne de l'équipe projet à mieux comprendre ses responsabilités. 

Motif

Cette zone de texte est utilisée pour le suivi de la source de la fonctionnalité demandée. Les exigences sont le fait de raisons bien spécifiques. Cette zone contient une explication ou une référence à une explication. Par exemple, la référence peut être une page et un numéro de ligne dans une spécification d'exigence du produit ou un marqueur de minute sur la vidéo d'un entretien important avec le client.

Attributs de BESOIN

Etat
Défini après la négociation et la revue par l'équipe responsable du projet. Suit l'avancement au cours de la définition de la version de référence du projet.

 
Proposé
Utilisé pour décrire les besoins en cours d'étude, mais qui n'ont été ni révisés ni acceptés "officiellement", par exemple par un groupe de travail constitué des représentants de l'équipe de projet, les responsables produit et la communauté des utilisateurs et de clients.
Approuvée
Fonctions reconnues comme utiles et réalisables et dont l'implémentation a été approuvée officiellement.
Intégré
Besoins satisfaits dans la version de référence du produit à un moment donné.

Effort

Défini par l'équipe de développement. Etant donné que certains besoins requièrent plus de temps et de ressources que d'autres, estimer les semaines-homme ou les semaines-équipe, les lignes de code nécessaires ou les points fonctionnels, par exemple, constitue le meilleur moyen pour évaluer la complexité et pour prévoir ce qui peut ou ne peut pas accompli dans un laps de temps déterminé. Utilisé dans la gestion du périmètre et la détermination de la priorité de développement. 

Risque

Défini par l'équipe de développement selon la probabilité que des événements non souhaités, tels qu'un dépassement des coûts, un retard de calendrier ou même l'abandon du projet, surviennent au cours du projet. Les responsables de projet estiment pour la plupart qu'il est suffisant de classer les risques en trois catégories (élevé, moyen, faible), même s'il est possible d'affiner ces catégories. Le risque peut souvent être évalué indirectement en mesurant l'incertitude (plage) quant à l'estimation du calendrier de l'équipe projet. 

Stabilité

Définie par l'analyste et l'équipe de développement en fonction de la probabilité que le besoin ou que la compréhension du besoin par l'équipe change. Utilisé pour faciliter l'élaboration des priorités de développement et pour déterminer les éléments pour lesquels des explications supplémentaires constituent l'action suivante appropriée. 

Edition cible

Contient la version du produit prévue qui répondra au besoin pour la première fois. Cette zone peut être utilisée pour attribuer des fonctionnalités mentionnées dans un document Vision à une édition de référence particulière. Lorsque cette zone est combinée avec la zone d'état, votre équipe peut proposer, enregistrer et traiter les diverses fonctionnalités de l'édition, sans qu'elles passent pour autant en phase de développement. Seuls les besoins présentant l'état Intégré et pour lesquels l'édition cible est définie seront satisfaits. Lorsque la gestion du périmètre a lieu, le numéro de version de l'édition cible peut être incrémenté, pour que l'élément continue d'apparaître dans le document Vision, mais que son intégration soit planifiée pour une édition ultérieure. 

Motif

Cette zone de texte est utilisée pour le suivi de la source du besoin. Les exigences sont le fait de raisons bien spécifiques. Cette zone contient une explication ou une référence à une explication. Par exemple, la référence peut être une page et un numéro de ligne dans une spécification d'exigence du produit ou un marqueur de minute sur la vidéo d'un entretien important avec le client.

Attributs de CU

Etat
Défini après la négociation et la revue par l'équipe responsable du projet. Suit l'avancement au cours de la définition de la version de référence du projet.

 
Proposé
Utilisé pour décrire les cas d'utilisation en cours d'étude, mais qui n'ont été ni révisés ni acceptés "officiellement", par exemple par un groupe de travail constitué des représentants de l'équipe de projet, les responsables produit et la communauté des utilisateurs et de clients.
Approuvé
Cas d'utilisation reconnus utiles et réalisables et dont l'implémentation a été approuvée officiellement.
Intégré
Cas d'utilisation intégrés dans la version de référence du produit à un moment donné.

Avantage

Défini par le marketing, le responsable produit ou l'analyse du marché. Les exigences ne sont pas toutes égales et classer les cas d'utilisation en fonction de l'avantage relatif apporté au client ouvre une discussion avec les clients, les analystes et les membres de l'équipe de développement. Utilisé dans la gestion du périmètre et la détermination de la priorité de développement.
 
Critique
Cas d'utilisation essentiels. Si l'implémentation n'aboutit pas, le système ne répondra pas aux besoins du client. Tous les cas d'utilisation critiques doivent être implémentés dans l'édition et le calendrier doit être décalé, si besoin est.
Important
Cas d'utilisation importants en termes d'efficacité du système pour la plupart des applications. La fonctionnalité ne peut pas facilement être apportée par un autre moyen. Si une fonctionnalité importante vient à manquer, cela peut influer sur la satisfaction du client ou même les recettes, mais l'absence d'une fonctionnalité importante n'a aucune répercussion sur le calendrier établi pour l'édition.
Utile
Cas d'utilisation utiles dans des applications moins courantes, qui seront utilisés moins fréquemment ou pour lesquels des solutions efficaces et raisonnables pourront être apportées. L'intégration d'un tel élément dans une édition n'influera pas sur les recettes ou la satisfaction du client de manière significative.

Effort

Défini par l'équipe de développement. Etant donné que certains cas d'utilisation requièrent plus de temps et de ressources que d'autres, estimer les semaines-homme ou les semaines-équipe, les lignes de code nécessaires ou les points fonctionnels, par exemple, constitue le meilleur moyen pour évaluer la complexité et pour prévoir ce qui peut ou ne peut pas accompli dans un laps de temps déterminé. Utilisé dans la gestion du périmètre et la détermination de la priorité de développement. 

Risque

Défini par l'équipe de développement selon la probabilité que des événements non souhaités, tels qu'un dépassement des coûts, un retard de calendrier ou même l'abandon du projet, surviennent au cours du projet. Les responsables de projet estiment pour la plupart qu'il est suffisant de classer les risques en trois catégories (élevé, moyen, faible), même s'il est possible d'affiner ces catégories. Le risque peut souvent être évalué indirectement en mesurant l'incertitude (plage) quant à l'estimation du calendrier de l'équipe projet. 

Stabilité

Définie par l'analyste et l'équipe de développement en fonction de la probabilité que le cas d'utilisation ou que la compréhension du cas d'utilisation par l'équipe change. Utilisé pour faciliter l'élaboration des priorités de développement et pour déterminer les éléments pour lesquels des explications supplémentaires constituent l'action suivante appropriée. 

Edition cible

Contient la version du produit prévue dans laquelle le cas d'utilisation apparaîtra pour la première fois. Cette zone peut être utilisée pour attribuer des cas d'utilisation d'un document Etude de cas d'utilisation à une édition de référence particulière. Lorsque cette zone est combinée avec la zone d'état, votre équipe peut proposer, enregistrer et traiter les divers cas d'utilisation de l'édition, sans qu'ils passent pour autant en phase de développement. Seuls les cas d'utilisation présentant l'état Intégré et pour lesquels l'édition cible est définie seront implémentés. Lorsque la gestion du périmètre a lieu, le numéro de version de l'édition cible peut être incrémenté, pour que l'élément continue d'apparaître dans le document Vision, mais que son intégration soit planifiée pour une édition ultérieure. 

Attribué à

Dans de nombreux projets, les cas d'utilisation seront attribués aux "équipes chargées des fonctionnalités", responsables des explications supplémentaires, de la rédaction des exigences logicielles et de l'implémentation. Cette liste déroulante simple aidera toute personne de l'équipe projet à mieux comprendre ses responsabilités. 

Motif

Cette zone de texte est utilisée pour le suivi de la source du cas d'utilisation demandé. Les exigences sont le fait de raisons bien spécifiques. Cette zone contient une explication ou une référence à une explication. Par exemple, la référence peut être une page et un numéro de ligne dans une spécification d'exigence du produit ou un marqueur de minute sur la vidéo d'un entretien important avec le client.

Attributs de SUPP

Etat
Défini après la négociation et la revue par l'équipe responsable du projet. Suit l'avancement au cours de la définition de la version de référence du projet.

 
Proposée
Utilisé pour décrire des spécifications supplémentaires en cours d'étude, mais qui n'ont été ni révisées ni acceptées "officiellement", par exemple par un groupe de travail constitué des représentants de l'équipe de projet, les responsables produit et la communauté des utilisateurs et de clients.
Approuvée
Fonctions reconnues comme utiles et réalisables et dont l'implémentation a été approuvée officiellement.
Intégrée
Spécifications supplémentaires intégrées dans la version de référence du produit à un moment donné.

Avantage

Défini par le marketing, le responsable produit ou l'analyse du marché. Les exigences ne sont pas toutes égales et les classer en fonction de l'avantage relatif apporté au client ouvre une discussion avec les clients, les analystes et les membres de l'équipe de développement. Utilisé dans la gestion du périmètre et la détermination de la priorité de développement.
 
Critique
Spécification essentielle. Si l'implémentation n'aboutit pas, le système ne répondra pas aux besoins du client. Toutes les fonctionnalités critiques doivent être implémentées dans l'édition et le calendrier doit être décalé, si besoin est.
Importante
Spécifications importantes en termes d'efficacité du système pour la plupart des applications. La fonctionnalité ne peut pas facilement être apportée par un autre moyen. Si une spécification importante vient à manquer, cela peut influer sur la satisfaction du client ou même les recettes, mais l'absence d'une fonctionnalité importante n'a aucune répercussion sur le calendrier établi pour l'édition.
Utile
Spécifications utiles dans des applications moins courantes, qui seront utilisées moins fréquemment ou pour lesquelles des solutions efficaces et raisonnables pourront être apportées. L'intégration d'un tel élément dans une édition n'influera pas sur les recettes ou la satisfaction du client de manière significative.

Effort

Défini par l'équipe de développement. Etant donné que certaines spécifications requièrent plus de temps et de ressources que d'autres, estimer les semaines-homme ou les semaines-équipe, les lignes de code nécessaires ou les points fonctionnels, par exemple, constitue le meilleur moyen pour évaluer la complexité et pour prévoir ce qui peut ou ne peut pas accompli dans un laps de temps déterminé. Utilisé dans la gestion du périmètre et la détermination de la priorité de développement. 

Risque

Défini par l'équipe de développement selon la probabilité que des événements non souhaités, tels qu'un dépassement des coûts, un retard de calendrier ou même l'abandon du projet, surviennent au cours du projet. Les responsables de projet estiment pour la plupart qu'il est suffisant de classer les risques en trois catégories (élevé, moyen, faible), même s'il est possible d'affiner ces catégories. Le risque peut souvent être évalué indirectement en mesurant l'incertitude (plage) quant à l'estimation du calendrier de l'équipe projet. 

Stabilité

Définie par l'analyste et l'équipe de développement en fonction de la probabilité que la spécification ou que la compréhension de la spécification par l'équipe change. Utilisé pour faciliter l'élaboration des priorités de développement et pour déterminer les éléments pour lesquels des explications supplémentaires constituent l'action suivante appropriée. 

Edition cible

Contient la version du produit prévue dans laquelle l'attribut ou la fonctionnalité spécifié(e) apparaîtra pour la première fois. Cette zone peut être utilisée pour attribuer des spécifications à une édition de référence particulière. Lorsque cette zone est combinée avec la zone d'état, votre équipe peut proposer, enregistrer et traiter les diverses spécifications de l'édition, sans qu'elles passent pour autant en phase de développement. Seules les spécifications présentant l'état Intégrée et pour lesquelles l'édition cible est définie seront implémentées. Lorsque la gestion du périmètre a lieu, le numéro de version de l'édition cible peut être incrémenté, pour que l'élément continue d'apparaître dans le document Spécification supplémentaire, mais que son intégration soit planifiée pour une édition ultérieure. 

Attribué à

Dans de nombreux projets, les attributs ou les fonctionnalités spécifié(e)s seront attribués aux "équipes chargées des fonctionnalités", responsables des explications supplémentaires, de la rédaction des exigences logicielles et de l'implémentation. Cette liste déroulante simple aidera toute personne de l'équipe projet à mieux comprendre ses responsabilités.

3.4  Rapports et mesures

Voir le plan de mesure du SISMP.

3.5  Gestion des changements apportés aux exigences

Voir le plan de gestion de configuration du SISMP.
Les groupes d'accès suivants seront paramétrés de manière à pouvoir contrôler l'accès aux exigences dans ExigencePro Rational.

 
 

- Administrateur outil : dispose des droits d'accès complets pour chaque partie de l'outil.  Peut ajouter et supprimer des personnes, modifier leurs droits d'accès, etc. 

- Auteur : peut créer des exigences.

- Responsable de projet : définit l'état des exigences.

- Testeur_AQ : définit l'état des exigences relatives aux cas d'utilisation.

3.6        Enchaînements d'activités et activités

Voir le plan de développement du SISMP.

4.  Jalons

Voir le plan de développement logiciel du SISMP.

5.  Formation et ressources

Voir le plan de développement logiciel du SISMP.

 
 
Rational Unified Process