Ingénierie des Exigences Logicielles : Concepts et Pratiques

Analyse des besoins

L'analyse des besoins est le processus de découverte, d'analyse, de documentation et de vérification des services nécessaires pour un système et de ses contraintes opérationnelles.

Qu'est-ce qu'une exigence ?

Cela peut varier d'une déclaration abstraite de haut niveau d'un service ou d'une contrainte du système à une spécification mathématique.

Types d'exigences

Exigences des utilisateurs

Déclarations en langage naturel, accompagnées de diagrammes des services que le système fournit et de ses contraintes opérationnelles. Écrit pour les utilisateurs.

Exigences système

Un document structuré énonçant des descriptions détaillées des fonctions, des services et des contraintes opérationnelles du système. Il définit ce qui doit être mis en œuvre et peut faire partie d'un contrat entre le client et le développeur.

Le système LIBSYS

Un système de gestion de bibliothèques qui fournit une interface unique à plusieurs bases de données réparties dans différentes bibliothèques.

Parties prenantes des exigences utilisateurs

Gestionnaires clients, utilisateurs finaux, ingénieurs systèmes, clients, fournisseurs, architectes système.

Parties prenantes des exigences système

Utilisateurs finaux, clients, ingénieurs système, architectes système, équipe de développement.

Exigences fonctionnelles logicielles

Elles décrivent les fonctionnalités des services ou du système. Elles dépendent du type de logiciel, des utilisateurs attendus et du type de système où le logiciel est utilisé. Elles peuvent être des déclarations de haut niveau, mais les exigences fonctionnelles du système devraient décrire les services en détail.

Exemple d'exigence fonctionnelle

• L'utilisateur doit être en mesure de rechercher l'ensemble initial de la base de données ou d'en sélectionner un sous-ensemble.
• Le système doit offrir des outils de visualisation appropriés pour que l'utilisateur puisse lire des documents dans le référentiel.

Exigences non fonctionnelles

Elles définissent les propriétés du système et sa fiabilité, par exemple les contraintes, le temps de réponse et les besoins de stockage. Elles incluent les restrictions sur la capacité des périphériques d'E/S, les représentations du système, etc. Elles peuvent être plus critiques que les exigences fonctionnelles.

Catégories d'exigences non fonctionnelles

• Exigences relatives aux produits
• Exigences organisationnelles
• Exigences externes

Exigences produit

Précisent que le produit livré doit se comporter d'une manière particulière (par exemple, vitesse d'exécution, fiabilité, etc.).

Exigences organisationnelles

Une conséquence des politiques et procédures de l'organisation (par exemple, normes de processus, prescriptions de mise en œuvre, etc.).

Exigences externes

Facteurs externes au système et à son processus de développement (par exemple, exigences d'interopérabilité, exigences législatives, etc.).

Exigences de domaine

Dérivées du domaine d'application, elles décrivent les caractéristiques du système qui reflètent ce domaine. Elles peuvent restreindre les exigences fonctionnelles existantes ou définir des calculs spécifiques à effectuer. Si les exigences de domaine ne sont pas remplies, le système ne peut pas fonctionner.

Problèmes liés aux exigences de domaine

Difficulté de compréhension

Les besoins sont exprimés dans la langue du domaine d'application, ce qui n'est pas souvent compris par les ingénieurs de développement logiciel du système.

Caractère implicite

Les experts connaissent si bien le domaine qu'ils ne pensent pas à rendre les exigences de domaine explicites.

Spécification des exigences documentaires

Elle doit être composée de phrases en langage naturel, en suivant certaines normes :

• Utiliser « doit » pour les exigences obligatoires et « devrait » pour les exigences souhaitables.
• Exemple : « Le système devrait fonctionner sur la gamme de PC IBM équipés d'un microprocesseur 486 DX ou supérieur. »
• Les exigences doivent être organisées logiquement.
• Chaque exigence doit avoir un identifiant unique (par exemple, un identifiant numérique pour référence ultérieure).
• Les exigences du logiciel devraient être divisées en exigences fonctionnelles et non fonctionnelles.
• Éviter d'utiliser le jargon informatique.

Format de spécification des exigences

IEEE/ANSI 830/1998. Structure typique : Introduction > Aperçu des exigences spécifiques > Annexes > Index.

Problèmes du langage naturel dans la spécification

Les lecteurs et les rédacteurs des exigences doivent interpréter les mêmes mots de la même manière. Le langage naturel est ambigu, ce qui rend cela très difficile.

Flexibilité excessive

La même chose peut être exprimée de plusieurs manières différentes dans la spécification.

Manque de modularisation

Les structures de la langue sont insuffisantes pour structurer les exigences du système.

Ingénierie des exigences : les 4 phases

• Étude de faisabilité
• Élicitation et analyse des besoins
• Validation des exigences
• Gestion des exigences

L'étude de faisabilité

Elle détermine s'il est judicieux d'investir du temps et des efforts dans le système proposé. C'est une courte étude ciblée qui vérifie :

• Si le système contribue aux objectifs organisationnels.
• Si le système peut être implémenté en utilisant la technologie actuelle et dans le budget.
• Si le système peut être intégré avec les autres systèmes.

Élicitation et analyse des besoins

Consiste à recueillir des informations sur le système proposé à partir de sources existantes : documents, organisation, spécifications existantes, observations, entretiens, etc.

Difficultés de l'ingénierie des exigences

• Les parties prenantes ne savent pas toujours ce qu'elles veulent et ne l'expriment pas clairement.
• Les parties prenantes expriment les exigences en utilisant leurs propres termes.
• Les différentes parties prenantes ont des besoins différents.
• Des facteurs politiques peuvent influencer.
• Environnement dynamique en constante évolution.

Validation des exigences

Elle vise à s'assurer que les exigences définissent le système que le client souhaite réellement. Les coûts des erreurs d'exigences sont élevés, la validation est donc très importante.

Vérification de la validité

Le système fournit-il les fonctions qui répondent le mieux aux besoins du client ?

Vérification de la cohérence

Y a-t-il des conflits entre les exigences ?

Vérification de l'exhaustivité

Toutes les fonctions requises par le client sont-elles incluses ?

Vérification du réalisme

Les exigences peuvent-elles être mises en œuvre avec le budget et la technologie disponibles ?

Vérifiabilité

Les exigences peuvent-elles être vérifiées ?

Gestion des exigences

Le processus de gestion des exigences évolutives tout au long de l'ingénierie des exigences et du développement du système. Les exigences sont inévitablement incomplètes et incohérentes.

Traçabilité des exigences

Elle est liée aux relations entre les exigences, leurs sources et la conception du système.

Traçabilité de la source

Liens des exigences vers les parties prenantes qui les ont proposées.

Traçabilité des exigences

Liens entre les exigences dépendantes.

Traçabilité du projet

Liens des exigences vers les modules du projet.