Comment rédiger le cahier des charges d un projet en mobilisant la démarche d Ingénierie Système en langage SysML?

Transcription

1 Comment rédiger le cahier des charges d un projet en mobilisant la démarche d Ingénierie Système en langage SysML? Expression du besoin et cahier des charges fonctionnel Olivier FORT Silvain CUVILLIER Lycée du Hainaut Valenciennes

2 Ingénierie système Définition : Démarche méthodologique coopérative et interdisciplinaire s appuyant sur les sciences et l expérience qui englobe les activités nécessaires pour concevoir, développer, faire évoluer et vérifier un ensemble de produits, de processus et compétences humaines apportant une solution économique et performante aux besoins des parties prenantes acceptable par tous.

3 Ingénierie système [ ]apportant une réponse [ ] aux besoins des parties prenantes acceptable par tous.

4 Système et parties prenantes Domaine du problème Besoin Besoins et contraintes d exploitation MAÎTRE D OUVRAGE INTÉGRATEUR DU BESOIN PP intéressées par l utilisation Compromis Possible Cahier des charges Exigences systèmes Opportunités et contraintes techniques Domaine de la solution MAÎTRE D ŒUVRE INTÉGRATEUR DE LA SOLUTION PP intéressées par la conception

5 Analyse et formalisation du besoin Emergence d'un besoin (études amont) Opportunité Faisabilité Go / no go Recueil et analyse des besoins des PP Besoins et contraintes Recadrages? Formalisation du besoin Cohérence Complétude Flexibilité

6 Ce que dit l'iso Elucider les besoins des parties prenantes Identifier les parties prenantes Elucider les besoins Définir les besoins des parties prenantes Définir les contraintes Définir des séquences d activités (scénarios) Identifier les interactions du système Spécifier les besoins Analyser et maintenir les besoins des parties prenantes Analyser les besoins Résoudre les problèmes Faire revoir par les parties prenantes Etablir que les besoins soient correctement exprimées Enregistrer les besoins Maintenir un lien de traçabilité avec leur origine 6

7 Qui sont les parties prenantes? Parties Prenantes côté acquéreur (dites intéressées) Utilisateur Exploitant Opérateur, exploitant-maintenancier (mise en œuvre) Parties Prenantes côté fournisseur (dites impliquées) Développeur Producteur Equipementiers Parties Prenantes potentiellement concernées Normes, réglementation, environnement potentiellement impacté (au sens large) Certificateur, homologateur, Conformité / réglementation...

8 Une démarche pour la Définition des Besoins des Parties Prenantes 8

9 Formalisation de l'expression des besoins initiaux Cahier des charges SysML : formalise le cahier des charges après élucidation Modélise la démarche de recherche des services rendus et contraintes Exprime les besoins initiaux Permet la validation (cohérence ; complétude) Permet la traçabilité (fonction, contrainte solution)

10 Expression du besoin initial Activité DBPP1 Définir la mission principale du système En amont de la démarche DBPP

11 Besoin initial Activité DBPP1 Définir la mission principale du système Diagramme d exigences (RD) NB : Eviter les autres types de lien! Le lien de décomposition/contenance n est pas très clair dans SysML (lien de classement avec peu de sémantique), de nombreux auteurs préconisent de ne pas l utiliser et de le remplacer par «derivereqt» ou «refine». 11

12 Diagramme de contexte Activité DBPP2 Définir le contexte du système Pour chaque phase de vie du système! exploitation, conception, réalisation, soutien, retrait, Parties prenantes NB : Peut-être illustré par des images réalistes des acteurs et entités externes NB : Eviter les autres liens comme ceux de généralisation/spécialisation Diagramme de définition de bloc (BDD) 12

13 Diagramme de cas d'utilisation Activité DBPP3 Définir les utilisations du système Diagramme de cas d utilisation (UCD) NB : Peut-être illustré par des images réalistes des acteurs et des systèmes 13

14 Définir les scénarios d'utilisation Activité DBPP4 Décrire les scénarios d'utilisation Diagramme de cas d utilisation (UCD) 14

15 Définir les besoins des parties prenantes Activité DBPP5 Formaliser un besoin Un nom (un verbe!) Un stéréotype Exigences SysML (Requirements) Un identifiant numérique ou alphanumérique Une description textuelle 15

16 Définir les besoins des parties prenantes Activité DBPP5 Définir les besoins des parties prenantes Diagramme d exigences (RD) NB : Eviter les autres types de lien! 16

17 Vérifier les besoins des parties prenantes Activité DBPP6 Vérifier les besoins des parties prenantes Processus de définition des besoins des parties prenantes BDD SysML UCD SysML RD SysML

18 Pourquoi SysML? Propose de modéliser avec précision Respecte strictement les méthodes de l ingénierie système Permet la traçabilité du besoin jusque la solution