L’analyse des besoins se situe dans différents contextes :
Le projet peut être nouveau, on recense les besoins pour la première fois, il peut également être au stade de la version X, et en voie de passage à la version X+1, enfin, la reprise d’un code dit legacy peut survenir.
Du coté informaticien, il peut être seul sur le projet, voir dans son laboratoire/unité, ou au contraire être dans un groupe d’informaticiens. Les commanditaires peuvent être ou non les futurs utilisateurs. Les commanditaires et utilisateurs peuvent avoir des connaissances en projet informatique plus ou moins avancés. Ils peuvent également être d’un autre domaine qu’informatique : agriculture, mathématiques, nucléaire …
Selon son importance, plusieurs informaticiens peuvent collaborer, en parallèle, sur des parties du projet. L’interconnections de ses projets est donc aussi à maîtriser. On peut aussi à l’opposé être sur un projet nécessitant 2 jours de travail …
Afin d’aider l’analyse, on peut s’appuyer sur la modélisation de tout ou partie du projet. Celle-ci se fait souvent à l’aide de diagrammes, plus ou moins formalisés. Unified Modeling Langage (UML) est une norme couramment utilisée dans les développements orienté objets, mais on voit aussi d’autres formalismes, tel que DEVS, PETRI …
Le premier objectif est de croiser les différents contextes, avec d’une part la modélisation des besoins, mais également l’expérience des participants au groupe de travail. Diverses questions peuvent se poser, par exemple :
Le second est d’exprimer les besoins du groupe de travail pour le futur, en termes d’actions potentielles ainsi qu’en tant qu’acteurs.
Participants :
accès à l'outil du compte rendu (construction collaborative) http://lite.framapad.org/p/JDEV2013.T1.gt2