La discipline Ingénierie des Exigences du RUP

La discipline ingénierie des exigences occupe une place importante dans le processus de développement du RUP. En plus d’être l’élément de base qui sert les autres disciplines telles que l’analyse et la conception, les exigences permettent également d’estimer le coût et l’effort du développement du système à produire. La discipline de la gestion des exigences contient l’enchaînement des activités qui permettent d’analyser le problème à résoudre, de définir le système, de comprendre les besoins des utilisateurs, de documenter les exigences logicielles et de gérer les changements. Les objectifs de la discipline de la gestion des exigences se résument donc dans les points suivants [Pas 06] :  Établir un accord entre les intervenants sur les objectifs du système à développer.  Fournir aux développeurs du système une meilleure compréhension des exigences logicielles.  Définir les limites du système à développer.  Fournir un plan initial des itérations à réaliser.  Fournir des estimations initiales des coûts, des échéanciers pour développer le système.  Définir les interfaces graphiques en se basant sur les besoins des utilisateurs. La Figure 3.6 illustre l’enchaînement des tâches pour la discipline gestion des exigences.   Chaque tâche est présentée par un enchaînement d’activités cohérentes les unes par rapport aux autres. Le processus réel employé par la discipline requise est largement axé sur les cas d’utilisation, qui sont supposés être un milieu approprié pour la communication des exigences fonctionnelles entre les parties prenantes et les développeurs. Pour cet effet, les Cas d’utilisation ainsi que toutes les autres spécifications et des documents traités dans cette discipline devraient également être créés dans la langue des clients. Dans les sections suivantes, chaque activité impliquée dans la discipline Exigences est brièvement expliquée. En outre, étant donné que chaque activité peut introduire d’autres tâches et des artefacts, des diagrammes montrant plusieurs des relations entre les tâches et artefacts seront affichés. 

La discipline Ingénierie des Exigences du RUP

L’activité : Analyse Problème

L’activité « Analyse problème», décrit les tâches initiales à effectuer si un nouveau système doit être développé. L’aspect le plus essentiel de cette activité est d’identifier les parties prenantes clé ainsi que les exigences clés pour le projet (Figure 3.7). Afin de cerner les limites du système, une partie de la tâche ″Développer Vision″ est de parvenir à un accord sur quelques problèmes réels à résoudre. Basé sur cette information, le premier artéfact le ″Document Vision″ pourra être rédigé. Ce document est destiné à décrire la vision globale du projet ainsi que pour documenter l’information sur les intervenants clés et les problèmes identifiés à ce jour. Pour éviter tout malentendu entre les parties prenantes dans le projet et aussi faciliter la compréhension et une vision commune, la tâche « Capturer vocabulaire commun″ recueille les terminologies les plus importantes utilisé dans le domaine du problème. Cette information est ensuite recueillie et structuré dans le glossaire, qui est maintenue et améliorée tout au long du reste de processus de développement. Figure 3.7 Tâches et artéfacts impliqués dans l’activité : Analyse du Problème 

L’activité : Comprendre les Besoins Utilisateurs

Après avoir identifié les parties prenantes dans l’activité précédente, des exigences plus détaillées peuvent désormais être collectées. La tâche ″Eliciter demandes intervenants″ inclut le processus d’interview des clients, l’évaluation des questionnaires et d’autres techniques visant à la collecte des besoins plus spécifiques. Une des techniques mises en évidence par le RUP est ″Storyboarding″ qui présente un ensemble de scénarios ou comportement du système créés et raffinés par les utilisateurs. Afin d’être en mesure de comprendre les intentions derrière les besoins individuels formulé à ce stade et les étapes ultérieurs, il sera désormais utile d’avoir une bonne compréhension du contexte du système, comme indiquée par la ″Modélisation métier″. En parallèle à la collecte des besoins fonctionnels, les besoins fonctionnels devraient désormais être identifiés. Contrairement aux exigences fonctionnelles qui sont incorporées principalement dans les cas d’utilisation, les exigences non fonctionnelles sont recueillies et structurées dans un artéfact à part appelé SS ″spécification supplémentaire″ (Figure 3.8).

L’activité : Définir le Système

La définition de la vision du système à construire et l’identification des intervenants et des exigences clés ont été élaborées par les deux activités précédentes. Ces informations peuvent être analysées plus amplement. La tâche la plus importante de l’activité ″Définir le système″ est donc : Trouver des acteurs, et des cas d’utilisation, qui visent à identifier et raffiner le système en se basant sur les informations recueillies. Les cas d’utilisation et les acteurs identifiés doivent ensuite être expliqués. Bien que la définition précise soit élaborée dans des activités ultérieures, chaque cas d’utilisation et acteur doivent être accompagnés d’une brève description, compréhensible par le client. Dans le cas des acteurs, les responsabilités individuelles doivent être décrites de même que la valeur fournie par le système pour cet acteur spécifique. Dans les cas d’utilisation, une description générale ainsi qu’un grand nombre d’événements doivent être spécifiés. La figure 3.9 montre les tâches et les artéfacts impliqués dans la définition d’un système. 

L’activité : Gestion de la Portée du Système

Le résultat des activités précédentes est l’identification d’un nombre important de cas d’utilisation. L’objectif l’activité « Gestion de la portée du système » est de structurer le modèle des cas d’utilisation et la priorisation des cas d’utilisation individuels. L’ordre des priorités est abordé par la tâche « Prioriser cas d’utilisation » en s’appuyant sur plusieurs critères. En plus de la prise en compte de la valeur de chaque cas d’utilisation fourni aux parties prenantes, aussi bien que le budget et le temps prévu. Cette tâche utilise deux artéfacts provenant d’autres disciplines effectuées en parallèle (« Gestion de projet » et «analyse et conception »)