ou comment réussir son projet applicatif ?

Derrière le terme cahier des charges se cache le préambule à tout projet informatique. En effet, il ne peut y avoir de développement informatique sans un écrit qui définisse ce que devra et ne devra pas faire le logiciel à développer.

A quoi sert un cahier des charges ?

D’aucuns diront qu’il n’est pas nécessaire pour des petits projets. Je fais partie de ceux qui pensent le contraire . Dans tout projet, si petit soit-il, il est indispensable qu’un écrit définisse ce qui sera réalisé.

C’est la garantie pour le client de recevoir ce pour quoi il signe. C’est aussi la garantie pour les développeurs de borner le projet. Les deux parties s’entendent donc sur le but et le fonctionnement de l’application et un écrit scelle ce contrat. Ainsi, l’engagement est clair pour les deux parties.

C’est comme pour un projet immobilier : seriez-vous prêt à acheter une maison neuve sans plan ? Moi non, pas même une cabane…
Pour cela il convient de définir différents points que je vais vous présenter.

Le contenu du cahier des charges

L’objectif

Le première chose est d’expliquer en quelques phrases le but de l’application. Le ou les objectifs qu’elle doit remplir.

Le but de l’application

On commence par expliquer succinctement le rôle que remplira le logiciel. Simplement quelques phrases qui cerneront son périmètre et l’objectif à remplir.

Inspirations

Si vous avez déjà vu des fonctionnalités ou des interfaces que vous souhaitez reproduire. Il est plus facile de les montrer pour expliquer ce que vous attendez. Comme on dit un dessin vaut mieux que mille mots. Cela vous affranchit aussi de tout jargon technique ou anglais que vous ne maîtrisez pas forcément.

Les acteurs

Ici, on va définir tous les intervenants. Que ce soit des personnes, ou d’autres systèmes qui doivent interagir avec notre application. On liste les différents profils qui se connectent au système : vendeur, client, manager, superviseur, etc. D’ailleurs, ces acteurs, définiront plus tard nos rôles. Rôles au sens profil de droit ; c’est à dire qu’ils détermineront « qui accèdent à quoi ».

Les cas d’utilisation

Là, on est au cœur du concret. Il s’agit de lister les fonctionnalités à remplir. On parle aussi de besoins fonctionnels.

Il suffit de prendre chacun des acteurs définis en amont et d’y adjoindre une action pour déterminer notre cas d’utilisation. Par exemple, le vendeur se connecte (avec son identifiant et son mot de passe) – ou encore – le client ajoute un produit à son panier en choisissant la quantité – le client sa commande et paie, etc…

Vous l’avez compris, en combinant les cas d’utilisation, on construit les scenarii du logiciel.

Les contraintes (délai, coût, environnement technique)

Ici, nous consignerons les délais à respecter ou du moins la date de livraison attendue. Seront mentionnés aussi, le budget alloué et les contraintes liées à l’environnement technique.

Dans quelle cadre intervient l’application ? Est-ce qu’elle interagit avec d’autres systèmes existants ? Est-elle prévue pour une utilisation pour des ordinateurs ? voire aussi pour des tablettes et téléphones portables ?

Ce que n’est pas le cahier des charges

Ce n’est pas un document commercial ! Ici il n’est pas nécessaire de vendre un produit ou une idée mais bel et bien d’exprimer simplement un besoin. Donc restez factuel, il ne s’agit pas de convaincre mais plutôt d’expliquer.