Accéder au contenu principal

Rédaction d'un document Cahier des Charges

Comment rédiger un Cahier des Charges

Pour rédiger un document cahier des charges d'un projet logiciel ou autre, nous proposons cette template qui pourrait servir éventuellement comme guide. Il s'agit de définir successivement les points suivants : Contexte et définition du projet, Objectifs, Scope, Parties Prenantes, Description des besoins à répartir entre les besoins fonctionnels et non fonctionnels.

Contexte et définition du problème

Dans cette rubrique, vous allez définir le problème pour bien clarifier la finalité du travail.
Il est important de souligner aussi les besoins ainsi que les contraintes et ce de manière
très sommaire. Par exemple, vous pouvez exposer la situation actuelle ou futur de votre
système tout en mettant l’accent sur les problèmes auxquels vous voulez faire face.

Objectifs

Après avoir exposé le problème dans la première partie, ici vous allez exprimer quelles
sont les attentes et les résultats escomptés. Normalement ces attentes et résultats
(objectifs du projet) doivent être quantifiables. Par exemple vous voudriez passer d’un
taux d’utilisation de 40 à 70%. Cela va vous permettre après de savoir si vous avez bien
atteint les objectifs ou non.

Périmètre

Le périmètre (scope) d’un projet veut dire les limites que vous allez donner à votre projet.
Vous pouvez par exemple à ce niveau bien identifier votre cible (target), est-ce que votre
projet concerne les jeunes ou bien il est dédié uniquement aux enfants. Vous pouvez aussi
souligner le type de plateforme (web, mobile, cloud etc).
Un périmètre qui est bien défini va vous aider par après pour ne pas déborder sur les
objectifs du projet et de se contenter uniquement du travail demandé.

Parties prenantes

Les parties prenantes (stakeholders) concernent les toutes les parties qui ont un intérêt de
près (direct) ou de loin (indirect) dans la réalisation de votre projet. Par exemple, si vous
avez à réaliser une application de gestion de paiement de caisse au niveau d’un super
marché, et que cette application va comptabiliser les ventes effectuées par les vendeurs à
l’intérieur du super marché, alors les parties prenantes dans ce cas vont être : le caissier, le
vendeur, le manager, etc.
Il est important de connaître ses parties prenantes vu qu’ils va falloir les impliquer lors du
recensement des besoins et donc lors de l’évaluation de votre projet.

Description des besoins

En principe on distingue deux types de besoins. Les besoins fonctionnels et les besoins
non fonctionnels. On peut ajouter à cela les besoins d’ordre techniques (type de
technologie utilisé, etc).

Besoins fonctionnels

Les besoins fonctionnels concernent tous les besoins recensés soit par le client, les
utilisateurs ou par les parties prenantes. Ces besoins ont un rapport direct avec le métier
(business). Si par exemple votre projet consiste à réaliser une application mobile pour la
gestion du courrier électronique, alors un besoin fonctionnel pourrait être : envoyer un
email.
Tous les besoins fonctionnels doivent être listés à ce niveau là en respectant par exemple
la template suivante pour chacun de ces besoins :
• Objectif
• Description
• Contraintes/règles de gestion
• Priorité

Besoins non fonctionnels

Un besoin non fonctionnel n’est pas lié directement au métier. Il est plutôt lié aux normes
de qualité en vigueur et aussi aux contraintes de réalisation. Par exemple, pour une
application web, un besoin non fonctionnel pourrait être le temps de réponse d’une page
web ne doit pas dépasser cinq secondes.
Les besoins non fonctionnels en général sont définis comme étant des besoins de qualité.
Ainsi, on peut avoir des besoins en terme de fiabilité, de robustness, de stabilité, etc. S’ils
sont exprimés dans un document cahier des charges, c’est que on doit les prendre en
considération lors de la réalisation de notre projet.

Posts les plus consultés de ce blog

Les cartes CRC pour l'analyse des classes UML

Les cartes CRC Un système Orienté Objet (OO), est un système constitué par un ensemble d'objets qui collaborent et communiquent par envoi de messages. Lorsqu'un objet envoie un message à un autre objet, c'est que en réalité il demande un service à cet objet, ce dernier doit rendre son service public et faire en sorte de l'offrir à ses collaborateurs. Plusieurs services sont définis et offerts par le système OO.
La collaboration s'avère alors comme un principe fondamental des systèmes OO. UML, étant un langage de modélisation des systèmes OO, offre un outil qui permet la modélisation de la Collaboration. Cet outil portant le nom de Collaboration est représenté pare une ellipse en pointillées.

Lors de l'Analyse d'un Système d'Information, il est important de relever toutes les entités "Classes" potentielles dans un premier temps. On peut dans ce cas utiliser une heuristique très simple qui consiste à identifier les noms communs (Classes) ou les…

Atelier JSF Facelets et Internationalisation I18n

Introduction
Dans cet atelier nous allons aborder deux thèmes importants du Framework JSF qui sont la technologie des Facelets et celle de l'Internationalisation connu par I18n (entre le caractère 'I' et le caractère 'n' on trouve 18 caractères). Il faut savoir que JSF au niveau de la version 1 utilisait JSP comme technologie de présentation, il se trouve que JSP et JSF ont deux cycles de vie différents, c'est pourquoi on a pensé à produire une nouvelle technologie de présentation qui soit totalement compatible avec JSF, il s'agit bien de la technologie des Facelets et ce depuis la version 2.0. L'internationalisation quant à elle s'avère être très importante aussi surtout lorsque l'objectif d'une application web est de prévoir plusieurs langues différentes pour la clientèle. L'idée est de ne pas produire une page par langue, mais plutôt traiter la chose de manière intelligente, c'est-à-dire le même contenu mais avec des affichages de…

Scope d'un projet

Comment définir le Scope d'un projet Le Scope ou Périmètre d'un projet est un point clé pour la réussite du dit projet. Il doit figurer parmi les éléments d'un document cahier des charges et partagé avec le Manager du projet, le Client ainsi que les parties prenantes.

Pour bien définir le Scope d’un projet, il est opportun de définir les points suivants :

Les objectifs du projetLes buts ou finalités (goals) à atteindreLes sous-phases ou étapesLes tâchesLes ressourcesLe budgetLa planning
Bien sûr pour pouvoir ce faire, il est nécessaire d'élaborer une étude approfondie de la finalité du projet en concertation avec d’une part le client et d’autre part avec les parties-prenantes. Une fois ces points sont détaillés, il y a lieu après de clarifier les limitations du projet à savoir les points à inclure dans le projet et ceux à ne pas inclure.
Il est à rappeler également que les objectifs du projet doivent respecter les critères SMART.