Ingénierie des exigences – Introduction (partie 1)
Nous avons précédemment abordé les 4 principales activités de l’ingénierie des exigences.
L’ingénierie des exigences est un processus de collecte et de définition de ce que les services doivent être fournis par le système.
Il se concentre sur l’évaluation si le système est utile à l’entreprise (étude de faisabilité), la découverte des exigences (élicitation et analyse), la conversion de ces exigences dans un certain format standard (spécification) et la vérification que les exigences définissent le système que le client veut (validation).
En pratique, l’ingénierie des exigences n’est pas un processus séquentiel, c’est un processus itératif dans lequel les activités sont intercalées.
Par exemple, vous itérez d’abord sur les exigences de l’utilisateur ; l’élicitation, la spécification et la validation, et répétez les mêmes étapes pour les exigences du système.
Au début du processus, la plupart des efforts seront consacrés à la compréhension des exigences métier et utilisateur de haut niveau. Plus tard dans le processus, plus d’efforts seront consacrés à l’élicitation et à la compréhension des exigences détaillées du système.
Certaines personnes considèrent l’ingénierie des exigences comme le processus d’application d’une méthode d’analyse structurée, telle que l’analyse orientée objet. Cela implique l’analyse du système et le développement d’un ensemble de modèles graphiques du système, tels que les modèles de cas d’utilisation, qui servent ensuite de spécification du système.
Bien que les méthodes structurées aient un rôle à jouer dans le processus d’ingénierie des exigences, il y a beaucoup plus à l’ingénierie des exigences que ce qui est couvert par ces méthodes.
L’analyse et la conception orientées objet seront abordées dans une autre série de tutoriels.
Exigences de l’utilisateur et du système
Typiquement, les exigences sont présentées en deux niveaux de détail ; les exigences de l’utilisateur et du système, où l’utilisateur a besoin d’un énoncé de haut niveau des exigences, tandis que les développeurs du système ont besoin d’une spécification plus détaillée du système. Ainsi, les exigences de l’utilisateur et du système se réfèrent juste à un niveau de détail différent.
Avoir un niveau de détail différent est utile car il communique des informations sur le système développé pour différents types de lecteurs.
Donc, les utilisateurs finaux ne seront pas concernés par le détail, ils ont besoin d’une exigence écrite générique et abstraite.
Alors que les personnes qui sont impliquées dans le développement, elles ont besoin de ce que le système doit faire exactement.
Vous finirez probablement avec beaucoup de problèmes et de malentendus si vous n’aviez pas une séparation claire entre les différents niveaux de détail.
Exigences des utilisateurs
Il décrit les services que le système doit fournir et les contraintes sous lesquelles il doit fonctionner. Nous ne nous attendons pas à voir un niveau de détail, ou ce que le système fera exactement, C’est plus des exigences génériques.
Il est généralement écrit dans un langage naturel et fourni par des diagrammes.
Nous discuterons des différentes façons de spécifier les exigences plus tard dans cette série.
Exigences du système
Les exigences du système signifient une description plus détaillée des services du système et des contraintes opérationnelles telles que la façon dont le système sera utilisé, et des contraintes de développement telles que les langages de programmation.
Ce niveau de détail est nécessaire pour ceux qui sont impliqués dans le développement du système, comme les ingénieurs, les architectes système, les testeurs, etc.
Exigences fonctionnelles &Exigences non fonctionnelles
Les exigences logicielles sont classées en exigences fonctionnelles et exigences non fonctionnelles.
Exigences fonctionnelles
Elles couvrent les principales fonctions qui doivent être fournies par le système. Lorsqu’elles sont exprimées en tant qu’exigences de l’utilisateur, elles sont généralement décrites de manière abstraite.
Toutefois, les exigences fonctionnelles plus spécifiques du système décrivent les fonctions du système, ses entrées, son traitement ; comment il va réagir à une entrée particulière, et quelle est la sortie attendue.
Exigences non fonctionnelles
Ce sont les contraintes sur les fonctions fournies par le système.
Les contraintes, comme le nombre de processus que le système peut gérer (performance), quels sont les problèmes (de sécurité) dont le système doit s’occuper comme les injections SQL…
Le taux d’échec (fiabilité), quels sont les langages et les outils qui seront utilisés (développement), quelles sont les règles que vous devez suivre pour assurer que le système fonctionne dans la loi de l’organisation (législatif).
Les exigences non fonctionnelles sont souvent plus critiques que les exigences fonctionnelles individuelles. Les utilisateurs peuvent généralement trouver des moyens de contourner une fonction du système qui ne répond pas vraiment à leurs besoins. Cependant, le fait de ne pas répondre à une exigence non fonctionnelle peut signifier que l’ensemble du système est inutilisable.
Par exemple, si un avion ne signifie pas répondre à ses exigences de fiabilité, il ne sera pas sûr pour le fonctionnement, ou si un système de contrôle embarqué ne répond pas à ses exigences de performance, les fonctions de contrôle ne fonctionneront pas correctement.
Les exigences non fonctionnelles doivent être mesurables
Dans la mesure du possible, nous devrions écrire les exigences non fonctionnelles de manière quantitative, afin qu’elles puissent être testées. Vous pouvez les mesurer lorsque le système est testé pour vérifier si le système répond à ses exigences non fonctionnelles.
En pratique, les clients d’un système ont souvent du mal à traduire leurs objectifs en exigences mesurables. Ils ne comprennent pas ce qu’est un certain nombre définissant la vitesse ou la fiabilité requise. Pour certains objectifs, comme la maintenabilité, il n’y a pas de métriques utilisables.
Le coût de la vérification des exigences non fonctionnelles mesurables peut être très élevé et les clients peuvent ne pas penser que ces coûts sont justifiés.
Les exigences non fonctionnelles et fonctionnelles sont dépendantes
Les exigences non fonctionnelles entrent souvent en conflit, interagissent ou même génèrent d’autres exigences fonctionnelles ou non fonctionnelles.
Une exigence utilisateur concernée par la sécurité, telle que la limitation de l’accès aux utilisateurs autorisés, peut générer d’autres exigences qui sont fonctionnelles, telles que la nécessité d’inclure des facilités d’authentification des utilisateurs dans le système.
La distinction entre les exigences fonctionnelles et non fonctionnelles
En pratique, il est difficile de séparer les exigences fonctionnelles et non fonctionnelles. La distinction n’est pas claire comme leurs définitions le suggèrent.
Séparer les exigences fonctionnelles et non fonctionnelles
Si les exigences non fonctionnelles sont énoncées séparément des exigences fonctionnelles, la relation entre elles peut être difficile à comprendre.
Cependant, nous devrions explicitement mettre en évidence les exigences qui sont clairement liées aux propriétés émergentes du système telles que la performance ou la fiabilité.
Les propriétés émergentes sont des propriétés du système dans son ensemble plutôt que des propriétés qui peuvent être dérivées des propriétés des composants individuels du système.
.