| ||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
Le terme "cahier des charges" "scope statement" est un terme générique pour désigner un document qui fera office de contrat entre deux parties. Dans le cadre de notre vision systèmes d'information, le cahier des charges est un document contractuel qui fait le lien entre les spécifications détaillées du système d'information et les équipes de développeur (Informaticien). C' est aussi un document qui va lier la Maîtrise d'ouvrage à la Maîtrise d'oeuvre.
De nombreuses normes existent : AFNOR, DoD
Un cahier des charges est un document contractuel qui va relier deux parties entre elles : La maîtrise d' ouvrage d' une part, qui maîtrise le métier, et la maîtrise d' oeuvre qui maîtrise les techniques informatiques (applicative, réseau, etc..) d'autre part.
Ce document est contractuel ce qui signifie qu' il doit être rédigé très précisément puisqu'il peut servir de document contradictoire en cas de litige.
Notons que ce terme "cahier des charges" est surtout utilisé pour décrire des applications, qui sont par définition l' unité de travail des informaticiens.
La norme AFNOR NF X 50 151
Identification Cahier des charges fonctionnel
Destinataires.
Objet
Exercice N° 38 : QCM cahier des charges.
1) Le cahier des charges est :
2) Il existe plusieurs catégories de cahier des charges :
3) Le mot "charges" vient de :
Compléments : Il existe plusieurs formes de cahiers des charges :
Le cahier des charges fonctionnel.
C'est un cahier des charges d'assez haut niveau, il va confier un travail spécifié de manière assez globale et laisser une part d'initiative importante à la maîtrise d'oeuvre.
Le cahier des charges détaillé.
C'est un cahier des charges beaucoup plus précis, qui va tenter de décrire totalement les éléments de la solution applicative proposée.
Exemple de cahier des charges :
Dans le cadre de la bibliothèque, le cahier des charges va décrire les spécifications fonctionnelles et les spécifications non fonctionnelles exigées (requirement) par la bibliothèque.
Ces choix vont s'imposer aux informaticiens qui devront développer une solution technique à partir de ce document, et faire en sorte que les exigences soient satisfaites, tant sur le plan fonctionnel que sur le plan non fonctionnel (Temps de réponse, sécurité, etc..) .
Dans ce cadre la notion de cahier des charges engage les deux parties (les hommes du métier, commanditaires du projet ou encore maîtrise d' ouvrage, et les techniciens comme les informaticiens ou les hommes réseaux).
Titre : Le Cahier des charges d'une application informatique : l'expression des besoins de l'utilisateur Auteur : Benard, Christian / Editeur : Paris , 1990 Coll. Hommes et Techniques
Titre : UML pour l'analyse d'un système d'information : le cahier des charges du maître d'ouvrage Auteur : Morley, Chantal / Hugues, Jean / Leblanc, Bernard / Editeur : Paris : Dunod , 2000 Informatiques -
http://normesenligne.afnor.fr/cgi-bin/normesenligne.storefront/1518594340/Ext/FicheProduit/NF027433
Plan-type d'un cahier des charges :
Cahier des charges fonctionnelles :
Contexte et objectifs.
Domaines et limites.
Contraintes.
Expression fonctionnelle du besoin.
Exigences qualité.
Annexes
Contenu détaillé du cahier des charges fonctionnelles.
(Norme Afnor X50 151)
Exercice N° 39: description d'une partie d'un cahier des charges.
INT entreprises propose plusieurs dizaines de stages aux entreprises. Pour des raisons d'efficacité, on souhaite permettre les inscriptions par internet, elles se font actuellement par fax, courrier ou téléphone, .
Périmètre.
Il s'agit d'automatiser les gestion des inscriptions des stagiaires aux différents stages. On exclut du périmètre les éléments de gestion de cours (planning, facturation, attestation,..).
Expression du besoin :
Le système doit permettre de :
Présentation du projet
Le besoin et son marché :
- Etudes déja effectuées.
- Suites prévues.
- Caractère confidentiel.
- Insatisfactions rencontrées sur des produits semblables.
- Nature de la prestation demandée.
- Personnes concernées par le déroulement du projet et des ses résultats.
Informations et documentations
Validation du besoin
Exemple : Le cas Gestion des devis.
Ceci est un cahier des charges réel sur une application de devis d' une entreprise de transport qui souhaitait faire des devis en ligne.
Gestion et management de projet multimédia : du cahier des charges à la commercialisation Auteur : Milon, Alain / Cormerais, Franck / Editeur : Paris : L'Harmattan , 1999 Communications en pratique -
La cahier des charges doit impérativement rappeler les objectifs, en effet, le document va être transmis à un certain nombre de sociétés qui peuvent devenir prestataires en réalisant le travail demandé, après avoir accepté de signer le cahier des charges.
Le rappel des objectifs va donc, permettre aux prestataires de mieux comprendre le pourquoi de ce travail, les finalités.
Contenu du cahier des charges
Les objectifs sont, nous l' avons vu, dans toute la mesure du possible exprimés de manière assez abstraite (synonyme de stratégie ou de tactique). C'est dans ce cadre que le rappel des objectifs prend toute son importance, puisqu' un prestataire potentiel pourra toujours comprendre pourquoi une telle mission.
La compréhension du contexte est sans doute un des éléments fondamentaux dans l' acceptation et la réalisation d' un cahier des charges.
La différence entre objectifs et besoins.
Cette différence est intéressante à noter . Elle apporte des compléments aux concepteurs, puisque dans tous les cas de figures, il est important de revenir ( si celà n'est pas déjà fait) aux objectifs.
Un objectif doit être défini par une idée relativement générale, qui ne donne pas à priori d' élément de réponse (organisationnel ou technique). L' intérêt de faire apparaître un objectif est que la pensée du concepteur en termes de solutions organisationnelles et techniques n'est pas contraintes fortement par les objectifs.
Exemple :
Le besoin est beaucoup plus précis, il correspond à un besoin en information pour une personne déterminée /
Exemple :
Les objectifs de la bibliothèque sont :
MERISE et le cahier des charges Auteur : Collongues, Alain / Laroche, Bernard / Editeur : Paris : Dunod , 1991 Dunod-Informatique
Résumé de la problématique
La problématique doit être rappelée dans chaque communication concernant un projet. Elle est indispensable pour comprendre le problème, les solutions, les synthèses. Intellectuellement, elle rappelle à chaque fois à celui qui conçoit pourquoi il fait tous ces efforts.
Il est donc indispensable de ne jamais perdre de vue ( dans ses idées en tous cas) ce pour quoi on travaille.
Les méthodes utilisées s'apparentent dans tous les cas à de la gestion de problèmes.
Compléments :
La problématique se décline souvent sur plusieurs niveaux d'abstraction :
Un niveau conceptuel (stratégique) : Notion de finalité, vision à long terme, idée générale sur le problème.
Un niveau plus organisationnel ( tactique) : notion de besoin, vision à court terme, idée précise sur le quoi faire en termes "organisés".
Exercice N° 41 : Expression de la problématique.
Dans l'exercice 18, exprimer une problématique stratégique. Compléter à l'aide d'une problématique opérationnelle.
Résumé des enjeux :
Un complément naturel au rappel sur la problématique est d'avoir une vision externe de celle-ci. Nous pouvons appeler celà les enjeux. Le marché nécessite de la part des entreprises, une adaptation permanente à celui-ci. Cette adaptation nécessite de bien comprendre le contexte (l'environnement, le positionnement) de l'entreprise dans son secteur d'activité.
Par exemple, dans le secteur des transports, les enjeux de demain sont snas doute Européen (Extension du marché, favorisation des gros transporteurs), mais aussi écologiste (Accès au ferroutage, puissance du corant écologiste en Europe,etc.)
Résumé de la problématique de la bibliothèque :
La bibliothèque a une problématique stratégique :
Sur le plan organisationnel, la problématique est de :
Qu'est ce que la description d'une solution détaillée :
Il s'agit de décrire en détail, tous les aspects de la solution, puisqu'il faut éviter toute ambiguité.
Ces spécifications détaillées vont permettre aux informaticiens d'exploiter ces informations pour les traduire en machine, dans une phase appelée codage ou implementation. Il est important que la solution détaillée soit complète de manière à ce que la MOA reste responsable de ce qu'elle veut faire, et d emanière également à ce que la MOE puisse se concentrer sur les problèmes de développement et n'ait pas à revenir sur les problèmes de spécification..
Outils et méthodes pour la solution détaillée :
Les outils utilisés vont être des structures déja définies ( le plus souvent dans des méthodes propriétaires).
Exemple de structures :
Les méthodes permettent de savoir exactement ce que nous devons décrire. Les traitements, par exemple obéissent à des règles de description de chacun des éléments issus du découpage fonctionnel. pour chacun de ses traitements, il sera enviagé l'impact sur les données, les effets de bords (Mise à jour d'une information avec des conséquences sur d'autres informations).
Complément de la solution détaillée : exigences non fonctionnelles :
Les exigences non fonctionnelles portent sur des aspects non liés directement et spécifiquement au projet.
exemple :
Description d'une partie de la solution détaillée de la bibliothèque :
Description du traitement " demande de livres".
La décomposition fonctionnelle donne un ensemble de tâches pour cette fonctionnalité "traitement de la demande de livres".
Description de l'enregistrement du prêt :
Pré-condition:
Toutes les vérifications sont OK.
Tâche:
Création d'une donnée prêt ( N° abonné, N° livre, datePrêt, duréePrévue).
Post-Condition:
Faire + 1 dans le nombreLivreEnCoursDePrêt (abonné).
nombreLivreEnCoursDePrêt doit rester < à 4.