Concept: Exigences dérivées
Une exigence dérivée est induite par ou provient d'une exigence de l'utilisateur. Ces exigences sont dérivées en approfondissant les détails de l'exigence de l'utilisateur.
Relations
Description principale

Introduction

Les exigences associées au développement du système sont inévitablement hiérarchisées, de la moins détaillée, qui définit la mission du système ou les objectifs récapitulatifs de l'utilisateur pour le système, à la plus détaillée, en passant certainement par plusieurs niveaux intermédiaires. Au niveau le moins élevé, les exigences peuvent être exprimées à l'aide du vocabulaire de la technologie utilisée par le système alors qu'au niveau le plus élevé, elles sont généralement exprimées de manière plus abstraite dans le langage du domaine que le système doit servir en termes de capacités, services, comportements, fonctions, options etc., le choix étant souvent arbitraire. Il est certainement possible de donner une signification différente à chacun de ces termes pour qu'ils soient précis (il est par exemple possible que la description d'un comportement précis d'un système ne donne pas beaucoup d'informations sur l'objectif ou l'intention et qu'un type descriptif soit nécessaire) mais ce n'est pas notre objectif ici.

Le détail des exigences (en ajoutant des détails à partir du niveau le plus élevé) peut se faire de manière purement fonctionnelle, c'est-à-dire en divisant les fonctions en sous-fonctions ou sous-tâches (sans tenir compte d'aucune architecture de réalisation) : ce qui est décrit (si le système était construit comme tel) se tiendrait à un niveau profond du système et n'aurait peut-être aucune communication directe en dehors du système. Ce serait le cas, par exemple, dans une approche d'analyse structurée qui irait jusqu'à un niveau de détail très poussé (par exemple, la bulle de transformation primitive).

Une telle approche n'est pas conseillée parce qu'elle identifie en tant qu'exigences, des choses qui ne le sont pas mais sont simplement des produits de la décomposition. Ensuite, elle peut entraîner des architectures pauvres (par exemple, qui ne répondent pas à d'autres exigences non fonctionnelles ou fonctionnent mal par rapport à elles) si le concepteur mappe précisément la réalisation et la décomposition. Il existe cependant une raison valable d'effectuer quelque décomposition fonctionnelle lorsque les objectifs de la vision sont exprimés à un niveau élevé, en limitant la profondeur de décomposition à une capacité ou des fonctions discernables, c'est-à-dire avec assez de détails pour enregistrer tous les comportements, les options, etc. significatifs (pour les parties prenantes) pour que le concepteur les réalise correctement. Les exigences détaillées (plus ou moins directement) à partir d'exigences d'un niveau plus élevé représentent un type d'exigence dérivée.

Exigences dérivées

Voici un exemple simple :

Supposez l'exigence suivante : "le système doit fonctionner en extérieur, 12 mois par an en Alaska."

Parmi les exigences dérivées, on peut citer :

  1. Le système doit fonctionner sous des températures inférieures à 32° F / 0° C.
  2. Le système doit fonctionner dans la neige.

Il existe un autre type d'exigence dérivée. Une fois les exigences au niveau du système détaillées correctement pour la réalisation, vous pouvez :

  • Diviser le système (modéliser) en éléments (par exemple en utilisant les méthodes OOAD).
  • Déterminer comment ces éléments collaborent pour produire le comportement escompté du système.
  • Rassembler à partir de la collaboration les comportements de niveau moins élevé pour produire les exigences au niveau de l'élément.

Ces exigences de niveau inférieur sont des exigences dérivées. Elles sont apparues avec la décomposition du système. Cela contraste avec une approche fonctionnelle où la division se fait sans tenir compte de la décomposition architecturale et du détail des exigences au niveau du système comme décrit en introduction.

Exigences affectées

Les exigences affectées sont des exigences qui ont été attribuées (en se basant sur des considérations fonctionnelles) aux composants d'un système tels que les sous-systèmes logiciels ou matériels. Au niveau le plus élevé, lorsque vous réfléchissez par exemple aux exigences au niveau de la mission pour un système de systèmes, il est toujours approprié d'élaborer ces exigences de manière fonctionnelle puis de diviser les exigences dérivées qui en résultent et d'affecter les groupes aux systèmes - en détaillant peut-être davantage avant la réalisation. En dehors de cela, il est préférable de procéder comme pour les exigences dérivées. Vous pouvez aussi procéder de cette façon au niveau du système de systèmes en utilisant une approche de modélisation métier.

Notez que dans une approche dérivée, on décompose le système en entités et on détermine les exigences de ces entités en étudiant comment elles collaborent pour répondre aux exigences de niveau supérieur. Dans une approche affectée et fonctionnelle, on décompose les exigences et on spécifie les entités qui satisfont les exigences de niveau inférieur.

L'approche à utiliser dépend du contexte et des attentes contractuelles et culturelles. Par exemple, pour l'agence spatiale américaine (la NASA) [dans le manuel d'assurance logicielle, édité par le bureau pour la sécurité, la fiabilité, la maintenance et le contrôle qualité du Goddard Space Flight Center de la NASA, 9/89] il y a quatre niveaux de détail des exigences :

  • Niveau 1, niveau de la mission - exigences de niveau très élevé qui se stabilisent très vite.
  • Niveau 2, niveau du système (affectées) - exigences qui se stabilisent aussi très vite. Ces exigences sont dérivées du niveau de la mission puis affectées aux segments.
  • Niveau 3, niveau du sous-système (ou segment) (dérivées) - à ce niveau, les exigences sont dérivées des exigences au niveau du système affectées au segment.
  • Niveau 4, niveau de l'élément de configuration (élément de configuration matérielle [HWCI], de l'élément de configuration logicielle [CSCI]) (détaillées) - là encore, les exigences sont affectées à partir du niveau précédent puis détaillées.

Niveaux d'exigences et mappage vers RUP

Niveaux d'exigences et mappage vers RUP.

En général, les contrats se font au niveau 3. La NASA a pour habitude de procéder de cette façon pour les exigences et il est naturel que toute organisation travaillant avec la NASA adopte la même taxinomie. Les développeurs disposent toujours d'une grande souplesse concernant la manière dont les exigences de niveau inférieur sont dérivées mais étant donné le niveau d'abstraction très élevé des exigences au niveau de la mission (elles ressemblent plus souvent à des exigences au niveau du programme), la dérivation des exigences au niveau du système (et leur affectation au système) peut se faire naturellement le long de lignes fonctionnelles. Même dans ce cas-là, avec l'intérêt porté aux architectures d'entreprise, il est de plus en plus courant que les exigences de système soit dérivées en tenant compte des considérations architecturales. La figure ci-dessus en est une illustration et montre le mappage des niveaux de la NASA aux produits RUP (y compris la modélisation métier). Notez comment, dans le processus RUP, l'affectation montrée dans le flux traditionnel s'effectue dans le processus Réalisation de cas d'utilisation et dans le regroupement comportemental qui en découle. Les lignes bleues en pointillés relient les produits de même niveau.