--- title: "PdP: Analyse des besoins" date: 2024-01-31 tags: ["besoins", "analyse", "developpement logiciel"] categories: ["Projet de programmation", "Cours"] --- Avant même de commencer à coder, il faut analyser les besoins du "commanditaire". Il faut maximiser les chances d'être adéquats mais **sans formalisme**, il est cependant **nécessaire** d'y mettre de la rigueur. Il faut définir et décrire les service que notre logiciel doit offrir, il faut aussi identifier et décrire ses différentes contraintes (domaine de fonctionnement, usage des ressources forme des résultats, etc.). Il faut cependant décorréler l'analyse des besoins de l'implémentation. Les langages doivent être considéré comme des outils, il faut les choisir en fonction des besoins (et non pas faire l'analyse en fonction du langage). L'analyse doit être effectuée *en langage naturel* de façon précise et avec rigueur. ## Deux types de besoins Nous pouvons commencer par classer les besoins en deux catégories : * **Les besoins fonctionnels**: les services et fonctionnalités comme rechercher dans une base de données, réaliser une sauvegarde... Il sont nécessaires au logiciel (*ceux que logiciel devrait faire*); * **Les besoins non-fonctionnels**: caractéristiques de ce que le programma *va faire* comme une réponse rapide de l'interface, la compatibilité avec des formats de fichiers... Les besoins fonctionnels sont souvent associés à **un verbe**, une action à réaliser. Les besoins non fonctionnels sont souvent critiques et demandent **beaucoup de travail**. Ces besoins peuvent aussi être en conflits comme *la rapidité* et la *sécurité* par exemple. Ils entraînent souvent des besoins fonctionnels. Ils sont eux caractérisés par **un adjectif**. ### Catégoriser des fonctionnalités non fonctionnelles #### Les besoins non fonctionnels de comportement. Ils comprennent *les performances*, *la fiabilité*, *la sécurité*, *la facilité d'utilisation*, *le domaine d'action*, *la portabilité* #### Les besoins non fonctionnels organisationnels Ils comprennent le choix *des processus de développement*, les *langages de spécification*, les *techniques de planification du travail*, le *calendrier des livrables*, le *cadre budgétaire*. #### Les besoins non fonctionnels externes Il dépendent de pré-requis qui ne sont pas dépendants de l'équipe de développement. Nous pouvons citer: * Les **contraintes matérielles** dépendant de l'architecture matérielle sur laquelle le programme tournera (ISA, espace mémoire, carte graphique, etc.); * Les **contraintes légales** comme les règlement sur les données personnelles, les différents cadres sur les captations vidéos, etc. * Les **contraintes éthiques**: préservation de la vie privée des utilisateur par exemple. ## Autre classement... Il est aussi possible de classer les besoins entre **utilisateur** et **système**. Les premiers sont associés à ceux qui vont utiliser le logiciel qu'il soient simple utilisateurs, clients, maître d'ouvrage, développeur. Les seconds sont liés aux contraintes internes du logiciel et ceux qui vont le développer (développeur, maître d'œuvre). Ce type de classement se montre utile lorsque la liste des contraintes est longue. ## De la précision ... Comme nous l'avons vu, l'analyse des besoin se doit d'être précise et rigoureuse. Plus elle est précise plus on obtiendra une description adéquate du logiciel à produire. La précision dans l'analyse indique aussi une bonne compréhension du domaine, elle permettra une organisation plus efficace du travail. ## ... de la vérification ... Un besoin doit ouvoir être testé et vérifié sinon il est ineffectif. oin qui ne peux pas être vérifié et/ou testé doit être décomposé en sous-besoins (ou être précisés). Prenons l'exemple: *importer des fichiers*. Ce besoin n'est pas vérifiable, validable et testable en l'état. Nous pouvons le décomposer: * Lire des types de fichiers distinct, mais il faut décrire lesquels; * Associer des traitements à chacun des types de fichiers; * Ajouter les types de fichiers acceptés dans l'interface; * etc. Un bon exemple de décomposition reste les options associés à la commande `ls`. ## ... et de la caractérisation En plus de la décomposition, il est important de **caractériser** un besoin en le qualifiant et l'associant à des *domaines de fonctionnements stricts*, à des *contraintes de faisabilités*, etc. ## Caractérisation des besoins comme nous l'avons vu les besoin peuvent être décomposés, mais ils peuvent être aussi **caractérisés** : qualifiés, assocoés à des domaines stricts de fonctionnement, des contraintes de faisabilité etc, Pour caractériser et préciser les besoins nous avons besoin: * *domaine de fonctionnement**: maîtrise de ce que l'on développe en accord avec le domaine, c'est une part essentielle pour *les tests*. Le vocabulaire doit être choisi avec précision et justifié. Les mots *protocole*, *donnée*, *format*, *configuration logicielle*, *serveur* soivent être justifiés et précisés. Les domaines de valeurs des entrées et sorties soivent être décris et bornés; * *attributs, qualifications, évaluations* de la performances, robustesse, sécurité. Cette partie nécessite de la précision et qualifiés (unité de mesure, taille, confiance); * *faisabilité*: par exemple le réalismes graphiquedans les jeux des années 90 était infaisable à la vue des contraintes techniques; * *décrire les difficultés et risques* associés. ### Par les stories Nous pouvons exprimer des besoins en racontant des "histoires", on imagine des scénarios en tant qu'utilisateur par example: > En tant que (...) je veux que (...) de manière à ce que (...) Nous utililons des phrases standards incluant le destinataire du besoin. ### Besoins non-fonctionnels quantifié Là encore nous avons besoins de précision, prenon l'exemple du besoin non fonctionnel "*Les animations graphiques doivent être fluides* de quoi est-il question: * Quel nombre d'image par seconde minimal? * Quelle machine cible? Quelle taille d'image? * Animation précalculée ou générée? * Quel framework / API graphique utilisé (OpenGL, Vulkan, DirectX)? En terme de sécurité, des **normes existes** comme *DO-178C* dans les logiciels pour l'aviation avec des niveau de A à E définissant la criticité des impacts. Le modèle *Capability Maturity Model Integration* fixe une mesure pour la qualité du travail d'une équipe de dévellopement : * *Initial*: peu de contrôle sur les processus, résultats imprévisibles dépendant de la compétence et volonté de l'équipe; * *MAnaged*: processus de gestion de projet caractérisés définis et appliqués, dévellopement planifié; * *Defined*: définition de processus standardisés à toute l'organisation / entreprise; * *Quantitatively*: utilisation systëmatique de mesures et de contrôle sur **tous** les processus; * *Optimizing*: optimisation des processus, amélioration et possibilité de changement intégrés dans le processus. ### Faisabilité Il faut se référer aux documentations et étudiant l'existant dans notre étude de faisabilité. Il est aussi possible de regader ... ce que fait la concurence. C'est à cette étape que nous pouvons utiliser le prototypage et analyser les résultats. Il est important de décrire les difficultés et d'estimer leur niveau. Les prototypes et leurs résultats pevent servir pour expliquer ces difficultés. ### Prioriser La priorisation va de pair avec la description des besoins. Il est nécessaire de décrire et déterminer les priorités. Le document *IEEE/ANSI 830-1998* propose trois niveau: * **Essentiel**: le logiciel ne sera pas acceptable sans que ce besoin soit réalisé; * **Conditinnel**: besoin qui améliore et/ou étend le logiciel sans que celui-si soit nécessaire pour rendre le logiciel acceptable; **Optionnel**: la valeur de ce besoin n'est pas encore assurée, mais il peut permettre de proposer une **plus** au fournisseur. L'échelle de *MoSCoW* : Must, Should, Could, Won't. (un peu à la manière des RFC)