Comment écrire un bon cahier des charges informatique ?
Force est de constater qu’un bon nombre d’erreurs sur un projet informatique ou encore d’échecs prennent leur source dans un cahier des charges incomplet, pas assez clair ou bien mal structuré.
Voici la liste des bonnes pratiques à respecter afin de minimiser les incompréhensions et fausses interprétations du cahier des charges qui mettent le projet web en difficulté. Rédiger un cahier des charges pour un logiciel informatique c’est prendre le temps de bien poser les choses de façon claire et précise dès le départ.
1. Choisir le bon modèle de document
Il est important que vous sélectionniez le bon modèle de cahier des charges fonctionnel ou technique. Un bon modèle doit comporter au minimum une page de couverture, un sommaire, des en-têtes pour chaque nouvelle section, des titres, des sous-titres etc. ainsi qu’une introduction brève qui présente l’objectif global du système informatique attendu. Le document doit également comporter un numéro de version et un tableau de suivi des modifications apportées au document avec les numéros de versions correspondants.
2. Organisez une structure hiérarchique
Pour fournir un document facile à utiliser dans son entièreté, structurez votre cahier des charges. La structure peut inclure une partie sur le fournisseur, une sur le donneur d’ordre, une sur la mission etc. En fonction du degré d’information fourni, n’hésitez-pas à intégrer des sous-niveaux. Cela vous aidera à définir le périmètre couvert par votre cahier des charges.
Ce type d’agencement de l’information va vous aider à vous concentrer sur le domaine précis qui doit être traité et par conséquent à rédiger des documents d’exigences fonctionnelles aussi précis et complets que possible.
Cela vous permettra également de mettre en exergue les zones que vous devrez modifier, ou sur lesquelles vous allez devoir porter une attention particulière.
La plupart des entreprises vont articuler leur document autour des niveaux des systèmes selon la nature de leur activité. Dans le cas où le document décrirait une structure fonctionnelle, les missions très larges seront définies au sommet, puis elles seront décomposées en sous-fonctions, puis ses propres sous-fonctions seront découpées en tâches etc.
3. Utilisez des identifiants uniques
Cela peut surprendre mais de nombreux documents ne disposent pas d’un système d’identification des exigences fonctionnelles. En général quand un système est commandé sous contrat entre un client et un fournisseur (comme par exemple, dans la plupart des systèmes commandés par le gouvernement) ces systèmes sont développées conformément à certaines normes et ces normes exigent que chaque document d’exigence soit marqué d’un identificateur unique de projet (PUI).
Pourquoi avoir un identificateur unique relié à la structure hiérarchique de votre cahier des charges ? Pour une très bonne raison, le marquage de chaque exigence par un identifiant unique améliore et simplifie la traçabilité entre les exigences de haut niveau et les exigences de bas niveau. Les identifiants facilitent la création de tableau de traçabilité et listent clairement les exigences liées aux documents supérieurs ainsi qu’aux tests spécifiques destinés à vérifier ces exigences. Les tableaux de traçabilité simplifient le processus de démonstration auprès du client et des intervenants sur le projet. Le suivi des développements et de la livraison des fonctionnalités finies est plus facilement traçable et ce type de document prouve que les livraisons sont conformes aux exigences définies dans les plus hauts niveaux du document.
Reliez les identifiants uniques des exigences aux paragraphes de votre cahier des charges, cela permettra aux utilisateurs de les retrouver plus facilement dans le document. Les cahiers des charges qui n’utilisent ce type de codification sont difficiles à lire et à consulter et font de la traçabilité un cauchemar.
Exemple de hiérarchie d’exigences fonctionnelles avec sous-paragraphes :
3. Gestion des informations d’un compte abonné
3.1 Mise à jour des informations d’un compte abonné
3.1.1 Synchronisation du compte abonné avec le CRM
3.2 Suppression d’un compte abonné
3.2.1 Synchronisation avec le CRM & le PDV associé
3.2.2 Mise à jour du statut de billing
4. Standardisez le vocabulaire employé
Comme la plupart des langues employées le français est une langue qui contient des mots qui comportent des nuances subtiles de sens. Pour éviter que chacun ne se fasse sa propre interprétation d’une phrase, et pour éviter la confusion et les désaccords, il s’agit là de bien spécifier et de définir le vocabulaire et les concepts qui vont être utilisé.
Définir le vocabulaire permet d’indiquer au lecteur de quel façon tel ou tel terme devra être interprété quand il sera découvert dans le document.
5. Assurez-vous que chaque besoin est testable
Chaque exigence est attribuée à un identifiant unique de projet. Ainsi grâce à cet identifiant unique, cela permettra à l’exigence de supporter le test et la traçabilité. L’objectif de test doit être décrit précisément afin que l’exigence puisse l’atteindre.
Pourquoi faire cela ? Afin de s’assurer que la fonctionnalité développée répondra avec pertinence à l’exigence demandée. Chaque fois que vous décrivez une exigence, vous devez vous poser la question « De quelle façon pourrais-je répondre à cette exigence ? » Vous écrivez donc un scénario de test pour chaque exigence, qui prouve que l’exigence est testable. En structurant votre demande selon un scénario de test spécifique, vous vous assurez que les ingénieurs de conception comprendront exactement ce qu’ils doivent faire.
6. Rédigez des exigences fonctionnelles à réaliser de façon neutre
Ecrire les exigences fonctionnelles de manière neutre afin de ne pas restreindre les ingénieurs en conception logicielle et leur permettre de concevoir le système de la manière la plus efficace possible. Indiquez ce que le système doit faire et non pas comment il doit le faire. Les contraintes liées à la mise en oeuvre ne doivent pas apparaître dans les exigences fonctionnelles.
Eviter d’utiliser la voix passive : au lieu de dire « L’abonnement résilié sera mis à jour dans le département des ventes », préférez dire « Si l’abonnement est résilié, alors une notification de résiliation de l’abonnement sera envoyée au département des ventes ».
7. Ne pas hésiter à contextualiser les demandes
Plus la demande est précisée par un contexte plus elle aura de sens et sera comprise par les ingénieurs de conception. Bien mettre en avant l’aspect métier de l’exigence (exemple : quand un abonné résilie son abonnement, il faut que l’équipe des ventes en soit avertie afin qu’elle ne propose plus de produit à cet abonné).
Veillez à bien séparer l’exigence de sa justification, que cette séparation soit bien claire.
8. Utilisez un format d’écriture d’exigence commun à toutes les exigences
Pour que les exigences soient claires et fonctionnelles utilisez une construction de phrase commune entre toutes les exigences fonctionnelles, utilisez des attributs communs à toutes les exigences.
Exemple :
ID : 1.1.2
Objet : La résiliation de l’abonnement
Action : Quand un abonnement est résilié, un message est envoyé à l’équipe des ventes pour les avertir de cette résiliation.
Condition : Si l’abonnement est résilié par l’abonné depuis au moins 14 jours.
9. Identifiez tous les scénarios possibles (identifiez les exceptions)
Afin de couvrir tous les cas d’utilisations d’une exigence, lister toutes les exceptions pouvant survenir. Cela permet d’éviter d’oublier des cas non pris en compte ou bien d’éventuels impacts que certains cas pourraient avoir sur d’autres exigences.
Exemple : 12 jours après avoir résilié son abonnement, l’abonné change d’avis et ne souhaite plus le résilier, il faut réactiver son abonnement.
Les autres actualités relatives à l’externalisation de projets IT.
SSII offshore, prestataire spécialisé dans le développement logiciel, nous vous accompagnons et vous conseillons dans l’écriture de votre cahier des charges. Nous disposons d’une forte expertise, en tant que créateur de logiciel, éprouvée sur plus de 120 projets.
Source : qracorp.com
