16 Janvier 2012

Plan de gestion des exigences - M-11

Maîtriser les exigences, leur traçabilité et le suivi de la validation et de la vérification

A. Objet

Le Plan de Gestion des Exigences détaille l'ensemble des activités prévues pour maîtriser les exigences du projet.

Il décrit la démarche mise en place par le projet pour assurer la formalisation des informations relatives aux exigences dont il est responsable.

Le cas échéant, ces activités sont à définir en réponse aux exigences formulées par le Client pour la gestion des exigences du projet. Sinon, elles sont définies et approuvées par le client, sur la base du « juste effort » conjointement évalué.

B. Principes d'élaboration

Le Plan de Gestion des Exigences est initié en début de phase A, avant l'écriture de la première spécification. Son contenu fait alors l'objet d'une discussion avec le client pour assurer la cohérence des processus de gestion des exigences chez les 2 partenaires. Il est finalisé en fin de phase A.

Les dispositions prises dans le Plan de Gestion des exigences doivent garantir la bonne exécution des objectifs suivants.

1. Prise en compte des exigences du Client du Projet

Le projet reçoit de son client un certain nombre de spécifications décrivant son besoin, avec dans le cas le plus simple une Spécification Technique de Besoin (cf. I-2), une Spécification Assurance Produit, voire une Spécification de Management.

Les exigences de besoin peuvent complétées d'exigences de définition d'Interface portant sur le produit attendu.

2. Caractérisation de la solution proposée

Au cours du développement, le projet va caractériser la solution technique sous la forme d'un produit en décrivant une architecture, des composantes, et leurs interfaces, des caractéristiques, des performances

Les exigences de définition du produit sont rédigées conformément aux préconisations du Plan de Gestion des Exigences. Elles sont liées aux exigences de besoin du client.

Par ailleurs, le projet se positionne lui-même en client s'il doit approvisionner un certain nombre de sous-ensembles. A ce titre, il émet des spécifications de besoin (STB des sous-ensembles, Spécifications AP applicables aux Fournisseurs, .) et des spécifications d'interface entre ces sous-ensembles.

Nota : tailoring d'un référentiel

Les meilleures pratiques des métiers du secteur spatial ont été spécifiées dans des référentiels (RNC, ECSS). Les exigences AP, de Management voire certaines exigences techniques sont produites par adaptation (ou « tailoring ») des exigences contenues dans ces référentiels.

Le Plan de Gestion des Exigences doit préciser les dispositions prises pour décrire les liens entre les exigences du projet et les exigences issues du référentiel utilisé, en particulier quand le projet va émettre des spécifications tailorées vers ses Fournisseurs.

3. Présentation au Client de l'état de conformité à ses exigences

En fin de phase C/D, le projet ayant réalisé à son niveau l'ensemble des activités prévues de validation et de vérification (analyses, simulations, essais, inspections, ...), ayant récupéré les Dossiers de Qualification (cf. I-13) de ses propres Fournisseurs et ayant consolidé à son niveau l'ensemble de ces informations, le produit est réputé qualifié.

Le projet est alors amené à se prononcer sur le statut de conformité de chaque exigence du Client.

C. Contenu type

1. Objet

Ce chapitre introduit les objectifs généraux et le périmètre des activités du Plan de Gestion des Exigences du projet.

En particulier, il décrit succinctement le produit concerné et le projet dans lequel il s'inscrit.

Exemple

1. Objet

Le présent document décrit l'organisation et les activités mises dans en place pour assurer la gestion et la traçabilité des exigences du projet « Instrument XXXX ».

L'instrument XXX comporte les 2 sous-ensemble suivants :

  • Sous-Ensemble 1...
  • Sous-Ensemble 2...

 

La maitrise d'ouvre de l'instrument XXX est assurée par le Laboratoire YYY, le Sous-Ensemble 1 étant réalisé par ce même Laboratoire, alors que le développement du Sous-Ensemble 2 sera confié à la société ZZZ.

 

2. Domaine d'application

Ce chapitre introduit les activités proposées pour la maîtrise des exigences du projet ainsi que les acteurs concernés et ce, tout au long de la vie du projet.

Exemple

1. Domaine d'application

Le document décrit :

  • les objectifs de maîtrise des exigences et de la conformité,
  • les informations manipulées,
  • l'outillage mis en ouvre,
  • l'interface avec la gestion de documentation et la gestion de configuration,
  • les modes d'échanges des informations avec les partenaires.

 

Les spécifications sont placées sous la responsabilité technique des divers responsables techniques du projet, l'ingénieur système étant garant des exigences de plus haut niveau.

Leur contenu est systématiquement approuvé par le chef de projet.

 

3. Documentation

3.1 Documents de référence

Ils constituent la bibliographie nécessaire à l'élaboration du Plan de Gestion des Exigences.

Exemple

3.1 Documents de référence

RNC-CNES-E-HB-10-504Contenu type de la STB
RNC-ECSS-E-ST-10Space engineering - General requirements
NASA/SP-2007-6105 Rev1Systems Engineering Handbook P. 279
INCOSE-TP-2110-006-01Guide for Writing Requirements

 

 

3.2 Documents applicatbles

Ce sont l'ensemble des documents applicables à l'élaboration du Plan de Gestion des Exigences.

Exemple

3.2 Documents applications

RNC-ECSS-E-ST-10-06Space engineering - Technical Requirements Specification
xxxxxxxFormat de la matrice de conformité du projet « Instrument XXX »
yyyyyyyFeuille de style WORD de saisie des spécifications du projet « Instrument XXX »
zzzzzzzSpécification de gestion de documentation du projet « Instrument XXX »
wwwwSpécification de gestion de configuration du projet « Instrument XXX »

 

 

3.3 Définitions

Ce paragraphe fournit la terminologie utilisée dans ce document.

Exemple

3.3 Définitions

ConformitéStatut définissant le niveau de satisfaction d'une exigence
Exigence de besoinExigence émise par le Client et caractérisant le besoin
Exigence d'IFExigence émise par le Client caractérisant la définition de l'interface entre 2 sous-ensembles du produit considéré
Exigence de définitionExigence émise par le Fournisseur caractérisant la solution technique, le produit
SpécificationCollection organisée d'exigences

 

 

3.4 Glossaire

Ce paragraphe fournit les sigles utilisés dans ce document.

Exemple

3.4 Glossaire

C/NC/PCConforme/ Non Conforme/Partiellement Conforme
IFInterface
SBSSystem Breakdown Structure (arbre de décomposition du produit)

 

 

4. Arbre produit et arbre des spécifications

Une spécification se rapporte à un voire plusieurs (pour les spécifications d'IF) éléments de l'arbre de décomposition du produit.

Les exigences de définition répondent aux exigences de besoin du Client ; toutes ces exigences se rapport au même élément de l'arbre produit.

De plus, les spécifications de besoin des sous-ensembles « raffinent » les spécifications de besoin du Client et des spécifications d'interface sont applicables à un certain nombre de sous-ensembles.

Ainsi toute nouvelle spécification produite par le projet est clairement identifiée et peut-être positionnée dans l'arbre des spécifications du projet.

Le projet doit donc s'approprier l'arbre de décomposition du produit et développer l'arbre des spécifications de son niveau de responsabilité.

Exemple

4. Arbre produit et arbre des spécifications

L'arbre produit relatif au projet est décrit dans le document [Réf. XXXX].

Les spécifications suivantes sont gérées par l'équipe projet :

  • STB de l'instrument XXX,
  • Spécification de définition de l'instrument XXX,
  • STB du Sous-Ensemble 1 de l'instrument XXX,
  • STB du Sous-Ensemble 2 de l'instrument XXX,
  • Spécification d'IF du Sous-Ensemble 1 et du Sous-Ensemble 2 de l'Instrument XXX
  • Spécification de définition du sous-ensemble de l'Instrument XXX,
  • Spécification AP applicable aux fournisseurs des Sous-Ensembles 1 et 2.

 

L'ensemble des spécifications gérées par le projet est organisé selon le graphe suivant :

GNS_FR_M11.jpg


 

 

5. Identification des exigences

5.1 Exigences et commentaires

Les exigences sont différenciées du reste du texte du document de spécification car elles seules porteront à terme un statut de conformité. Le libellé de chaque exigence est donc physiquement isolé du reste du texte et en particulier des commentaires informatifs donnés pour introduire son contexte, préciser une définition, ...

Par ailleurs, la rédaction d'une exigence obéit à un certain nombre de règles que l'on trouve dans des guides de « bonnes » pratiques (cf. documents de référence et documents applicables).

5.2 Numérotation et version des exigences

Chaque exigence portera un numéro ou « identifiant » unique dans le référentiel du projet, uniquement destiné à la repérer.

Le projet choisit a priori une règle de numérotation pour toutes ses exigences.

Par ailleurs, chaque exigence est accompagnée de l'indication de sa version, qui est incrémenté de 1 à chaque modification.

Exemple

5. Identification des exigences

Les exigences de la première version de chaque spécification du projet sont numérotées de 10 en 10, en partant de 10 et portent un préfixe permettant d'identifier la spécification à quelle elle se rapporte.

Exemple d'identification d'exigences : ZZZ-REQ-050

La renumérotation des exigences est interdite et les exigences nouvellement introduites portent un numéro quelconque non encore utilisé.

Pour la rédaction des libellés des exigences du projet, les « bonnes » pratiques spécifiées par l'ECCS en document applicable et explicitées par l'INCOSE en document de référence seront mises en ouvre.

 

6. Caractérisation des exigences

La définition du libellé d'une exigence est accompagnée de la définition d'un certain nombre de caractéristiques ou « attributs » qui permettront

  • l'identification de l'exigence,
  • la compréhension du libellé voire du contexte de l'exigence,
  • le renseignement du statut de conformité.

 

Il convient de définir les attributs qui seront renseignés par le projet.

En général, il est demandé de renseigner au minimum les attributs suivants : identifiant de l'exigence, version de l'exigence, libellé de l'exigence et statut de conformité, ainsi que, pour une exigence issue d'un tailoring du RNC, le numéro, la version et le statut de tailoring de l'exigence du RNC dont elle est issue.

De façon pratique, le projet définit un tableau donnant le nom et la définition de chaque attribut retenu.

Exemple

6. Caractérisation des exigence

Le tableau suivant définit la liste des attributs mis en ouvre pour la gestion des exigences du projet.

NomDéfinition
IdentifiantSuite de caractères unique non significative permettant de nommer l'exigence
VersionNuméro de 1 à N donnant la version de l'exigence
LibelléExpression textuelle de l'exigence
......

 

 

7. Outillage

7.1 Les outils de bureautique WORD et EXCEL

Les différents attributs relatifs aux exigences peuvent être saisis directement dans WORD et, à condition d'utiliser une feuille de style particulière, il est possible d'exporter automatiquement le contenu du document dans un outil dédié de gestion d'exigences. Cette feuille de style est à fournir par le Client.

L'applicabilité des exigences, en particulier pour les spécifications d'IF peut être indiquée par la production de matrice d'applicabilité donnant pour chaque exigence le ou les éléments de l'arbre produit sur lequel s'appliquent l'exigence.

7.2 Les outils de gestion d'exigences

Dans le cas de la mise en ouvre d'un outil dédié, le projet doit définir les activités de paramétrage de l'outil qui répondent aux exigences de gestion des exigences du Client.

Exemple

7. Outillage

Les spécifications sont gérées sous WORD.

A des fins de récupération des exigences par le Client, toutes les spécifications du projet sont saisies dans WORD sous la feuille de style donnée en document applicable.

 

8. Interface avec la gestion de documentation et la gestion de configuration

8.1 Gestion des exigences et gestion de la configuration

En début du projet, la gestion des versions d'exigences et de spécifications est limitée à la gestion des différentes versions des fichiers support des informations. Des sauvegardes sont fortement préconisées.

Ensuite, il est décidé de gérer des spécifications du projet en configuration. Pour les exigences sont au minimum gérées en configuration l'identifiant, la version et le libellé des exigences. Les règles de gestion de configuration s'appliquent alors de façon habituelle à ces contenus (gestion des Demandes de Modifications, mise en place des Commissions de Modification, ...).

A souligner que dans tous les cas, numérotation des exigences oblige, la granularité de gestion des modifications est au niveau des exigences élémentaires.

8.2 Gestion des exigences et gestion de la documentation

Quel que soit l'outil utilisé pour la gestion des exigences, une spécification au sens collection organisée d'exigences se traduit toujours par un document.

Les règles de gestion documentaire s'appliquent de façon habituelle aux documents de spécifications. Il convient simplement de gérer de façon cohérente les numéros des différentes versions des spécifications et les numéros des différentes éditions des documents.

Exemple

8. Interface avec la gestion de documentation et la gestion de configuration

Les règles de gestion de documentation décrites dans le document applicable « Spécification de gestion de documentation du projet « Instrument XXX » s'appliquent aux documents de spécifications.

Chaque version de spécification est repérée par un couple (numéro d'édition, numéro de révision) et un historique des modifications récapitulant les versions passées est inséré dans les pages liminaires du document.

Dès le prononcé de mise en gestion de configuration des premières spécifications, le projet met en place l'organisation nécessaire à la mise en ouvre des mécanismes de gestion de configuration décrits dans le document applicable « Spécification de gestion de configuration du projet « Instrument XXX ».

 

9. Modes d'échanges des informations avec les partenaires

Globalement, il s'agit pour le projet d'échanger avec ses partenaires - Client et Fournisseurs - des informations relatives aux exigences.

L'échange sous forme documentaire est incontournable car il est le seul admis au niveau contractuel. A cette fin, le projet utilise les documents de spécification gérés par le système de gestion de documentation du projet.

Pour les partenaires utilisant un outil dédié de gestion d'exigences, il est utile de définir des formats d'échange « standard »se présentant sous forme de tableaux.

De façon pratique, le projet utilisera un fichier au format Excel, en particulier pour la fourniture de la matrice de conformité (cf. FM-7) à la Spécification de Besoin du Client.

Exemple

9. Modes d'échanges des informations avec les partenaires

Le projet assurera la diffusion de ses spécifications à tous ses partenaires sous forme de documents WORD.

Le projet assurera la diffusion à son Client de la matrice de conformité à la Spécification de Besoin de l'Instrument XXX sous la forme d'un tableau EXCEL définis en document applicable.

 

Formulaires

Activités / documentation