diff --git a/content/projet_programmation/4_besoins/index.md b/content/projet_programmation/4_besoins/index.md
new file mode 100644
index 0000000..d82efef
--- /dev/null
+++ b/content/projet_programmation/4_besoins/index.md
@@ -0,0 +1,112 @@
+---
+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.