Méthode de rédaction des exigences d’un projet

La gestion de projet est particulièrement difficile et nécessite beaucoup de rigueur. La rédaction des exigences constitue le point de départ de beaucoup de projets. Salomé nous propose de découvrir comment les rédiger de façon précise et efficace.

Inhérente à toute réalisation de projet, la phase de rédaction des exigences permet de déterminer quelles fonctionnalités seront disponibles et comment elles seront implémentées. Cet article aborde la manière de structurer et de rédiger des exigences à partir d’un cahier des charges à partir des définitions des différents types d’exigences et d’un cas concret d’application. Un exemple volontairement compréhensible par tous et non exhaustif. L’opportunité de vous exercer vous-même en complétant les divers points développés.

Toutefois, la méthode déployée dans cet article n’est pas unique. Ses avantages et inconvénients seront donc étudiés ci-après.

Qu’est-ce qu’une exigence ?

En méthodologie projet, il est obligatoire et essentiel de rédiger un référentiel d’exigences. Une base qu’il faudra développer tout au long du projet. Ce référentiel est composé de :

• Dossier des exigences – DEX : liste des cas d’utilisation composés d’un bref descriptif, ainsi que des règles fonctionnelles et techniques globales du projet (par exemple les AEF : autres exigences fonctionnelles).
• Cas d’utilisation – CU : description détaillée du cas d’utilisation.
• Règles de gestion – RG : règles appliquées lors d’un cas d’utilisation. Elles peuvent être décrites directement dans le cas d’utilisation mais si elles sont trop nombreuses ou trop complexes, elles peuvent aussi faire l’objet d’un document annexe.
• Liste des exigences – LEX : liste de tous les cas d’utilisation, règles de gestion et autres règles.
• Glossaire : liste des termes avec leurs définitions.

Pour illustrer concrètement le référentiel d’exigences, prenons le cas de l’exemple suivant : imaginez que vous venez de recevoir un cahier des charges « Calcul d’aliments » dans lequel se trouvent quelques lignes de fonctions demandées.

Le calcul d’aliments

Votre projet : construire une application de calcul d’aliments mangés sur une journée avec comme cahier des charges :

• Pouvoir ajouter et modifier des mensurations
• Pouvoir ajouter les aliments mangés
• Pouvoir paramétrer son compte
• Avoir des statistiques sur les aliments mangés et sur l’évolution du poids
• …

Vous devez alors commencer par rédiger le dossier des exigences.

Le dossier des exigences

Dans le dossier des exigences seront rédigées les grandes lignes du projet :

• Contexte du projet
• Différents types d’utilisateurs
• Différentes fonctionnalités
• Règles de gestion transverses

Dans le cas du projet de calcul d’aliments, il est donc nécessaire de rédiger les grandes lignes des différentes fonctionnalités suivantes :

• Macronutriments ingérés
• Mensurations
• Statistiques
• Paramétrage
• …

Pour la partie mensurations :

Les mensurations seront renseignées par les différents utilisateurs dans l’onglet Mensurations. Chaque utilisateur pourra ajouter, modifier ou supprimer une de ses mensurations. De ces mensurations seront générées des statistiques (voir la partie Statistiques). Elles sont nécessaires au calcul des calories ingérées à la journée (voir la partie Paramétrage). Un tableau des différentes mensurations renseignées par chaque utilisateur devra lui aussi être disponible.

Exemples de règles de gestion transverses rédigées :

• Application en français
• Application disponible 24/24h
• Application disponible via une URL
• Nombre d’utilisateurs connectés au maximum en simultanée
• …

Une fois le dossier des exigences rédigé de manière assez générale, l’étape suivante consiste en la rédaction de cas d’utilisation plus détaillés.

Les cas d’utilisation

Des cas d’utilisation détaillés seront présentés sur chacune des fonctionnalités identifiées. Généralement, ces cas d’utilisation sont composés de :

• Un scénario nominal : cas le plus fréquent
• (Optionnel) Un ou plusieurs scénario(s) alternatif(s) : cas qui partent du scénario nominal, qui retournent dessus et sont moins fréquents, que celui-ci
• (Optionnel) Un ou plusieurs scénario(s) d’échec : cas qui partent du scénario nominal et qui conduisent à l’échec du scénario

Pour faire simple, dans l’exemple des mensurations, seuls un scénario nominal et un scénario alternatif seront créés :

• Scénario nominal : ajout d’une mensuration
  
• Scénario alternatif A1 : modification d’une mensuration
  

L’analyse de cet exemple démontre que toutes les actions utilisateurs se trouvent bien du côté gauche et, à l’opposé, que seules les actions systèmes se trouvent du côté droit. En effet, il n’est pas possible de demander à un utilisateur d’effectuer une action du côté du système et, inversement, il est impossible pour le système d’effectuer une action utilisateur. Autre constat : toutes les règles de gestion se trouvent appelées côté système (l’appel à un scénario alternatif n’était pas une règle de gestion).
À noter : il est également possible d’ajouter la consultation et la suppression de mensuration comme scénarios alternatifs.
La rédaction de ce cas d’utilisation permet donc d’expliquer la démarche utilisateur pour réaliser l’action souhaitée. Dès lors, vous pouvez rédiger toutes les règles de gestion nécessaires à la bonne réalisation de cette action. Ces règles de gestion sont rédigées en dehors du tableau des actions sous peine d’alourdir considérablement sa lecture.

Les règles de gestion

On peut observer un appel à un certain nombre de règles de gestion toutes côté système et expliquées soit dans un autre document, soit à la fin du cas d’utilisation. Une règle de gestion peut être appelée autant de fois que nécessaire. Une règle de gestion générique peut aussi être créée afin d’aider la compréhension.

Pour résumer, vous avez jusqu’ici rédigé le dossier des exigences, les cas d’utilisation ainsi que toutes les règles de gestion nécessaires appelées dans les cas d’utilisation. Une fois toutes ces tâches effectuées, vous pouvez rédiger la liste des exigences ainsi que le glossaire. Vous disposez de toutes les informations nécessaires pour ce faire. La liste des exigences regroupe le nom de toutes les exigences afin de les retrouver facilement et de les suivre le plus simplement possible. Le glossaire regroupe la définition des termes clés du projet.

La liste des exigences

Dans la liste des exigences se trouvent donc les exigences suivantes :

Le glossaire

Le glossaire regroupe les explications des termes clés :

• Mensuration
• Macronutriments
• …

Mais, une fois les exigences rédigées, quels sont les avantages et les inconvénients à utiliser cette méthode de rédaction des exigences ?

Principaux avantages de cette méthode de rédaction des exigences :

• Méthode très structurée : simplicité de recherche d’une information, facilité de développement de la base selon le temps et l’avancement du projet.
• Rédaction très complète et exhaustive de toutes les exigences, toute incohérence ou interrogation sera automatiquement vue et traitée au plus tôt.
• Suivi très rapide des exigences : étant donné leurs structures, il sera plus rapide de chercher une information afin de la modifier ou de la mettre à jour.
• Rédaction des cas de tests à partir des exigences simplifiée grâce à cette structure détaillée des exigences (point développé dans un prochain article).

Principaux inconvénients de cette méthode de rédaction des exigences :

Les exigences étant exhaustives et très détaillées, les problèmes suivants doivent être maîtrisés :

• Temps de rédaction : au vu de la complexité et de l’exhaustivité des informations, le temps de rédaction des exigences sera élevé.
• Temps de lecture du document assez long : une fois rédigés, l’ensemble des différents documents d’exigences peuvent atteindre des centaines de pages.
• Temps de validation des documents à prendre en compte : prévoir un temps conséquent de rédaction, de relecture et d’ateliers entre les différentes parties prenantes.
• Maturité des collaborateurs indispensable : afin de pouvoir rédiger les exigences de la manière la plus détaillée possible, une certaine maturité des collaborateurs s’avère indispensable.

Vous devez donc prendre en compte le facteur « temps disponible et maturité de l’équipe sur la rédaction des exigences » avant de valider cette méthode de rédaction des exigences pour un projet.

Voici donc un exemple de rédaction d’exigences. Dans un prochain article, nous aborderons comment rédiger des cas de tests en partant de ces exigences.

N’hésitez pas à commenter et à présenter ce que vous auriez rédigé par vous-même. Pour rappel, l’exemple n’est pas exhaustif et ne couvre pas l’ensemble des points. Seule une partie du cahier des charges a été modélisée en exigences. Cet article a pour but de proposer une vision d’ensemble des exigences et servira de base pour aborder le sujet de la rédaction des cas de tests.

À très bientôt !