Add second part of needs article
This commit is contained in:
parent
78ded52610
commit
6317896a16
1 changed files with 84 additions and 0 deletions
|
@ -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)
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue