• 8 heures
  • Moyenne

Ce cours est visible gratuitement en ligne.

course.header.alt.is_video

course.header.alt.is_certifying

J'ai tout compris !

Mis à jour le 04/01/2021

Comprenez les avantages d’un cahier des charges fonctionnel

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

Nous avons vu comment rédiger de la documentation. Entrons dans le vif du sujet de ce cours et parlons du cahier des charges fonctionnel.

Donnez une définition du cahier des charges

Un cahier des charges peut être défini comme un résumé des faits, des constatations et des objectifs visant à fournir au lecteur un bref aperçu au niveau d'un plan, d'une situation ou d'un projet.

L'utilisation du cahier des charges comme base de la documentation agile est logique. De par sa nature, un cahier des charges vise à fournir juste assez d'informations pour que le lecteur puisse faire son travail. Il ne s'agit pas d'une représentation détaillée et exhaustive d'un projet. Cependant, cela ne signifie pas qu'un cahier des charges est un document agile. Il peut être utilisé dans une configuration agile ou non.

Découvrez les différents types de cahier des charges

Il existe différents types de cahier des charges mais 4 sont très courants :

  • recueil des besoins commerciaux (dans certains cas) ;

  • cahier des charges fonctionnel ;

  • brief créatif ;

  • cahier des charges technique ;

Dans ce cours, je vais me concentrer sur le cahier des charges fonctionnel. C'est parti !

Faisons un tour d’horizon de ces cahiers des charges.

Découvrez le cahier des charges fonctionnel

Le cahier des charges fonctionnel n’est généralement pas écrit par le client, mais plutôt par le chef de projet. Le client peut préparer un cahier des charges pour l'agence de développement, ou le chef de projet peut mener des entretiens avec le client afin de déterminer les besoins du projet. Le chef de projet prépare ensuite le cahier des charges fonctionnel, qui est un résumé du projet que le client a demandé et qui est présenté au client pour vérification et approbation. Cela donne au client l'assurance que le chef de projet comprend exactement ce qu'il veut et sert d'énoncé de ce qui sera livré.

Dans ce cours, nous allons nous concentrer sur le cahier des charges fonctionnel et apprendre comment le rédiger et le présenter à votre client, en fonction des informations qui sont fournies par ce dernier.

Que ce soit un cahier des charges à destination de la communication ou un cahier des charges fonctionnel, les deux contiennent à peu près les mêmes informations.

La différence réside dans l'orientation de la campagne de marketing par rapport aux besoins de l'entreprise.

Découvrez la différence entre un cahier des charges et des spécifications techniques de besoins logiciels

Cela fait un moment que je vous répète que les cahiers des charges sont courts.

Oui… Effectivement, cela fait plusieurs fois que tu nous le dis. Mais pourquoi insister autant ?

Eh bien, parce que c’est exactement le contraire d’un document de spécifications techniques de besoins logiciels, ou SRS (software requirements specifications, en anglais).

Ce type d'artéfact est un vestige des méthodologies de gestion de projet en cascade. C'est un document coûteux à produire parce qu'il exige que l'ensemble du projet soit planifié à l'avance et de façon exhaustive. Le problème, c'est que les projets logiciels se déroulent rarement, voire jamais, exactement comme prévu. Lorsque des changements surviennent et que le projet commence à évoluer, l'ensemble du document SRS doit être révisé ou réécrit, ce qui signifie généralement des séances de planification longues et coûteuses pour discuter des changements et de leurs effets sur les autres aspects du projet.

Pour vous donner une idée de la façon dont un tel document peut rapidement devenir un problème aussi coûteux, voici un aperçu structurel d'un document SRS typique.

  1. Objectif

    1. Définitions et conventions relatives aux documents

    2. Coordonnées de l'équipe

    3. Références

    4. Contexte général

    5. Vue d'ensemble du système

    6. Références

  2. Énoncé de mission du projet

    1. Présentation du projet

    2. Vision et portée du produit

    3. Intervenants

    4. Besoins commerciaux

  3. Description générale

    1. Perspective du produit

      1. Interfaces du système

      2. Interfaces utilisateurs

      3. Interfaces de matériel

      4. Interfaces de logiciels

      5. Interfaces de communication

      6. Contraintes du cahier des charges 

    2. Contraintes de conception

      1. Opérations

      2. Besoins en matière d'adaptation du site

    3. Fonctions du produit

    4. Caractéristiques de l'utilisateur

    5. Contraintes, hypothèses et dépendances

  4. Besoins spécifiques

    1. Besoins relatifs à l'interface externe

    2. Besoins fonctionnels

      1. Classification des besoins fonctionnels

      2. Partitionnement fonctionnel

      3. Description fonctionnelle

      4. Description du contrôle

    3. Besoins non fonctionnels

    4. Besoins de performance

    5. Besoins logiques en matière de bases de données

    6. Besoins en matière de sécurité

    7. Attributs du système logiciel

      1. Fiabilité

      2. Disponibilité

      3. Sécurité

      4. Maintenabilité

      5. Portabilité

    8. Caractéristiques de l'environnement

      1. Matériel informatique

      2. Périphériques

      3. Personnes

    9. Autres

  5. Conclusion

  6. Annexes

    1. Cas d'utilisation

    2. Diagrammes architecturaux

    3. Diagrammes de flux de données

    4. Diagrammes d'état

    5. Diagrammes de relations d'entités

    6. Autres

Vous voyez pourquoi un tel document est très coûteux en temps et en ressources ? Le projet doit être planifié dans son intégralité, jusque dans les moindres détails, avant même que la conception ou le développement n’aient eu lieu.

Et je ne vous parle même pas du coût d’une petite modification en milieu de projet.

Les méthodologies agiles suppriment le SRS au profit de documents beaucoup plus courts qui contiennent juste assez d'informations et qui sont produits juste à temps pour être utilisés. Ce modèle constitue naturellement un support efficace pour l'évolution des projets et de la documentation. Si des modifications sont apportées, seules de petites modifications dans la documentation seront nécessaires, et les documents suivants seront écrits avec les modifications déjà appliquées.

En résumé

  • Un cahier des charges est un résumé des faits, des constatations et des objectifs visant à fournir au lecteur un bref aperçu haut niveau d'un plan, d'une situation ou d'un projet.

  • Il existe des cahiers des charges marketing et des cahiers des fonctionnels Quand il est utilisé dans le cadre d'un projet de développement agile, le cahier des charges fonctionnel est souvent rédigé par le chef de projet et présenté au client pour vérification et approbation. Il fournit :

    • un résumé du projet demandé par le client.

    • l'assurance que le chef de projet comprend exactement ce que l'on attend de lui.

    • un énoncé de ce qui doit être livré.

Maintenant, résumons ce que vous avez appris dans la première partie de ce cours, après quoi vous pourrez terminer la première partie en remplissant le quiz de la première partie.

Exemple de certificat de réussite
Exemple de certificat de réussite