Cahier des charges 

CanevasCanevas	
Wallonie

Référence : 
0.2Version/Révision: 0.1  Page 1/18	

	Projet : CMM 	
Imprimé le : 	
E:\\AW-CMM\\PRODUCTIONS

Destinataires pour action
	<pilote>, <membres du comité de pilotage>

Destinataires pour information	<resp. MSI> , <resp..>

Préparé par:

  
Visa:	Approbateur :

Nom: <>
Visa:	Approbateur:

Nom:
Visa:	
Vérificateurs	Service – Equipe	Visa	
<personne ayant participé à l’offre, impliquée dans le projet mais n’appartenant pas à l’équipe projet>			
<resp. BTE>			
…			

Objet : 
Canevas de Cahier des Charges

Domaine d’application :
Après un Boscar et avant toute Offre Commerciale

Références :
<UPP- P002>
<UPP- P251>
<UPP- P250>
<document père>
<check-lists>
<guide d’utilisation>
<exemples>

Retours :

Etat :
	1er draft

	Cahier des charges 

Canevas	
Wallonie

Référence : 
0.2Version/Révision: 0.1  Page 1/18	

	Projet : CMM
Le projetCMM
	
Imprimé le : 	
E:\\AW-CMM\\PRODUCTIONS

Destinataires pour action
	<Ing d’affaire>, <membres du comité de pilotage>

Destinataires pour information	<resp. I> , <resp..>

Préparé par:

<pilote>  
Visa:	Approbateur :

Nom: <Consultant informatique>
Visa:	Approbateur:

Nom:
Visa:	
Vérificateurs	Service – Equipe	Visa	
<personne ayant participé à l’offre, impliquée dans le projet mais n’appartenant pas à l’équipe projet>			
<resp. BTE>			
…			

Objet : 
Cahier des Charges

Domaine d’application :
<…>

Références :
<document père>
<check-lists>
<guide d’utilisation>
<exemples>

Retours :
	<pilote>

Etat :
	1er draft

1.	Overview
1.1	But du document
Ce document est un cahier des charges pour le projet informatique <xxx>, relatif à la BOSCAR <xxx> et à l’ Avant-projet sommaire <xxx>.
Une brève mise en contexte introduit le cahier des charges en décrivant : 
•	Le but du document, ses références, sa terminologie et son évolution
•	une description de la demande, en terme d’objectifs et de portée (rappel résumé du P002)

Ensuite les exigences du projet, formulées par le pilote, sont structurées en 5 volets :
1.	les exigences “ fonctionnelles ” des domaines couverts par le projet, en terme de résultats d’affaires (et non en terme de solution ou résultat informatique)
2.	les exigences non-fonctionnelles liées à l’utilisation d’un système informatique
3.	les exigences d’intégration de la solution informatique dans son environnement
4.	les exigences de participation des utilisateurs et externes à l’élaboration de la solution
5.	les exigences de gestion du projet (communication de l’avancement, contrôle financier) 

Une exigence est un ensemble d’énoncés sur un domaine qui répond à au moins un des 3 critères suivants:
•	ils sont vrais indépendamment de la solution informatique (descriptif)
•	on souhaite les rendre vrai à l’aide de la solution informatique (optatif)
•	ils décrivent le comportement “ externe ” d’une solution informatique (interface utilisateur-solution)

Toutes les exigences doivent être identifiées de manière unique.

1.2	Table des matières
La table des matières ci-dessous facilite l’utilisation du canevas comme une “ checklist ”  permettant d’ éviter l’oubli de points importants de la demande. 
Pour les paragraphes que vous ne savez pas remplir, veillez à faire la distinction entre :
•	ce qui est sans objet dans le contexte de votre projet : enlevez le paragraphe
•	là où vous n’avez pas d’exigences particulières : précisez-le si utile pour la suite du projet
•	là où votre information n’est pas suffisante : précisez-le avec une date

1.	Overview	2
1.1	But du document	2
1.2	Table des matières	2
1.3	Références	4
1.4	Terminologie	4
1.5	Évolutions et approbation du document	4
2.	Description de la demande	5
2.1	Perimetre de la demande	5
2.2	Analyse de la situation actuelle	5
2.3	Objectifs généraux de l’investissement SI	5
2.4	enjeux generaux du projet	5
2.5	Portée du cahier de charges	6
3.	Exigences “ fonctionnelles ” des domaines couverts par le projet	7
3.1	Fiche de processus	7
3.1.1	“trigger”de début et fin du processus (condition de déclenchement)	7
3.1.2	objectifs du processus	7
3.1.3	description du processus	7
3.1.4	entrées ou informations à recevoir	8
3.1.5	sorties ou informations à produire	8
3.1.6	soutiens logistiques	8
3.1.7	rôles & influences	8
3.1.8	évolutions du domaine	8
3.1.9	exigences d’utilisation spécifiques au domaine	8
4.	Exigences non-fonctionnelles ou exigences d’utilisation	9
4.1	performance et disponibilité	9
4.2	securite, solidite	9
4.3	facilité d’utilisation	9
4.4	service a l’utilisateur	9
4.5	hierarchie des exigences d’utilisation	9
5.	Exigences d’intégration de la solution informatique dans son environnement	11
5.1	Contexte organisationnel d’intégration de la solution	11
5.2	Migration vers la solution	11
5.3	Intégration dans l’architecture applicative de l’utilisateur	11
5.4	Intégration dans l’infrastructure informatique de l’utilisateur	11
5.5	Intégration dans l’environnement de service (operation, administration, help desk)	11
5.6	Intégration dans l’environnement futur de moyen terme (applicative, infrastructure et service)	11
6.	Exigences de participation des utilisateurs et externes àu projet	12
6.1	vue globale des intervenants au projet	12
6.2	Suivi des intervenants externes	12
6.3	Participation des utilisateurs a la conception de la solution	12
6.4	Préparation a l’accueil de la solution	12
6.4.1	Exigences d’environnement et de gestion du changement	12
6.4.2	Les tests fonctionnels (ou de validation)	12
6.4.3	La réception en production	12
6.4.4	La période de garantie et le transfert en maintenance	13
7.	Exigences de gestion du projet	14
7.1	Exigences de gestion	14
7.1.1	la durée	14
7.1.2	le délai	14
7.1.3	le budget	14
7.1.4	la qualité	14
7.2	Exigences de planning et de suivi	14
7.2.1	Exigences concernant les jalons et livrables	14
7.2.2	Exigences de suivi du projet	14
7.2.3	Exigences de revues	14
7.3	Gestion des engagements	14
7.3.1	Exigences de la prestation	14
7.3.2	Exigences de gestion des avenants au cahier des charges	15
Annexes	16

1.3	Références
	Titre	Edition / date	Réf.	
DOC.1	BOSCAR			
DOC.2	APS			
DOC.3				

Dans le cadre d’un cahier des charges à soumettre à des sous-traitants extérieurs au groupe -, il faut envisager la référence à un contrat ou la description de clauses contractuelles et juridiques non mentionnées à ce stade-ci.

1.4	Terminologie
Cette section décrit brièvement (2 lignes maximum), d’une part  le vocabulaire spécifique au domaine, et d’autre part les abréviations couramment utilisées ainsi que  les sigles et acronymes. 
Si la liste est longue, ces deux aspects peuvent se trouver dans deux tableaux différents et triés chacun par ordre alphabétique.

1.5	Évolutions et approbation du document
<Décrit comment on peut amender ce document>
Le présent document est sous la responsabilité de <pilote> chargé du projet. Après approbation d’un conseiller de l’informatique, ce document est figé pour être la base de référence d’une offre commerciale. 

En cas d’évolution majeure dans la demande (changement de pilote, transformation importante du contexte, …), le cahier des charges doit faire l’objet d’un changement de version qui provoquera une nouvelle offre commerciale. Les différentes versions de ce document sont conservées dans l’historique du projet.

2.	
Description de la demande
<NB : ce chapitre comprends des informations globale sur la demande initiale et ne couvre donc pas d’exigences spécifiques ou détaillées ni d’hypothèses sur la solution.>

C’est une copie, qui peut être résumée, du P002 ou faire simplement un renvoi au P002.

2.1	Périmètre de la demande
<NB : à décrire si pas déjà inclus dans l’énoncé de projet P002>

Les intervenants, demandeurs d’un système d’information (responsables de services et futurs utilisateurs):
•	départements (avec éventuellement un organigramme de ces départements en annexe)
•	personnes, rôles, coordonnées de contact (tel, email) pour le pilote et les utilisateurs clés
•	externes: sociétés (nom, adresse; personne de contact)
Schéma du/des processus à couvrir dans le projet
Diagramme de contexte externe et de communication avec l’environnement 
Description de ce qui n’est pas couvert dans le projet

2.2	Analyse de la situation actuelle
<NB : à décrire si pas déjà inclu dans l’énoncé de projet P002>

Brève description de la situation actuelle : contraintes, risques, incidence
Liens à d’autres projets
Hypothèses de changement du contexte : évolutions en cours, ou probables, ou souhaitées

2.3	Objectifs généraux de l’investissement SI
<NB : à décrire si pas déjà inclus dans l’énoncé de projet P002>

Les objectifs sont les cibles stratégiques de long terme à atteindre grâce aux moyens que fourniront les résultats attendus du projet. Pas plus de 5 objectifs concrets et mesurables

Les objectifs sont souvent de 4 ordres : 
1.	de contribution globale à l’entité “ supérieure ”, plus globale dirigeant le(s) processus
2.	d’excellence opérationnelle, performance,  productivité (rapidité et qualité de réalisation en regard de l’effort mis en œuvre)
3.	de déploiement des services aux  “clients” du/des processus, niveau et étendue (variété)  des services rendus
4.	d’innovation et d’apprentissage

Pour chaque objectif,  il est utile de décrire :
•	facteurs de réussite: atouts et faiblesses internes au contexte (organisationnel, culturel, budgétaire)
•	enjeux externes : opportunités et risques de l’environnement (politique, légal, technologique)
•	bénéfices escomptés
•	indicateurs et mesures de réalisation de l’objectif

2.4	enjeux generaux du projet
<NB : à décrire si pas déjà inclus dans l’énoncé de projet P002>

Les enjeux sont à décrire selon leur criticité pour le projet :
•	délais de mise en œuvre
•	budget
•	contraintes techniques
•	points ou problèmes non résolus et en attente
•	actions  nécessaires avant toute décision
•	idées de solution et progiciels connus
•	documents et information à disposition des intervenants

2.5	Portée du cahier de charges 
Le cahier des charges peut couvrir l’entièreté ou une partie de la demande décrite dans le P002 ou dans le paragraphe “ 2.1 périmètre de la demande ”

Le cahier des charges peut aussi couvrir :
•	la réalisation d’un prototype pour “ essayer ”  une technologie ou un processus innovant
•	l’expression d’un besoin qui aboutira à la conception d’un ou plusieurs scénarios de solution
•	la mise en œuvre et le déploiement d’une conception réalisée suite à un cahier des charges antérieur

La portée du cahier des charges peut être envisagé sur des  plans  “ hiérarchiques ” de plus en plus opérationnels  : 
1.	processus, 
2.	fonctions, 
3.	activités,
4.	tâches

<NB : pour les informaticiens habitués à la terminologie de COOLGEN, veillez à ajuster le vocabulaire ;  un “ processus ”  de COOLGEN est au niveau “  activité ”  dans ce document-ci>

Il est utile de mettre en évidence :
•	l’ampleur du projet : nombre de domaines, divisions et processus concernés
•	les interactions entre les domaines concernés
•	les liens avec les autres domaines (non concernés), manuels ou automatisés
•	les lieux de changements par rapport à la situation actuelle
•	les applications impliquées dans le changement
•	les hypothèses à vérifier, les présupposés sur la situation de départ, 
•	les points critiques: inconnues, blocages potentiels, pointes saisonnières, goulet d'étranglement, nœuds de relations, innovations  

3.	
Exigences “ fonctionnelles ” des domaines couverts par le projet
Le niveau de détail et de précision de la description est à apprécier par le rédacteur selon :
•	qu’il permette à ses destinataires de l’informatique de développer une offre commerciale suffisamment précise en termes d’engagements de ressources pour réaliser la demande
•	qu’il fournit des éléments de mesure permettant de  vérifier que ce qui a été réalisé satisfait aux exigences 
•	qu’il existe ou non un progiciel sur le marché répondant aux exigences
•	que la connaissance du domaine couvert est interne ou externe à l’environnement immédiat de ceux qui répondront au cahier des charges (dans le groupe -, à -, à Flémalle, …)
•	que cette description a déjà été réalisée dans d’autres documents (par exemple dans un projet antérieur)
•	qu’il y aura lieu de faire une analyse conceptuelle et fonctionnelle plus détaillée par la suite

Pour ce chapitre, le rédacteur s’appuiera sur :
•	le livrable UPP – P251 pour les processus et/ou P250 pour les fonctions
•	les techniques et outils de modélisation en vigueur dans les départements : VISIO, UML, Rational Rose, … 

Décrire chaque processus concerné dans une  “ fiches de processus”  contenant par exemple les rubriques comme proposées ci-dessous.

3.1	Fiche de processus
<NB : Pour faciliter la compréhension , quelque soit le plan “ hiérarchique ”  considéré (processus, fonction, activité, tâches), nous parlons ici de processus. Vous apprécierez pour votre projet l’utilité de documenter des “ fiches de fonction ”, “ fiches d’activités ” et “ fiches de tâches ”>

Ne pas détailler à ce stade-ci (sauf pour lever une ambiguïté) :
•	les données ou informations
•	les écrans ou listes à produire
•	les règles de fonctionnement ou de calcul interne
Ces éléments font partie de l’étape d’analyse de la solution informatique

Lorsque la description fournit un niveau de détail trop important en regard de l’objectif du cahier des charges, veillez à extraire cette description  pour l’introduire dans les documents des phases ultérieures de conception ou d’analyse fonctionnelle. 

3.1.1	“trigger”de début et fin du processus (condition de déclenchement)
•	démarrage  par qui, sur quelle base,… 
•	ce qui officialise la fin

3.1.2	objectifs du processus
•	décisionnels, 
•	opérationnels, 
•	vérification 
•	encadrement

3.1.3	description du processus
•	la documentation disponible et son état de mise à jour
•	la nature principale du processus (de gestion ou d’exécution opérationnelle),
•	l’enchaînement ou séquence de fonctions, cycle opérationnel et temporel,
•	la traçabilité des informations et des opérations
•	le degré d’informatisation et d’ interaction avec les actions “ manuelles ”,
•	les progiciels et  applications à remplacer ou à interfacer
•	le degré de centralisation / décentralisation géographique et organisationnelle des utilisateurs
•	les solutions alternatives (non informatiques) envisagées ou à envisager : organisations, procédures de travail, autres technologies, échange accru d’informations
•	l’importance du processus dans la solution informatique : 
•	obligatoirement “ tel quel ”, 
•	adaptable (en fonction du coût par exemple), 
•	“ de confort”
•	les processus de décision : niveaux de décisions,  lieux de prise de décision, moyen de communication de la décision, indicateurs de performance du domaine et moyens de les mesurer
•	la volumétrie : nombre de personnes impliquées, nombre de transactions par type, objets traités

3.1.4	entrées ou informations à recevoir
•	information ou action en direct sur le “cœur” du processus, 
•	pour chaque groupe  d’informations : type, source(s), volume, fréquence d’accès
•	ressources humaines et  techniques, 
•	présupposés ou hypothèses de départ

3.1.5	sorties ou informations à produire 
documents ou  résultats en terme d’information et du rôle de cette information pour les principaux destinataires (mais non pas en terme d’écran ou de liste)
•	information ou action en direct sur le “coeur” du processus, 
•	pour chaque groupe  d’informations : type, source(s), volume, fréquence de production

3.1.6	soutiens logistiques
ressources indirectes, mais nécessaires au processus :
•	bâtiments (badge d’accès, parking , …)
•	bureaux et services associés (nettoyage, café, ..)
•	facilités : téléphone, connexions réseaux, imprimantes,….

3.1.7	rôles & influences
•	propriétaire du processus, niveaux hiérarchique dans l’organisation, 
•	influences et responsabilités dans le processus : consulter, informer, décider, valider
•	qui oriente l’évolution du processus, qui mesure son efficacité

3.1.8	évolutions du domaine
•	maturité dans la connaissance et la compréhension du processus
•	stabilité du processus
•	évolution probable à court , moyen et long terme et jalons

3.1.9	exigences d’utilisation spécifiques au domaine
< exigences d’utilisation telles que décrites au chapitre 4, mais spécifiques au processus et en discordance avec les exigences d’utilisation globales du chapitre 4)

4.	
Exigences non-fonctionnelles ou exigences d’utilisation  
<rempli par le pilote ou responsable des utilisateurs suite à sa propre analyse>

<NB : Il est probable que dans un environnement d’application mainframe la plupart de ces exigences ne sont pas nécessaires>

Ces exigences d’utilisation sont exprimées en utilisant la terminologie et les indicateurs des processus couverts et de leurs utilisateurs. Il sont décrits ici pour l’ensemble de la solution ; pour les exigences spécifiques à un processus, mentionnez-les dans la “  fiche de processus ”

Pour rendre ces critères opérationnels dans le projet, il est utile de décrire pour chacune de ces exigences :
•	le contexte de l’exigence
•	la formalisation de l’exigence : une norme, un chiffre, une technique d’appréciation
•	un moyen de mesurer l’atteinte de cette exigence

4.1	performance et disponibilité
•	catégories d’utilisateurs et nombre d’utilisateurs “concurrents” par catégorie,
•	volumes critiques des principales informations, pointes saisonnières dans le cycle temporel du processus,
•	temps de réponses critiques (sec/transaction ou nombre de transaction/minute)
•	délais optimal entre deux activités clés
•	disponibilité (quotidienne, hebdomadaire) souhaitée, continuité ou plan de secours en cas d’arrêt 

4.2	securite, solidite
•	sécurité d’accès au système pour les différents groupes d’utilisateurs et les informaticiens 
•	confidentialités des informations et autorisation sur les fonctions 
•	normes et standards à respecter (ISO, IEEE, …)
•	intégrité de l’information :  transparence (logging ou traçage et sauvegarde) des modifications
•	continuité du système : fréquence et criticité des copies de sauvegarde et plan de secours
•	durée de vie souhaitée du système, qualité et fiabilité du système 

4.3	facilité d’utilisation
•	“ maturité informatique ” des principaux utilisateurs et “ profil type ” par groupe d’utilisateur
•	standards actuels d’interface utilisateur et/ou référence à un prototype d’interface utilisateur 
•	convivialité de l’interface utilisateur (apparence à l’écran) et des documents imprimés
•	facilité d’apprentissage : formations, assistance à l’écran, documentation externe
•	convivialité de navigation : vision globale, “ hélicoptère ”  (menu principal vers transaction spécifiques et inversement) et transversale (entre transactions de “ branches ” différentes)

4.4	service a l’utilisateur
•	En conseil dans la définition de la solution,
•	En assistance à l’installation, 
•	En formation & documentation,
•	En assistance téléphonique à l’utilisateur

4.5	hierarchie des exigences d’utilisation
Le but de ce paragraphe est de prioriser les exigences d’utilisation. Ceci est  utile lorsque les exigences ont un aspect antinomique ou sont contradictoires dans leur réalisation informatique.
Décrivez les principes fondateurs et poids relatif des exigences non-fonctionnelles 
Un tableau permet de prioriser des exigences potentiellement contradictoires (voir annexe)
•	soit un arbre de critère à deux niveaux, soit un tableau de critère avec pour chacun une pondération (en %)
•	le plus souvent les deux combinés : arbre pondéré à chaque niveau de branche (deux niveaux suffisent)
5.	
Exigences d’intégration de la solution informatique dans son environnement 
<rempli par le pilote assisté ou non d’un “ conseiller en informatique ”>

5.1	Contexte organisationnel d’intégration de la solution
<description générale, diagramme de contexte de la solution>
Le contexte organisationnel sera-t-il maintenu ?, qui va assurer son changement ?
•	implication  dans les responsabilités, tâches, rôles
•	implication dans les structures de pouvoir, dans les processus de décisions
•	implication de recrutement et formation de personnes
•	implication d’écriture de procédures et d ‘instructions de travail 

5.2	Migration vers la solution
•	les pré-requis technologiques (non informatiques) et contraintes de coordinations temporelles
•	la reprise des informations du passé, dimension temporelle de l’archivage des informations
•	l’abandon progressif de(s) application(s) du passé 
•	planning de migration des processus environnants informatisés ou non

5.3	Intégration dans l’architecture applicative de l’utilisateur
•	position de la solution dans l’architecture globale des systèmes d’information (applications)
•	interfaces “ applications ” à développer
•	partage d’informations, de fichiers, de Data Base,…
•	coordination avec des avenants dans les applications “ voisines ”
•	interfaces avec d’autres logiciels : e-mail, inter/intra net, voice/GSM, ..

5.4	Intégration dans l’infrastructure informatique de l’utilisateur
Par infrastructure informatique, il faut comprendre tout élément de configuration : mainframe, serveurs, réseau,  terminaux, PC, imprimantes, logiciels, utilitaires, …
•	standards “ maison ” : marge de manœuvre par rapport à ces standards
•	investissements d’infrastructure à préserver : nombre, âge, caractéristiques
•	partage / “ cohabitation ” de l’infrastructure informatique  avec d’autres systèmes
•	capacités et limites de la configuration actuelle

5.5	Intégration dans l’environnement de service (operation, administration, help desk)
•	dossier d’opération du système (ex : lancement de programmes occasionnels,  paramétrage)
•	sauvegarde et recouvrement (ex : timing des sauvegardes)
•	plan de secours
•	contraintes éventuelles à l’opération de la solution ( ex contraintes d’archivage)

5.6	Intégration dans l’environnement futur de moyen terme (applicative, infrastructure et service)  
•	degré de souplesse et d’ouverture de la solution pour y inclure les avenants (préciser les thèmes) 
•	 portabilité éventuelle de la solution sur une plate-forme informatique différente de la plate-forme initiale
6.	
Exigences de participation des utilisateurs et externes àu projet
<rempli par le pilote assisté ou non d’un “ conseiller en informatique ”  

Dans ce chapitre, les paragraphes ne sont à compléter que si ce sont des exigences particulières au projet et qui ne correspondent pas à la façon habituelle de travailler d’- SI – ASC Wallonie

6.1	vue globale des intervenants au projet
•	utilisateurs, fournisseurs de produits et de service, service achat, conseillers externes
•	lieux, moments et niveaux de participation, bénéfices attendus de la participation
•	organisation : le rôle du pilote et des intervenants clés

6.2	Suivi des intervenants externes
•	suivi des sous-traitants et consultants externes dans leurs interactions avec les départements
•	suivi des commandes et réceptions pour les achats liés à l’élaboration de la solution

6.3	Participation des utilisateurs a la conception de la solution
•	nombre de solutions alternatives demandées  
•	hypothèses de conception, options à envisager
•	méthode ou procédé de conception 
•	organisation de la conception :  
•	profils des acteurs “ non-informatiques ”
•	rôles et niveau de participation des départements impliqués, 
•	noms et disponibilités des personnes à impliquer dans la conception 
•	validation de l’analyse effectuée et des prototypes éventuels : qui, quand, comment
•	documentation des évolutions et avenants en regard de la demande initiale : où, par qui, comment

6.4	Préparation a l’accueil de la solution
6.4.1	Exigences d’environnement et de gestion du changement
•	préparer l’environnement logistique et technique à l’accueil du nouveau système 
•	organiser le changement dans les départements utilisateurs:
•	sessions de sensibilisation,
•	 documentation et moyens d’information , 
•	 formations et “ coaching ” des futurs utilisateurs du système
 
6.4.2	Les tests fonctionnels (ou de validation)
•	environnement de test fonctionnels
•	hypothèses de test et niveau de qualité exigé 
•	plan de test : activités, résultats, calendrier des tests
•	organisation des tests fonctionnels:  
•	profils des acteurs “ non-informatiques ”
•	rôles et niveau de participation des départements impliqués, 
•	noms et disponibilités des personnes à impliquer dans les tests

6.4.3	La réception en production
•	organisation et planning de réception en production
•	formation et mise en place des ressources
•	critères de réception,  “ officialisation ” des réceptions : noms, documents
•	engagements et contraintes liées à la période de mise en production

6.4.4	La période de garantie et le transfert en maintenance
•	organisation et planning de la garantie et modalités organisationnelles de cette période
•	formation et mise en place des ressources
•	critères de transfert en maintenance
•	engagements  et contraintes liées à la période de transfert en maintenance

7.	Exigences de gestion du projet 
<rempli par le pilote assisté ou non d’un “ conseiller en informatique ”  
Dans ce chapitre, les paragraphes ne sont à compléter que si ce sont des exigences particulières au projet et qui ne correspondent pas à la façon habituelle de gérer un projet à - SI – ASC Wallonie

7.1	Exigences de gestion
7.1.1	la durée
•	durée attendue de l’élaboration de la solution
•	taux de disponibilité des ressources à impliquer

7.1.2	le délai 
•	niveau d’ urgence opérationnelle, impact d’un retard dans la mise en œuvre de la solution
•	ajustement à  l’environnement :légal, politique, culturel, social, technologique et technique (e.g.  EURO)

7.1.3	le budget
•	référence à une analyse coût-bénéfice, à un “ business case ”, à un calcul de “ retour sur investissement ”..
•	étalement du budget sur les exercices budgétaires, …
•	budget d’investissement global, hardware et/ou progiciel
•	budget  par livrable, par année
•	budget particulier de la période de transition ou autre coût additionnel attendu
•	budget d’exploitation et de maintenance : fixes et variables (par nbr d’utilisateur, par volumes de transactions) 

7.1.4	la qualité 
•	conformité à des normes et standards de qualité

7.2	Exigences de planning et de suivi
7.2.1	Exigences concernant les jalons et livrables
<séquence et timing des livraisons>

7.2.2	Exigences de suivi du projet
<périodicité des réunions, intervenants, thèmes du suivi : avancement, coût, qualité, risques, points en suspens>

7.2.3	Exigences de revues
<périodicité des revues , critères d’évaluation, intervenants>

7.3	Gestion des engagements
7.3.1	Exigences de la prestation
•	 le lieu et les  modalités de prestation (sous responsabilité de qui)
•	la mesure  de conformité au cahier des charges 

7.3.2	Exigences de gestion des avenants au cahier des charges
•	spécificités de gestion des avenants
•	date de limite de validité du cahier des charges

Annexes
<rempli par le pilote assisté ou non d’un “ conseiller en informatique ” 
< mettre ici tout ce qui 
-	n’est pas “ exigences ”, mais permet de mieux les comprendre 
-	alourdirait le texte 
-	permet de lever des ambiguïtés>

MISES A JOUR
	
Date
	Version	Auteur(s)	Commentaires	
03/05/2001
	0.1	C. Gallez	Version initiale	
 
	0.2