Vous trouverez ci-dessous un extrait d’un document rédigé par Madame Catherine Laval, PDG de la société Apte System, qui vise à faciliter le positionnement de l’analyse fonctionnelle (AF) et de SysML :
la complémentarité tient dans le fait que l’Analyse fonctionelle (AF) est une méthodologie d’expression du besoin des utilisateurs en terme de finalité, alors que SysML est un langage de modélisation qui s’appuie en entrée sur cette expression de besoin pour formaliser la solution sous forme de différents diagrammes dépendant de la solution retenue.
L’analyse fonctionnelle et une démarche de type SysML ne s’opposent pas, mais elles se complètent, car elles n’ont pas le même point de vue.
L’analyse fonctionnelle s’intéresse aux finalités du système, et aux besoins et contraintes de toutes les parties prenantes.
Rappel : la notion de parties prenantes comprend les acteurs suivants :
– Les utilisateurs, à l’origine des besoins, et réels juges de la solution.
– Les parties intéressées, contributeurs ou acteurs tout au long du processus de vie.
– Les parties impliquées dans le projet (développement, réalisation, qualification…)
C’est l’analyse fonctionnelle qui apporte la base objective des exigences, à travers des notions qui lui sont propres :
– Finalités et limites du système,
– Cycle de vie
– Modes dégradés
– Besoins, contraintes, Fonctions
– Critères
– Hiérarchisation
Elle se place en amont de toute modélisation du système lui-même (et s’attache essentiellement à ses interactions avec ses environnements tout au long de son cycle de vie). En approche systémique, on parle alors de « boîte noire ».
Seule l’analyse fonctionnelle permet de balayer tout le cycle de vie d’un produit et d’étudier toutes ses interactions avec les éléments de son environnement, ce qui garantit une certaine exhaustivité dans la recherche des besoins et contraintes. Elle permet également d’éviter toute expression de besoin en terme de solution.
Couplée avec une démarche d’Analyse de la Valeur, elle permet d’optimiser un système, produit ou service en s’assurant de construire une réponse optimisée répondant aux besoins et contraintes, au moindre coût.
Couplée à une démarche de maîtrise des risques, elle permet l’exhaustivité de l’inventaire des modes de défaillance et une vision claire des conséquences des défaillances sur les services attendus.
C’est une méthodologie au sens propre du terme.
SysML se positionne en processus de développement, avec un point de vue industriel/concepteur (maitre d’œuvre), en réponse aux exigences du maître d’ouvrage (le maître d’ouvrage étant responsable de l’expression des besoins et contraintes des parties prenantes).Ses données d’entrée sont essentiellement issues de l’analyse fonctionnelle (document d’entrée que l’on appelle « expression de besoin » ou « cahier des charges fonctionnel » ou « spécifications fonctionnelles » ou « cahier des charges client », ou « exigences du maître d’ouvrage » ou « CCTP » ou autre dénomination selon secteur d’activité).
Nota : ce document d’entrée constitue la base du contrat de l’industriel vis-à-vis du maître d’ouvrage – on parle alors « d’exigences initiales ».
Le « diagramme d’exigences » sous SysML est une traduction, par l’industriel, des données de l’analyse fonctionnelle, par adoption d’un point de vue « conception système » – une déclinaison des exigences client en exigences fonctionnelles et techniques (spécifications techniques).
– Il y a alors transcription, par le maître d’oeuvre, des exigences initiales (issues de l’analyse fonctionnelle) sur un concept système donné, proposé par le maître d’oeuvre et retenu par le maître d’ouvrage.
– Cette traduction sera complétée par d’autres types d’exigences, dites « exigences techniques » :
– Exigences liées au montage industriel retenu pour le développement et la réalisation du système (exigences d’interfaces entre plusieurs industriels, entre industriel et ses sous-traitants,…)
Exigences liées aux propres contraintes de l’industriel (exigences techniques, financières, exigences de management,…),
– voire modifications d’exigences initiales, relevant de compromis entre exigences ou non-faisabilité technologique.
– Ces exigences techniques seront proposées au maître d’ouvrage : leur validation les transforme en « spécifications ».
SysML s’attache ensuite davantage à ce que l’on appelle en systémique une vue « boîte blanche » du système (vue interne, fonctionnement). La partie exigences/spécifications ci-dessus faisant le lien entre la vue « boite noire » (besoins, environnements) avec un concept de « boîte blanche ».
Ainsi le terme « acteur » dans SysML (diagramme « cas d’utilisation ») ne différencie pas le fait qu’il s’agisse d’un utilisateur final ou d’un opérateur du système (l’utilisateur est celui pour lequel est créé le système, l’opérateur est un élément de la la solution de système envisagé, c’est un moyen (il serait différent si l’on change de choix système).
Les objectifs des autres diagrammes illustrent également bien ce point de vue « interne » :
Diagramme « cas d’utilisation » : interactions entre « acteurs » et système lors de scénarios-type d’utilisation,
Diagramme de séquences : pour décrire chronologiquement « comment » s’enchaînent les fonctions élémentaires dans le temps, au sein du système
Diagramme « Etats-Transitions » : pour décrire le comportement interne du système
Diagramme « d’activité » : pour décrire l’enchaînement d’actions élémentaires lors d’une activité du système
Diagramme « de définition de bloc » : pour représenter le système sous forme de constituants hiérarchisés
Diagramme « de bloc interne » : pour montrer comment sont les liens entre blocs/constituants
Reproduit avec l’aimable autorisation de Mme Catherine Laval – APTE System © – 2014
Remarque : Knowllence vous propose le logiciel TDC Need pour élaborer vos analyses fonctionnelles.