Add second part of needs article

This commit is contained in:
Yorick Barbanneau 2024-02-06 22:11:11 +01:00
parent 78ded52610
commit 6317896a16

View file

@ -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 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 le qualifiant et l'associant à des *domaines de fonctionnements stricts*, à des
*contraintes de faisabilités*, etc. *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)