Analyse des exigences
Cet article est une ébauche concernant l’informatique.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
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[modifier | modifier le code]
Interviews de parties prenantes[modifier | modifier le code]
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.
Workshops d'analyse des exigences[modifier | modifier le code]
Prototypes[modifier | modifier le code]
Cas d'utilisation[modifier | modifier le code]
Spécification d'exigences de logiciel[modifier | modifier le code]
Identification des parties prenantes[modifier | modifier le code]
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[modifier | modifier le code]
Problèmes des utilisateurs[modifier | modifier le code]
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é.
Problèmes des ingénieurs et des développeurs[modifier | modifier le code]
Essais de solutions[modifier | modifier le code]
