Sciences de l'ingénieur (Spé) — Analyser un système
Cahier des charges et exigences
Analyse fonctionnelle, diagramme des exigences SysML, besoin client et performances attendues
Résumé synthétiqueFiche en 4 sectionsQuiz de 10 questionsGratuit, sans pub
Résumé
L'analyse d'un système technique commence par l'identification du besoin auquel il répond. Le cahier des charges fonctionnel (CdCF) traduit ce besoin en exigences mesurables : par exemple, pour un drone de livraison, on spécifie une charge utile de 2 kg, une autonomie de 30 minutes et une portée de 5 km. Le diagramme des exigences SysML (requirement diagram) organise ces exigences de manière hiérarchique, en distinguant exigences fonctionnelles (ce que le système doit faire) et exigences non fonctionnelles (contraintes de masse, coût, sécurité). Chaque exigence est identifiée par un identifiant unique, un texte descriptif et des critères d'acceptation. Les relations entre exigences incluent la dérivation (derive), le raffinement (refine) et la satisfaction (satisfy) par un bloc du système. Cette modélisation permet de vérifier que toutes les attentes du client sont prises en compte avant la conception.
Tout projet technique part d'un besoin : le service que l'utilisateur attend du système. Le cahier des charges fonctionnel (CdCF) traduit ce besoin en fonctions de service mesurables. Identifier le besoin avant de concevoir, c'est s'assurer qu'on résout le bon problème.
Le diagramme pieuvre relie le système à son environnement : les fonctions principales (FP) passent à travers le système, les fonctions contraintes (FC) le relient à un seul élément.
- Le besoin se formule avec la question « À qui/quoi le système rend-il service et sur quoi agit-il ? » (méthode bête à cornes).
- Le cahier des charges fonctionnel (CdCF) liste les fonctions de service (principales et contraintes) avec leurs critères et niveaux.
- Une fonction principale (FP) exprime le service rendu : ex. « Transporter un colis de A à B ».
- Une fonction contrainte (FC) traduit une limitation : ex. « Résister à la pluie (IP54) ».
- Les critères d'appréciation sont mesurables : masse $\leq 5\ \mathrm{kg}$, vitesse $\geq 10\ \mathrm{km/h}$, autonomie $\geq 30\ \mathrm{min}$.
- La flexibilité d'un critère indique sa marge de tolérance (classe F0 = impératif, F3 = très flexible).
Exemple
Pour un drone de livraison, on spécifie : charge utile $2\ \mathrm{kg}$ (critère F0, impératif), autonomie $\geq 30\ \mathrm{min}$, portée $5\ \mathrm{km}$. Chaque fonction de service est ainsi assortie d'un critère et d'un niveau vérifiables à la livraison.
Piège à éviter
Erreur fréquente : confondre besoin (le service attendu) et solution technique (le « comment »). Le CdCF décrit ce que le système doit faire, jamais comment il est construit.
Une fois les fonctions identifiées, le diagramme des exigences SysML organise les attentes du client et assure leur traçabilité : chaque exigence est reliée à ce qui la satisfait et à ce qui la vérifie.
- Le diagramme des exigences (req) est l'un des 9 diagrammes SysML, dédié à la traçabilité des besoins.
- Chaque exigence est un rectangle stéréotypé «requirement» avec un id et un text.
- La relation «deriveReqt» lie une exigence dérivée à son exigence source (décomposition).
- La relation «satisfy» relie un bloc (composant) à l'exigence qu'il satisfait.
- La relation «verify» relie un cas de test à l'exigence qu'il vérifie.
- La relation «refine» précise une exigence par un modèle ou un diagramme plus détaillé.
Exemple
Exigence « Autonomie $\geq 30\ \mathrm{min}$ » (id REQ-12). Elle est «satisfy» par le bloc Batterie Li-ion, «verify» par le cas de test Essai d'endurance, et «deriveReqt» de l'exigence parente « Réaliser une livraison de $5\ \mathrm{km}$ ».
Piège à éviter
Ne confonds pas «satisfy» (un composant remplit l'exigence) et «verify» (un test prouve qu'elle est remplie) : la première relie un bloc, la seconde un cas de test.
Toutes les exigences ne sont pas de même nature. Les distinguer aide à n'oublier aucune contrainte : un système peut remplir sa fonction principale mais échouer sur la sécurité ou l'environnement.
- Exigences fonctionnelles : décrivent ce que le système doit faire (fonctions principales).
- Exigences de performance : vitesse, précision, capacité, temps de réponse — toujours chiffrées.
- Exigences de sécurité : normes CE, indice IP, résistance aux chocs, protection des utilisateurs.
- Exigences d'interface : compatibilité avec d'autres systèmes, connectique, protocoles.
- Exigences environnementales : plage de température, humidité, recyclabilité.
Exemple
Pour un portail automatique : « ouvrir le vantail » (fonctionnelle), « ouverture en $\leq 8\ \mathrm{s}$ » (performance), « s'arrêter si obstacle détecté » (sécurité), « commande via télécommande $433\ \mathrm{MHz}$ » (interface).
Piège à éviter
Une exigence non fonctionnelle (performance, sécurité, environnement) n'est pas une exigence « secondaire » : un défaut de sécurité peut rendre le système inutilisable même si la fonction principale marche.
Analyser un système suit un enchaînement logique : on part des acteurs, on liste les fonctions, on les caractérise, puis on formalise tout dans le diagramme des exigences. Cette démarche évite les oublis et structure le dialogue avec le client.
- Étape 1 : identifier les parties prenantes (utilisateur, mainteneur, environnement).
- Étape 2 : recenser les fonctions de service à l'aide d'un diagramme pieuvre (après la bête à cornes, qui exprime le besoin).
- Étape 3 : caractériser chaque fonction avec critères, niveaux et flexibilité.
- Étape 4 : construire le diagramme des exigences SysML à partir du CdCF.
- Étape 5 : vérifier la couverture (chaque exigence satisfaite par au moins un bloc).
- Le diagramme permet de communiquer clairement entre ingénieurs, clients et fournisseurs.
Exemple
Projet « arrosage automatique » : parties prenantes (jardinier, plantes, réseau d'eau) → fonctions (« arroser selon l'humidité du sol ») → critères (« déclencher si humidité $< 30\ \%$ ») → exigences SysML → vérification que le capteur d'humidité satisfait bien l'exigence.
Piège à éviter
Ne saute pas l'étape de couverture : une exigence qu'aucun bloc ne «satisfy» signale une fonction oubliée dans la conception.
Quiz - Cahier des charges et exigences
10 questions
S'entraîner
Articles utiles
Questions fréquentes
Les points clés à retenir sur Cahier des charges et exigences, extraits du quiz de révision.
Quel document traduit le besoin du client en exigences mesurables ?
Réponse :
Le cahier des charges fonctionnel
Le cahier des charges fonctionnel (CdCF) est le document qui formalise les fonctions de service et les exigences associées, avec des critères mesurables.
Dans un diagramme SysML des exigences, quel stéréotype identifie une exigence ?
Réponse :
«requirement»
En SysML, les exigences sont représentées par des rectangles avec le stéréotype «requirement», contenant un id et un text.
Quelle relation SysML relie un composant à l'exigence qu'il remplit ?
Réponse :
«satisfy»
La relation «satisfy» indique qu'un bloc (composant du système) satisfait une exigence donnée.
Qu'est-ce qu'une exigence non fonctionnelle ?
Réponse :
Une contrainte sur la performance, la sécurité ou l'environnement
Les exigences non fonctionnelles portent sur les contraintes (performance, sécurité, coût, environnement) et non sur les fonctions principales.