Analyse des exigences
En ingénierie des systèmes et en ingénierie logicielle, l'analyse des exigences comprend les tâches qui ont pour but de déterminer les exigences d'un système nouveau ou à modifier, en prenant en compte le conflit possible entre les exigences de diverses parties prenantes, telles que les utilisateurs. L'analyse des exigences est critique pour le succès d'un projet.
Techniques principales
Interviews de parties prenantes
Les interviews de parties prenantes sont une méthode communément employée dans l'analyse des exigences. En général il est nécessaire de faire un choix, le coût étant un facteur pour décider qui interviewer. Ces interviews peuvent révéler des exigences qui n'avaient pas été envisagées auparavant comme faisant partie du champ du projet, et des exigences peuvent entrer en contradiction. Cependant, une partie prenante doit avoir une idée de ses attentes ou devra avoir visualisé ses exigences.
Identification des parties prenantes
Un nouvel enjeu majeur dans les années 1990 a été l'attention portée à l'identification des parties prenantes. On reconnaît de plus en plus que les parties prenantes ne se limitent pas à l'organisation qui emploie l'analyste. Les autres parties prenantes sont :
- les organisations qui intègrent (ou devraient intégrer) horizontalement l'organisation pour laquelle l'analyste conçoit le système,
- tout système ou organisation de back office,
- le management senior.
Problèmes
Problèmes des utilisateurs
Steve McConnell, dans son livre Rapid Development, détaille un certain nombre de manières selon lesquelles les utilisateurs peuvent ne pas maîtriser l'ensemble des exigences :
- Les utilisateurs ne savent pas ce qu'ils veulent ;
- Les utilisateurs ne veulent pas s'engager à écrire les exigences ;
- Les utilisateurs insistent sur de nouvelles exigences après que le coût et le calendrier ont été fixés ;
- La communication avec les utilisateurs est lente ;
- Les utilisateurs ne participent le plus souvent pas aux revues ou sont incapables de le faire ;
- Les utilisateurs manquent de compétence technique ;
- Les utilisateurs ne comprennent pas le processus de développement.
Cela peut conduire à une situation où les exigences des utilisateurs continuent de changer même lorsque le développement du système ou du produit a commencé.
