Analyse des besoins pour automatisation RAF – Société JeConseille

Ce document traite de l’analyse des besoins dans le cadre de plusieurs projets d’automatisation et de gestion informatique, notamment pour une société de conseil, un laboratoire de recherche, un système de vote électronique et une gestion aéroportuaire. Il s’adresse aux étudiants en génie logiciel ou en informatique qui souhaitent comprendre comment identifier les acteurs, exprimer et classer les besoins fonctionnels et non fonctionnels dans un projet de développement logiciel.

La question

Le travail porte sur la définition précise des besoins pour différents systèmes informatiques dans des contextes variés : automatisation du reporting d’activité et de frais (RAF) pour une société de conseil, gestion des demandes de moyens dans un laboratoire de recherche (ALLOC), mise en place d’un système de vote électronique (Sys_Vote), et gestion des tâches du personnel au sol dans un aéroport (logiciel L). La problématique centrale est d’identifier clairement les acteurs impliqués, de distinguer les besoins fonctionnels des besoins non fonctionnels, et de reformuler les besoins mal exprimés pour qu’ils soient vérifiables. Ce travail est essentiel pour garantir que le système développé réponde aux attentes réelles des utilisateurs et soit techniquement réalisable.

Concepts de base

Avant de pouvoir analyser un système, il est nécessaire de comprendre plusieurs notions clés :

• Acteurs : Ce sont les personnes, groupes ou systèmes externes qui interagissent avec le système étudié. Identifier les acteurs permet de comprendre qui utilise le système et quelles sont leurs attentes.
• Besoins fonctionnels (BF) : Ils décrivent ce que le système doit faire, c’est-à-dire les fonctionnalités ou services qu’il doit fournir.
• Besoins non fonctionnels (BNF) : Ils concernent les qualités attendues du système, telles que la performance, la fiabilité, la sécurité, l’ergonomie, etc.
• Besoins mal exprimés (MAL) : Ce sont des besoins formulés de manière vague ou ambiguë, ce qui empêche leur vérification ou leur mise en œuvre directe. Ils doivent être reformulés clairement.
• Besoins inadéquats (Aucun) : Ce sont des éléments qui ne correspondent ni à un besoin fonctionnel ni à un besoin non fonctionnel, souvent des confusions ou des attentes hors du périmètre du système.

La distinction entre ces catégories est cruciale pour rédiger un cahier des charges clair et exploitable.

Approche

Pour chaque projet, la méthode consiste à :

• Identifier les acteurs du système en analysant les rôles et les interactions décrits dans le contexte.
• Examiner une liste de besoins proposés et les classer selon les catégories BF, BNF, MAL ou Aucun, en justifiant chaque choix.
• Reformuler les besoins mal exprimés pour qu’ils soient précis, mesurables et vérifiables.
• Pour certains projets, exprimer les besoins spécifiques de chaque acteur et rédiger un cahier des charges synthétique.

Cette démarche permet de clarifier les attentes, d’éviter les ambiguïtés et de préparer le terrain pour la conception et le développement du système.

Résultats

Les exercices montrent comment appliquer cette méthode dans différents contextes :

• RAF (Reporting d’Activité et de Frais) : Les acteurs identifiés sont les employés, la secrétaire, et le manager de division. Les besoins fonctionnels incluent la saisie des rapports prévisionnels, la consolidation des données par la secrétaire, et l’envoi d’e-mails. Les besoins non fonctionnels concernent la gestion de plusieurs connexions simultanées et la minimisation des temps de réponse. Un besoin mal exprimé, comme l’utilisation d’un tableur pour la saisie, doit être reformulé pour préciser l’interface et les modalités de saisie.
• ALLOC (Gestion des moyens dans un laboratoire) : Les acteurs sont le chercheur, le directeur de laboratoire, le directeur scientifique, le coordonnateur, la direction générale, et éventuellement le stagiaire. Les besoins fonctionnels comprennent la saisie et la consultation des demandes de moyens, l’édition des fiches, la gestion des propositions et arbitrages. Les besoins non fonctionnels portent sur l’ergonomie, la fiabilité et la facilité d’utilisation par des utilisateurs peu expérimentés.
• Sys_Vote (Vote électronique) : Les acteurs sont l’administrateur, l’électeur, l’employé d’élection, le scrutateur, et le Directeur Général des Élections (via le serveur central). Les besoins fonctionnels couvrent la gestion des partis politiques, la vérification d’identité, la saisie et l’enregistrement sécurisés des votes, ainsi que la comptabilisation des résultats. Les besoins non fonctionnels incluent la sécurité, la confidentialité, la rapidité de traitement, et la fiabilité des données.
• Logiciel L (Gestion aéroportuaire) : Les acteurs sont le personnel au sol (agents), le régulateur R, et le service de recherche opérationnelle. Les besoins fonctionnels concernent la gestion des tâches liées aux vols, l’affectation des agents, la prise en compte des aléas, et la modification en temps réel des plannings. La complexité croissante du volume des vols rend nécessaire un logiciel performant et flexible.

Limitations et questions ouvertes

Le travail présenté se concentre sur l’expression et la classification des besoins à partir d’énoncés donnés. Il ne traite pas de la conception détaillée, de la validation technique ou de la mise en œuvre des systèmes. De plus, certains besoins sont parfois formulés de manière imprécise, ce qui nécessite une reformulation rigoureuse pour garantir leur vérifiabilité. Enfin, la gestion des aléas en temps réel, la sécurité des données dans le système de vote, ou l’ergonomie pour des utilisateurs peu expérimentés restent des défis à approfondir dans les phases suivantes du projet.

Glossaire

• Acteur : Personne ou système externe interagissant avec le système étudié.
• Besoins fonctionnels (BF) : Fonctions ou services que le système doit fournir.
• Besoins non fonctionnels (BNF) : Qualités ou contraintes du système (performance, sécurité, ergonomie, etc.).
• Besoins mal exprimés (MAL) : Besoins formulés de façon vague ou ambiguë, non vérifiables.
• Besoins inadéquats (Aucun) : Éléments hors périmètre ou non pertinents pour le système.
• Cahier des charges : Document formalisant les besoins et contraintes du système à développer.
• Consolidation : Regroupement et synthèse des données provenant de plusieurs sources.
• Ergonomie : Facilité d’utilisation et d’apprentissage d’un système par ses utilisateurs.
• Requête SQL : Instruction permettant d’interroger ou de modifier une base de données.
• Serveur central : Ordinateur centralisé qui stocke et gère les données partagées par plusieurs appareils.