Ingénierie des besoins et des exigences Nicolas Treves.

Présentation au sujet: "Ingénierie des besoins et des exigences Nicolas Treves."— Transcription de la présentation:

1 Ingénierie des besoins et des exigences Nicolas Treves

2 Ingénierie des besoins et des exigences 1 UN PETIT BRAINSTORMING POUR DÉMARRER ! Proposez des définitions pour les notions de « besoin » et d’« exigence »

3 Ingénierie des besoins et des exigences 2 Les cinq référentiels fondamentaux  Référentiel n°1 : l'expression de besoins et exigences comportementales  L'observation et les faits expérimentaux du point de vue des utilisateurs  Référentiel n°2 : la conception générale  L ’architecture / les interfaces  Référentiel n°3 : la conception détaillée  Les modules / les composants  Référentiel n°4 : la programmation (y compris les langages de commandes, scripts, paramétrages, etc.)  La « matière » exécutable (Le produit)  Référentiel n°5 : les tests et les résultats de tests  Scénarios et protocoles expérimentaux (tests) vérifiant la conformité du modèle par rapport au monde réel  Preuves de fonctionnement (V&V) Un référentiel = une sortie d’une activité du processus de développement

4 Ingénierie des besoins et des exigences 3 Cycle de développement Processus de conception Processus de développement Assurance qualité et activités transverses AQ Mesure de la qualité de service Mesure de la maturité de l’EB/EC Expression de besoin et exigences Exploitation et support EB/EC CG CD P/TU VVT Conception générale Conception détaillée Programmation et tests unitaires Intégration (VV&T) Implémentation Défauts propagés Défauts ajoutés Défauts détectés Taux de défauts résiduels Nombre de RA/AC Mesure de la maturité (i.e. contrat de service) en exploitation Durée

5 Ingénierie des besoins et des exigences 4 Modèle des besoins Concepts (1/2)  Acteur  Entité externe au système qui interagit avec lui  Peut-être un humain, un dispositif physique, un sous-système... Pilote > Logiciel de comptabilité > Client

6 Ingénierie des besoins et des exigences 5 Modèle des besoins Concepts (2/2)  L’acteur interagit avec le système  Un acteur doit être identifié en fonction de son rôle Étudiant Utilisateur Administrateur Professeur Système Informatique Logiciel de comptabilité >

7 Ingénierie des besoins et des exigences 6 EXTÉRIEUR ET INTÉRIEUR D’UN SYSTÈME Alimentation électrique Dentistes Système de maintenance Système de distribution Sous-systèmes humains Lieux d’utilisation Flux Internet Flux L’extérieur d’un système est l’ensemble des systèmes externes de son environnement qui ont une influence sur le système. Une partie prenante est un acteur humain qui incarne un système externe, i.e. qui est légitime pour représenter le système externe considéré. Systèmes externes Parties prenantes Brosse-@-dent électronique utilisée Dentifrice Brosse-@-dents utilisée Systèmes externes Sous-systèmes logiciels Sous-systèmes matériels Utilisateurs Environnement Système projet (conception & industrialisation) Flux

8 Ingénierie des besoins et des exigences 7 BESOINS DES SYSTÈMES EXTERNES Alimentation électrique Dentistes Système de maintenance Système de distribution Sous-systèmes logiciels Sous-systèmes matériels Sous-systèmes humains Lieux d’utilisation Internet Système projet (conception & industrialisation) Brosse-@-dent électronique utilisée Dentifrice Brosse-@-dents utilisée Un besoin B(S) vis-à-vis d’un système S est une propriété attendue ou imposée par l’un des systèmes externes de son environnement qui a un impact sur le système considéré (1). Besoins Le dentitice doit respecter les normes sanitaires européennes. Le système de maintenance doit pouvoir identifier et réparer une panne – le cas échéant – en moins de 2 jours ouvrables. Besoin Les dentistes veulent améliorer l’hygiène dentaire de leurs patients. Les lieux d’utilisation ont un taux élevé d’humidité. Utilisateurs Le système projet doit concevoir une brosse-@- dents électronique en moins de 9 mois. Environnement Flux (1) Le processus de définition des besoins est notamment fortement lié aux analyses opérationnelles (cf. Module 3). Le terme « besoin » est pris ici en un sens technique différent de son sens commun. Il englobe notamment ce qu’on appelle couramment « contrainte ».

9 Ingénierie des besoins et des exigences 8 EXIGENCES DU SYSTÈME Une exigence E(S) d’un système S est une propriété du système qui doit obligatoirement être satisfaite (en général pour répondre à un ou plusieurs besoins exprimés par les systèmes externes de l’environnement vis-à-vis du système). Sous-systèmes logiciels Sous-systèmes matériels Sous-systèmes humains Les utilisateurs doivent pouvoir mettre en oeuvre des recommandations de brossage. Exigence de niveau sous- système Exigence de niveau système Exigences de niveau sous-système Le logiciel embarqué de la brosse-@-dents doit transmettre des mesures de qualité de brossage. Les composants matériels de la brosse-@-dents doivent pouvoir mesurer les pressions de brossage. Utilisateurs Brosse-@-dent électronique utilisée Brosse-@-dents utilisée Actions de dérivation de l’exigence de niveau système sur les sous- systèmes La brosse-@-dents utilisée doit permettre une amélioration continue de la qualité du brossage.

10 Ingénierie des besoins et des exigences 9 BESOINS & EXIGENCES : UNE QUESTION DE POINT DE VUE Ingénierie système [IEEE Std 1220-1998] Une exigence E(S) d’un système S est une propriété non ambiguë, testable et mesurable exprimant une caractéristique ou une contrainte opérationnelle, fonctionnelle ou organique de ce système qui est nécessaire pour que le système soit accepté par ses parties prenantes. Une définition fondamentalement relative La notion d’exigence est toujours relative à un système donné : comme il s’agit d’une réponse de ce système à une demande de ses systèmes externes, il faut donc toujours savoir quel est le système de référence concerné, vu que plusieurs systèmes interdépendants sont en jeu. Notre convention pour éviter toute ambiguïté Dès lors que l’on a fixé un système de référence, on appellera : « exigence » : une exigence (au sens IEEE) de ce système de référence, « besoin » : une exigence (au sens IEEE) de l’extérieur du système de référence (qui est donc le système formé de l’ensemble des systèmes externes au système considéré). Extérieur de la brosse-@-dents utilisée La brosse-@-dents utilisée doit permettre une amélioration continue de la qualité du brossage. Exigence Besoin Action de dérivation du besoin en exigence Brosse-@-dents utilisée Sous-systèmes logiciels Sous-systèmes matériels Sous-systèmes humains Les dentistes veulent améliorer l’hygiène dentaire de leurs patients.

11 Ingénierie des besoins et des exigences 10 A QUOI SERVENT LES BESOINS ET LES EXIGENCES ? Besoins & exigences sont des propriétés qui doivent être énoncées de manière non ambiguë car elles doivent pouvoir être mesurées et testées : Pour les exigences : lors de l’« intégration » du système pour vérifier qu’il répond aux propriétés auxquelles il devait répondre du point de vue de ses concepteurs, Pour les besoins : lors de la « livraison » du système pour valider qu’il répond bien aux propriétés auxquelles il devait répondre du point de vue de ses parties prenantes ! Besoins & exigences doivent être élaborés en même temps que leurs critères de satisfaction pour tenir compte des contraintes d’intégration & de livraison dès le début de la conception ! Système cible intégré Système cible en phase de conception Le cycle en V d’un système Exigence Action de définition du critère de satisfaction Permet la vérification d’une exigence Système cible livré Critère de satisfaction de l’exigence Extérieur du système cible Besoin Critère de satisfaction du besoin Action de dérivation du besoin Action de définition du critère de satisfaction Permet la validation d’un besoin

12 Ingénierie des besoins et des exigences 11 ENCORE UN PETIT BRAINSTORMING … Proposez des exemples concrets de catégories (1) de besoins ou d’exigences (1) Types, familles, sortes, classes, etc.

13 Ingénierie des besoins et des exigences 12 EXEMPLES DE TYPES DE BESOINS ET D’EXIGENCES (1/2) Types de besoins & de contraintes d’un système industriel Systèmes externes correspondants Exemples de besoins & de contraintes pour la brosse-@-dents PPolitiquesSystème politique Le système politique doit garantir l’efficacité du système de santé publique. EEconomiquesSystème économique L’entreprise veut faire la marge maximale possible sur ses ventes. SSociétalesSociété Les Français veulent pouvoir vivre en bonne santé le plus longtemps possible. TTechnologiques Système d’innovation technologique Les technologies libres veulent être ouvertes au plus grand nombre. EEnvironnementalesSystème Terre Le système Terre doit être le moins pollué possible. LLégales ou règlementaires Système législatif & règlementaire Le système règlementaire veut que les normes sanitaires soient respectées. Quelques grandes catégories classiques de besoins vis-à-vis d’un système industriel classées par types de systèmes externes

14 Ingénierie des besoins et des exigences 13 EXEMPLES DE TYPES DE BESOINS ET D’EXIGENCES (2/2) Thématiques de besoins & d’exigences pour un système industriel Exemples de besoins ou d’exigences pour la brosse-@-dents Opérabilité Capacité à être facilement opéré par les utilisateurs, les opérateurs & les exploitants techniques Les utilisateurs veulent pouvoir se brosser rapidement les dents sans perte d’efficacité. Disponibilité Capacité à rester en conditions opérationnelles normales (regroupe maintenabilité & fiabilité) Le capteur de pression doit pouvoir être remplacé par un technicien en moins d’1 minute. Performance Capacité à garantir un niveau de service et de performance économique & temporelle donnée Le remplissage du dentifrice doit pouvoir être assuré en moins d’une minute. Sûreté & sécurité Capacité à fonctionner sans (resp. sous) impacts négatifs sur (resp. de) l’extérieur du système La brosse-@-dent ne doit pas électrocuter ses utilisateurs en conditions normales d’utilisation. Evolutivité & durabilité Capacité à évoluer au cours du temps et à s’adapter à de nouveaux besoins Le système de maintenance doit pouvoir installer de nouvelles versions du logiciel embarqué. Transparence Capacité à rendre visible de l’extérieur des vues internes du système cible La transmission des informations de brossage doit être effectuée via Internet. Quelques grandes catégories classiques de besoins & d’exigences pour un système industriel Cette classification est complètement orthogonale & transversale à la précédente.

15 Ingénierie des besoins et des exigences 14 STRUCTURE STANDARD D’UN BESOIN Objectif du besoin du point de vue de la partie prenante avec sa justification associée Template d’énoncé de besoin à respecter Un domaine correspond ici à un ensemble « signifiant » de systèmes externes et/ou de parties prenantes A ne jamais oublier car cet item permet souvent de reformuler de manière plus pertinente le besoin associé Description des éléments de contexte connus Besoin = capacité demandée ou contrainte imposée par un système externe

16 Ingénierie des besoins et des exigences 15 STRUCTURE STANDARD D’UNE EXIGENCE FONCTIONNELLE Justification de l’exigence du point de vue du concepteur du système cible Le composant peut être le système cible dans son ensemble ou l’une de ses briques fonctionnelles ou organiques Template d’énoncé d’exigence fonctionnelle à respecter A ne jamais oublier car cet item permet souvent de reformuler de manière plus pertinente l’exigence associée Description des éléments de contexte connus Exigence fonctionnelle = capacité à « faire » du système cible

17 Ingénierie des besoins et des exigences 16 STRUCTURE STANDARD D’UNE EXIGENCE ORGANIQUE Template d’énoncé d’exigence organique à respecter A ne jamais oublier car cet item permet souvent de reformuler de manière plus pertinente l’exigence associée Description des éléments de contexte connus Justification de l’exigence du point de vue du concepteur du système cible Le composant peut être le système cible dans son ensemble ou l’une de ses briques organiques Exigence organique = capacité à « être » du système cible

18 Ingénierie des besoins et des exigences 17 LE PROCESSUS D’ARCHITECTURE DES BESOINS & DES EXIGENCES Processus d’architecture des besoins Parties prenantes Besoins « bruts » Processus d’architecture des exigences fonctionnelles Architecture des exigences fonctionnelles de niveau système Architecture des exigences fonctionnelles de niveau sous-système Exigences fonctionnelles de niveau système Exigences fonctionnelles de niveau sous- système … Exigences fonctionnelles organisées (cahier des charges « fonctionnel ») Processus d’architecture des exigences organiques Architecture des exigences organiques de niveau système Architecture des exigences organiques de niveau sous-système Exigences organiques de niveau système Exigences organiques de niveau sous- système … Besoins organisés (cahier des charges « clients ») Exigences organiques organisées (cahier des charges « technique ») 1 2 3 4 Exigences organisationnelles (i.e. sur les procédures le cas échéant) Exigences techniques Exigences sur les fonctions Structuration des attentes du dehors Structuration des réponses du dedans Attention à tenir compte de toutes les parties prenantes et pas des seuls clients (au sens usuel du terme) dans le processus d’architecture des besoins et notamment dans les analyses opérationnelles qui doivent être menées en parallèle (voir Module 3) Vision d’ensemble de l’architecture des besoins et des exigences

19 Ingénierie des besoins et des exigences 18 ARCHITECTURE DES BESOINS & DES EXIGENCES (1/2) Sous-systèmes logiciels Sous-systèmes matériels Sous-systèmes humains Les utilisateurs doivent connaître les emplacements des centres de maintenance. Exigences de niveau sous- système Le logiciel embarqué de la brosse-@-dents doit pouvoir identifier les pannes des composants matériels. Les composants matériels de la brosse-@-dents doivent être modulaires et remplaçables en moins de 30 minutes. Extérieur du système Le système de maintenance doit pouvoir maintenir la brosse-@-dents en condition opérationnelle. Besoin Relations de dérivation Le système de maintenance doit pouvoir gérer une panne en moyenne en moins de 8 jours ouvrables à partir de sa détection. Relation de dérivation Brosse-@-dent électronique utilisée Utilisateurs Brosse-@-dents utilisée Relation de dérivation Besoin Une propriété (1) P (dite source) se dérive en une propriété (1) Q (dite dérivée) si et seulement si Q contribue à P, autrement dit s’il existe une propriété (2) R (non nécessairement unique) telle que Q  R  P (1) Ici un besoin ou une exigence (2) Ici une conjonction (i.e. un ensemble) de besoins ou d’exigences La brosse-@-dents utilisée doit pouvoir être réparable en moins d’une journée en cas de panne d’un composant matériel. La brosse-@-dents utilisée doit pouvoir être réparable en moins de deux journées à partir de la détection d’une panne. Relation de dérivation P Q Exigences de niveau système

20 Ingénierie des besoins et des exigences 19 ARCHITECTURE DES BESOINS & DES EXIGENCES (2/2) Les relations de dérivation existant entre besoins et exigences permettent de les organiser selon des architectures hiérarchiques par vision architecturale & niveau systémique

21 Ingénierie des besoins et des exigences 20 COUVERTURE D’UN BESOIN OU D’UNE EXIGENCE Il y a couverture d’un besoin ou d’une exigence par des besoins ou exigences dérivés quand la validité de ces derniers entraîne celle du besoin ou de l’exigence source. Toute dérivation de besoins ou d’exigences doit assurer la couverture du besoin ou de l’exigence source par les besoins et/ou les exigences dérivées, de façon notamment à garantir que le référentiel de besoins et d’exigences respecte les critères de complétude (1) & de conformité (2) Les utilisateurs doivent connaître les emplacements des centres de maintenance. Le logiciel embarqué de la brosse-@-dents doit pouvoir identifier les pannes des composants matériels. Les composants matériels de la brosse-@-dents doivent être des modules remplaçables en moins de 30 minutes. Le brosse-@-dents utilisée doit pouvoir être réparable en moins d’une journée en cas de panne d’un composant matériel. ER EL EH EM Dérivation Relation de couverture : EH  EL  EM  ER La brosse-@-dents utilisée doit pouvoir être réparable en moins de deux journées à partir de la détection d’une panne. Relation de couverture : ER  ES  EI EI Le brosse-@-dents utilisée doit pouvoir être réparable en moins d’une journée en cas de panne d’un composant logiciel. ES Dérivation (1)La couverture permet d’être sûr que le référentiel de besoins et d’exigences intègre bien tous les besoins exprimés : cela ne garantit bien sûr pas que tous les besoins réels sont bien exprimés, ce qui reste de la responsabilité de la capture des besoins. (2)La couverture garantit la conformité dès lors que les besoins règlementaires ont bien été intégrés dans le référentiel des besoins.

22 Ingénierie des besoins et des exigences 21 TRAÇABILITÉ DES BESOINS & DES EXIGENCES La traçabilité est la capacité – fondamentale pour les analyses d’impact – à savoir connaître et exprimer explicitement l’ensemble des relations de causalité bidirectionnelles (dérivation & couverture) existant au sein du référentiel de besoins & d’exigences. Exigences systèmes Niveaux sous- systèmes Dérivation Exigences sous-systèmes … Dérivation Dérivatioin Niveau système Dérivation Exigences sous-systèmes … Dérivation Extérieur Dérivation Architecture des besoins Architecture des exigences fonctionnelles Architecture des exigences organiques Exigences systèmes Niveaux sous- systèmes Structuration des réponses du dedans Dérivation Architecture type des besoins et des exigences d’un système Besoins des parties prenantes Cahier des charges fonctionnel Cahier des charges technique Cahier des charges « clients » Niveau système Structuration des attentes du dehors Couverture

23 Ingénierie des besoins et des exigences 22 Modèle des besoins Formalisation des exigences  Cas d’utilisation (use case)  Enchaînement d’interactions entre un ou plusieurs acteurs et le système  Exemple : Acteur principal Connexion Gestion des Commandes Gestion des Clients

24 Ingénierie des besoins et des exigences 23 Définition  Ce qu’est un cas d ’ utilisation  C’est un ensemble de s é quences d ’ actions réalisées par le système et produisant un résultat observable sémantiquement intéressant pour un acteur particulier (humain et/ou non humain) ‒ Un cas d’utilisation modélise un service rendu par le système. Il exprime les interactions acteurs/système et permet de comprendre ce que fait exactement l’acteur(s) concerné(s) par le cas d’utilisation. C’est une exigence du système à mettre en œuvre. ‒ Le cas d’utilisation porte la s é mantique du point de vue des acteurs  Un cas d’utilisation est décrit à l’aide de scénarios : c’est une succession particulière d’enchaînements jugés significatifs et porteur de sémantique par rapport aux opérations futures  C’est une représentation en extension du système

25 Ingénierie des besoins et des exigences 24 Modèle des besoins Exemple  Exemple de description textuelle d’un UC : Cas d’utilisation : Connexion Acteurs : Utilisateur, Administrateur. Description : 1 Ce cas d’utilisation commence lorsque l’utilisateur, se connecte au système informatique. 2 L’utilisateur fournit son identifiant puis son mot de passe. 3 Si l’identifiant et le mot de passe sont corrects, l’utilisateur est connecté au système avec un profil qui a été préalablement défini. 4 Si les informations fournies sont incorrectes, le système redemande l’identifiant et le mot de passe. Exceptions : Après 3 tentatives infructueuses, l’administrateur est prévenu.

26 Ingénierie des besoins et des exigences 25 Modèle des besoins Exemple  2 scénarios UtilisateurSIAdministrateur Connecté OK id/passwd UtilisateurSIAdministrateur KO id/passwd KO id/passwd bloqué id/passwd informé

27 Ingénierie des besoins et des exigences 26 FIN MODULE 2 : INGÉNIERIE DES BESOINS ET DES EXIGENCES