8.1 KiB
| title | date | tags | categories | |||||
|---|---|---|---|---|---|---|---|---|
| PdP: Analyse des besoins | 2024-01-31 |
|
|
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)