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 **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** (bête à cornes).
- **É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
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.