Ingénierie, innovation et développement durable (STI2D) · Terminale · Outils de l’ingénierie système
Analyse du besoin et exigences
Du besoin de l’usager au critère chiffré.
En bref
À l’épreuve comme en projet, tout commence par la lecture d’un cahier des charges exprimé en SysML.
À l’épreuve comme en projet, tout commence par la lecture d’un cahier des charges exprimé en SysML. Savoir en extraire l’information utile est la première compétence attendue.
Du besoin au système
BesoinCas d’utilisationExigencesArchitectureConstituants
| L’étape | La question | Le diagramme |
|---|---|---|
| Besoin initial, mission | À quoi sert le produit, pour qui ? | Texte, contexte |
| Cas d’utilisation | Quels services pour quels acteurs ? | uc |
| Exigences | Quelles performances vérifiables ? | req |
| Architecture | Quels blocs, quels flux ? | bdd, ibd |
| Comportement | Quels états, quels échanges ? | stm, sd |
Lire un diagramme d’exigences
Chaque exigence a un identifiant, un texte et souvent un critère chiffré. Les relations utiles :
| La relation | Sens |
|---|---|
| contient (containment) | Une exigence se décompose en sous-exigences |
| dérive de (deriveReqt) | Une exigence technique découle d’une exigence de plus haut niveau |
| satisfait (satisfy) | Un bloc répond à une exigence |
| vérifie (verify) | Un essai ou une simulation contrôle une exigence |
| raffine (refine) | Un élément précise une exigence |
L’IVVQ
| Le terme | Définition |
|---|---|
| Intégration | Assembler les constituants, sur site si possible |
| Vérification | Chaque constituant respecte-t-il sa spécification ? |
| Validation | Le système répond-il au besoin de l’usager ? |
| Qualification | Quelles sont les performances réelles du système produit ? |
On vérifie par rapport aux spécifications, on valide par rapport au besoin.
Exemple travaillé : une station de recharge de vélos
Exigence 1 « Recharger un vélo », décomposée en :
| Id | Texte | Critère |
|---|---|---|
| 1.1 | Recharger une batterie de 500 Wh | En moins de 4 h |
| 1.2 | Fonctionner hors réseau | Autonomie solaire de 3 jours |
| 1.3 | Protéger l’usager | Aucune partie sous tension accessible |
Vérification de 1.1 : un chargeur de 150 W de rendement 0,9 fournit 135 W à la batterie. Durée : 500 / 135 ≈ 3,7 h < 4 h : l’exigence est satisfaite, avec une faible marge. Un chargeur de 120 W donnerait 500 / 108 ≈ 4,6 h : non conforme.
Parties prenantes et contexte
Le besoin ne vient pas que de l’usager : mainteneur, gestionnaire, réglementation (normes électriques, accessibilité), environnement (intempéries, vandalisme) imposent aussi des exigences. Oublier une partie prenante, c’est oublier une exigence.
À l’épreuve
Les questions typiques : « Relever l’exigence qui… », « Justifier que la solution satisfait l’exigence 1.2 », « Compléter le diagramme ibd ». La réponse attendue cite l’identifiant et compare une valeur calculée au critère.
Teste-toi
6 questions pour vérifier
Touche une réponse : la correction s’affiche tout de suite.
1.Quel diagramme SysML présente les performances vérifiables attendues ?
2.Que signifie la relation « satisfy » dans un diagramme d’exigences ?
3.Quelle relation indique qu’un essai contrôle une exigence ?
4.On vérifie un constituant par rapport…
5.Un chargeur de 150 W de rendement 0,9 fournit à la batterie…
6.Combien de temps pour charger 500 Wh sous 135 W ?
0 / 6 questions
Dans l’app, ce chapitre a son quiz complet, chronométré, et tes erreurs reviennent au bon moment pour ne plus les refaire.
La fiche de révision, sur une page
Tout « Besoin et exigences » sur une seule page A4 illustrée : l’essentiel, les pièges et un mini-test. Elle se débloque dans l’app avec des gemmes — et ton compte gratuit en offre assez pour tes trois premières fiches.
