Exemple de Cahier de Charges Fonctionnel

CAHIER DES CHARGES Projet Intranet
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
1. Présentation de l’étude
Dans le cadre du nouvel intranet transactionnel, il est nécessaire, comme dans tout système,
de traiter le problème de l’identification et de l’authentification. Ainsi l’utilisateur doit-il :
• décliner son identité ;
• la prouver.
1.1 Le produit et ses objectifs

Afin d’offrir un premier service d’identification aux applications prototypes de l’intranet
transactionnel, un lot 0 offrira une fonction d’identification et authentification simple, calquée
sur celle qui est utilisée pour les applications 3270 et qui se fonde sur le modèle de
l’application AAAA. Elle sera d’abord mono-application, puis, si nécessaire, multi-
application.
C’est ce lot 0, identification et authentification qui fait l’objet du présent cahier des charges
fonctionnel.
1.2 Le contexte du projet

Le lot 0 s’inscrit (voir la note de cadrage du projet 10 du SIZZ : Identification et
authentification) comme une étape transitoire avant le lot 1, qui est le service d’identification
et d’authentification du SIZZ, et qui devrait être suivi du lot 2 (identification mutualisée, ou
SSO) et du lot 3 (authentification forte).
1.3 Date de mise en service
La mise en service du lot 0 est liée à la mise en service de l’expérimentation prospects SIZZ,
prévue pour fin janvier 2002.
1.4 Enveloppe budgétaire
La charge du lot 0 est estimée à 3 mois-hommes.
1.5 Les intervenants
Maîtrise d’ouvrage : DXXX (D. J.)
Maîtrise d’œuvre : DI/DZZ (P. M., coordination par P.P.)
_________________________________________________________________________________
Cahier des charges fonctionnel : Identification et authentification 1/37
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
2 Expression des besoins

2.1 Environnement
Ce projet concerne la population des utilisateurs potentiels de la première application
prototype de l’intranet transactionnel. Il s’agit de conseillers commerciaux de l’entreprise
2.2 Description des fonctions
Les fonctions de l’identification-authentification :
• F1 – Se connecter
• F2 – Se déconnecter
• F3 – Sécuriser la connexion
• F4 – Accéder aux traces
2.2.1 F1 - Se connecter
Principes :
• l’utilisateur doit se connecter avant de pouvoir utiliser l’application intranet
• il doit décliner :
1. son site de rattachement (les habilitations sont par site) ;
2. son identifiant ;
3. son code secret.
• quels que soient les éléments intermédiaires de l’architecture technique (serveur de
présentation), il s’agira bien d’une identification et authentification « de bout en
bout », c’est-à-dire de la station de travail au serveur de traitements et données.
• il ne doit y avoir qu’une seule connexion simultanée par utilisateur
2.2.2 F2 - Se déconnecter
Principes :
• l’utilisateur doit se pouvoir se déconnecter après avoir utilisé l’application intranet
• l’utilisateur doit être déconnecté automatiquement s’il quitte le navigateur Web
sans terminer l’application ni se déconnecter volontairement, ou si le navigateur
Web se ferme brutalement suite à un dysfonctionnement interne ;
• dans le cas éventuel du multi-application (cf. § 2.10 Possibilités d’évolution),
l’utilisateur doit pouvoir se déconnecter sans être entré dans aucune application.
2.2.3 F3 – Sécuriser la connexion

Principes :
• la confidentialité du code secret doit être assurée de bout en bout (de la station de
travail au serveur de traitements et de données) ;
• les tentatives de connexions avec un code secret erroné doivent être limitées à
trois, seuil au-delà duquel l’utilisateur doit être bloqué ; il faudra disposer d’une
fonction de déblocage du code secret (cette fonction peut n’être accessible qu’à
travers AAAA).
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• les connexions, les tentatives infructueuses de connexion et les déconnexions

doivent être tracées.
2.2.4 F4 – Accéder aux traces
Principes :
• pour des besoins d’audit, il faut pouvoir accéder aux traces de l’identification-
authentification.
• il est souhaitable :
• de prévoir une habilitation pour cet accès aux traces ;
• de tracer les accès aux traces eux-mêmes.
2.3 Description des contraintes
2.3.1 Contraintes organisationnelles
L’identification transitoire est issue de l’identification AAAA; elle ne doit nécessiter aucune
administration supplémentaire par rapport à l’actuelle identification AAAA.
L’identification transitoire doit être disponible au moins dans les mêmes plages horaires que
les applications auxquelles elle donne accès.
2.3.2 Contraintes techniques
Compte tenu du choix fondamental de SIZZ de centraliser données et traitements sur système
central, on utilisera les techniques et produits standards de l’environnement grand système
IBM OS/390.
2.3.3 Contraintes réglementaires et légales
Sans objet.
2.3.4 Contraintes humaines
Ce système d’identification et authentification étant partagé avec AAAA, on veillera à utiliser
une terminologie similaire afin de bien montrer l’unicité des concepts. Ainsi utilisera-t-on les
termes « Identifiant utilisateur » et « Code secret ».
2.3.5 Contrainte des normes et standards
S’agissant d’un système d’identification et d’authentification intranet s’appuyant sur AAAA,
il devra se conformer aux normes 17.1.5 et 17.1.6 de la Direction générale, qui définissent
respectivement les principes et les règles relatifs à l’octroi, la gestion et l’utilisation des
habilitations à AAAA et aux systèmes informatiques autres qu’AAAA.
2.3.6 Contraintes du système de traitement dans l’entreprise
Sans objet.
2.4 Hiérarchisation des fonctions
Fonctions Hiérarchie
F1 – Se connecter 1
F2 – Se déconnecter 1
F3 – Sécuriser les connexions 2
F4 – Accéder aux traces des connexions 2
Rappel de la signification des niveaux hiérarchiques :
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
1. fonction fondamentale
2. fonction importante
3. fonction utile
2.5 Principes comptables

Sans objet.
2.6 Contrôles et sécurité
Toute connexion (et a fortiori toute tentative infructueuse de connexion) sera journalisée.
2.7 Organisation
Rien ne change fondamentalement par rapport à l’organisation classique décrite ci-dessous,
d’autant plus que toutes les créations, modifications, suppressions continuent de se faire avec
les outils AAAA, l’identification transitoire de l’intranet transactionnel s’appuyant totalement
sur les tables d’utilisateurs du système AAAA.
Néanmoins, il conviendra de préciser, surtout en cas de passage au mode multi-application
(cf. § 2.10 Possibilités d’évolution), les points suivants :
• qui informe les gestionnaires des habilitations de la mise en place d’une
application intranet ?
• qui demande l’actualisation de la table des transactions (s’il en existe une) à qui ?
Acteurs Rôles
Gestionnaire des habilitations (logistique DE)
Gère (à travers AAAA) les habilitations des
utilisateurs de la DE.
Adresse aux utilisateurs, via la hiérarchie locale,
leur identifiant et code secret, sous pli individuel et
cacheté.
Gestionnaire de personnel (ressources humaines
Informe le gestionnaire des habilitations des
DE)
mouvements définitifs de personnel
Hiérarchie locale Tient à jour le dossier local des habilitations.
Demande une habilitation urgente pour
dépannage au gestionnaire des habilitations.
Demande un nouveau code secret pour un
utilisateur qui a perdu son code.
Demande à l’utilisateur de modifier son code
secret.
Utilisateur Accuse réception de son identifiant et de son
code secret.
Modifie périodiquement son code secret, à son
initiative ou à la demande de sa hiérarchie.
2.8 Volumes à traiter et leur évolution

Nombre d’utilisateurs potentiels : les conseillers commerciaux des 10 agences sites produits
de l’expérimentation prospects SIZZ, soit au maximum 150 utilisateurs.
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
2.9 Performances principales

La phase d’identification et authentification en doit pas être plus longue qu’en identification
3270. La durée maximale admissible est donc de 4 secondes.
2.10 Possibilités d’évolution
• Multi-application : le lot 0 prévoit de traiter l’identification-authentification et le droit à
l’opération pour une seule application. Une évolution possible consisterait à gérer le droit
à plusieurs opérations.
• Ergonomie : au lancement du projet, le standard ergonomique SIZZ n’est pas encore
connu. Il faudra donc prévoir une remise à niveau ultérieure une fois le standard établi.
3 Besoins non retenus

Comme pour l’identification des applications 3270, le lot 0 de l’identification intranet ne
comporte aucune fonction de création ou de suppression d’utilisateur, pas plus que de
changement de code secret : toutes ces fonctions continueront d’être effectuées avec les outils
AAAA.
4 Mise en place
4.1 Caractéristiques principales
La mise en place de l’identification transitoire sera associée à celle de l’application qui va
l’utiliser, à savoir l’expérimentation prospects SIZZ.
4.2 Phase de recette
L’environnement de recette devra refléter fidèlement l’architecture d’exploitation, tant en ce
qui concerne la station de travail et les serveurs que le réseau.
4.3 Sites pilotes
Les sites pilotes seront bien sûr les sites pilotes de l’expérimentation prospects SIZZ.
4.4 Conditions de généralisation
La généralisation ne pourra se faire qu’après validation par la DXXX du fonctionnement des
sites pilotes. Elle touchera bien évidemment le périmètre retenu pour l’expérimentation
prospects SIZZ.
De même, l’identification et authentification transitoires sera mise en place sur réseau école
dans les mêmes conditions que l’expérimentation prospects SIZZ (si elle doit l’être).
♦♦♦
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
1. PRESENTATION DE L’ETUDE ...............................................................................................................1

1.1 LE PRODUIT ET SES OBJECTIFS ....................................................................................................................1
1.2 LE CONTEXTE DU PROJET ............................................................................................................................1
1.3 DATE DE MISE EN SERVICE..........................................................................................................................1
1.4 ENVELOPPE BUDGETAIRE ...........................................................................................................................1
1.5 LES INTERVENANTS ....................................................................................................................................1
2 EXPRESSION DES BESOINS....................................................................................................................2
2.1 ENVIRONNEMENT .......................................................................................................................................2
2.2 DESCRIPTION DES FONCTIONS ....................................................................................................................2
2.2.1 F1 - Se connecter .............................................................................................................................2
2.2.2 F2 - Se déconnecter..........................................................................................................................2
2.2.3 F3 – Sécuriser la connexion.............................................................................................................2
2.2.4 F4 – Accéder aux traces...................................................................................................................3
2.3 DESCRIPTION DES CONTRAINTES ................................................................................................................3
2.3.1 Contraintes organisationnelles ........................................................................................................3
2.3.2 Contraintes techniques.....................................................................................................................3
2.3.3 Contraintes réglementaires et légales..............................................................................................3
2.3.4 Contraintes humaines.......................................................................................................................3
2.3.5 Contrainte des normes et standards.................................................................................................3
2.3.6 Contraintes du système de traitement dans l’entreprise ..................................................................3
2.4 HIERARCHISATION DES FONCTIONS ............................................................................................................3
2.5 PRINCIPES COMPTABLES .............................................................................................................................4
2.6 CONTROLES ET SECURITE ...........................................................................................................................4
2.7 ORGANISATION...........................................................................................................................................4
2.8 VOLUMES A TRAITER ET LEUR EVOLUTION .................................................................................................4
2.9 PERFORMANCES PRINCIPALES.....................................................................................................................5
2.10 POSSIBILITES D’EVOLUTION ...................................................................................................................5
3 BESOINS NON RETENUS .........................................................................................................................5
4 MISE EN PLACE.........................................................................................................................................5
4.1 CARACTERISTIQUES PRINCIPALES ...............................................................................................................5
4.2 PHASE DE RECETTE .....................................................................................................................................5
4.3 SITES PILOTES .............................................................................................................................................5
4.4 CONDITIONS DE GENERALISATION ..............................................................................................................5
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
Document de référence
CODE CAHIER DES CHARGES

PROJET FONCTIONNEL GENERAL
Réf. : (référence du document)

Projet : (Désignation du projet)
Tél. xx xx xx xx
xx
Emetteur : x. xxxxx Fax. xx xx xx xx
xx
Mail : @
Date
le xx/xx/xx
d’émission :
Validation
Validation
Nom Date Commentaires
(O/N)
x. xxxxxx
x. xxxxxx
Historique des modifications

Version Date Etat Description de la modification
1 Présentation du projet
• Rappeler les objectifs et le périmètre du Projet
• Donner les références des documents produits et tout particulièrement celle de la note
de cadrage
2 Architecture fonctionnelle
Décrire la situation du projet dans le système existant
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
3 Les fonctions
3.1 Modèle général des fonctions
• Identifier et lister les fonctions attendues
• Représenter le modèle général si il y a lieu (enchaînement des fonctions)
3.2 Description des principales fonctions
Décrire de façon générale les principales fonctions :
• définition et objectif
• description fonctionnelle
• principales règles de gestion
4 Les données
4.1 Description des données
Décrire les principales données utilisées :
• Libellé descriptif
• Format
• Longueur
• Indentifiant N/O ; externe, interne
• Liste de valeur
• Règle de gestion
• Règle d’historisation et de purge de la donnée
4.2 Reprise de l’existant

• Indiquer les principes de reprise
• Décrire le scénario général de reprise
5 Les flux
5.1 Schéma général des flux
• Lister les flux principaux, exprimés en entrée, sortie
• Représenter le schéma général des flux
5.2 Descriptif des flux
5.2.1 Fichiers
• Identifier les principaux fichiers
• Donner une description générale
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• Format
• Fréquence
• Contenu
5.2.2 Editions
Etablir une liste générale des besoins en édition
A cette étape,indiquer :
• la fréquence et les conditions d’édition
• le volume (= nombre de pages) moyen, mini, maxi
6 Organisation et profils-types
6.1 Répartition
• Identifier les différents sites géographiques, services
• Représenter le schéma de répartition des fonctions
6.2 Profils-types
• Identifier les profils-types
7 Contraintes
Lister les contraintes identifiées dans les domaines suivants :
• Fonctionnel
• Technique
• Réglementaire
• Organisationnel
• Performance
• Logistique
• Sécurité, secours ...
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
CODE CAHIER DES CHARGES

PROJET FONCTIONNEL DETAILLE
Réf. : Référence du document
Tél : xx xx xx xx
xx
Emetteur : x. xxxxx Fax : xx xx xx xx
xx
Mail : @
Date
le xx/xx/xx
d’émission :
Validation
Validation
(O/N)
x. xxxxxx
x. xxxxxx

1 Présentation du projet
• Décrire le contenu du projet
• Donner les références des documents produits dans la phase préalable de « Choix de la
solution »
2 Architecture fonctionnelle
• Représenter l’intégration de l’application dans le système existant
• Exprimer l’ensemble des inter-actions du projet avec le système existant
• Identifier les flux externes de façon exhaustive
3 Les fonctions
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
3.1 Modèle détaillé des fonctions

• Identifier et lister la totalité des fonctions attentues
• Décrire les enchaînements de fonctions
• Représenter le modèle détaillé des fonctions
3.2 Description détaillée de l’ensemble des fonctions
• Décrire de façon détaillée chaque fonction :
o définition et objectif
o description fonctionnelle :
traitements
écrans
enchaînement d’écrans
règles de gestion
contrôles sur les données
• Lister par fonctions les entrées/sorties
4 Les données
4.1 Modèle détaillé des données
Joindre le MCD
4.2 Description des données
• Décrire les données utilisées :
o Libellé descriptif
o Format
o Longueur
o Identifiant N/O ; externe, interne
o Liste de valeur
o Règle de gestion
o Règle d’historisation et de purge de la donnée
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• Indiquer la volumétrie
4.3 Reprise de l’existant
• Décrire de façon détaillée les principes de reprise
• Indiquer le scénario de reprise
• Détailler les règles de reprise pour chacune des données :
o données d’origine
o règles de conversion
o données cible
5 Les flux
5.1 Schéma général des flux
Représenter la totalité des flux externes et internes, exprimés en entrée/sortie
5.2 Descriptif des flux
Décrire chaque flux
5.2.1 Fichiers
Préciser pour chacun des fichiers :
• le support physique
• le format
• la provenance ou la destination
• la fréquence de réception ou d’émission
• La fréquence d’accès (gain d’optimisation)
• le volume (moyen, mini, maxi)
• les points particuliers
• les données véhiculées par le flux
5.2.2 Editions
Préciser pour chacune des éditions :
• les données
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• la fréquence et les conditions d’édition

• le nombre d’exemplaire
• le volume (= nombre de pages) moyen, mini, maxi
• les destinataires
5.2.3 Messages
Décrire les messages d’erreur associés aux contrôles définis préalablement sur les données,
les fonctions.
6 Organisation et profils-types
6.1 Répartition
• Lister les différents sites géographiques, services
• Représenter le schéma de répartition des fonctions
6.2 Profils-types
• Lister les différents profils types
• Les décrire de façon détaillée :
o Fonctions
o Habilitations
o Menus
7 Contraintes
Décrire les contraintes identifiées dans les domaines suivants :
• Fonctionnel
• Technique
• Réglementaire
• Organisationnel
• Performance
• Logistique
• Sécurité, secours ...
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
Post-scriptum : Enchaînement des documents de gestion de projet selon un ordre séquentiel

d’utilisation :
1 La note de cadrage
2 Cahier des charges fonctionnel général
3 Le document Avant projet
4 La Lettre de mission
5 Cahier des charges fonctionnel détaillé
6 Dossier Analyse Technique Détaillée
7 La fiche de tests
8 PV de Recette
Chaque document est issu d’un document parent et permet de produire le document de l’étape
suivante. L’enchaînement peut-être illustré avec les phases de gestion de projet
CODE
NOTE de CADRAGE
PROJET
Réf. : NoteCadrage.dot
Tél. xx xx xx xx
xx
xx
Mail : @
Date
le xx/xx/xx
d’émission :
Validation
Validation
(O/N)
x. xxxxxx
x. xxxxxx
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
Version Date Etat Description
1. Introduction
o Rappel du contexte dans lequel l’étude a été lancée
o Indication des Directions et (ou) des événements déclencheurs à l’origine de
l’étude
o Description succinte de l’étude
2. La portée et les limites de l’étude
o Positionnement de l’étude par rapport aux objectifs de l’Entreprise
o Les impacts de l’étude, (forces, faiblesses)
en interne
en externe
o Les contours du projet
définitions des utilisateurs
exposé du contenu
délimitation du domaine concerné par l’étude
impacts sur les autres domaines
exigence de qualité
o Les opportunités, les risques, (conjoncture, concurrence, habitudes de marchés)
3. Le budget
o Gain attendu (commission, impact trésorerie ....)
o Coûts et charges (externes ou internes)
Charges (MOA/MOE/utilisateurs/Organisation, assistance externe)
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
Coûts informatiques (environnements, logiciels et matériels, ...)

Coûts de déploiement (formation, manuels utilisateur, gestion du
changement...)
o Coûts de fonctionnement prévisibles
o Numéro de ligne budgétaire
4. L’organisation
o Intervenants
Direction chargée du projet :
Responsable du projet :
Autres acteurs :
Maîtres d’œuvre
Maîtres d’ouvrage
Utilisateurs
Organisation
Assistance extérieure
o La démarche retenue pour l’avant projet
Actions à mener
Résultats et livrables attendus (décisions, documents ...)
o Organisation spécifique de l’avant-projet
Comités : rôle, composition, compétence, périodicité
Documentation associée (localisation, codification du projet,
organisation des répertoires )
5. Le calendrier
o Dates clefs
o Phasage du projet
o Planning possible
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
6. Annexes
o Etude de marché, etc ...
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
CODE
AVANT-PROJET
PROJET
Réf. : Références du document
Tél. xx xx xx xx
xx
xx
Mail : @
Date
le xx/xx/xx
d’émission :
Validation
Validation
(O/N)
x. xxxxxx
x. xxxxxx

1 Introduction
• Rappel de la définition du projet
• Rappel des dates clefs
• Rappel de la démarche
2 Analyse des solutions
• Faire référence au « Dossier de choix de la solution » élaboré au préalable
• Proposer toutefois une synthèse de la démarche utilisée (présentation des solutions,
mode de notations, comparatif, synthèse et recommandation ...)
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
En fonction de l’importance du projet, si il n’y a pas eu d’élaboration de « Dossier de choix de

la solution », la démarche et les solutions seront décrites dans ce chapitre suivant le même
plan type que celui décrit pour le dossier de choix.
3 Solution retenue
• Description de la solution :
• Description fonctionnelle
• Description technique
• Niveau de qualité attendu
• Impact de la solution sur l’organisation
• Faisabilité :
• Avantages
• Inconvénients
• Conditions de mise en oeuvre :
• Moyens humains et matériel nécessaire
• Besoins formation, documentation, communication
• Sous-projet
• Déploiement
• Reprise de l’existant :
• Principes et scénario général de reprise
4 Le budget
Le présent chapitre permet de revenir en détail sur le budget esquissé dans la note de cadrage
et d’établir le budget du projet
• Gain attendu (commission, impact trésorerie ....)
• Coûts et charges (externes ou internes) :
• Charges (MOA/MOE/utilisateurs/Organisation, assistance externe)
• Coûts informatiques (environnements, logiciels et matériels, ...)
• Coûts de déploiement (formation, manuels utilisateur, ...)
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• Coût de fonctionnement prévisibles

• Numéro de ligne budgétaire
5 L’organisation
Confirmer :
• Les intervenants :
• Direction chargée du projet
• Responsable du projet, (cf. lettre de mission)
• Autres acteurs (désignation des équipes, rôles et responsabilités) :
• Maîtres d’œuvre
• Maîtres d’ouvrage
• Utilisateurs
• Organisation
• Assistance extérieure
• L’organigramme du projet
• Les instances de fonctionnement du projet :
• Comité de pilotage :
• Composition
• Rôle
• Compétence
• Périodicité
• Comité de suivi :
• Composition
• Rôle
• Compétence
• Périodicité
• Méthode de reporting
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• Documentation associée (localisation, codification du projet, organisation des

répertoires ...)
6 Le phasage et la planification
• Phasage et étapes du projet
• Référenciel des livrables attendus à chaque étape
• Planification du projet et méthode de suivi (en délai, en charge, en qualité ...)
7 Annexes
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
CODE LETTRE DE MISSION

PROJET du responsable de projet
Nom du Projet :
Commanditaire : structure ou Direction qui initie le projet et décide du lancement

Nom du Responsable du Projet :
Mission du Responsable de Projet :

• Description
• Délégation de décision
Désignation des MOA :
Moyens alloués à la MOA :
Désignation des MOE :
Moyens alloués à la MOE :
Modalités de reporting :
Durée :
Documents de référence :
• Cahier des charges fonctionnel général
• Avant-projet
Date : Signature du Commanditaire : Date : Signature du Responsable de

Projet :
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
Code DOSSIER D’ANALYSE

PROJET TECHNIQUE DETAILLEE
Réf. : Référence du document
Tél : xx xx xx xx
xx
Emetteur : x. xxxxx Fax : xx xx xx xx
xx
Mail : @
Date
le xx/xx/xx
d’émission :
Validation
Validation
(O/N)
x. xxxxxx
x. xxxxxx

1 Présentation du document
1.1 Caractéristiques du projet
Rappeler les caractéristiques du projet.
1.2 Documents de références du projet
Rappeler les différents livrables préalablement établis :
• Note de cadrage
• Cahier des charges fonctionnel général
• Dossier de consultation (si consultation externe)
• Dossier de choix de la solution
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• Avant-projet
• Lettre de mission
• Cahier des charges fonctionnel détaillé
• ....
2 Présentation de la solution à mettre en œuvre
2.1 Solution
Expliciter la manière dont on va assembler les éléments du projet :
• Partage entre les développements spécifiques, progiciels et réutilisation de logiciels
existants,
• Outils utilisés.
• Environnement technique.
2.2 Version et composants livrés
Décrire la version livrée en production, avec l’ensemble des composants et leur version.
2.3 Configurations matérielle et logicielle
Décrire les caractéristiques matérielles et logicielles des ordinateurs sur lesquels l’exploitation
du logiciel est prévu (Serveur et poste client). Indiquer uniquement les spécificités par rapport
à la configuration standard du site. (Ex : niveaux de version des logiciels de base différents
par rapport à la production).
3 Architectures - Fonctionnelle et Technique
3.1 Architecture fonctionnelle
• Faire référence au schéma d’architecture fonctionnelle représenté dans le Cahier des
charges fonctionnel détaillé.
• Rappeler la liste des fonctions attendues décrites dans le Cahier des charges
fonctionnel détaillé.
3.2 Architecture technique
3.2.1 Représentation
• Représenter le schéma d’architecture technique.
• Préciser sur le schéma la nature des relations entre les traitements.
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
3.2.2 Unités de traitement

Une unité de traitement est la traduction technique d’une ou plusieurs fonctions ou sous-
fonctions.
• Lister les unités de traitements.
• Faire le lien avec les fonctions correspondantes.
• Expliciter pour chacune des unités de traitements, les composants.
Nom
Nom Nom Création /
sous Composants Type Mode Désignation Langages
UF UT modification
UF
Descriptif
UF1.1 Module 1 M sommaire Création
du module
UF1 UT1 Descriptif
sommaire
UF1.2 ECR1 E Modification
de l’écran
ECR1
UF2.2 Module 1 M Création
UF2 UF2.2 UT2 Module 2 M Création
UF2.3 ECR2 E Modification
UF3 UF3.1 UT3 Module 3 M
UF = Unité Fonctionnelle
UT = Unité de Traitement
Type : M=Module ; E=Ecran
Mode : T= Temps réel ; B= Chaîne Batch
4 Données
Expliciter les supports de données utilisés par les unités de traitement (hors fichiers internes).
Si il existe des documents décrivant les fichiers et donnant au moins lesmêmes informations
que celles mentionnées ci-après, rappeler les référencesdes documents
4.1 Fichiers en entrée
Décrire l’ensemble des fichiers d’origine externe au projet en entrée de l’une, au moins, des
unités de traitement du projet.
4.1.1 Fichier entrant de 1 à n
• Décrire le fichier
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• Objet
• Provenance
• Périodicité d’arrivée
• Donner les caractéristiques physiques du fichier
• Forme
• Nom
• Type des enregistrements
• La clef par type
• La taille par type d’enregistrement
• Les séparateurs utilisés
• ...
• Décrire les champs
N° du champ Désignation Type Format Longueur Valeur Clef
1 Nom-champ 1
.
.
n Nom-champ n
• N° du champ : Numérotation séquentielle de 1 à n
• Désignation : Nom du champ
• Type : N pour Numérique , A pour Alphanumérique, D pour Date, B pour Binaire
• Format : Qualification du type (nombre de décimales, format date, ...)
• Longueur : en octets
• Valeur : Pour les zones ayant des valeurs " en dur "
• Clef : O si la zone fait partie de la clef primaire N sinon
• Préciser si nécessaire les valeurs utilisées pour certaines rubriques :
• règles de cadrage.
• valeurs spécifiques.
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• tables de contrôle à utiliser.

• signification de la non présence d’une zone.
• valeurs par défaut à utiliser pour les zones non renseignées.
• de manière générale, tout ce qui qualifie une zone de ce fichier entrant.
4.2 Fichier en sortie
Décrire l’ensemble des fichiers produits par les unités de traitement à destination de
l’extérieur ou d’un autre projet.
4.2.1 Fichiers sortant de 1 à n
• Décrire le fichier
• Objet
• Destination
• Périodicité de fabrication
• Donner les caractéristiques physiques du fichier
• Forme
• Nom
• Type des enregistrements
• La clef par type
• La taille par type d’enregistrement
• Les séparateurs utilisés
• ...
• Décrire les champs
N° du champ Désignation Type Format Longueur Valeur Clef
1 Nom-champ 1
.
.
n Nom-champ n
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date

• Type : N pour Numérique ,B pour binaire, A pour Alphanumérique, D pour Date
• Valeur : Pour les zones ayant des valeurs " en dur "
• Préciser ni nécessaire les valeurs utilisées pour certaines rubriques :
• règles de cadrage
• valeurs spécifiques
• tables de contrôle à utiliser
• signification de la non présence d’une zone
• valeurs par défaut à utiliser pour les zones non renseignées
• de manière générale, tout ce qui qualifie une zone de ce fichier sortant
4.3 Bases de données
• Lister l’ensemble des tables des bases de données utilisées par le projet.
• Si des vues sont utilisées les mentionner.
• Inclure si nécessaire un modèle de données utilisées.
4.3.1 Base de 1 à n
4.3.1.1 Table de 1 à n
• Donner la référence du document décrivant la table pour les tables permanentes.
• Décrire la table si c’est une table temporaire du projet.
N° Désignation Type Format Longueur Clef
1 nom-colonne 1
.
.
n nom-colonne n
• N° : Numérotation séquentielle de 1 à n
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• Désignation : Nom de la colonne

• Type : N pour Numérique, A pour Alphanumérique, D pour Date
5 Ecrans
5.1 Navigation
Décrire le principe de navigation entre les différents écrans.
Un schéma est indispensable. Il indiquera notamment le moyen retenu pour passer d’un écran
à l’autre :
• Menu contextuel
• Touche de fonction
• Lien Applicatif
• ...
SCHEMA
5.2 Ecrans
5.2.1 Ecran de 1 à n
5.2.1.1 Description
• Décrire la ou les fonctions de l’écran ainsi que son mode opératoire (généralement :
création, modification, visualisation)
• Préciser le mode d’indication d’erreur retenu (position du curseur sur zone erronée ou
non, encadrement de la zone en erreur, changement de couleur de la zone, ...)
• Préciser les options de navigation (menus accessibles, touches fonctions activées,
débranchements applicatifs possibles, ...) au besoin en spécifiant le contexte (création,
modification, visualisation, ...) et les contraintes (restriction d’accès par profil,
limitation de nombre de lignesen affichage, ...).
5.2.1.2 Dessin d’écran
• Insérer ici la maquette de l’écran ou le joindre en annexe
5.2.1.3 Description des champs
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
N° Désignation Type Format saisie Format restitué Longueur saisie Longueur affichée
1 nom-champ 1
.
.
n nom-champ n
• N° : Numérotation séquentielle de 1 à n
• Format de saisie : Spécification saisie autorisée (nombre de décimales, format date, ...)
• Format d’affichage : Spécification du format restitué
• Longueur saisie : longueur de la zone de saisie en octet
• Longueur affichée : longueur de la zone affichée si on la remplie de la lettre " A "
5.2.1.4 Contrôles
Saisie Saisie
N° Désignation Contrôle Message
Création modification
1 nom-champ 1
.
.
n nom-champ n
• N° : Numérotation séquentielle de 1 à n (ordre de saisie des champs)
• S. création : Saisie ayant une caractère permanent compte tenu du contexte (O
Obligatoire, I impossible, F facultatif, C condition)
• S. modification : Idem précèdent
• Contrôle : Contrôles unitaires sur le champ y compris de présence dans un référentiel
• Message : Numéro du message de la liste du 6.1.0. si le contrôle unitaire n’est pas
satisfait
5.2.1.5 Traitements
• Décrire :
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• les accès aux tables concernées.

• les contrôles croisés et contextuels.
• les insertions en qualifiant les tables concernées.
• les modifications en qualifiant les tables concernées.
• Faire référence aux modules utilisés, décrits au chapitre concerné
5.2.1.6 Fonctionnement détaillé
• Décrire :
• l’enchaînement des traitements décrits précédemment.
• les conditions d’apparition des messages.
• et tout ce qui doit être codé dans la grille.
5.3 Messages Applicatifs
• Renseigner cette liste au fur et à mesure de la conception des écrans afin de permettre
une gestion performante des messages.
N° du message Libellé
1
2
.
n
6 Modules
On entend par module, un programme, unsous-programme, réutilisable ou non par plusieurs
unités de traitement,exécuté en temps réel et/ou lancé dans une chaîne batch.
6.1 Module de 1 à n
6.1.1 Fonctions
Décrire la ou les fonctions que doit remplir le module.
6.1.2 Descriptif
• Décrire le module.
• Indiquer ici le nom du source, le langage utilisé, la procédure de compilation, ainsi que
le nom du module compilé.
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• Préciser si le module est réutilisable.

• Indiquer si le module est exécuté en temps réel, et/ou est à insérer dans une chaîne
batch.
6.1.3 Interface de communication en entrée/sortie
• Décrire l’ensemble des paramètres en entrée/sortie dans le bon ordre, et donner un
exemple de lancement avec des valeurs de paramètres significatives.
• Indiquer également les conditions d’exécution.
• Décrire les champs :
N° champ Désignation Type Format Longueur Sens
1 CODE-RETOUR B 2 S
2 CODE-FONCTION B 2 E
3 SS-CODE-FONCTION B 2 E
4 CODE-LANGAGE C 2 S
5 CODE-ERREUR B 2 S
6 LIBELLE-1 C 80 S
7 LIBELLE-2 C 80 S
8 xxxxxxxxxx E/S
• Longueur : En octets
• Sens : E pour entrée, S pour sortie
• Préciser si nécessaire les valeurs utilisées pour certaines rubriques
• Règles de cadrage
• Valeurs spécifiques
• Tables de contrôle à utiliser
• Signification de la non présence d’une zone
• Valeurs par défaut à utiliser pour les zones non renseignées
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
• De manière générale, tout ce qui qualifie une zone de ce fichier interne

6.1.4 Fichiers utilisés en entrée/sortie
• Faire référence aux fichiers utilisés ou générés par le module. (ces fichiers ont été
décrits aux paragraphes précédents)
• Pour les fichiers en entrée, spécifier les données utilisées et le type d’accès,
(lecture/Maj ..).
CODE Fiche de test

PROJET
DESCRIPTION
Projet : N° de fiche : Auteur : Référence séquence
de test :
Date du test :
CONTEXTE Pièce Jointe O/N
(identification du cas traité)
ACTIONS A REALISER Pièce Jointe O/N
RESULTATS ATTENDUS Pièce Jointe O/N
RESULTATS OBTENUS
Anomalie n° :
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
A la vue des rubriques proposées, il est aisé de comprendre que le PV de recette n’est qu’un
simple document entre client et fournisseur permettant de déclarer officiellement que la
recette est validée par le client. Il est important toutes fois de savoir que la signature du PV de
recette permet de déclencher le processus de maintenance des éléments livrés et recettés. On
peut également entendre par client et fournisseur, maîtrise d’ouvrage (MOA) et maîtrise
d’oeuvre (MOE).
CODE PROCES VERBAL DE RECETTE

PROJET
INTITULE DE LA RECETTE
Référence :
PARTICIPANTS
DIRECTION MOA : DIRECTION MOE :
Travaux faisant l’objet de la recette :

La recette est déclarée prononcée
Procés verbal établi le :
Pour la Direction MOA Pour la Direction MOE
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
L’intégration d’un progiciel ne se limite pas à l’installation d’un ensemble de programmes et

à leurs tests, mais doit comprendre les étapes permettant de fondre le progiciel dans le S.I.,
autant du coté applicatif que du coté des utilisateurs.
Selon un canevas d’intégration, ces étapes pourraient être :
4.4.1 Phase de conception

Cette phase est en charge de la maîtrise d’ouvrage.
Analyse de l’existant
Il s’agit de réaliser une cartographie du système actuel, pour le découper en fonctionnalités
afin de comprendre ce qu’il fait. Quelles sont ses entrées et sorties. De cette analyse de
l’existant, il doit être possible de réaliser un découpage des nouvelles fonctionnalités en
ateliers
Analyse des écarts
Dans chaque atelier précédemment défini, cette phase doit permettre en relation avec l’éditeur
du progiciel de déterminer quelles sont les fonctionnalités non prises en compte, et qu’il
faudrait implémenter par des nouveaux développements, nouveaux paramétrages ou nouvelles
adaptations.
Analyse des besoins
Il s’agit à partir de l’analyse des écarts de formaliser ce que doit faire le progiciel pour
intégrer les fonctionnalités non prises en compte, pour fonctionner à l’identique du système
actuel. De cette analyse, les cahiers des charges peuvent être conçus (livrable).
4.4.2 Phase de réalisation

Prise en charge par la MOE :
Développements spécifiques
Depuis les cahiers des charges, les documents de conception fonctionnelle et détaillée sont
rédigés pour permettre la réalisation.
Tests unitaires
Les développements sont testés unitairement ainsi qu’en tests de chaîne.
4.4.3 Phase de déploiement et de tests

Mise en place du paramétrage
C’est installer le nouveau paramétrage sur le futur système
Tests fonctionnels
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
Réalisé par la MOA, les tests doivent permettre de comparer le fonctionnement du progiciel
avec le fonctionnement prévu dans le cahier des charges. Les tests peuvent être gérés au
niveau des règles de gestion, avec ou sans automate de tests, selon une méthodologie de
recette : voir Recette utilisateur un metier
Tests d’intégration
Réalisé egalement par la MOA, il s’agira de tester le comportement du progiciel dans le
fonctionnement normal du SI, et notamment au regard des interfaces echangées entre les
systèmes.
Gestion du changement
Il s’agit de communiquer avec les utilisateurs sur les changements qui vont intervenir sur leur
mode de fonctionnement dans le nouveau SI.
L’idéal est d’arriver à ce que les utilisateurs s’approprient le nouvel outil.
Une bonne gestion du changement passe par une implication des utilisateurs (utilisateurs clés
et ayant un rôle moteur dans le SI), dés le début, et une communication régulière par les
divers moyens possibles aujourd’hui (lettre d’info, intranet ...)
Formation des utilisateurs
Le moyen, mais pas le seul, permettant d’aider les utilisateurs à passer de l’ancien système au
nouveau.
L’intégration de progiciels dépend également du progiciel lui-même ; intégrer le même
progiciel sur deux à trois sites permet de mettre en place une méthodologie et de capitaliser
sur les connaissances liées à l’intégration du progiciel. Intégrer un autre progiciel ne peut pas
par contre être réalisé en utilisant une méthodologie même éprouvée mais spécifique à un
progiciel. Le consultant à l’intégration doit s’adapter au S.I., S.I. dont le progiciel fait partie
intégrante.
_________________________________________________________________________________
FONCTIONNEL
IDENTIFICATION ET
AUTHENTIFICATION
Émetteur : Date
_________________________________________________________________________________

Exemple de Cahier de Charges Fonctionnel

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Exemple de Cahier de Charges Fonctionnel

Uploaded by

Copyright:

Available Formats

CAHIER DES CHARGES Projet Intranet

1.1 Le produit et ses objectifs

1.2 Le contexte du projet

2 Expression des besoins

2.2.3 F3 – Sécuriser la connexion

• les connexions, les tentatives infructueuses de connexion et les déconnexions

Rappel de la signification des niveaux hiérarchiques :

2.5 Principes comptables

2.8 Volumes à traiter et leur évolution

2.9 Performances principales

3 Besoins non retenus

1. PRESENTATION DE L’ETUDE ...............................................................................................................1

CODE CAHIER DES CHARGES

Réf. : (référence du document)

Historique des modifications

4.2 Reprise de l’existant

CODE CAHIER DES CHARGES

Historique des modifications

3.1 Modèle détaillé des fonctions

• la fréquence et les conditions d’édition

Post-scriptum : Enchaînement des documents de gestion de projet selon un ordre séquentiel

Historique des modifications

Version Date Etat Description

 Coûts informatiques (environnements, logiciels et matériels, ...)

Historique des modifications

En fonction de l’importance du projet, si il n’y a pas eu d’élaboration de « Dossier de choix de

• Coût de fonctionnement prévisibles

• Documentation associée (localisation, codification du projet, organisation des

CODE LETTRE DE MISSION

Commanditaire : structure ou Direction qui initie le projet et décide du lancement

Mission du Responsable de Projet :

Désignation des MOA :

Moyens alloués à la MOA :

Désignation des MOE :

Moyens alloués à la MOE :

Date : Signature du Commanditaire : Date : Signature du Responsable de

Code DOSSIER D’ANALYSE

Historique des modifications

3.2.2 Unités de traitement

• tables de contrôle à utiliser.

• Désignation : Nom du champ

• Désignation : Nom de la colonne

• les accès aux tables concernées.

• Préciser si le module est réutilisable.

• De manière générale, tout ce qui qualifie une zone de ce fichier interne

CODE Fiche de test

CONTEXTE Pièce Jointe O/N

(identification du cas traité)

ACTIONS A REALISER Pièce Jointe O/N

RESULTATS ATTENDUS Pièce Jointe O/N

CODE PROCES VERBAL DE RECETTE

Travaux faisant l’objet de la recette :

Pour la Direction MOA Pour la Direction MOE

L’intégration d’un progiciel ne se limite pas à l’installation d’un ensemble de programmes et

4.4.1 Phase de conception

4.4.2 Phase de réalisation

4.4.3 Phase de déploiement et de tests

You might also like

Coûts informatiques (environnements, logiciels et matériels, ...)