Analyse et Spécification des Besoins

Cette ressource porte sur l’analyse et la spécification des besoins dans le domaine du développement de systèmes informatiques. Elle s’adresse aux étudiants en informatique, gestion de projet, ou toute personne souhaitant comprendre comment définir précisément ce qu’un système doit faire avant sa réalisation. L’objectif est d’éviter les erreurs fréquentes liées à une mauvaise compréhension des attentes du client.

La question

Le travail aborde le problème fréquent des systèmes informatiques mal utilisés, voire inutilisés, car ils ne correspondent pas aux besoins réels des clients. Cette inadéquation génère des frustrations telles que « ce n’est pas ce que je voulais » ou « ça ne sert à rien ». La question centrale est donc : comment analyser et spécifier correctement les besoins afin de concevoir un système qui réponde réellement aux attentes des utilisateurs ? Ce problème est crucial car il impacte la réussite des projets informatiques et la satisfaction des clients.

Concepts de base

Avant d’aborder l’analyse et la spécification des besoins, il est essentiel de comprendre plusieurs notions clés :

• Besoins (Requirements) : ce sont les exigences que le système doit satisfaire. Ils peuvent être fonctionnels (ce que le système doit faire) ou non fonctionnels (contraintes sur le système, comme la sécurité ou la performance).
• Besoins fonctionnels : décrivent les fonctions, services et données manipulées par le système. Par exemple, dans un système de contrôle d’ascenseur, un besoin fonctionnel serait que le système planifie efficacement les déplacements.
• Besoins non fonctionnels : ce sont des contraintes sur les fonctions, comme la vitesse, la fiabilité, la facilité d’utilisation, ou la robustesse. Ils sont souvent plus difficiles à formuler précisément et à vérifier.
• Besoins du domaine : liés aux usages spécifiques de l’entreprise, comme les normes internes, la charte graphique ou les règles métier.
• Analyse des besoins : étude du domaine d’application pour définir ce que le système doit faire (le « quoi ») sans se préoccuper du « comment ».
• Spécification des besoins : formalisation des besoins sous forme de documents ou modèles, qui serviront de référence pour le développement.

Le processus d’analyse des besoins est complexe car le client ne sait pas toujours exprimer clairement ses attentes, et l’informaticien peut mal comprendre le client. De plus, le client exprime souvent une solution plutôt que le besoin réel, et il peut ignorer ce qui est techniquement possible.

Approche

Le processus d’analyse des besoins se divise en deux grandes phases :

• Expression des besoins : identification, validation et gestion des besoins. Cette étape implique des entretiens, questionnaires, observations, étude des systèmes existants, et parfois des techniques modernes comme le prototypage ou des ateliers collaboratifs (JAD, FAST, QFD).
• Spécification des besoins : modélisation et formalisation des besoins, suivies d’une validation. Cette étape produit des documents comme le cahier des charges qui décrit les comportements attendus du système et les contraintes.

La validation est essentielle pour s’assurer que les besoins sont complets, cohérents, réalisables, vérifiables et traçables. La gestion des besoins inclut leur identification, classification, hiérarchisation et mise à jour.

La spécification peut être réalisée à différents niveaux de formalité :

• Informelle : en langage naturel, libre mais peu rigoureuse, ce qui peut entraîner des ambiguïtés et des difficultés de vérification.
• Semi-formelle : utilisation de langages structurés textuels ou graphiques, comme les diagrammes de flux de données (DFD), les dictionnaires de données (DD), ou les modèles entité-relation (E/R).
• Formelle : utilisation de langages mathématiques avec syntaxe et sémantique précises, comme le langage Z, permettant de réduire les erreurs mais nécessitant des compétences spécifiques.

Parmi les outils semi-formels, le DFD est un diagramme qui représente graphiquement le flux des données à travers le système, décomposé en processus, dépôts de données, sources et destinations. Le dictionnaire de données complète le DFD en documentant précisément chaque donnée utilisée. Le modèle E/R sert à décrire les données au repos et leurs relations, notamment pour la conception de bases de données.

Pour modéliser le comportement dynamique, on utilise les machines à états finis, qui décrivent les transitions entre états du système en fonction des événements.

Le langage UML est également mentionné comme un outil de modélisation avec divers diagrammes (cas d’utilisation, séquence, transitions d’états) pour représenter les différents aspects du système.

Résultats

Le travail souligne que :

• Une bonne analyse des besoins est déterminante pour la réussite d’un projet informatique.
• Les besoins doivent être validés avec les utilisateurs pour éviter les erreurs d’interprétation.
• Les besoins non fonctionnels, bien que plus difficiles à formuler, sont essentiels et doivent être rendus vérifiables autant que possible.
• La spécification formelle réduit les erreurs mais demande des compétences spécifiques et un investissement en temps.
• Les méthodes semi-formelles, comme les DFD et dictionnaires de données, facilitent la communication entre analystes et utilisateurs et permettent une meilleure compréhension du système.
• Le cahier des charges est un document clé qui doit être clair, complet, cohérent, réalisable, vérifiable et traçable, et qui sert de référence contractuelle.

Limitations et questions ouvertes

Le document met en avant plusieurs difficultés non complètement résolues :

• La difficulté pour le client d’exprimer clairement ses besoins, surtout dans un domaine nouveau ou complexe.
• La complexité de la communication entre clients non informaticiens et analystes informaticiens, souvent issus de cultures différentes.
• Les besoins non fonctionnels restent souvent imprécis et difficiles à vérifier.
• La spécification formelle, bien que rigoureuse, nécessite un bagage mathématique et une implication importante des parties prenantes, ce qui peut ne pas être toujours réalisable.
• Le raffinement des modèles doit être fait avec méthode pour éviter des erreurs de continuité ou de cohérence dans la modélisation.

Glossaire

• Besoins fonctionnels : Fonctions et services que le système doit fournir.
• Besoins non fonctionnels : Contraintes sur le système, telles que la performance, la sécurité, la convivialité.
• Analyse des besoins : Étude visant à définir ce que le système doit faire, sans se préoccuper du comment.
• Spécification des besoins : Formalisation des besoins sous forme de documents ou modèles.
• Diagramme de flux de données (DFD) : Représentation graphique des flux d’informations dans un système.
• Dictionnaire de données (DD) : Documentation détaillée des données utilisées dans le système.
• Modèle Entité/Relation (E/R) : Modèle graphique décrivant les données et leurs relations.
• Machine à états finis : Modèle décrivant les états d’un système et les transitions entre eux.
• Langage formel : Langage mathématique rigoureux utilisé pour spécifier les besoins.
• Cahier des charges : Document contractuel qui décrit les besoins et contraintes du système à développer.