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.
Objectif
Définitions et conventions relatives aux documents
Coordonnées de l'équipe
Références
Contexte général
Vue d'ensemble du système
Références
Énoncé de mission du projet
Présentation du projet
Vision et portée du produit
Intervenants
Besoins commerciaux
Description générale
Perspective du produit
Interfaces du système
Interfaces utilisateurs
Interfaces de matériel
Interfaces de logiciels
Interfaces de communication
Contraintes du cahier des charges
Contraintes de conception
Opérations
Besoins en matière d'adaptation du site
Fonctions du produit
Caractéristiques de l'utilisateur
Contraintes, hypothèses et dépendances
Besoins spécifiques
Besoins relatifs à l'interface externe
Besoins fonctionnels
Classification des besoins fonctionnels
Partitionnement fonctionnel
Description fonctionnelle
Description du contrôle
Besoins non fonctionnels
Besoins de performance
Besoins logiques en matière de bases de données
Besoins en matière de sécurité
Attributs du système logiciel
Fiabilité
Disponibilité
Sécurité
Maintenabilité
Portabilité
Caractéristiques de l'environnement
Matériel informatique
Périphériques
Personnes
Autres
Conclusion
Annexes
Cas d'utilisation
Diagrammes architecturaux
Diagrammes de flux de données
Diagrammes d'état
Diagrammes de relations d'entités
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.
