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 :
-
Le système doit fonctionner sous des températures inférieures à 32° F / 0° C.
-
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.
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.
|