01 53 63 37 87

certification PMI

fiche de connaissance

Fiche deuxième exemple plan type de définition des besoins

consulting formations PMP® simulateur PMP®

Deuxième exemple plan type de définition des besoins

Trouvez ici un deuxième exemple de plan type de définition des besoins. Cette fiche est mise à disposition des stagiaires Delf dans le cadre de nos formations en gestion de projet.

Utilisation :

  • Rédaction d’un cahier des charges
  • Description d’une analyse des besoins

Fiches complémentaires :

  • Autres Cahier des charges

Présentation :

Chaque rubrique est accompagnée d’un conseil de rédaction.

1.1 Historique du projet

Référence aux dossiers d'opportunité et de faisabilité.

Référence au PAQ associé au contrat de spécifications

1.2 Objectifs à atteindre, besoins à satisfaire

Reprise du dossier d'opportunité.

1.3 Positionnement et périmètre du projet

Reprise du dossier d'opportunité.

1.4 Axes d'évolution et enjeux

Reprise des dossiers de faisabilité (axes d'évolution) et d'opportunité (Enjeux).

1.5 Principes de base de la solution fonctionnelle retenue en étude de faisabilité

Ces principes sont récupérés du Dossier de Faisabilité. Le cas échéant, ils auront étés réactualisés / complétés d'éléments nouveaux issus :

Des demandes de réaménagement ou de compléments d’étude formulés en Faisabilité.

Des travaux de spécifications réalisés au cours de la présente étape.

1.6 Planning et budget du projet

Fournir ici la référence du contrat de spécifications, dans lequel figurent des informations relatives au planning et au budget global souhaité, tel qu'identifié à l'issue de l'étude de faisabilité.

Si l’application à réaliser fait partie d’un ensemble plus vaste de logiciels à livrer, décrire très succinctement les développements envisagés lors de l’étude de faisabilité, avec le calendrier de déploiement.

1.7 Risques / réserves éventuelles identifiés lors de la faisabilité

Reprendre ici les éléments de risque identifiés lors de la faisabilité au niveau de la solution et, sans que cela ne la remette en cause, les éventuelles réserves faites à son égard lorsque la faisabilité a été prononcée.

Réactualiser si nécessaire ces éléments à la date de lancement de l’étape de spécification.


2. Couverture organisationnelle de l’application à mettre en œuvre

Il s’agit de spécifier de façon exhaustive et détaillée les fonctionnalités attendues.

2.1 Métiers

Il s’agit de(s) domaine(s) d’activité(s), les activité(s), les flux (internes ou avec l’extérieur), les processus concernés par l’informatisation.

Ces informations sont récupérées à partir du dossier de faisabilité.

2.2 Types de sites

Il s’agit de lister de façon exhaustive les types de sites concernés par l’informatisation. Pour chaque type de site identifié, on précisera le nombre de sites impliqués.

Ces informations sont récupérées à partir du dossier de faisabilité.

2.3 Types d’acteurs

Il s’agit de lister de façon exhaustive les types d’acteurs (au sens poste de travail RH : facturier, comptable, accueil, ...) concernés par l’informatisation. Pour chaque type d’acteur identifié, on précisera le nombre d’acteurs impliqués.

Ces informations sont récupérées à partir du dossier de faisabilité.

2.4 Organisation du travail

Il s’agit de lister de façon exhaustive les tâches, procédures, organigramme type ... qui sont concernés par l'informatisation.

Ces informations sont récupérées à partir du dossier de faisabilité.


3. Les fonctionnalités de l’application à mettre en œuvre

Il s’agit de spécifier de façon exhaustive et détaillée les fonctionnalités attendues.

3.1 Liste des fonctionnalités

Description synthétique (quelques lignes) mais exhaustive des fonctionnalités à mettre en œuvre. Les fonctionnalités correspondent aux services que l'application doit rendre à l'utilisateur final, au vu des futures missions de ce dernier.

Ces fonctionnalités sont la raison d'être de l'application.

Cette description s’effectue à partir des éléments déjà identifiés au dossier de faisabilité.

Il convient d'identifier explicitement les fonctionnalités jugées fondamentales pour la MOA.

3.2 Positionnement dans l'organisation cible

Croisement fonctionnalité/métiers/types de sites/types d’acteurs/organisation du travail.

Il s’agit également de préciser de façon exhaustive, à partir de ce croisement, les contraintes de la future organisation du travail qui s’appliqueront à chaque fonctionnalité : fréquences d'utilisation, les plages horaires d'utilisation (en précisant les éventuels phénomènes de concentration (exemple :  tous les lundis matin, les utilisateurs vont solliciter la même fonctionnalité), nombre d’utilisateurs, dispersion géographique.

Cette description exhaustive s’effectue à partir des éléments déjà identifiés au dossier de faisabilité.

3.3 Enchaînements logiques des fonctionnalités

Description succincte (sous la forme d'un graphe) de la manière dont les différentes fonctionnalités de l’application s’enchaîneront logiquement les unes par rapport aux autres pour assurer au final le service attendu par l’utilisateur. Par exemple, pour assurer la facturation mensuelle des clients, l’application enchaînera les fonctionnalités suivantes :

Identification des clients présentant telle caractéristiques,

Récupération des informations X, Y et Z relatives aux commandes non encore facturées,

Calcul des montants, compte tenu des tarifs en vigueur et des droits à promotion,

Génération des bordereaux de facturation,

fourniture, pour impression, de l'ensemble des bordereaux constitués, triés par départements.

Remarques :

Il s'agit de décrire ici la logique de fonctionnement interne de l'application, du point de vue fonctionnel. L'enchaînement de ces fonctionnalités peut être entièrement automatisée ou bien nécessiter l'intervention de l'utilisateur. Dans ce cas, les principes de l'interface homme-machine à mettre en place sont décrit au paragraphe 5.

Le cas échéant, on précisera dans quelle mesure l'application dépend d'autres applications (génération d'un événement déclenchant ou service rendu).

3.4 Règles de gestion associées

Lister de façon exhaustive des règles de gestion associées aux fonctionnalités listées au paragraphe 3.1.

Les règles de gestion associées aux données manipulées (règle de calcul par exemple) sont quant à elles décrites au paragraphe 4.1.

Remarque : ces règles de gestion correspondent à celles que souhaitent mettre en place la MOA (et qui par ailleurs sont jugées faisables par la MOE) et celles qui s’imposent à elle, du fait par exemple des systèmes connexes ou de la législation en vigueur. Ces dernières doivent être bien distinguées.

3.5 Données manipulées

Les données dont on parle ici sont décrites en détail au paragraphe 4. Il s'agit uniquement d'associer chaque fonctionnalité avec les objets de gestion et les données qu'elle manipule (création, modification, suppression, lecture, copie).

Il convient d'identifier de façon particulière les fonctionnalités manipulant des données nominatives, afin de pouvoir les déclarer ensuite à la CNIL.


4. Données à gérer

4.1 Description sémantique des données et règles de gestion associées

Extrait du dictionnaire sémantique des données concernées, ainsi que les règles de gestion associées (calcul, mise à jour, contrôle, ...).

Ce dictionnaire est établi sur la base du dictionnaire sémantique des données déjà existantes. Il explicite fonctionnellement les données élémentaires associées à chaque objet de gestion concerné et qui présentent un intérêt pour la MOA.

Il s’agit également d’identifier les informations considérées par la MOA comme fondamentales.

Cette description s’effectue à partir des éléments déjà identifiés au dossier de faisabilité.

4.2 Données échangées

Ce paragraphe est le pendant du paragraphe 4.1 pour les données échangées avec d’autres applications, internes ou externes à la société. Il conviendra de préciser le mode (synchrone/asynchrone) et la périodicité de ces échanges.

4.3 Données de type référentiel

Ce paragraphe est le pendant du paragraphe 4.1 pour les données issues d'un référentiel. Il conviendra de préciser le mode (synchrone/asynchrone) et la périodicité des alimentations correspondantes.

4.4 Volumétrie

Préciser, pour chaque donnée, le nombre d'occurrences et son évolution dans le temps.

Le cas échéant, signaler explicitement les données pour lesquelles une forte variation de la volumétrie est possible, en fournissant la raison.

4.5 Historisation des données

Pour les données concernées : durée de rétention et procédure d'historisation à proprement parler (automatique sur la base de critères prédéfinis, manuel, ...).

Remarque : ce qui concerne le fait de savoir comment les données historisées/archivées doivent rester accessibles/récupérables est traité de façon explicite dans le paragraphe 6.3.


5. Interface utilisateur

Il s’agit ici de décrire de façon exhaustive les principes de communication entre l’utilisateur final et sa future application.

Cette description exhaustive pourra reprendre les éléments relatifs aux exigences ergonomiques identifiées au dossier de faisabilité.

Remarque : Ces différents éléments ont pu faire l'objet d'une maquette globale lors de l'étude de faisabilité. Au stade des spécifications, il peut être pertinent de recourir à une maquette détaillée, qui facilitera d'autant le processus de validation des spécifications (DFB + DCG).

5.1 Architecture du dialogue homme-machine

Il s'agit ici de décrire de façon exhaustive la logique d'accès des utilisateurs aux différentes fonctionnalités de la future application, telles qu'elles sont décrites au paragraphe 3 :

Accueil,

Navigation au sein de l'application (par les données ou par menus, la cinématique d'enchaînement des écrans pouvant être prédéterminée ou pas selon les types d'utilisateurs),

Exigences de la MOA relativement aux messages de confirmation, d'erreur, ...

Éventuelles interactions avec des systèmes connexes de type bureautique,

...

5.2 Aides

Il s’agit ici de préciser:

la liste des thèmes à aborder, le degré de précision des thèmes par cible, la définition de la structure des informations de l’aide générale,

le mode d'activation et de désactivation du système d'aide en ligne de l'application., les procédures d'accès à la documentation de l'application (papier ou électronique).

5.3 Éditions

Description des types de rapports nécessaires (finalité, destinataires, contenu, rupture (sous-totaux...), agrégations (niveau de détail), fréquence...), du mode d'activation et de désactivation, ...


6. Exigences vis-à-vis de l'application

Il s’agit de préciser ici toutes les informations qui sont indispensables à la MOE pour construire une solution totalement appropriée au besoin exprimé par la MOA.

Ces éléments d’information ont pu être évoqués en tout ou partie dans les paragraphes précédents mais sont ici présentés en tant que tels et de façon détaillée.

Remarque: s’il y des variantes locales, elles devront figurer dans ce paragraphe (ex: heure d’ouverture différente dans les DOM,..)

Ils reprennent des éléments déjà évoqués au dossier de faisabilité et sont en cohérence avec les facteurs de réussite exprimés lors de l’étude d’opportunité (pour ceux qui relèvent de l’informatique).

Ces exigences seront en toutes ou parties:

testées à l’occasion de la recette fonctionnelle,

inscrites dans le contrat de service. A ce titre, la maîtrise d’ouvrage précisera explicitement, au fil des paragraphes ci-dessous, les exigences de qualité de service qu’elle souhaite voir pris en compte dans le contrat de service ainsi que les indicateurs de mesure associés.

6.1 Contraintes liées aux futures conditions de travail

Il s’agit ici de préciser de façon exhaustive les éléments du futur environnement de travail qui devront être pris en compte par la future application.

Il peut s’agir par exemple :

- Dans le cadre d’une application de gestion de stocks, de la nécessite pour l’utilisateur de saisir les bordereaux de livraison tout en gardant ses gants et tout en restant sur le quai de chargement, même par temps de pluie.

Des contraintes relatives aux logiciels de services (réutiliser tel type d’imprimante, messagerie, etc… ...).

6.2 Niveau de performances

Expression, par la MOA, des temps de réponses et/ou débits (tant de factures par heures par exemple), de la variation des volumes (caractères saisonnier) à respecter, compte tenu des objectifs métier poursuivis et des résultats attendus en terme de performance (cf. paragraphe 1.4.2 du dossier d’opportunité).

6.3 Accès aux données historisées

Préciser de façon exhaustive, dans le cadre des fonctionnalités correspondantes, les règles d'accès aux données historisées. Dans le cas d'une historisation hors ligne, préciser quel type de procédure de récupération la MOA souhaite mettre en œuvre, compte tenu de la fréquence envisagée de ce type d’accès.

Remarque : Ces informations, combinées à celles fournies au paragraphe 4.5, permettront à la MOE de développement de concevoir la solution permettant de garantir que les données historisées seront toujours accessibles[1].

6.4 Niveau de visibilité sur les données

Préciser, pour des données qui sont logiquement indépendantes les unes des autres (issues de plusieurs bureaux par exemple) si certaines d'entre elles doivent être visibles (lecture/écriture) simultanément par tout ou partie des utilisateurs.

Selon le cas, ce genre de contrainte aura pour conséquence un regroupement physique de ces données ou la mise en place d'une solution donnant l'illusion qu'elles sont regroupées.

6.5 Niveau de sécurité

Cette sécurité découle de l’importance accordée par la MOA à certaines fonctionnalités et à certaines données de l’application, comme indiqué aux paragraphes 3.1 et 4.1.

Cette description exhaustive s’effectue à partir des éléments déjà identifiés au paragraphe 2.2.1.8 du dossier de faisabilité et d’une analyse fine des risques d’insécurité encourus, compte tenu de l’utilisation prévue de l’application et de son environnement.

6.5.1 Confidentialité, droits d'accès

La MOA indique ici de façon explicite :

- Les profils d’accès, c’est à dire les ensembles de droits d’accès à la future application (matériel/logiciel de base, locaux, ...), à ses fonctionnalités et à ses données . Ces profils accès seront attribués à des individus ou à des groupes d’individus, pendant une période donnée.

- Le cas échéant, la MOA précisera le niveau de traçabilité qu'elle souhaitera avoir (qui a fait quoi et quand), ainsi que les modalités d'accès aux traces correspondantes (procédures et habilitations).

La procédure d’administration de ces droits d’accès dans le cadre de la future organisation du travail.

6.5.2 Intégrité

La MOA spécifie ici de façon explicite :

- Les contraintes liées à l'intégrité des données (peut-on ou non se permettre de perdre des données, sur quelle période),

- Les éventuelles contraintes organisationnelles relatives à l'intégration de dispositifs tels que les anti-virus,

Ses éventuels besoin en terme de traçabilité des actions entreprises.

6.5.3 Disponibilité

La MOA spécifie ici le niveau de disponibilité qu'il souhaite avoir (24/24?), mode de fonctionnement dégradé de l’application en cas de problèmes, la durée admissible d’interruption de service, les délais maximum de reprise après panne, ...

6.6 Comportement de l'application face aux anomalies

Il s’agit ici de préciser le comportement de l’application lorsque l’utilisateur détecte une anomalie de fonctionnement et la procédure de reprise de traitement. Cela concerne par exemple la manière dont il conviendra de traiter le cas de figure où un bordereau incomplet empêcherait sa saisie (abandon pur et simple ou mémorisation des informations déjà saisies puis routage vers une personne chargée de résoudre le problème).

6.7 Traçabilité des erreurs

En complément du mécanisme d'alerte décrit au paragraphe 5.1, il s’agit ici de préciser la façon dont l’application doit traiter les erreurs de fonctionnement (disque plein par exemple) ou de manipulation : historisation dans un éventuel journal, durée de rétention de ce journal, niveau de finesse et de traçabilité des erreurs, ...

6.8 Fonctionnalités critiques

La MOA doit fournir ici la liste des fonctionnalités qu'il considère comme critiques pour la réussite de son projet.

Une fonctionnalité peut être critique pour plusieurs raisons :

Niveau de performance exigé particulièrement important,

Fréquence d'utilisation élevée, par tout ou partie des utilisateurs,

Importance fonctionnelle fondamentale,

Fonctionnalité déjà informatisée dans un système existant (performances de référence),

Fonctionnalités présentant un risque de rejet de la part des utilisateurs (par exemple parce qu'elle suppose d’eux qu’ils changent leurs habitudes de travail sans leur apporter en contrepartie de valeur ajoutée)

...

Ce paragraphe consiste en une synthèse des paragraphes 6 x ci-dessus et, en toute logique, doit inclure les fonctionnalités identifiées comme fondamentales au paragraphe 3.1. C'est à partir des informations fournies ici que la MOE pourra identifier la liste des transactions critiques (au sens informatique).

6.9 Évolutivité / Maintenabilité

Ce paragraphe est à remplir dans le cas où l’application à mettre en œuvre correspond à un lot provisoire, en attente d’une version définitive. Il s’agit alors ici d’indiquer le niveau d’évolutivité et de maintenabilité attendu pour cette version provisoire, compte tenu de sa durée de vie souhaitée par la MOA.

6.10 Contrôle interne

Il s'agit ici de préciser les activités de contrôle qui doivent être automatisées (nature, fréquence, durée, ...), les statistiques à fournir à cet égard ainsi que les éléments utiles au contrôle de 1er et 2ème degré (responsable, informations de reporting nécessaires).


7. Migration de l’existant à mener

Cette description s’effectue à partir des éléments déjà identifiés au dossier de faisabilité et résulte d’une négociation entre les souhaits de la MOA et les contraintes de la MOE.

7.1 Nature de l’existant à reprendre

Il s’agit de décrire notamment :

La nature des données à reprendre (y compris leurs origines)

Les volumes à récupérer

7.2 Bascule ancien/nouveau système

Il convient d’indiquer explicitement le mode de bascule souhaitée par la MOA (bascule immédiate ou étalée dans le temps).

Dans le cas d’une bascule progressive (par sites et/ou par fonctionnalité ou lorsque, par précaution, la MOA souhaite conserver l'ancien système), il convient de décrire le type de cohabitation à mettre en oeuvre avec le ou les systèmes existants.

Remarque : Ce type de cohabitation sera à considérer systématiquement pour la phase de sites pilotes.


8. Besoins fonctionnels connexes

Il s’agit ici de recenser tous les besoins fonctionnels relatifs à l’environnement technique de recette fonctionnelle, à la constitution de jeux d’essais automatisés, à la réalisation d’une base école, à la mesure des objectifs métier et des enjeux du projet pour la Société....

Ces besoins découlent des réflexions portant sur le cadre de la recette fonctionnelle (protocole de recette fonctionnelle) et sur la solution d’accompagnement.


9. Annexe : glossaire des termes /abréviations"métiers" employés.

La MOA fournit ici le glossaire des termes métiers employés dans le présent document.