112 lines
4.4 KiB
Markdown
112 lines
4.4 KiB
Markdown
---
|
|
title: "PdP: Analyse des besoins"
|
|
date: 2024-01-24
|
|
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.
|