Système d'informations sportives par messagerie de poche Plan de gestion des exigences Version 1.0 Historique de révision
Sommaire 1.3 Définitions, acronymes et abréviations 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.5 Gestion des changements apportés aux exigences 3.6 Enchaînements d'activités et activités Plan de gestion des exigences 1. Introduction1.1 ObjetCe 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éeCe plan concerne toutes les phases du projet.
1.3 Définitions, acronymes et abréviationsVoir Glossaire
1.4 RéférencesPlan 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 exigences2.1 Organisation, responsabilités et interfacesVoir le plan de développement logiciel du SISMP.
2.2 Outils, environnement et infrastructureL'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 exigences3.1 Identification des exigences
3.2 Traçabilité![]() Figure -1 - Diagramme de traçabilité Critères de FONCTLes fonctionnalités seront établies d'après les cas d'utilisation.
Critères de BESOINLes 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 CULes cas d'utilisation seront établis d'après les cas de test.
Critères de SUPPLes spécifications supplémentaires seront établies d'après les cas de test.
3.3 AttributsAttributs de FONCTEtat
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.
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.
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 BESOINEtat
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.
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 CUDé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.
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.
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 SUPPEtat
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.
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.
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 mesuresVoir le plan de mesure du SISMP.
3.5 Gestion des changements apportés aux exigencesVoir 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ésVoir le plan de développement du SISMP.
4. JalonsVoir le plan de développement logiciel du SISMP.
5. Formation et ressourcesVoir le plan de développement logiciel du SISMP.
|
Rational Unified Process
|