Le cahier des charges (cdc) est un document crucial qui définit les besoins et exigences d'un projet sans proposer de solutions, se concentrant sur les fonctions à accomplir. Il joue un rôle central dans la communication entre la maîtrise d'ouvrage et les fournisseurs, précisant le problème à résoudre et les objectifs à atteindre. La qualité de ce document influence directement le succès du projet, car des erreurs peuvent engendrer des coûts élevés si découvertes tardivement.

1. Génie Logiciel
DÉFINITION DES BESOINS

2. Cahier de charges: définition
 Le Cahier des Charges (CDC) est un document par lequel la maîtrise
d'ouvrage exprime son besoin pour le projet.
 Ce besoin doit être formulé en termes de fonctions que le futur utilisateur
aura à accomplir, ou que le système devra accomplir pour lui.
 les contraintes sous lesquelles les fonctions seront exécutées et
présentées.
 Il est au centre des négociations et des échanges entre les fournisseurs et le
donneur d’ordres.
 Il définit dans quel environnement un objet fonctionne et quelle(s) fonction(s) il
doit réaliser sans apporter des solutions pour les effectuer.

3. Cahier de charges: définition
Exemple concret
 Un rétroprojecteur.
 Sa fonction est facile à trouver : réaliser la projection des informations(images, texte ou
vidéos…),
 Une contrainte pourrait être: de ne pas pouvoir projeter des informations d’un appareil
dont la résolution est inférieure à 320 x 568( pour une image ou une vidéo).
 Il est tentant d'essayer d'expliquer comment on réalisera cette fonction et
se pliera à cette contrainte. Cependant, c'est typiquement ce qu'il ne faut
pas faire.
 Dans le cahier de charges, on ne doit pas apporter de solutions de
conception, mais uniquement expliquer clairement le rôle de l'objet en
question.

4. Cahier de charges: Position dans le
cycle de vie
 Contexte :
 un problème posé chez le client (objectifs, besoins)
 Phase de définition des besoins :
 formulation de ce problème (expression des besoins)
 cahier des charges
(si cycle de vie en V : + plan de validation des besoins)
 Phase suivante : analyse des besoins
 sera la formulation d'une réponse à ce problème
 dossier d'analyse (spécifications fonctionnelles, ...)

5. Cycle de vie :modèle en cascade
(rappel)

6. Cycle de vie :modèle en V (rappel)

7. Importance du cahier des charges
Le cahier de charges:
 définit précisément le problème ou la situation à améliorer;
 identifie clairement les besoins de l'entreprise;
 précise les objectifs de l'intervention et les résultats attendus;
 établit les règles et les exigences de base pour la réalisation de l'intervention;
 présente les éléments d'une entente pouvant lier les deux parties;
 sert de document de référence pour éviter les problèmes d'interprétation;
 définit les responsabilités et les rôles respectifs des parties engagées dans
l'intervention;
 détermine les modalités de règlement en cas de litiges.
 …

8. Importance du cahier des charges
 Si erreur dans le cahier des charges
(besoin inadapté, oublié, mal exprimé, etc.)
alors coût énorme si découvert trop tard
 Élément principal d'un appel d'offres
 Élément de base pour la signature d’un contrat

9. Sources d'information pour la
réalisation du cahier des charges
 Spécification d'objectifs
 Selon la stratégie de l'entreprise(CdC ou entretien)
 Interview des utilisateurs potentiels du futur produit
 infos sur leur travail actuel (sans le nouveau produit)
 questionnaire d'observation des utilisateurs dans leurs tâches
 souhaits pour le futur environnement
 Consultation d'experts
 Tout autre document pouvant fournir des informations sur le produit à
réaliser

10. Méthodologie
Examiner la relation entre :
 le produit et l'utilisateur
 description du produit vu par l'utilisateur
→ modèle conceptuel ( analyse des besoins)
 le produit et l'environnement
 brève description du monde extérieur
 placer aussi l'utilisateur dans cet environnement

11. Forme du cahier des charges
Réf. Cahier de charges
 Séparation des concepts
= 1 concept par paragraphe
 Numérotation des paragraphes
→ facilité de référence
→ traçabilité (dans les phases ultérieures)

12. Contenu du cahier des charges
 Énoncé du problème à résoudre
 bref (un ou quelques paragraphes)
 Liste des services requis
 fonctionnalités de base
 Caractéristiques techniques du produit
 limites, performances, nombre d'utilisateurs, ressources, interfaces avec
d'autres produits, fiabilité, disponibilité, sécurité, compatibilité logicielle
/ matérielle, ...

13. Contenu du cahier des charges
 Facteurs de qualité
 par ex: performances, sécurité…
 Critères de qualité
 mesurables avec les métriques appropriées
 par ex : temps de réponse < 2s
 Priorités éventuelles

14. Caractéristiques des besoins
Les besoins doivent être:
 Précis
 problème bien délimité
 caractéristiques techniques bien définies
 formulation non ambiguë
 Cohérents
 entre eux
 avec l'environnement technique

15. Caractéristiques des besoins
Les besoins doivent être:
 Complets
 tenir compte de tous les aspects du problème
 Testables
 par une métrique
 Traçables
 suivre leur devenir dans les phases ultérieures
 Maintenables / flexibles
 comment prendre en compte les évolutions futures?

16. Confusion à ne pas faire dans la
définition des besoins
 Buts (~ intentions)
 par ex. : « système agréable à utiliser »
 problème : c'est difficile à évaluer (agréable...)
 Besoins (~ moyens)
 par ex. : « commandes activables par menu ou clavier »
(On dit aussi « exigences » / anglais : « requirements »)
 Contraintes (~ seuils / choses (im)possibles)
 par ex. : « au moins 10 connections simultanées »

17. Principales difficultés
 Trouver une formulation adéquate des besoins
 Être précis, non ambigu malgré l'usage d'un langage naturel (≠
mathématique)
 Être complet (pas d'omission involontaire)
 Être cohérent (pas d'inférence de fonctionnalités)
 Évaluer la faisabilité des besoins
 → faire éventuellement une maquette, une simulation

18. Un bon cahier des charges...
 Bon niveau de généralité
 Problème bien décrit
 Critères de validation définis
 Distinction entre besoins, buts et contraintes
 Facilité à exprimer un changement ou ajout de besoins

19. Norme IEEE/ANSI 830-1998 du cahier
des charges

20. FIN
MERCI