Vous devez choisir les produits devant être utilisés, ainsi que la façon dont ils seront utilisés. Vous devez
aussi personnaliser chaque produit qui sera utilisé pour répondre aux besoins du projet.
Le tableau ci-dessous indique les produits des exigences conseillés et facultatifs (c'est-à-dire ceux ne devant être
utilisés que dans certains cas). Pour plus d'informations sur la personnalisation, consultez la section
personnalisation de la page de description du produit.
Produit
|
Objectif
|
Personnalisation (facultatif, recommandé)
|
Produit : Modèle de cas d'utilisation (Produit : Acteur, Produit : Cas d'utilisation, Produit : Package de cas d'utilisation)
|
Les cas d'utilisation permettent de définir les exigences fonctionnelles.
|
Recommandé pour la plupart des projets.
Les cas d'utilisation sont la méthode recommandée d'enregistrement des exigences fonctionnelles.
|
Produit : Storyboard
|
Il est recommandé, pour les projets comportant des exigences de comportement qui ne sont pas bien
comprises, de recourir aux storyboards afin d'expliciter ces exigences.
|
Facultatif
Il est possible de recourir à d'autres techniques d'explicitation des exigences.
|
Produit : Glossaire
|
Garantit que toutes les personnes participant au projet utilisent un vocabulaire commun.
|
Recommandé pour la plupart des projets.
|
Produit : Attributs d'exigences
|
Une base de données des attributs d'exigences permet de garantir que les exigences sont correctement
priorisées, suivies et tracées.
|
Facultatif
Les bases de données des attributs d'exigences peuvent toutefois ne pas être obligatoires pour les
projets comptant relativement peu d'exigences.
|
Produit : Plan de gestion des exigences
|
Décrit les informations à collecter et les mécanismes de contrôle à utiliser pour mesurer, contrôler et
rendre compte des changements apportés au produit. Un document distinct est nécessaire si la complexité
de la gestion des exigences ou la visibilité client l'imposent.
|
Facultatif
Les projets comptant relativement peu d'exigences peuvent adopter une approche légère à l'égard de
la gestion des exigences qui peut être documentée directement dans le plan de développement
logiciel.
Les autres projets peuvent retenir et suivre une approche plus rigoureuse, mais produisent peu ou
pas de descriptions formelles. L'ensemble d'attributs d'exigences à réunir peut, par exemple, être
implicitement documenté par la configuration des outils.
|
Produit : Spécification des exigences logicielles
|
Permet de réunir l'ensemble des exigences dans un document formel fourni au client.
|
Facultatif
Pour les projets moins formels, il peut ne pas être obligatoire de fournir un document formel.
|
Produit : Demandes des parties prenantes
|
Enregistre toutes les demandes formulées au sujet du projet, ainsi que la suite qui leur a été donnée.
|
Recommandé pour la plupart des projets.
Pour générer un système qui réponde aux besoins des parties prenantes, il est important de
collecter leurs demandes et de les étudier.
De nombreux projets gèrent les demandes des parties prenantes comme une simple catégorie de demande
de changement. D'autres projets peuvent n'enregistrer les demandes des parties prenantes que de
manière informelle.
|
Produit : Spécifications supplémentaires
|
Permet d'enregistrer les exigences non-fonctionnelles.
|
Recommandé pour la plupart des projets.
|
Produit : Vision
|
Enregistre des exigences et des contraintes de conception de très haut niveau afin de permettre au
lecteur de comprendre le système à développer.
|
Recommandé pour la plupart des projets.
|
Le choix des rapports à utiliser dépend des outils de rapports disponibles pour le projet. Si des outils de génération
de rapports sont disponibles, nous préconisons de générer des rapports pour les produits orientés modèle ou orientés
base de données, tels que les cas d'utilisation et les acteurs. Des rapports existants dans la configuration de votre
processus RUP sont disponibles dans les pages descriptives du produit et regroupés sous le produit en question dans le
navigateur d'arborescence.
Cette section ne s'applique que dans le cas où un contrat formel, une norme ou un document de spécification impose des
exigences à l'effort de gestion des exigences. On l'appelle « spécification des exigences d'entrée ».
Durant l'effort de collecte des exigences, vous enregistrez les exigences dans les documents suivants : Produit : Vision, Produit : Demandes des parties prenantes, Produit : Modèle de cas d'utilisation, Produit : Spécifications supplémentaires.
Décidez si la spécification des exigences d'entrée sera gérée ou pas. Reviendrez-vous en arrière et mettrez à jour la
spécification des exigences d'entrée si vous découvrez qu'une exigence était mauvaise, incorrecte ou mal définie ? Vous
devez aussi décider comment maintenir les traces ou les
références entre les spécifications des exigences d'entrée et le Produit :
Cas d'utilisation.
Choisissez une ou plusieurs des stratégies suivantes :
-
Ne pas mettre à jour la spécification des exigences d'entrée. Laisser les cas d'utilisation et la spécification
supplémentaire définir ce que le système effectuera ensuite.
-
Ne pas mettre à jour la spécification des exigences d'entrée, mais gérer la traçabilité
des cas d'utilisation vers la spécification.
-
Mettre à jour la spécification des exigences d'entrée avec tous les travaux et les coûts induits.
-
Laisser la spécification des exigences d'entrée se transformer en une spécification supplémentaire contenant des
exigences. Les exigences d'entrée fonctionnelles sont simplement transférées aux cas d'utilisation.
Dans la plupart des projets, on se rend compte que les exigences mauvaises, mal définies ou incorrectes sont si
nombreuses que maintenir la spécification des exigences d'entrée d'origine n'aurait aucune justification. Rares sont
les clients de projets qui acceptent de financer la mise à jour de la spécification des exigences d'entrée avec les
nouvelles informations obtenues lors de la modélisation de cas d'utilisation.
Ne mettez pas trop tôt l'accent sur ce sujet. Au début d'un projet, les personnes croient en la spécification des
exigences initiale, mais après s'être attaqués au problème avec un cas d'utilisation, la plupart d'entre eux ont une
vision tout à fait différente de cette spécification.
Décider comment valider les cas d'utilisation. Il est possible de gagner un temps considérable en limitant le nombre de
cas d'utilisation devant être formellement révisés par le
client. La revue formelle d'un seul sous-ensemble de tous les cas d'utilisation peut éventuellement suffire.
Choisissez une ou plusieurs des stratégies suivantes :
-
Tous les cas d'utilisation doivent être révisés de manière formelle par des intervenants extérieurs au projet.
-
Certains cas d'utilisation secondaires peuvent être validés de manière simplifiée, que la revue soit informelle ou
formelle et interne.
Les cas d'utilisation secondaires sont ceux qui sont essentiels au système mais pas à la tâche de l'utilisateur
principal ; par exemple, les cas d'utilisation liés à l'administration et à la maintenance du système, tels que l'ajout
d'utilisateurs au système, le changement de leurs droits d'accès et la création de sauvegardes. Le système ne
fonctionnera pas sans ces cas d'utilisation, bien qu'ils ne constituent pas un point d'intérêt central pour les
utilisateurs importants.
La stratégie que vous employez dépend de vos relations avec le client. Estiment-ils que vous pouvez vous occuper des
cas d'utilisation secondaires sans processus formel de validation ? Bien que cela puisse permettre de gagner un temps
considérable, parviendrez-vous à atteindre le niveau de qualité qui convient pour le modèle de cas d'utilisation ?
Remarque : trouver une solution au problème peut nécessiter d'impliquer le client dans l'effort lié aux
exigences. Faire participer les ingénieurs commerciaux leur permet de valider ou de formuler des recommandations aux
autres clients, l'implication du client permettant au projet de gagner en crédibilité.
Pour plus d'informations sur les niveaux de revue, voir aussi les Instructions :
Niveaux de revue.
|