From 6317896a16689669c395293a4eef1789f148d0d7 Mon Sep 17 00:00:00 2001
From: Yorick Barbanneau <ephase@xieme-art.org>
Date: Tue, 6 Feb 2024 22:11:11 +0100
Subject: [PATCH] Add second part of needs article

---
 .../projet_programmation/4_besoins/index.md   | 84 +++++++++++++++++++
 1 file changed, 84 insertions(+)

diff --git a/content/projet_programmation/4_besoins/index.md b/content/projet_programmation/4_besoins/index.md
index d82efef..61a6fa4 100644
--- a/content/projet_programmation/4_besoins/index.md
+++ b/content/projet_programmation/4_besoins/index.md
@@ -110,3 +110,87 @@ Un bon exemple de décomposition reste les options associés à la commande `ls`
 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)