Instructions: Décisions importantes en termes d'exigences
Ces instructions décrivent les éléments importants à prendre en considération lors de la personnalisation des exigences du processus.
Relations
Description principale

Détermination de l'utilisation des produits

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.


Quels rapports utiliser

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.

Comment gérer les exigences d'entrée

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.

Comment valider les cas d'utilisation

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