4.4 KiB
| title | date | tags | categories | |||||
|---|---|---|---|---|---|---|---|---|
| PdP: Analyse des besoins | 2024-01-24 |
|
|
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.