Logo ANAP
Ce site requiert l'activation de javascript pour être utilisé, merci de l'activer.
S'abonner

Méthode

Ressources associées

Personne ressource

Etienne MAUGET

 1175 vues

Cette activité préalable est indispensable. Elle consiste à

  • définir le concept et les objectifs du produit, 
  • définir le périmètre, ou champ de l’étude, 
  • identifier les parties prenantes 
  • décrire les exigences au plus haut niveau.

Par parties prenantes nous entendons toutes les personnes ou organisations impactées (positivement ou négativement) par l’introduction du système ou susceptibles d’influencer son choix, son développement ou son déploiement.

Définir les objectifs

Les objectifs du système (à choisir, à développer ou à mettre en œuvre) ne sont rien de plus que des exigences de haut niveau.

Les objectifs d’aussi haut niveau doivent être formulés avec le plus grand soin, puis validés au plus haut niveau hiérarchique possible.

Il est de première importance de préciser, sur une page maximum, en collaboration avec le donneur d’ordre, l’objectif à atteindre.

On peut formaliser l’objectif sous la forme 

  • finalité : le but à atteindre ; 
  • avantage : ce que cela apporte ; 
  • mesure : comment on saura, de manière chiffrée, que le but a été atteint.

Les techniques pour recueillir ces objectifs et besoins à haut niveau sont les réunions et les interviews. Il peut s’agir d’une réunion de lancement à l’initiative du donneur d’ordre, de réunions avec les représentants des utilisateurs, ou d’interviews individuelles.

Quand les rôles et responsabilités sont mal définis, que les objectifs ne sont pas clairs, l’interview est la technique la plus efficace.

Déterminer le domaine et le périmètre

Il s’agit de déterminer 

  • le domaine d’application : À qui et à quoi servira le futur système, et pour quoi faire ? 
  • quels sont les principaux acteurs : à qui servira le système ? Qui sera impacté ?

Le périmètre définit les limites du produit.

La définition du périmètre va permettre de clarifier les concepts, de découvrir des contraintes, de déterminer les parties prenantes et de préciser l’objectif.

On décrira le périmètre sous forme textuelle. Ce texte, qui devra faire l’objet d’un consensus entre toutes les parties prenantes, sera soumis à l’approbation formelle du donneur d’ordre.

Ce diagramme peut être utilisé pour décrire l’existant (diagramme de contexte métier) ou pour situer le futur système dans ses interactions avec le monde extérieur (diagramme de contexte produit).

Un diagramme de contexte est un diagramme de flux à un niveau très macroscopique, où le système à l’étude est au centre. Il peut être élaboré dès cette première étape, et affiné par la suite.

Analyser les parties prenantes

On appelle partie prenante (anglais, stakeholder) toute personne, ou organisation qui a un intérêt (positif ou négatif) dans le projet.

Les points à déterminer : 

  • Qui paye ? 
  • Qui va réaliser ? 
  • Qui va utiliser ? 
  • Qui va conduire le projet ? 
  • Qui va s’opposer au projet ?

On identifiera et formalisera dans un tableau 

  • les personnes ou profils concernés, 
  • leurs rôles, intérêts et objectifs dans l’organisation, 
  • leur rôle potentiel dans l’élaboration des cahiers des charges.

Liste des parties prenantes

Compléter la liste établie lors de la planification. À titre indicatif : 

  • le donneur d’ordres ou maîtrise d’ouvrage stratégique, ; 
  • la maîtrise d’ouvrage opérationnelle ; 
  • les utilisateurs ; 
  • l’assistant à maîtrise d’ouvrage ; 
  • les concepteurs, architectes, réalisateurs ; 
  • l’équipe de test et de validation ; 
  • les rédacteurs de la documentation du produit ;
  • les personnes du support technique ou fonctionnel ; 
  • le marketing du produit ; 
  • les juristes ; 
  • les organismes de normalisation (leurs représentants) ; 
  • les experts métier ; les experts techniques.

Le document de concept et objectifs

Il est utile de formaliser l’objectif, le champ de l’étude et le tableau des parties prenantes dans un document unique, le document de cadrage, qui est le livrable de la phase de préparation du processus. Il contiendra : 

  • le concept ; 
  • les objectifs ; 
  • les parties prenantes : rôles, responsabilités ; 
  • les catégories (classes) d’utilisateur ; 
  • les contours du futur produit et échanges avec l’extérieur : diagramme de contexte 
  • les cas d’utilisation métier (business use cases) dans leurs grandes lignes, par priorité ; 
  • les cas d’utilisation qu’on a décidé d’informatiser.

Une fois validé par les décideurs, ce document est un cahier des charges en condensé et pourra servir de préambule au cahier des charges. C’est aussi une aide à la gestion de projet. Il peut faire fonction de lettre de mission pour l’analyste.

Cependant, on il est possible se passer de document de cadrage : dans ce cas, toutes les informations recueillies seront directement rédigées dans les chapitres du cahier des charges prévus à cet effet (en pratique, les trois premiers chapitres).

Check-list

  • Les objectifs sont-ils clairement spécifiés ? 
  • A-t-on identifié, analysé et formalisé la liste des parties prenantes ? 
  • Les objectifs spécifiés sont-ils approuvés par les parties prenantes ? 
  • Les objectifs sont-ils réalistes, en termes de délais, de charge, de budget et aussi de risques ? 
  • A-t-on analysé les risques ? 
  • Y-a-t-il consensus entre parties prenantes sur le périmètre ? 
  • Le périmètre a-t-il été formellement approuvé par le donneur d’ordres ? 
  • Les parties prenantes se sont-elles engagées à participer ?
Cette réponse vous paraît-elle utile ?
Date de parution : 20/03/2017

Commentaires - Soyez le premier à déposer un commentaire

Pour ajouter un commentaire vous devez vous identifier

Vous êtes actuellement sur la page consacrée à Elaborer un cahier des charges (Méthode).

Vous êtes perdu ?

Haut de page

Vous êtes actuellement sur la page consacrée à Elaborer un cahier des charges (Méthode).

Vous êtes perdu ?