Gestion de la portée - Domaine de connaissances

Système national de gestion de projet
Projets opérationnels appuyés par les TI

TITRE :

Domaine de connaissances de la gestion de la portée

1. DATE D'ENTRÉE EN VIGUEUR :

DE 2010

2. AUTORITÉ :

Le présent document est publié avec l'autorisation du sous-ministre, Travaux publics et Services gouvernementaux Canada (TPSGC).

3. CONTEXTE :

Le présent domaine de connaissances sera mis en œuvre à l'aide de la politique sur le Système national de gestion de projets (SNGP) de TPSGC.

4. OBJECTIF :

Décrire les composantes et les exigences du SNGP qui s'appliquent à la gestion de la portée d'un projet.

5. RENSEIGNEMENTS SUR LA PROCÉDURE :

La portée d'un projet est la somme des produits et des résultats réalisés ainsi que des services offerts dans le cadre du projet en question.

La gestion de la portée doit être prise en compte pendant toute la durée d'un projet. Dans le cadre du SNGP, la gestion de la portée est un élément du Plan préliminaire de projet (PPP). Les éléments de portée des projets opérationnels appuyés par les TI compris dans le PPP sont davantage élaborés durant la phase de planification, et font partie du plan de gestion de projet. Pour ce qui est des projets plus importants et plus complexes, il se peut qu'un plan de gestion de la portée distinct soit créé. Le plan de gestion de la portée du projet décrit la manière dont la portée du projet sera définie, élaborée et vérifiée, ainsi que la manière dont la structure de répartition du travail (SRT) sera créée et définie. Le plan de gestion de la portée fournit des directives sur la manière dont la portée du projet sera gérée et contrôlée par l'équipe de gestion de projet.

Le projet est géré au moyen du PPP durant l'étape d'identification. Le projet est géré au moyen du PGP durant l'étape de réalisation. La réalisation de la portée du produit est évaluée par rapport aux exigences qui ont été satisfaites, alors que la réalisation de la portée du projet est évaluée par rapport au plan de gestion de projet.

Dans le SNGP, un plan de gestion de la portée est préparé pour chaque projet, soit en tant que composant du plan de gestion de projet ou en tant que document distinct. Les documents connexes, comme la SRT et les activités prévues au calendrier du projet, sont liés au plan de gestion de la portée. Le calendrier contient les blocs de tâches du projet. Ces derniers doivent être mis à jour tout le long du cycle de vie du projet, selon l'évolution de ce dernier. Les mises à jour reflètent le processus d'amélioration de la portée ou les changements approuvés conformément au processus de gestion des changements. Ce processus est décrit ci-dessous en fonction des neuf phases du SNGP.

Objectif

L'objectif de la gestion de la portée est de s'assurer que le projet comporte toutes les tâches nécessaires, et uniquement les tâches nécessaires, pour mener à bien le projet. Elle vise principalement à définir et à contrôler ce qui doit être inclus ou non dans le projet.

Par conséquent, l'objectif de la gestion de la portée consiste à fournir une méthode permettant de :

• décrire les processus et les outils visant à définir la portée du projet;
• élaborer un énoncé de la portée du projet;
• définir et élaborer la SRT;
• décrire les activités de vérification de la portée;
• décrire la manière dont la portée du projet sera contrôlée.

La portée est définie puis améliorée au cours d'un processus itératif qui commence à l'étape d'identification du projet et qui s'étend à l'étape de réalisation. Ce processus est mené en collaboration avec les experts en la matière et les intervenants, et devient de plus en plus précis au fil du projet. Une fois la portée du projet entièrement définie, elle comportera les éléments suivants :

• les buts, les résultats opérationnels et les objectifs du projet;
• la description de la portée du produit;
• les limites du projet;
• les activités particulièrement exclues;
• les produits livrables et les critères d'acceptation connexes;
• les contraintes du projet;
• les hypothèses du projet.

Processus de gestion de la portée en fonction des étapes et des phases du SNGP

Étape de début de projet

Phase de définition

Effectuer une première évaluation et documenter le besoin opérationnel ou l'occasion d'affaires dans un énoncé des exigences. À ce stade-ci, on n'élabore pas de portée globale et on ne nomme aucune solution. Il s'agit simplement de demander à la direction de fournir un financement de démarrage pour faire une analyse plus approfondie du problème.

Étape d'identification de projet

Phase de lancement

Établir un énoncé de la portée préliminaire globale dans le PPP, ainsi qu'une liste de jalons et de résultats proposés. Lors de l'étape de début, les exigences opérationnelles d'un projet sont définies et une vision opérationnelle souhaitée peut être documentée afin de traiter du besoin opérationnel ou de l'occasion d'affaires. La vision opérationnelle et les exigences opérationnelles forment le cadre selon lequel la portée du projet est principalement élaborée. Toutefois, certaines contraintes, comme les contraintes relatives aux coûts et au temps, peuvent limiter la portée.

Phase de la faisabilité

L'équipe de projet peut réaliser une analyse de la conjoncture afin d'examiner les solutions techniques possibles au problème opérationnel et de contribuer au processus d'évaluation de la faisabilité. Le rapport de la faisabilité contient toutes les options viables et toutes les activités globales éventuelles relatives à chacune de ces options. Ces dernières feront l'objet d'une analyse plus approfondie. Un document sur l'architecture conceptuelle de la solution est préparé pendant la phase de faisabilité. De plus, un document sur le concept de fonctionnement est préparé ou un document existant est amélioré de manière à représenter le fonctionnement de la solution une fois qu'elle sera mise en œuvre. Ces documents appuient le processus de définition de la portée.

Phase de l'analyse

Au cours de la phase de l'analyse, l'objectif relatif aux projets opérationnels appuyés par les TI est de préparer une analyse de rentabilisation qui contient une solution technique recommandée et un arrêté de projet qui comprend un énoncé global de la portée. La base de référence de la portée ainsi établie, elle sera contrôlée tout le long du cycle de vie du projet, au fil de l'évolution de ce dernier.

Afin de préparer l'analyse de rentabilisation et l'arrêté de projet, l'approche relative aux projets opérationnels appuyés par les TI comprend les activités suivantes :

• améliorer la portée globale;
• créer une SRT globale;
• vérifier la portée globale;
• contrôler la portée.

L'étape d'identification vise à contrôler la portée des activités nécessaires à l'élaboration d'un rapport de la faisabilité, des documents techniques à l'appui et de l'analyse de rentabilisation. Si la solution est approuvée, un arrêté de projet est préparé. L'analyse de rentabilisation et l'arrêté de projet doivent être joints à la présentation au Conseil du Trésor.

Le contrôle de la portée une fois l'approbation préliminaire de projet (APP) obtenue comprendra le contrôle de la portée de la gestion de projet, le contrôle de la portée du produit ainsi que le contrôle de la portée de la transformation des activités.

Voici une description détaillée des activités relatives à la portée :

1. Améliorer la portée : La préparation d'un énoncé de la portée détaillé est essentielle à la réussite du projet et se fonde sur les principaux produits livrables et sur les principales hypothèses et contraintes qui avaient été exposées dans le PPP, et précisées davantage dans les sections de l'arrêté de projet qui portent sur l'énoncé de la portée de base, les jalons et les produits livrables décrits.
2. Une fois achevée, la portée du projet regroupera à la fois la portée du produit et la portée du projet. La portée du produit comprend les caractéristiques et les fonctions du produit, du service ou du résultat qui doit être fourni. La portée du projet comprend les tâches qui doivent être effectuées afin de fournir un produit, un service ou un résultat qui présente les caractéristiques et les fonctions attendues.
3. Créer la SRT : le gestionnaire de projet divise la portée totale du projet en parties plus petites et plus faciles à gérer qu'on appelle « blocs de tâches », et ce sont ces blocs qui forment la SRT. Plus on descend de niveaux dans la SRT, plus les définitions des travaux relatifs au projet sont détaillées.
4. Vérifier la portée : la vérification de la portée permet aux intervenants d'approuver officiellement la portée du projet au moyen d'examens des produits livrables effectués pour vérifier que les éléments faisant partie de la portée à cette phase du projet ont été réalisés de manière satisfaisante. Elle permet également de s'assurer qu'il n'y a pas de glissement de portée, et s'effectue conjointement avec une évaluation des répercussions sur les coûts et l'échéancier. Un glissement de portée se produit lorsque des caractéristiques et des fonctions sont ajoutées sans tenir compte de leurs répercussions sur l'échéancier, les coûts ou les ressources, ou sans l'approbation du client.
5. La base de référence de la portée du projet est approuvée à l'étape de l'APP, puis la portée est définie complètement au cours de la phase de la planification de l'étape de réalisation. Le contrôle de la portée est effectué durant les phases de conception et de mise en œuvre. Les changements proposés et approuvés sont gérés au moyen du processus de gestion des changements.
6. Remarque : la gestion des changements est le processus qui consiste à contrôler les changements apportés à l'infrastructure, aux processus, aux produits livrables ou à tout autre aspect des services, de manière contrôlée, afin d'exécuter les changements approuvés avec le moins de perturbations possible.

Phase de la clôture de l'étape d'identification

La phase de la clôture de l'étape d'identification vise à garantir que le nécessaire a été fait en ce qui concerne l'appréciation, l'établissement de rapports, l'évaluation, le transfert et la clôture administrative. Une clôture officielle doit fournir assez de renseignements directionnels au gestionnaire de projet (organisation chargée de la réalisation) pour qu'il procède sans heurt à l'étape de réalisation.

À la suite de l'APP, obtenue pendant la phase d'analyse, les équipes de projet s'assureront que le plan de projet définitif préparé pendant la présente phase comprend l'énoncé de la portée et la SRT globale.

Étape de réalisation de projet

Phase de la planification

Au cours de la phase de la planification, on établit complètement la portée, dont la base de référence avait été définie précédemment, et des blocs de tâches sont conçus. Ceux-ci contiennent toutes les activités de gestion de projet et de réalisation de produits qui doivent être menées.

Durant la phase de la planification, la gestion de la portée dans le cadre de projets opérationnels appuyés par les TI comprend une récapitulation des activités suivantes, mais une récapitulation beaucoup plus détaillée que précédemment. Les équipes de projet doivent :

• améliorer la portée;
• créer la SRT;
• vérifier la portée;
• contrôler la portée.

D'autres exemples de produits relatifs à la portée sont les exigences fonctionnelles et non fonctionnelles et le document relatif à l'architecture logique. Durant la phase de la planification, le concept de fonctionnement est mis à jour de manière à rendre compte de la vision plus détaillée de la solution d'affaires. Une ébauche de plan de transition est outre préparée, et décrit :

• la manière dont l'organisation et l'équipe de projet lanceront la production des produits et des processus définitifs;
• la manière dont les processus opérationnels actuels et futurs seront maintenus au cours du projet, et après celui-ci.

Phase de la conception

Durant la phase de la conception, le document sur l'architecture logique est de nouveau mis à jour afin de refléter la conception de l'architecture physique. Un plan de migration est ensuite rédigé afin d'indiquer de quelle façon les éléments existants seront intégrés à l'architecture d'entreprise en tant que produits et processus finaux.

Lors de l'élaboration et de la mise à jour de ces produits, il est essentiel d'effectuer une vérification de la portée et de mener des activités de contrôle.

La vérification de la portée diffère du contrôle de la qualité, car elle est principalement axée sur l'acceptation de la conception, qui se rapporte à la portée, alors que le contrôle de la qualité porte surtout sur le respect des exigences de qualité établies pour les produits livrables. De façon générale, le contrôle de la qualité est réalisé avant la vérification de la portée, mais il est possible que les deux activités soient menées en parallèle. Une vérification de la portée est effectuée après chaque phase ou jalon important du projet.

La portée définitive du projet est approuvée au point de vérification de l'approbation définitive de projet (ADP).

Phase de la mise en œuvre

Durant la phase de la mise en œuvre, des changements supplémentaires à la portée peuvent être proposés par suite d'essais ou d'activités de contrôle de la qualité. Voici les changements qui doivent être approuvés et dont la mise en œuvre doit être contrôlée.

Contrôle de la portée : les changements apportés à la portée peuvent avoir des répercussions sur les coûts, le calendrier et la qualité. Le contrôle de la portée est un processus utilisé dans le cadre de projets opérationnels appuyés par les TI afin de s'assurer que les changements éventuels à la portée sont examinés attentivement, de manière à déterminer la raison, la justification, la valeur et les répercussions de chacun d'eux. Les changements doivent être approuvés au moyen du processus de gouvernance décrit dans l'arrêté de projet et gérés conformément au processus de gestion du changement, qui est habituellement exposé dans le plan de gestion de projet.

Phase de la clôture de l'étape de réalisation

Lorsque le projet est achevé, l'équipe de projet prépare le document de clôture de projet, dont les leçons apprises, et réalise les activités administratives et les activités de clôture du contrat, et consigne le processus de façon approfondie. La SRT et tout autre document complémentaire relatif à la gestion de la portée, comme le registre des changements lié au plan de gestion de la portée, doivent être mis à jour de manière à résumer tous les changements à la portée qui ont été proposés. Si un changement a été approuvé, le registre décrit les activités de mise en œuvre et les conséquences du changement en question.

6. PORTÉE :

Le présent domaine de connaissances de la gestion de la portée s'applique à TOUS les projets opérationnels appuyés par les TI de TPSGC.

7. DÉFINITIONS :

Plan de gestion de la portée du projet

Le plan de gestion de la portée du projet décrit la manière dont la portée du projet sera définie, élaborée et vérifiée, ainsi que la manière dont la SRT des travaux sera créée et définie. Source : Guide du corpus des connaissances en management de projet (Guide PMBOK®)

Énoncé de la portée du projet

Il s'agit d'une description narrative de la portée du projet, dont les principaux produits livrables, les objectifs, les hypothèses et les contraintes du projet et un énoncé des travaux, qui constitue un fondement documenté pour la prise de décisions dans le cadre du projet, et qui permet d'assurer ou d'établir une compréhension commune de la portée du projet chez les intervenants. Source : Guide PMBOK®

Portée

La portée d'un projet est la somme des produits et des résultats réalisés ainsi que des services offerts dans le cadre du projet en question. La portée comprend les tâches devant être accomplies afin de fournir un produit, un service ou un résultat qui présente les caractéristiques et les fonctions attendues. Source : Guide PMBOK®

Structure de répartition du travail

Il s'agit d'une décomposition hiérarchique du travail axée sur les produits livrables qui doit être effectuée par l'équipe de projet afin d'accomplir les objectifs du projet et de générer les produits livrables nécessaires. Elle organise et définit la portée totale du projet. Plus on descend de niveaux dans la SRT, plus les définitions des travaux relatifs au projet sont détaillées. La SRT se divise en blocs de tâches. Cette orientation vise à la fois les produits livrables externes et les produits livrables internes. Source : Guide PMBOK®

Bloc de tâches

Il s'agit du niveau le plus bas de la SRT. Regroupés, les blocs de tâches constituent toutes les tâches nécessaires à la réalisation des objectifs du projet. Un bloc de tâches ne devrait pas représenter plus de 10 % du coût ou de la durée du projet. Sa responsabilité devrait incomber à une seule personne. Source : Guide PMBOK®

8. RESPONSABILITÉS :

On encourage fortement toutes les parties responsables de l'élaboration des plans de gestion de la portée à consulter les autres chefs de projet et gestionnaires de projet ainsi que les gestionnaires principaux de projet au moment de rédiger le plan de gestion de la portée. On recommande également aux gestionnaires de projet de demander des conseils aux experts techniques et à d'autres experts en la matière et d'examiner les données historiques de projets semblables réalisés à TPSGC et les leçons apprises dans le cadre de ces projets, lorsqu'ils produiront ou mettront à jour la SRT, les calendriers et les plans.

Chef de projet (aspect opérationnel)

Le chef de projet ou le directeur de projet définit les besoins opérationnels ou les occasions, dirige les activités de l'étape d'identification et représente le client pendant la réalisation. Plus particulièrement, ses responsabilités sont les suivantes :

• planifier, contrôler et assurer une surveillance générale de la gestion du projet conformément au cadre du SNGP pour les projets opérationnels appuyés par les TI;
• établir l'orientation générale et les priorités du projet;
• autoriser tous les documents de planification;
• examiner et approuver l'arrêté de projet;
• approuver le plan de gestion de projet et d'autres produits livrables;
• assumer la responsabilité des budgets;
• faire des recommandations quant aux principaux changements qui auront une incidence sur la portée, l'échéancier et les coûts;
• approuver les changements qui n'auront pas d'incidence sur les jalons fermes et les coûts;
• surveiller les progrès;
• affecter des ressources ou approuver des affectations;
• assurer la liaison avec le comité directeur du projet;
• agir à titre de principal interlocuteur entre l'équipe responsable des activités et l'équipe de projet;
• assumer la responsabilité des activités d'approvisionnement dans le cadre du projet (ou déléguer cette tâche à un gestionnaire de l'approvisionnement).

Gestionnaire de projet

Le gestionnaire de projet est responsable de l'ensemble de la gestion de la portée du projet. Plus particulièrement, ses responsabilités sont les suivantes :

• élaborer le plan de gestion de la portée et s'assurer que l'équipe de projet connaît les processus et les suit lorsqu'elle exerce ses responsabilités;
• élaborer l'énoncé de la portée;
• obtenir l'avis des intervenants sur la portée du projet et du produit;
• documenter la portée du projet;
• créer la SRT;
• vérifier la portée du projet;
• contrôler la portée du projet;
• rendre compte de la portée du projet.

Promoteur du projet

Le promoteur de projet est responsable des activités suivantes :

• contribuer à l'analyse de la portée et au processus de définition;
• appuyer le gestionnaire de projet dans l'élaboration de l'énoncé de la portée;
• approuver la base de référence de la portée et tous les changements importants apportés à la portée.

Équipe de projet

L'équipe de projet doit exécuter les tâches suivantes :

• contribuer à l'analyse de la portée et au processus de définition;
• appuyer le gestionnaire de projet dans l'élaboration de l'énoncé de la portée et du plan de gestion de la portée;
• élaborer et tenir à jour les documents relatifs au projet et les produits livrables qui comprennent la portée du projet entièrement élaborée;
• effectuer les tâches qui lui sont assignées sans s'éloigner de la portée approuvée;
• présenter, au besoin, des demandes de changement qui pourraient avoir des répercussions sur la portée.

Analyste des exigences

L'analyste des exigences est responsable des activités suivantes :

• tenir à jour une matrice de toutes les exigences approuvées;
• assurer la coordination avec les centres d'expertise;
• participer au processus de contrôle des changements apportés aux exigences;
• indiquer les changements dans la matrice des exigences;
• tenir un registre des modifications apportées aux exigences.

Analyste des activités

L'analyste des activités est responsable des activités suivantes :

• regrouper les exigences opérationnelles, fonctionnelles et non fonctionnelles;
• élaborer les documents relatifs aux exigences opérationnelles, fonctionnelles et non fonctionnelles.

Analyste des systèmes

L'analyste des systèmes est responsable des activités suivantes :

• définir les exigences du système;
• élaborer les spécifications des exigences du système en fonction des exigences fonctionnelles et non fonctionnelles;
• effectuer les mises à l'essai et l'intégration des fonctions de manière à respecter les spécifications des exigences du système.

Équipe technique

L'équipe technique est responsable des activités suivantes :

• élaborer les spécifications techniques et les plans;
• effectuer les mises à l'essai et l'intégration des fonctions de manière à respecter les spécifications techniques.

Gestionnaire de la qualité

Le gestionnaire de la qualité est responsable des activités suivantes :

• vérifier le produit livrable afin de s'assurer qu'il répond aux exigences approuvées;
• consigner les résultats de la vérification des exigences dans un rapport sommaire d'essai de système.

Intervenants et experts en la matière

Les experts en la matière sont responsables des activités suivantes :

• contribuer à l'analyse de la portée du projet et au processus de définition;
• appuyer le gestionnaire de projet dans l'élaboration de l'énoncé de la portée et du plan de gestion de la portée.

9. RÉFÉRENCES :

• Énoncé des exigences (EE)
• Outil de sélection de projet
• Plan préliminaire de projet, Version « complète »
• Plan préliminaire de projet, Version « allégée »
• Rapport de la faisabilité (RF)
• Plan de gestion des projets
• Analyse de rentabilisation, Version « complète »
• Analyse de rentabilisation, Version « allégée »
• Guide sur l'analyse de rentabilisation du SCT
• Arrêté de projet, Version « complète »
• Arrêté de projet, Version « allégée »
• Guide de l'arrêté de projet du SCT
• Demande de changement
• Registre des demandes de changement

10. PIÈCES JOINTES :

Annexe A - Processus de gestion des exigences

11. DEMANDES DE RENSEIGNEMENTS :

Veuillez adresser toute demande de renseignements relative au présent domaine de connaissances au directeur, Centre d'excellence, Bureau d'exécution des projets, Direction générale des services d'infotechnologie.

Annexe A - Processus de gestion des exigences

Introduction à la gestion des exigences

Contexte

La gestion des exigences est un processus itératif visant à définir les exigences opérationnelles, fonctionnelles, non fonctionnelles et techniques afin de concevoir, d'élaborer, de mettre en œuvre et d'entretenir un produit tout le long de son cycle de vie. Pour être efficace, la gestion des exigences doit prendre en compte les changements qui peuvent être apportés aux plans, aux concepts et aux produits à chaque étape du projet, jusqu'à la mise en œuvre du produit.

Le processus de gestion des exigences établit une base de référence à partir de laquelle on élabore une solution sur mesure, acquiert et intègre un logiciel commercial ou conçoit différemment les processus opérationnels sans avoir recours à un élément technologique. La gestion des exigences permet de s'assurer que les plans, les produits et les activités respectent les exigences et qu'ils répondent au besoin opérationnel.

L'objectif est de s'assurer que les exigences sont traçables et que les changements sont gérés de manière uniforme.

L'objectif du processus de gestion des exigences du projet est de documenter la manière dont les exigences du client doivent être regroupées, consignées, gérées, modifiées et rapprochées en vue de la livraison finale de la solution technique du produit.

Dans le cas de petits projets, le processus de gestion des exigences est décrit dans le plan de gestion de projet. Dans le cas de projets plus importants et plus complexes, il peut s'avérer nécessaire de préparer un plan de gestion des exigences distinct.

Objectif

L'objectif de la gestion des exigences consiste à fournir une méthode permettant de :

• déterminer la portée de ce qui est géré;
• déterminer les rôles et les responsabilités des parties qui participent au présent processus;
• déterminer la manière dont les exigences seront consignées, suivies et modifiées;
• déterminer les outils qui seront utilisés.

Rôles et responsabilités

Gestionnaire de projet

Le gestionnaire de projet est responsable de l'ensemble de la gestion des exigences. Plus particulièrement, ses responsabilités sont les suivantes :

• s'assurer que l'équipe du projet connaît et suit le plan, les processus décrits dans ce dernier et les responsabilités connexes;
• examiner et approuver le plan de gestion des exigences;
• s'assurer que la gestion des exigences est conforme aux processus de gestion du changement;
• communiquer les répercussions sur les exigences aux clients;
• négocier les modifications aux exigences, au besoin;
• rendre compte des activités relatives aux exigences.

Analyste des exigences

L'analyste des exigences est responsable des activités suivantes :

• tenir à jour une matrice de toutes les exigences approuvées;
• assurer la coordination avec les centres d'expertise;
• participer au processus de contrôle des changements apportés aux exigences;
• indiquer les changements dans la matrice des exigences;
• tenir un registre des modifications apportées aux exigences.

Analyste des activités

L'analyste des activités est responsable des activités suivantes :

• regrouper les exigences opérationnelles, fonctionnelles et non fonctionnelles;
• élaborer les documents relatifs aux exigences opérationnelles, fonctionnelles et non fonctionnelles.

Analyste des systèmes

L'analyste des systèmes est responsable des activités suivantes :

• définir les exigences du système;
• élaborer les spécifications des exigences du système en fonction des exigences fonctionnelles et non fonctionnelles;
• effectuer les mises à l'essai et l'intégration des fonctions de manière à respecter les spécifications des exigences du système.

Équipe technique

L'équipe technique est responsable des activités suivantes :

• élaborer les spécifications techniques et les plans;
• effectuer les mises à l'essai et l'intégration des fonctions de manière à respecter les spécifications techniques.

Gestionnaire de la qualité

Le gestionnaire de la qualité est responsable des activités suivantes :

• vérifier le produit livrable afin de s'assurer qu'il répond aux exigences approuvées;
• consigner les résultats de la vérification des exigences dans un rapport sommaire d'essai de système.

Expert en la matière

Les experts en la matière sont responsables des activités suivantes :

• contribuer au processus d'analyse des exigences;
• appuyer l'équipe technique dans l'élaboration des documents sur les spécifications, les mises à l'essai et les autres aspects de la solution technique.

Processus de gestion des exigences

Le processus de gestion des exigences commence durant l'étape d'identification du projet, lorsqu'on détermine les besoins opérationnels et qu'on définit les exigences opérationnelles. Après l'obtention d'une APP pour la solution privilégiée, de plus amples analyses sont effectuées. Les exigences globales deviennent progressivement plus précises et plus détaillées au cours des phases de planification et de conception. Il en résulte un document sur les spécifications très détaillé et une matrice de traçabilité, qui seront utilisés par l'équipe technique au moment d'élaborer la solution, et de la mettre à l'essai, au cours de la phase de mise en œuvre. Afin de gérer les changements au cours des phases de planification et d'exécution, le processus de gestion des exigences est lié au processus de gestion des changements.

Le processus de gestion des exigences du projet regroupe les activités suivantes :

• définir les exigences;
• évaluer les exigences;
• valider les exigences et les classer par ordre de priorité;
• obtenir l'approbation et établir la base de référence;
• analyser et préciser les exigences;
• contrôler les changements apportés aux exigences.

Figure 1 - Processus de gestion des exigences

Une version agrandie du diagramme - Processus de gestion des exigences, est disponible sur une page séparée.

Étape d'identification de projet

Durant l'étape d'identification, les divers intervenants expriment leurs besoins lors de réunions. Ces besoins deviennent ensuite des exigences globales et sont approuvés par le client ou par le comité directeur du projet.

Définir les exigences

Le client approuve la liste des principaux intervenants auxquels l'équipe de projet s'adressera pour connaître ses besoins. En fonction de cette liste, l'analyste des activités du projet détermine les besoins du client au moyen des techniques d'enquête appropriées (p. ex., entretiens, séances d'élaboration d'application en collaboration, ateliers ou réunions). Les besoins déterminés par les intervenants sont ensuite analysés, puis évalués afin de déterminer les exigences globales. Les processus, les procédures et les guides opérationnels existants de même que les études antérieures seront examinés afin de déterminer d'autres exigences globales.

De la même manière, toutes les politiques, les lois et les règlements sur lesquels le projet pourrait avoir des répercussions seront ciblés afin de déterminer les exigences globales, puis saisis dans un document au cours de la phase de faisabilité.

Les incohérences et les conflits parmi les exigences des intervenants seront traités dans le cadre d'un processus de négociation avec les intervenants concernés. Toutes les exigences globales sont consignées dans le document sur les exigences opérationnelles (et dans la matrice de traçabilité des exigences qui sera créée après l'approbation par client (APP)).

Évaluer les exigences globales

Chaque exigence globale est évaluée par l'analyste des activités en collaboration avec le client ou avec un expert en la matière, selon les critères mentionnés ci-dessous, afin de vérifier qu'elle contribue à l'élaboration du produit.

• Correcte - L'exigence sera respectée par le système ou par un de ses composants. L'exigence n'est pas en conflit avec une autre exigence.
• Nécessaire - L'exigence représente une capacité, une caractéristique physique ou un facteur de qualité essentiel. Si l'exigence était supprimée, le produit aurait une lacune inacceptable.
• Claire - L'exigence est énoncée de manière à ce qu'il n'y ait aucune ambiguïté. En d'autres mots, l'exigence est définie de façon à ce qu'il n'y ait qu'une seule interprétation possible.
• Réalisable - L'exigence est réalisable dans l'environnement actuel et peut être réalisée dans le respect du budget, du calendrier et des autres contraintes du projet.
• Traçable - L'origine de l'exigence est claire et il est possible de la relier à d'autres produits.

L'analyste des activités corrigera, reformulera et mettra à jour la description des lacunes contenue dans le document sur les exigences opérationnelles.

Valider les exigences et les classer par ordre de priorité

Une équipe d'intervenants valide les exigences globales. Le plan de gestion des exigences contient un échantillon représentatif d'intervenants et le nom de ceux qui participeront à l'exercice de validation. La liste des participants peut comprendre tous les intervenants, des représentants de ceux-ci, ou seulement les principaux intervenants.

Une fois validées, les exigences seront classées par ordre de priorité selon les catégories suivantes : « essentiel », « important » ou « utile ». (Se reporter aux Critères d'attribution des priorités ci-dessous).

La validation et le classement par ordre de priorité des exigences peuvent s'effectuer lors de réunions de groupe, par exemple.

La priorité approuvée de chaque exigence sera consignée dans la matrice de traçabilité des exigences qui sera créée au cours de l'activité suivante.

Le gestionnaire de projet vérifie avec le promoteur que les exigences globales représentent bien les besoins ciblés par les intervenants.

Critères d'attribution des priorités

Essentiel

Caractéristiques essentielles. Si une caractéristique essentielle n'est pas intégrée, le système ne répondra pas aux besoins du client. Toutes les caractéristiques essentielles doivent être intégrées à la version, autrement le calendrier ne sera pas respecté.

Important

Caractéristique importante afin d'assurer l'efficacité et l'efficience du système pour la plupart des applications. Cette fonction ne peut pas être facilement assurée d'une autre manière. Si une caractéristique importante n'est pas intégrée, cela pourrait avoir des répercussions sur le degré de satisfaction de l'utilisateur ou du client, ou même sur les recettes. Le déploiement de la version ne sera toutefois pas retardé pour autant.

Utile

Caractéristique qui peut s'avérer utile en dehors des applications types ou pour laquelle il existe des solutions de rechange raisonnablement efficaces. On ne s'attend pas à ce qu'il y ait des répercussions importantes sur les recettes ou sur le degré de satisfaction du client si la caractéristique n'est pas intégrée à la version.

Obtenir l'approbation et établir la base de référence

On demande au client d'approuver les exigences opérationnelles globales, afin d'en garantir la compréhension commune. Les exigences approuvées formeront la base de référence aux fins de planification de projet. Tout autre changement sera apporté selon le processus de gestion des changements.

Après avoir obtenu l'approbation du client, l'équipe de projet crée la matrice de traçabilité des exigences durant la phase d'analyse.

Voici les champs que comportera la matrice de traçabilité des exigences au départ :

• identificateurs uniques pour chaque exigence globale;
• identificateurs des besoins des intervenants (optionnel);
• énoncés globaux décrivant les besoins des intervenants;
• type d'exigence (se reporter à la section Analyse des exigences);
• ordre de priorité de l'exigence (remarque : il ne s'agit pas de la même chose que l'ordre de priorité établi par les intervenants, mais plutôt de l'ordre établi par le comité directeur du projet);
• vérifié - un champ servant à indiquer qu'une exigence a été vérifiée (les données saisies dans ce champ pourraient être « Oui » ou « Non », ou une date);
• d'autres champs seront ajoutés au besoin.

Étape de réalisation de projet

Phase de planification

Durant la phase de planification, après que le projet eut obtenu l'APP, le gestionnaire de projet évalue l'analyse de rentabilisation, l'arrêté de projet et les exigences opérationnelles globales préparées au cours de l'étape d'identification. Au cours de la présente phase, les exigences sont précisées davantage et les changements sont contrôlés. Des documents relatifs aux exigences fonctionnelles et non fonctionnelles et aux spécifications des exigences du système sont préparés et les documents relatifs à la matrice de traçabilité des exigences sont mis à jour.

Analyser et préciser les exigences

Au cours de la phase de la planification, les exigences globales sont classées en tant qu'exigences fonctionnelles ou non fonctionnelles du système. Au cours de la phase de conception, des exigences détaillées sont élaborées à partir de ces exigences globales. Les exigences du système forment une description exhaustive de l'objectif et de l'environnement visés du processus opérationnel, du logiciel ou de l'infrastructure en cours d'élaboration. Les exigences fournissent une description complète des tâches que le processus, le logiciel ou l'infrastructure accomplira, et du rendement attendu de cette solution.

• Les exigences fonctionnelles définissent le comportement attendu d'un système (fonctionnalité). Ce comportement s'exprime sous forme de services que le système doit offrir, de tâches qu'il doit accomplir ou de fonctions qu'il doit posséder. On le représente le plus souvent sous la forme d'énoncés déclaratifs ou de cas d'utilisation.
• Les exigences non fonctionnelles définissent les contraintes auxquelles le nouveau logiciel doit se plier. Ces exigences ne décrivent pas les tâches que le système doit accomplir, mais plutôt la qualité de celles-ci. Les exigences non fonctionnelles comprennent notamment la convivialité, la portabilité, l'accessibilité, la confidentialité, la fiabilité, la disponibilité, l'efficience, l'intégrité, la sûreté, la sécurité, la robustesse, le rendement, la testabilité, la maintenabilité et la réutilisabilité.
• Les exigences seront consignées dans le document sur les exigences fonctionnelles, le document sur les exigences non fonctionnelles et la matrice de traçabilité des exigences mise à jour. Les problèmes soulevés au cours de l'analyse des exigences qui pourraient entraîner la modification de politiques existantes sont consignés dans le document sur les exigences relatives à la modification de politiques.

Chaque exigence est précisée davantage afin d'obtenir des exigences précises et bien définies. Une exigence bien construite doit être réalisable et mesurable, doit pouvoir être mise à l'essai, doit être attribuable à un des besoins opérationnels ciblés, et doit être suffisamment détaillée pour permettre l'actualisation de la conception du système.

Des vérifications planifiées des exigences suivront le processus de gestion de la qualité. Au cours de la vérification des exigences, l'équipe de projet, en collaboration avec l'équipe technique, s'assurera que les exigences fonctionnelles et non fonctionnelles représentent bien la totalité des exigences opérationnelles.

Les exigences qui ne respectent pas les normes de vérification seront corrigées avant l'activité suivante.

Avant de passer à l'étape de conception, le client doit approuver les exigences détaillées afin de garantir une compréhension commune de celles-ci. Ensuite, la matrice de traçabilité des exigences sera également mise à jour de manière à y inclure les exigences détaillées.

Les exigences détaillées sont consignées dans la section appropriée de la matrice de traçabilité des exigences. La matrice de traçabilité des exigences sera également mise à jour de manière à y inclure les exigences détaillées. Voici les attributs supplémentaires qui devront être utilisés au besoin :

• Sous-système (facultatif - lorsque des changements sont apportés à un système existant dont les sous-systèmes sont déjà connus - les exigences sont attribuables au sous-système).
• Effort relatif - l'effort nécessaire pour respecter l'exigence. Les lettres « É », « M » ou « F » devraient être utilisés pour indiquer si le niveau d'effort requis est élevé, moyen ou faible. Le niveau d'effort requis, qu'il soit élevé, moyen ou faible, dépend de la disponibilité des ressources qualifiées et des contraintes du projet.
• Cas d'utilisation (facultatif - afin d'éventuellement consigner les cas d'utilisation associés à l'exigence).
• Version (facultatif - afin d'éventuellement consigner la version dans laquelle l'exigence sera mise en œuvre).
• Cas type (facultatif - afin d'éventuellement consigner les cas types associés à l'exigence).

Spécifications (conception de produit)

L'analyste des systèmes se servira des exigences détaillées pour créer un document sur les spécifications des exigences du système. Les spécifications des exigences du système contenues dans le document doivent être suffisamment détaillées pour permettre l'élaboration et la mise à l'essai du produit. En d'autres mots, les spécifications détaillées doivent décrire clairement ce qui doit être fait et la manière dont ce sera fait :

• pour qu'un développeur puisse créer ce qui a été décrit;
• pour qu'un essayeur puisse ensuite mesurer le niveau de réussite ou d'échec du produit en ce qui concerne le respect des spécifications.

La matrice de traçabilité des exigences sera mise à jour de manière à contenir les spécifications des exigences du système.

Les vérifications planifiées des spécifications suivront le processus de gestion de la qualité. Au cours de la vérification de la conception, l'équipe de projet, en collaboration avec l'équipe technique, s'assurera que les spécifications des exigences du système correspondent aux exigences du système. Le gestionnaire technique, en collaboration avec le gestionnaire de projet, approuvera les spécifications.

Les spécifications qui ne respectent pas les normes de vérification seront corrigées avant l'activité suivante.

À l'ensemble des étapes et des phases du projet

Contrôle des exigences

Processus de gestion des changements

Le processus de gestion du contrôle des changements du projet servira à gérer les suppressions, les modifications et les ajouts apportés aux exigences, ainsi que les changements apportés au calendrier, aux coûts et aux ressources affectées.

Si de nouveaux besoins sont signalés après que la base de référence des exigences a été établie, les changements pouvant découler de ces besoins seront évalués au moyen du processus de gestion des changements, avant que des exigences soient ajoutées à la matrice de traçabilité des exigences. Une fois approuvées, les nouvelles exigences seront ajoutées à la base de référence d'origine. Cette dernière deviendra la nouvelle base de référence représentant les besoins des intervenants.

Traçabilité des exigences

L'équipe de projet entretiendra et contrôlera la relation entre chaque exigence et sa source dans la matrice de traçabilité des exigences, à l'usage des équipes de conception, d'élaboration, de mise à l'essai et de déploiement. Comme l'illustre le diagramme ci-dessous, un identificateur unique de spécification constitue un lien entre les exigences opérationnelles d'une part et les exigences fonctionnelles et non fonctionnelles, les spécifications de conception et les cas types d'autre part. La matrice de traçabilité des exigences regroupe tout autre document relatif aux exigences.

La traçabilité des exigences permet à l'équipe de projet de mieux comprendre l'incidence d'un changement (ou une demande de changement) apport à une exigence sur les autres exigences, en amont et en aval. Elle sera assurée de façon à ce que chaque fois qu'un changement est apporté à une exigence, toutes les exigences, les composants de logiciels et les cas types touchés par le changement soient ciblés.

L'équipe de projet suivra le modèle de traçabilité suivant :

Modèle de traçabilité

Figure 2 - Traçabilité des exigences

Une version agrandie du Modèle de traçabilité, est disponible sur une page séparée.

Techniques et outils de gestion des exigences

L'équipe de projet peut utiliser les moyens suivants pour établir des exigences :

• des séances d'élaboration d'application en collaboration;
• entrevues;
• des questionnaires d'enquête;
• des prototypes;
• des projets pilotes;
• tout autre moyen pertinent.

Comme la Figure 3 - Outil de gestion des exigences ci-dessous le montre, les exigences peuvent également provenir des résultats sommaires des essais et des demandes de changement transmises par des utilisateurs, et peuvent être approuvées dans le cadre des activités de gestion du changement.

La traçabilité sera assurée au moyen d'outils comme Rationale Requisite Pro.

L'outil de gestion des exigences permettra à l'équipe de projet de trouver, de consigner et d'organiser les changements apportés aux exigences du client, aux spécifications du logiciel et aux cas types, et de faire le suivi de ces changements.

Le diagramme ci-dessous illustre de quelle manière on peut utiliser un ensemble d'outils intégrés et leurs extensions pour gérer les exigences, les changements et les configurations dans le cadre d'un projet.

Outils intégrés de changements et de configuration des exigences

Figure 3 - Outil de gestion des exigences

Une version agrandie de l'Outil de gestion des exigences, est disponible sur une page séparée.