49 lines
1.5 KiB
Markdown
49 lines
1.5 KiB
Markdown
---
|
|
title: "Conduite de projet: les besoins"
|
|
date: 2024-09-16
|
|
tags: ["besoins", "conception"]
|
|
categories: ["Conduite de projet", "Cours"]
|
|
mathjax: true
|
|
---
|
|
Une fois le cahier des charge et les spécifications effectué, nous pouvons
|
|
passer aux besoins.
|
|
|
|
Mais attention, l'expression des besoin contient des pièges:
|
|
|
|
* les besoins fantômes;
|
|
* les besoins mal exprimés.
|
|
|
|
Un besoin se caractérise par deux stades:
|
|
|
|
1. en cours de rédaction;
|
|
2. rédigé et en attente de qualification.
|
|
|
|
6 bonnes pratiques:
|
|
|
|
* un besoin doit être identifié par un numéro de besoin
|
|
* un besoin doit être précis
|
|
* un besoin doit être qualifié (type, difficulté, priorisé)
|
|
* un besoin doit être planifié (échéance, unité de temps)
|
|
* un besoin doit être clos (à un moment donné)
|
|
* les besoins doivent être homogénéisés
|
|
|
|
Nos besoins contiennent dont un *identifiant*, une *description*, un *objectif*
|
|
et un *contrôle*. Il faut absolument **tuer tout espace laissé au flou et à
|
|
l'interprétation**. Nous avons besoin de précision.
|
|
|
|
Ils doivent être auto-contenus.
|
|
|
|
**Homogénéité**: chacun des besoins doivent avoir le même point de vue, exprimé
|
|
de la même façon avec la même granularité. Il ne faut **laisser aucune place au
|
|
flou et à l'interprétation**.
|
|
|
|
Un besoin doit être **priorisé** selon 3 critères: `élevé`, `normal`, `bas`
|
|
|
|
### 4 types de besoins
|
|
|
|
* Nouvelle fonctionnalité.
|
|
* Bugfix / amélioration
|
|
* Amélioration de performances
|
|
* Refactoring (visibilité du code)
|
|
|
|
Une fois les besoins définis, nous passer aux tâches.
|