cours/content/projet_programmation/4_besoins/index.md

---
title: "PdP: Analyse des besoins"
date: 2024-01-31
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.

## 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)