Le dossier d`expression des besoins

Le dossier d'expression des besoins
Introduction
On peut distinguer plusieurs sortes de documents d'expression des besoins (on parle également de cahiers des
charges), celui fourni par le maître d'ouvrage et qui sert de base au document d'expression des besoins
(requirements Analysis document ou cahier des charges), le dossier d'expression composé d'un certain nombre de
documents comme le document de spécifications externes encore appelé cahier des charges détaillé.
Donner une forme générale à un document d'expression des besoins sans tenir compte de l'environnement, du
domaine concerné est une tâche assez scabreuse, ce qui suit est donc une tentative de "standardisation" qu'il faut
manipuler avec précaution, elle doit être adaptée à toute situation concrète
Comme de nombreux documents, le dossier d’expression des besoins ne se construit pas « en une fois »
Règles de base
Lisibilité du document
Utiliser des phrases courtes
Utiliser des lignes courtes (marges importantes)
Utiliser des sections et sous sections
Utiliser les caractères gras, italiques. Adopter une règle qu'il faut ensuite respecter!
Utiliser des tableaux, des listes, des graphiques
Utiliser des diagrammes simples (pas plus de 12 éléments)
Adaptabilité du document
La forme du document doit rendre possible et facile des changements ultérieurs. Comme pour le développement,
la rédaction des documents doit reposer sur une classification (un plan) adapté afin qu'une modification ne
remette en cause qu'un petit nombre de paragraphes. Pour cela on peut utiliser quelques techniques.
Utiliser une structuration arborescente de façon à ce que les modifications ne se fassent qu'au niveau le plus bas.
Eviter les références "en dur" par numéro de pages, celui ci ayant toutes les chances d'être modifié s'assurer que
tous les tableaux, les schémas sont bien répertoriés, ne pas y faire référence par leur place actuelle (schéma cidessous)
Laisser des chapitres vides ou à remplir
Démarrer un nouvelle page par chapitre
Si vous avez besoin de faire référence à un numéro de page, de schéma, il est préférable de numéroter par
chapitre, section, sous section (schéma 5.2.3). Si votre traitement de texte le permet utiliser les renumérotations
automatiques.
Patron du dossier d'expression des besoins
Projet<<nom du projet>>
Dossier d’expression des besoins
[Pour <sous système>]
Version < ?. ?>
Historique des révisions
[tableau avec une ligne par révision, chaque révision est composée de la date, la version, la description,
l'auteur]
Table des matières
[Un renvoi vers les parties du document à partir de la date des matières est souhaitable]
Introduction
Présentation du document
Objectifs du document
Contenu du document
A qui s’adresse ce document (comment lire ce document)
Références
Sigles
Description du domaine [peut être mise en annexe ou renvoyer sur un document de description du
domaine (ce document sert généralement pour plusieurs produits)]
Description du Métier [peut être mise en annexe]




Les flux principaux d’information
Les entités métiers
Les processus métiers
Les règles métiers
Description du produit
[Description des principaux facteurs qui influencent le produit, il ne faut entrer trop dans le détail, les sections
suivantes sont là pour ça]
 Les objectifs du produit, les avantages qu'apporte le produit
 Les fonctionnalités du produit
 Les utilisateurs du produit et leurs caractéristiques (acteurs humains)
 Les contraintes du produit
 Les hypothèses (conditions d'utilisation) et les dépendances (acteurs système)
 La classification des besoins-exigences
Description des besoins exigences
[ on peut trouver une référence à la "maquette" qui a permis de se mettre d'accord sur les besoins exigences ]
Les besoins-exigences fonctionnels
[Cette section est généralement organisée par fonctionnalité, sous fonctionnalité, sous sous ….. On peut utiliser
d'autres organisations comme par exemple utilisateur, services de la structure destinataire du produit, ….]
 Les besoins communs / spécifiques
 Description d’un besoin exigence (autant de descriptions que de besoins-exigences)
 Récapitulatif
[ Les besoins seront classés en fonction de leur importance ]
Les besoins-exigences non fonctionnels
Exigence en terme de qualité
[ On indique le niveau de qualité(les facteurs de qualité) et de sécurité qu'on désire pour le produit.]
 Utilisabilité (Maniabilité)
[Par exemple: le temps de formation nécessaire à la prise en main du produit, exigence de standardisation, …
Autant de paragraphes que d'exigences]
 Fiabilité (Conformité)
[On trouve ici les caractéristiques principales de la fiabilité comme, par exemple: temps moyen entre 2 pannes,
le temps moyen d'intervention, l'accès à la maintenance,… ]
 Performance (Efficacité)
[Par exemple: Temps de réponse moyen et maximal pour une transaction, le nombre d'utilisateurs simultanés,
les fonctionnements dégradés acceptables, l'utilisation des ressources (mémoire, disque, communications,...) ]
 Supportabilité (Réutilisabilité Interopérabilité, Portabilité),
[On trouve ici pour les exigences qui vont rendre la réutilisation, la lisibilité plus faciles, utilisation de
standard, application de conventions propres à la structure (nomage,….)]
 Documentation et aide en ligne
[Selon son importance, ce paragraphe peut être placé dans l'utilisabilité
Description des différents types d'aide/documentation proposés, sur l'utilisation du logiciel, sur le domaine, sur
les notices disponible,…. ]
Autres exigences
 Contraintes de conception
[plate-forme système, langage de développement, contrainte d'architecture, réutilisation de composants,… ]
 Les composants non développés dans l'application
[ Tous les composants développés en externes (achetés ou sous traités) avec les caractéristiques d'utilisation ]
 Les interfaces
[ Description des interfaces que le produit doit prendre en compte ]
 Les interfaces utilisateurs
[ Descriptions des interfaces à implémenter pour les utilisateurs, respect d'une charte graphique, …. ]
 Les interfaces de matériel
[ références aux notices des matériels utilisés ]
 Les interfaces logicielles
[ interfaces des composants réutilisés, achetés, sous traités ]
 Les interfaces de communication
[ communication entre dispositifs (logiciels ou matériels) distants ]
 Exigences en termes de licences
[ mise en conformité, niveau, restriction d'usage,… ]
 Dispositions légales:
[ Copyright, garanties, documents livrables, …. ]
 Application de standard
[ éventuellement, si cela n'a pas été traité dans les sections précédantes ]
Index
[ L'index doit être créé au fur et à mesure de la rédaction du texte. Le fait que le mot soit indexé doit être visible
dans le texte ( police spéciale, marqueur, ...) ]
En annexe :
[Tout ou parties de la liste suivante (il peut s’agir de simples références): ]
 Le cahier des charges de la maîtrise d'ouvrage
 Les interviews et toutes les informations provenant de la maîtrise d’ouvrage
 Description du domaine (si ce n'est pas mis dans le document)
 Description du Métier (si ce n'est pas mis dans le document)
 Description des acteurs, de la hiérarchie des acteurs.
 Description sommaire des cas d'utilisation (matrice des cas d'utilisation - acteurs), leur priorité, difficulté, etc.
 Diagrammes de cas d'utilisation (par paquetage)
 Diagrammes d'activité décrivant l'enchaînement des cas d'utilisation.






En tenant compte des priorités des besoins et des risques, un premier découpage en itérations peut être
proposé.
Dossier des cas d'utilisation c'est à dire, pour chaque cas, la description textuelle, La description en terme de
diagrammes de séquence.
Les diagrammes de classes déjà élaborés. Il s'agit essentiellement des classes métiers qui sont déjà
probablement regroupées en paquetages.
Le cahier des tests (ou une base de données des tests à réaliser)
Le glossaire
….