Phase de développement  -  Technique
Développement spécifique
Etude préalable
   Expression des besoins
  
puceorange.gif (570 octets)Cahier des charges fonctionnel
Etude détaillée

   Dossier d'étude détaillée
   Modèle de données
   Règles d'ergonomie
Etude technique et réalisation
  
Dossier d'étude technique
   Tests de validation
Conduite du changement

Mise en oeuvre

   Bilan sites pilotes
   Documentation utilisateur
   Formation des utilisateurs
Développement avec progiciel

 

 

 

 

 

 

glossairetélécharger pour imprimercontact
puceorange.gif (570 octets)Cahier des charges fonctionnel
1. Objet et domaine d’application
2. Documents de référence
3. Abréviations et terminologie
4. Principes d'élaboration

1 - Objet et domaine d'application

L'élaboration d'un cahier des charges fonctionnel débute lorsque la phase de lancement du projet est terminée (charte de projet validée).

Les objectifs d'un cahier des charges fonctionnel sont :

  • préciser les orientations et le champ du domaine étudié,
  • analyser l'existant au niveau organisation, documents utilisés, traitements effectués, données manipulées,
  • proposer des solutions d'organisation, fonctionnelles et techniques répondant aux exigences et besoins exprimés,
  • obtenir une description globale du système (organisationnelle, fonctionnelle, technique, contraintes majeures de sécurité, de performance, interfaces avec d'autres systèmes, ...),
  • vérifier la faisabilité organisationnelle et technique,
  • aboutir à un choix argumenté d'une solution type de développement.

L'expression des besoins, initiée en phase de lancement du projet puis complétée en phase d'étude préalable, est contenue dans le cahier des charges fonctionnel.

Au niveau technique, il est souvent menée une étude de faisabilité technique.

ATTENTION : le contenu d'un cahier des charges n'est pas davantage abordé dans le présent guide.

La suite de ce guide propose une liste de contrôles pour aider le(s) relecteur(s) à vérifier le fond et la forme d'une étude de faisabilité technique. Cette vérification a pour but de détecter d'éventuelles non-conformités qui pourraient être préjudiciables dans la suite du projet. Le(s) relecteur(s) devra s'assurer :

  • de la conformité du contenu par rapport à ce qui est attendu,
  • de la complétude et de la cohérence du contenu,
  • du respect des standards applicables au projet.

Ce guide est destiné aux personnes impliquées dans le processus de vérification d'une étude de faisabilité technique associé à un projet : chef de projet, membres de l'équipe projet, personnes extérieures au projet sollicitées pour la vérification du document.

Ce document ne peut être exhaustif par rapport à la diversité des organisations, des environnements et des spécificités des projets de la DSI. Chaque projet peut compléter cette liste de manière à l'adapter à son contexte.

2 - Documents de référence

3 - Abréviations et terminologie

cf Glossaire " Conduite de projet Systèmes d’information "

4 - Principes d’élaboration

Le(s) relecteur(s) examine chacun des deux thèmes abordés dans la liste ci dessous : Forme, Contenu.

Chaque non-conformité détectée par le relecteur est notée sur une fiche de relecture (voir le guide méthodologique gestion de la documentation ou directement le plan type d'une fiche de relecture w.gif (84 octets)).

FT.1

Forme

O/N

FT.1-1

La présentation du document est-elle conforme à la présentation type d’un document projet ? en particulier, vérifier : page de garde, entête, pied-de-page, dates du document, référence du document, indices de version d’application et de révision du document

 

FT.2

Contenu

O/N

FT.2-1

Le domaine d’application de l’étude est-il décrit ?

 

FT.2-2

Les limites de l’étude sont-elles décrites ?

 

FT.2-3

La démarche d’étude (étapes, responsabilités, validation...) est-elle donnée ?

 

FT.2-4

Les références aux sources d’information (études antérieures, documentations, contacts téléphoniques...) sont-elles citées ?

 

FT.2-5

L’étude de faisabilité répond-elle point par point au cahier des charges ?

 

FT.2-6

En cas d’expérimentations, trouve-t-on la description des machines, progiciels (versions), bases (volume), logiciels applicatifs (version) utilisés ?

 

FT.2-7

Les résultats des expérimentations sont-ils présentés de manière claire et synthétique ?

 

FT.2-8

En cas de généralisation, a-t-on indiqué les risques et les probabilités d’erreur ?

 

FT.2-9

Les actions nécessaires à la mise en œuvre des solutions techniques envisagées sont-elles identifiées ?

 

FT.2-10

Les difficultés de mise en œuvre dans l’existant des solutions techniques envisagées sont-elles clairement identifiées ?

 

FT.2-11

Les moyens (humains, matériels, logiciels...) à prévoir pour pallier ces difficultés sont-ils décrits ?

 

FT.2-12

Les impacts des solutions techniques envisagées sont-ils décrits au niveau de l’organisation (ressources humaines, formation...), de l’environnement logistique (matériel, logiciel, réseau), de la qualité (maintenabilité, ergonomie, performance, sécurité de l’application...), de la charge de travail nécessaire (à la mise en oeuvre puis à l’exploitation), des coûts et délais ?

 

FT.2-13

Les points nécessitant des éclaircissements ou une étude approfondie sont-ils identifiés ?

 

FT.2-14

Existe-t-il un récapitulatif des différentes solutions techniques, qui fasse ressortir les points majeurs de l’étude et qui permette de prendre une décision ?

 
htpage.gif (1527 octets) glossairetélécharger pour imprimercontact