Objet du chapitre

Le processus d’expression du besoin peut être modélisé selon deux étapes majeures :

L’étape d’écoute qui consiste à capturer les besoins.
L’étape de formalisation qui doit conduire à la mise au point d’un document : l’expression des besoins ou cahier des charges.

La première étape met en œuvre des méthodes et outils qui peuvent être utilisés dans des contextes métiers très différents (BTP, informatique, industrie, etc.). Ce n’est pas le cas de l’étape de formalisation qui utilise des méthodes et outils parfois propres à chaque contexte métier. En effet, les techniques pour exprimer une architecture de bâtiment et les exigences fonctionnelles d’un logiciel sont bien différentes.

Ce chapitre présente des méthodes et outils propres aux projets logiciels. Néanmoins, nombre des points abordés valent quelque soit le domaine métier considéré.

Après les enjeux de l’expression du besoin, le chapitre présente :

Les méthodes d’identification des besoins.

Les méthodes de formalisation des besoins.
Les méthodes d’écoute et de recueil des besoins.

Du point de vue du cadre général de travail proposé dans cet ouvrage...

Enjeux de l’expression de besoin

1. Objectif

Avant d’engager les activités qui doivent conduire le projet à la production d’un produit, encore faut-il décrire (de manière plus ou moins précise certes) le produit en question. C’est là le principal objectif de la phase d’expression du besoin.

2. Documents

Comme vu dans le chapitre Structurer et gouverner le projet, la responsabilité de la formalisation de l’expression du besoin incombe à la maîtrise d’ouvrage du projet sous la forme d’un cahier des charges fonctionnel. La description du produit qui répond aux besoins n’est absolument pas à traiter dans le cahier des charges fonctionnel mais dans le document de conception du produit (responsabilité de la maîtrise d’œuvre).

Les utilisateurs expriment leur besoin oralement (entretiens, groupes de travail) et dans le meilleur des cas rédigent une expression du besoin en langage courant.

La maîtrise d’ouvrage capture le besoin, rédige ou précise l’expression du besoin et formalise le cahier des charges fonctionnel. Le cahier des charges fonctionnel est complété par un ou plusieurs dossiers de spécifications des fonctionnalités (parfois un dossier de spécification générale et plusieurs dossiers de spécifications détaillées pour...

Expression des besoins selon le type de cycle projet et le type de projet

Le chapitre Structurer et gouverner le projet présente les différents types de cycles de vie pour ce qui concerne les projets informatiques. De manière simplifiée, deux grands types sont présentés : le cycle en V et le cycle itératif.

Par ailleurs, les projets informatiques sont soit réalisés sur la base de progiciels, on parle alors d’intégration de progiciel, soit réalisés à l’aide de langages informatiques qui permettent de faire des développements sur mesure, on parle alors de développement spécifique.

Si le principe général de recueil des besoins est identique quel que soit le type de cycle de vie ou le type d’outil utilisé, le type d’expression des besoins est lui différent.

1. Cycle en V et développement spécifique

La mise en œuvre d’un cycle projet en V dans le cas d’un développement spécifique nécessite une expression du besoin absolument détaillée. Toute imprécision se traduirait in fine par des écarts entre le résultat souhaité et le résultat obtenu concernant le périmètre fonctionnel décrit.

La complétude de l’expression, elle, n’est pas primordiale. Ainsi, si un oubli est avéré...

Identification du besoin par les processus

1. Principe

Le concept de processus est largement répandu dans les organisations et utilisé dans bien des domaines de gestion de l’entreprise : l’organisation du travail, la qualité où la représentation sous forme de logigramme est largement utilisée, etc.

Un processus est un ensemble d’activités ordonnancées qui permettent de satisfaire un client interne ou externe. Les activités qui constituent le processus sont supportées par des ressources humaines et des outils (les ressources humaines effectuent les activités à l’aide d’outils). Un processus est souvent transverse à l’organisation hiérarchique de l’entreprise.

Exemples de processus : gestion de commandes, livraison, approvisionnement, achat, embauche d’un nouveau salarié, etc.

Le schéma suivant fait apparaître par ailleurs deux notions :

Les outputs qui sont les produits qui résultent de l’exécution du processus pour le client.
Les inputs qui sont les éléments en entrée qui permettent d’engager les activités du processus. Ces inputs sont fournis par un fournisseur (supplier).

Cette modélisation constitue la base de la représentation SIPOC (Suppliers Inputs Process Outputs Customers) des processus métiers.

Le concept de processus est fondamental dans le domaine de l’automatisation de la gestion de l’information. En effet, l’informatique peut être considérée comme l’automatisation partielle des processus métiers de l’entreprise. Ainsi, il convient de modéliser ces processus avant de les automatiser. À ce titre, le concept de processus se retrouve mis en œuvre dans les langages UML, ou encore Merise et BPMN largement utilisés au sein des projets informatiques à travers les diagrammes d’activités, pour ce qui concerne UML, ou encore les modèles organisationnels des traitements (MOT), pour ce qui concerne Merise.

2. Cartographie du système d’information et de l’entreprise

Afin d’établir un lien concret entre les processus de l’entreprise et son système d’information, la modélisation de l’organisation de l’entreprise selon quatre vues est suggérée...

Description du besoin

1. Concept de besoin

La description du besoin concernant une application informatique consiste en grande partie à identifier les fonctions du logiciel (ce qui peut être envisagé par une approche par les processus) puis à décrire ces fonctions. La norme AFNOR parle ici de fonction principale (FP). Cette description s’obtient par un travail d’analyse fonctionnelle conduisant à l’expression d’exigences fonctionnelles.

Cependant, la description du besoin est aussi complétée par des contraintes :

de performance ;
de niveau de service ;
de disponibilité ;
de sécurité ;
de respect d’un standard ;
de respect d’une réglementation ;
de respect d’une norme ;
des attentes en termes de support ;
des attentes en termes de maintenance et de retrait de service, etc.

On parle ici de fonction contrainte (FC). Il ne s’agit donc pas réellement de fonctions mais d’exigences non fonctionnelles.

Fonction : "Action d’un produit ou de l’un de ses constituants exprimée exclusivement en termes de finalité. Une fonction est formulée par un verbe à l’infinitif suivi d’un complément." AFNOR

Contrainte : "La contrainte c’est la limitation à la liberté de choix du concepteur-réalisateur d’un produit." AFNOR

Au-delà de l’identification et de la description des fonctions, il est par ailleurs très important de pouvoir structurer le document qui présente ces éléments. En effet, l’expression de ces exigences donne lieu à une quantité importante d’informations dont il s’agit d’assurer la cohérence, la précision de description et la qualité afin de participer au succès du projet considéré. Enfin, des activités de gestion des exigences fonctionnelles sont donc à mener.

Fonction versus exigence

Si on peut considérer que les exigences sont issues de l’analyse fonctionnelle, les fonctions et exigences sont en réalité de même nature et la différence de vocabulaire vient essentiellement de différents points de vue :

Le maître d’ouvrage considère les exigences comme les fonctions décrites dans le cahier des charges fonctionnel....

Spécification du besoin

Les produits des travaux de formalisation des processus, les exigences fonctionnelles et non fonctionnelles collectées, et tout ce qui s’y rapporte (priorités, critères d’appréciation, niveaux des critères d’appréciation, flexibilités) sont bien entendu des éléments qui doivent être intégrés au cahier des charges fonctionnel. Mais, comme vu précédemment, ces éléments ne sont pas suffisants dans le cas des applications informatiques et doivent être complétés par des éléments qui spécifient de manière plus précise encore les exigences collectées.

Ainsi, l’ensemble des exigences est complété par toute explication la plus précise possible en langage naturel. Au-delà, nous proposons trois outils qui permettront de spécifier les exigences fonctionnelles : le langage UML, la spécification de l’interface homme-machine et le prototypage. Une fois la spécification du besoin terminée, une revue de spécification doit être engagée afin d’assurer la cohérence globale des exigences (voir section Revue de spécification).

1. UML

Cette partie ne vise pas à présenter en détail le langage UML (Unified Modeling Language) qui fait l’objet d’ouvrages dédiés auxquels le lecteur aura avantage à se référer. Nous nous contentons ici de préciser le contexte d’utilisation d’UML dans la cadre de projets informatiques et comme un outil permettant de produire des documents de spécification associés aux exigences fonctionnelles. Pour ce faire, la présentation de trois diagrammes UML importants est abordée rapidement à titre d’illustration.

a. Qu’est-ce qu’UML ?

UML est un langage et n’est pas une méthode. UML permet d’exprimer et de formaliser les résultats des phases d’analyse (côté maîtrise d’ouvrage) et de conception (côté maîtrise d’œuvre) avec le même langage. Le fait que ce langage soit partagé par la maîtrise d’ouvrage et la maîtrise d’œuvre d’un projet constitue une grande...

Cas de l’analyse de l’existant

Les outils, méthodes et langages présentés dans le présent chapitre peuvent être utilisés pour exprimer le besoin et mettre au point le cahier des charges fonctionnel et c’est là leur raison d’être.

Dans le cas de la refonte ou de l’évolution d’un système existant, ces mêmes outils peuvent être utilisés pour :

Modéliser le système en place.
Opérer une phase de critique de l’existant avec les acteurs.
Proposer une évolution du modèle en place en décrivant un modèle cible basé sur la présentation des écarts entre le modèle cible et le modèle existant.

Du cahier des charges fonctionnel au cahier des charges

Nous proposons de faire évoluer le cahier des charges fonctionnel en document contractuel entre un client et son fournisseur. Ainsi, le cahier des charges fonctionnel est enrichi de certains éléments afin d’être transformé en cahier des charges. Les éléments à ajouter sont (liste non exhaustive, voir Annexe 1 de ce chapitre) :

Présentation générale de l’entreprise.
Rappel des objectifs et description générale du projet.
Description des acteurs et de la structure de pilotage du projet.
Présentation du phasage du projet.
Description des exigences non fonctionnelles et contraintes.
Attentes en termes de prestations.
Présentation des spécifications administratives et légales du cahier des charges.
Identification des documents administratifs attendus.
Présentation du format de l’offre attendue.
Présentation des spécifications d’évaluation des réponses.

Méthodes d’écoute et de recueil du besoin

Les précédentes sections du présent chapitre présentent la manière d’identifier le besoin et la façon de le formaliser. Cette dernière section présente les méthodes d’écoute des utilisateurs et de recueil du besoin.

Dans la chronologie du projet, ces méthodes sont mises en œuvre dès la phase d’identification du besoin.

1. Techniques de recueil de besoin

Le recueil du besoin est effectué, pas seulement, mais principalement au niveau des futurs utilisateurs du système, ce qui conduit à engager des travaux d’écoute (entretiens, enquêtes, groupes de travail), d’étude et d’observation.

Chaque technique d’écoute et de recueil convient pour la collecte de certains types d’informations, comme le présente le tableau suivant.

Outils de collecte d’information	Informations recueillies
Entretien	Des faits (à vérifier par d’autres sources), les attitudes, les opinions, les motivations, les enjeux, les jeux d’acteurs
Groupe de travail	Des faits, les attitudes, les opinions et les motivations, les enjeux et jeux d’acteurs
Questionnaire	Des faits, des chiffres
Étude de documents	Des faits, des chiffres
Observation : visites sur sites, accompagnement des acteurs sur le terrain	Les pratiques, des faits, les comportements
Expérience : benchmarking (analyse comparative) et application des normes, comparaison à partir de bases de données ou fondée sur une expérience, bonnes pratiques	Des faits, des chiffres, des pratiques

Le succès du processus repose en partie sur la capacité de l’auditeur à vérifier les informations (ici les besoins) à travers plusieurs sources avec différentes techniques de recueil. Il est donc important de mettre en œuvre plusieurs techniques d’écoute au cours de la phase de recueil des besoins.

2. Entretien

a. Objectif

Un entretien concerne une personne ou un petit groupe de personnes (deux à trois maximum). L’entretien permet de recueillir des opinions, des faits, de comprendre l’organisation du travail de la personne, ses attentes et ses besoins.

Cependant, l’entretien permet d’aller au-delà de la capture du besoin....

Annexe 1 : Éléments types de contenu d’un cahier des charges

Le positionnement et les objectifs du projet : la description générale du projet, l’objet du marché et la description des processus informatiques et non informatiques. Dans quel contexte le cahier des charges est-il établi et quels sont les objectifs du projet ?
La description générale du projet :

les objectifs poursuivis par l’entreprise ;
le positionnement du projet dans l’entreprise par rapport à son fonctionnement actuel ;
l’importance stratégique et économique.

La qualité de cette partie du cahier des charges permet entre autres de :

mesurer l’implication de la direction générale dans le projet ;
identifier clairement les objectifs du projet ;
permettre aux personnes chargées de répondre au cahier des charges de proposer des améliorations et de suggérer des solutions qui seront alignées par rapport à l’objectif stratégique.

L’objet du marché :

la description non équivoque et la quantification du marché (fourniture de matériel informatique et/ou de logiciels, services de développement, gestion de réseau, infogérance, etc.) ;
l’identification des éléments pour lesquels une réponse obligatoire est requise sous peine que l’offre ne soit pas prise en considération ;
la possibilité pour le candidat de proposer toutes les options qu’il estimera susceptibles d’améliorer son offre (évaluées en utilisant les mêmes critères que pour la partie obligatoire).

Les acteurs et la structure de pilotage du projet : les personnes en charge de répondre à ce cahier des charges doivent comprendre dans quelle structure de gouvernance du projet ils vont évoluer et être capables d’appréhender :

les responsabilités des différents acteurs ;
les canaux de communication entre les différents acteurs ;
les responsabilités des différents comités de gouvernance ;
l’organisation et la planification des comités de gouvernance.

Le phasage du projet doit être aussi décrit à ce niveau :

les étapes et les jalons : description du contenu et des attentes...

Capturer et formaliser le besoin