Cahier des charges : 7 conseils pour bien rédiger les cahiers des charges

Le succès ou l’échec d’un projet est dû, en grande partie, aux exigences qui sous-tendent l’effort.

Lorsqu’ils sont rédigés en tenant compte de ces étapes, les gestionnaires de projet sont susceptibles d’obtenir plus rapidement l’adhésion des parties prenantes. En outre, l’équipe de projet bénéficiera d’un gain de temps lors du développement ainsi que d’un ensemble plus complet de scénarios de test grâce à des exigences bien rédigées. Qu’il s’agisse d’exigences commerciales, fonctionnelles ou de performance, ces étapes vous permettront d’améliorer vos performances et de devenir un analyste commercial plus efficace. Lisez cet article pour plus d’informations.

1. Connaître votre public

Lorsque vous vous asseyez pour commencer la composition de vos exigences, prenez un moment pour réfléchir aux lecteurs potentiels. Dans la plupart des cas, vos exigences seront lues par les dirigeants, les parties prenantes du projet, les développeurs et les testeurs. Lorsque vous examinerez ces sous-sections de votre entreprise, réfléchissez à l’ensemble des compétences collectives de chaque groupe. Que s’attendent-ils à trouver dans un document d’exigences ? À quelles questions pouvez-vous répondre de manière préventive pour chaque groupe d’utilisateurs ? Comment pouvez-vous écrire à la satisfaction de chacun de ces groupes disparates ?

2. Utiliser un langage simple

Intégrer un langage professionnel clair dans vos exigences commerciales sera toujours payant lorsque vous tenterez de satisfaire vos collègues dans l’ensemble de l’entreprise. La clé de la rédaction d’une bonne exigence est l’équilibre. Plus l’exigence est technique, plus il est nécessaire de la formuler clairement, même pour le membre de votre auditoire le moins technique. Un nouvel employé doit être capable de lire votre exigence le premier jour de son travail et avoir une compréhension de base de ce qui doit se passer. En même temps, vous voulez que l’exigence soit énoncée de manière succincte et qu’elle contienne toutes les informations techniques dont les développeurs et les testeurs ont besoin pour accomplir leur travail. Un bon exemple de cet équilibre pourrait ressembler à ceci :

Requête 9.0 – Une section intitulée « Détails du membre » est présente dans la fenêtre de détails décrite à la requête 7.5. Cette section contient le champ suivant :

1. Date de naissance – mm/jj/aaaa
2. Lorsqu’un membre est un souscripteur principal, cette valeur est alimentée à partir du segment DB712 de la section 1100F du fichier des transactions du membre retourné.
3. Lorsqu’un membre est dépendant d’un souscripteur primaire, cette valeur est alimentée à partir du segment DB712 de la section 1100G du fichier de transactions du membre ré-accordé

Dans cet exemple, j’ai fourni aux développeurs le formatage de champ nécessaire et les points d’origine des données spécifiques pour permettre la cartographie tout en indiquant clairement et succinctement ce qui doit se passer lorsque cette exigence est exécutée. Une partie prenante du projet ou un nouvel employé peut examiner cette exigence et, bien qu’il ne soit pas familier avec le fichier référencé, il peut comprendre exactement ce qui doit se produire et quel doit être le résultat attendu.

3. Indiquez l’objectif de l’exigence

Dans chaque section de votre cahier des charges, la toute première exigence doit toujours fournir une image globale de ce qui est attendu en ce qui concerne la sous-section particulière du projet. Par exemple, je pourrais rédiger des exigences pour la création d’une nouvelle page web. Ma première exigence consistera toujours à décrire chaque élément de la page par une seule phrase descriptive indiquant à quelle fonction l’élément est destiné.

Cette méthode permet à tout le monde, des testeurs aux dirigeants, de se faire une idée du résultat attendu dès le départ, avant de plonger dans les détails de chaque élément et de se perdre potentiellement au fur et à mesure que l’on s’enfonce dans les mauvaises herbes. Cette exigence sert également de pierre de touche pour les programmeurs et les testeurs qui leur fournit une image de haut niveau du produit fini ainsi qu’une liste unique et facile à lire des éléments à aborder.

4. Énumérer, puis en énumérer d’autres

Examinons à nouveau l’exemple d’exigence.

Requête 9.0 – Une section intitulée « Détails du membre » est présente dans la fenêtre de détails décrite à la requête 7.5. Cette section contient le champ suivant :

1. Date de naissance – mm/jj/aaaa
2. Lorsque le membre est le souscripteur principal, cette valeur est alimentée à partir du segment DB712 de la section 1100F du fichier de transactions du membre retourné.
3. Lorsque le membre est la personne à charge du souscripteur principal, cette valeur est alimentée à partir du segment DB712 de la section 1100G du fichier de transactions du membre ré-accordé

Nous voyons ici une seule exigence, décomposée en plusieurs points. La raison unique de ce niveau de délimitation : les tests.

Ce style d’énumération est utile lors de la composition des scénarios de test lorsque l’exigence contient une déclaration « si/alors ». Dans ce cas, nous inscrivons la date de naissance du membre dans un champ dépendant de sa relation avec l’abonné principal ; nous avons deux endroits pour extraire ces données.

Les personnes chargées de tester cette exigence voudront s’assurer que tous les scénarios sont pris en compte. Sur la base de ce style de recensement, un testeur pourrait composer son scénario de test comme suit :

Req 9.0.1.A – Le membre est un abonné, la DOB est extraite de la DB712 sur la section 1100F du fichier du membre

Req 9.0.2.B- Le membre est dépendant, la DOB est tirée du DB712 sur la section 1100G du fichier du membre.

Cela peut être particulièrement utile. J’ai inclus plusieurs éléments dans une seule exigence. Par exemple, je peux avoir une date de naissance, un numéro d’identification, un nom de famille et un prénom. J’attribuerais un numéro à chacun de ces éléments et une lettre à chaque déclaration « si/alors » pour aider mes analystes d’assurance qualité à s’assurer que leurs scénarios de test sont en phase avec vos exigences.

5. Les rendre spécifiques et définitifs

Lorsque l’on rédige des exigences, il n’y a pas de place pour un langage mou ou un ton passif. Ces exigences constituent le fondement du projet et doivent absolument être respectées. Bien qu’il ne soit jamais conseillé de dire aux développeurs COMMENT exactement exécuter le travail, il est impératif d’être précis et d’énoncer le résultat attendu sans aucune marge de manœuvre.

Notez le ton et la spécificité de l’exemple suivant :

Requête 1.2 – L’utilisateur final ne peut pas demander une date de renouvellement future dépassant 15 jours à compter de la date de la demande (date actuelle). En outre, l’utilisateur final ne peut pas interroger une date de renouvellement historique dépassant 12 mois à compter de la date de la demande (date actuelle).

Date de renouvellement future

1. Les dates dépassant 15 jours dans le futur sont désactivées sur le contrôle du calendrier de sélection des dates.
2. Lorsqu’une date de renouvellement future dépassant 30 jours à compter de la date de l’enquête est saisie manuellement, l’erreur suivante s’affiche en rouge :

« La date de service ne peut pas être postérieure de plus de 30 jours à la date d’aujourd’hui ».

1. Toute valeur de date saisie manuellement qui s’écarte du format MM/JJ/AAAA génère une erreur de validation documentée dans la demande 1.1.
2. Toute valeur de date saisie manuellement contenant un caractère non numérique génère une erreur de validation documentée à la rubrique 1.1.

Date de renouvellement historique

1. Les dates dépassant 12 mois dans le passé sont désactivées sur le contrôle du calendrier de sélection des dates.
2. Lorsqu’un renouvellement historique dépassant 12 mois à partir de la date d’enquête est saisi manuellement, l’erreur suivante s’affiche en rouge :

« La date de service ne peut être antérieure à 36 mois à compter d’aujourd’hui ». Le bouton d’éligibilité de la recherche reste désactivé.

1. Toute valeur de date saisie manuellement qui s’écarte du format MM/JJ/AAAA génère une erreur de validation documentée dans la demande 1.1.
2. Toute valeur de date saisie manuellement contenant un caractère non numérique génère une erreur de validation documentée à la rubrique 1.1.

Cette formulation de cette exigence est spécifique et ne laisse aucune possibilité d’interprétation erronée de la part des développeurs et des testeurs.

6. Prise en compte des cas de bord

Dans le cadre d’un projet, il y aura toujours des scénarios extrêmes qui entraîneront des résultats inattendus. Certains d’entre eux peuvent nécessiter un ensemble de circonstances presque parfait pour se produire. Si ces scénarios extrêmes peuvent sembler impossibles, votre projet est toujours soumis à la loi de Murphy.

J’ai pris l’habitude d’examiner tous les cas extrêmes imaginables, ce qui implique souvent de consulter des collègues pour réfléchir à toutes les façons dont un produit pourrait produire des résultats non désirés. Une fois qu’une liste complète de scénarios est établie, incluez-les dans vos exigences. Certaines parties prenantes peuvent estimer que c’est exagéré. Toutefois, vos développeurs et testeurs apprécieront cette réflexion préalable.

7. Énoncer l’évidence

Les analystes commerciaux, qu’ils soient expérimentés ou nouveaux, peuvent avoir tendance à supposer que tous les participants au projet possèdent un niveau de connaissances de base. Par souci de concision, nous évitons souvent de documenter ce qui est considéré comme des « exigences implicites ». Dans la culture professionnelle actuelle des employés sous contrat, nous ne pouvons plus omettre les détails évidents. Compte tenu du taux de désabonnement enregistré pendant la durée de vie d’un projet, le risque que votre public omette un détail essentiel dans le développement et les tests du produit est nettement plus élevé. Avec l’ajout de contractants temporaires, vous pouvez constater que la composition de l’équipe de projet est radicalement différente au moment du développement qu’au début.

N’ayez pas peur d’affirmer l’évidence, même si elle vous semble inutile ou redondante. Vous n’écrivez pas un court métrage de fiction ; vous composez un artefact vital du projet qui vise à répondre à toutes les questions et à ne laisser aucune pierre intacte.