Glossaire
LES DEFINITIONS DE L’INGENIERIE SYSTEME
Garantir un langage commun en architecture et ingénierie système, MBSE et architecture d’entreprise
L’utilisation d’un glossaire assure un usage efficace et juste de termes ou d’expressions qui sont adoptées afin d’avoir une compréhension commune de certains concepts. Pensé pour les ingénieurs, architectes et managers techniques, ce glossaire sur les méthodes d’architecture et d’ingénierie système appliqués à la conception et à la maîtrise de systèmes complexes est un outil pour nous permettre d’employer un langage commun!
Les définitions présentées ici s’appuient sur le cadre d’architecture CESAM. Elles sont reconnues internationalement, utilisées dans de nombreux secteurs, indépendantes de tout outillage et s’inscrivent dans une logique méthodologique solide. Pour compléter cette référence, des liens vers d’autres sources majeures en ingénierie système – notamment la norme ISO 15288 et l’INCOSE Handbook – sont également fournis. Sources : CESAM, ISO/IEC/IEEE 15288, 19514, 24765, 26580, 29148, 42010, 42020, INCOSE SEBoK.
A
Analyse de compromis
Une analyse de compromis est un ensemble d’actions décisionnelles qui permettent de choisir parmi diverses exigences et solutions alternatives en fonction de l’avantage net pour les parties prenantes.
Réf. : CESAM, ISO 24765:2017
Architecture système
L’architecture système est la discipline qui synthétise les méthodes et les outils permettant la modélisation exhaustive et cohérente d’un système (sous sa triple dimension opérationnelle, fonctionnelle et organique) dans le but de piloter efficacement sa mise en place (conception, déploiement, maintenance, …)
Réf. : CESAM, ISO/IEC/IEEE 15288:2015
Architecture fonctionnelle
L’architecture fonctionnelle est l’ensemble des vues et analyses qui décrivent le système du point de vue de ses fonctions, indépendamment de ses composants : décomposition et interactions fonctionnelles, exigences fonctionnelles, modes fonctionnels, scénarios fonctionnels et flux fonctionnels.
Réf. : ISO/IEC/IEEE 42020:2019
Architecture opérationnelle
L’architecture opérationnelle est l’ensemble des vues et analyses qui décrivent le système du point de vue de son environnement et ses parties prenantes: Systèmes externes et parties prenantes, environnement, besoins, cycle de vie, cas d’utilisation, scénarios opérationnels et interfaces opérationnelles.
Réf. : CESAM
Architecture organique
L’architecture organique est l’ensemble des vues et analyses qui permettent de définir la structure et les ressources permettant d’implémenter les fonctions du systèmes: composants et leurs interactions, exigences organiques, configurations techniques et scénarios organiques.
Réf. : CESAM
Architecture de référence
Modèle d’architecture réutilisable pour une famille de systèmes, promouvant cohérence et standardisation.
Réf. : CESAM, ISO/IEC/IEEE 42010; INCOSE
Aspect
Un aspect correspond aux types d’informations qui peuvent être décrites dans chaque architecture du Framework CESAM : Il y a 5 aspects dans le cadre CESAM : Propriétés attendues, États, Éléments statiques, Scénarios, Flux.
Réf. : CESAM
Atelier collaboratif d’architecture
Un atelier d’architecture est un mécanisme qui permet à l’ensemble des acteurs d’un projet concernés par un problème d’architecture de partager une même vision et de définir une même solution de ce problème.
Réf. : CESAM
Attribut
Un attribut est toute information qui peut être ajoutée à un besoin ou à une exigence et qui permet de soutenir leur analyse, leur compréhension et la gestion de leur cycle de vie
Réf. : CESAM, ISO/IEC/IEEE 29148:2018
B
Besoin
Un besoin est une condition ou une capacité, énoncée de façon non ambiguë et dont la satisfaction doit pouvoir être démontrée, requise – dans un contexte donné – par un ou plusieurs systèmes externes d’un système pour arriver à un objectif qui leur est propre et qui génère une dépendance mutuelle, une interaction, un échange ou une influence entre ce(s) système(s) externe(s) et le système cible.
Elle se formule ainsi : le <système externe> doit être capable de <faire quelque chose> (capacité), impose <quelque chose> (condition) avec <un certain niveau de performance> dans un <contexte opérationnel> donné.
Réf. : CESAM
C
Cadre d’architecture
Un cadre d’architecture contient des conventions, des principes et des pratiques pour la description des architectures établies dans un domaine d’application spécifique et/ou une communauté de parties prenantes.
Réf. : CESAM, ISO/IEC/IEEE 42010:2022
Cas d’utilisation
Un cas d’utilisation est un objectif d’un ou plusieurs systèmes externes lors de l’utilisation du système dans un contexte donné. Remarque : il est généralement formalisé comme une déclaration « faire quelque chose », dont le sujet est un système externe.
Réf. : CESAM
Catalogue des features
Un catalogue des features est un modèle de la collection de toutes les options de fonctionnalités et contraintes de fonctionnalités disponibles sur tous les produits membres de la famille de produits.
Réf. : CESAM, ISO/IEC 26580:2021
Composant
Voir sous-système
Réf. : CESAM
Conception
Une conception est le résultat d’un processus visant à définir l’architecture, les éléments système, les interfaces et autres caractéristiques d’un système ou d’un élément système.
Réf. : CESAM, ISO/IEC/IEEE 15288:2015
Configuration technique
Une configuration technique est un état du système dans lequel le système n’a – à un niveau d’abstraction donné – qu’une seule structure. En pratique, on peut voir une « structure » comme la combinaison de 2 conditions : un ensemble de composants présents dans le système et un niveau de performance structurel.
Réf. : CESAM
Contexte opérationnel
Le contexte opérationnel, ou phase du cycle de vie, est un état stable de l’environnement du système, dans lequel cet environnement n’a – à un niveau d’abstraction donné – qu’un seul comportement. En pratique, on peut voir un « comportement » de l’environnement comme la combinaison de 2 conditions : un ensemble cohérent d’attentes (ou cas d’utilisation) et un niveau de performance.
Réf. : CESAM
Couche d’architecture
Les couches d’architecture (lignes) correspondent aux 3 perspectives à partir desquelles tout système peut être décrit dans le cadre CESAM – son environnement (couche opérationnelle), – son comportement (couche fonctionnelle), – sa structure (couche organique).
Réf. : CESAM, ISO/IEC/IEEE 42010:2022
Cycle de vie
Le cycle de vie d’un système donné est une représentation de toutes les phase de vie du système depuis sa naissance jusqu’à sa mort, avec leurs relations temporelles relatives – c’est-à-dire respectivement consécutivité, inclusion ou simultanéité – et les événements qui provoquent les transitions entre les contextes.
Réf. : CESAM, ISO/IEC/IEEE 15288:2015
D
Décomposition des parties prenantes
La décomposition des parties prenantes d’un système donné représente l’ensemble des systèmes externes du système. Dans ce diagramme, les parties prenantes sont regroupées selon des critères choisis (par exemple, la similarité des interactions, l’appartenance à un même système ou la nature des systèmes externes).
Réf. : CESAM
Décomposition fonctionnelle (FBS)
La décomposition fonctionnelle (FBS) d’un système donné est une représentation arborescente des fonctions du système.
Réf. : CESAM
Décomposition opérationnelle
La décomposition opérationnelle d’un système représente tous les cas d’utilisation du système, classés par phase de vie.
Réf. : CESAM
Décomposition produit (PBS)
La décomposition produit (PBS) d’un système donné est une représentation arborescente des sous-systèmes du système.
Réf. : CESAM, ISO 24765:2017
Dérivation des besoins en exigences fonctionnelles
La dérivation des besoins en exigences fonctionnelles formalise les liens de traçabilité entre les besoins des parties prenantes et les exigences fonctionnelles, signifiant qu’une exigence fonctionnelle contribue à satisfaire un besoin.
Réf. : CESAM
Dérivation des besoins et exigences fonctionnelles en exigences organiques
Dérivation des besoins et exigences fonctionnelles en exigences organiques formalise les liens de traçabilité, signifiant qu’une exigence organique contribue à satisfaire un besoin ou une exigence fonctionnelle.
Réf. : CESAM
Diagramme de cas d’utilisation
Un diagramme de cas d’utilisation, qui représente tous les cas d’utilisation réalisés dans un contexte donné, montrant les systèmes externes qui contribuent à chaque cas d’utilisation et les relations logiques entre les cas d’utilisation.
Réf. : CESAM, INCOSE Handbook v4 (2022) ; ISO/IEC 19514:2017
Diagramme d’environnement
Voir Environnement
Réf. : CESAM
Diagramme des modes fonctionnels
Le diagramme des modes fonctionnels d’un système donné est une représentation de tous les modes fonctionnels du système depuis la naissance jusqu’à la mort, avec leurs relations temporelles relatives – c’est-à-dire respectivement consécutivité, inclusion ou simultanéité – et les événements qui provoquent les transitions entre les modes fonctionnels.
Réf. : CESAM
Diagramme d’interaction fonctionnelle
Le diagramme d’interaction fonctionnelle représente les fonctions d’un système et les flux fonctionnels échangés entre les fonctions et avec les systèmes externes, indépendamment du temps.
Réf. : CESAM
Diagramme d’interaction organique
Le diagramme d’interaction organique représente les composants d’un système et les flux organique échangés entre les composants et avec les systèmes externes, indépendamment du temps.
Réf. : CESAM
E
Environnement
L’environnement d’un système donné est le système constitué de tous les systèmes externes d’un système d’intérêt, et de tous les flux qu’ils échangent avec le système (tous contextes opérationnels confondus).
Réf. : CESAM, ISO/IEC/IEEE 15288:2015
État
Un état modélise une situation dans laquelle une condition invariante (généralement implicite) est vérifiée. La nature de cette condition dépend de la couche d’architecture considérée.
Réf. : CESAM, ISO/IEC/IEEE 29148:2018
Exigence
Une exigence relative à un système définit une performance du système qui doit être nécessairement satisfaite, généralement pour satisfaire un ou plusieurs besoins. Le référentiel CESAM définit plusieurs types d’exigences : les exigences fonctionnelles et les exigences organiques.
Réf. : CESAM, ISO/IEC/IEEE 29148:2018 ; INCOSE Handbook v4 (2022)
Exigence fonctionnelle
Une exigence fonctionnelle est une exigence portant sur le comportement d’un système c’est-à-dire spécifiant la performance d’un comportement (d’une fonction, d’une transformation).
Elle se formule ainsi : le <système> doit <faire quelque chose> avec <un niveau de performance> dans un <mode fonctionnel> donné.
Réf. : CESAM, ISO/IEC/IEEE 29148:2018 ; INCOSE Handbook v4 (2022)
Exigence organique
Une exigence organique ou technique est une exigence portant sur la structure d’un système c’est-à-dire spécifiant une performance concrète du système :
Elle se formule ainsi : le <système> doit <être / avoir quelque chose> avec <un niveau de performance> dans une <configuration technique > donnée.
Réf. : CESAM
F
Famille de produits
Une famiille de produits désigne un ensemble de produits qui partagent des fonctions et des composants communs et répondent à une variété d’utilisations, de marchés et d’environnements.
Réf. : CESAM
Feature
Une feature est une caractéristique d’un produit d’une famille de produits qui le distingue des autres produits de la même familles. Les features peuvent être externes ou internes.
Réf. : CESAM, ISO/IEC 26580:2021
Flux
Un flux est la spécification du transfert d’un ou plusieurs éléments d’une source vers une cible. L’élément peut être une information, une matière ou de l’énergie. La source et la cible peuvent être un système externe, une fonction ou un composant.
Réf. : CESAM, ISO 24765:2017
Flux fonctionnel
Un flux fonctionnel est la spécification du transfert d’un ou plusieurs éléments entre 2 fonctions du système ou entre une fonction et l’un de ses systèmes externes.
Réf. : CESAM
Flux opérationnel
Un flux opérationnel est la spécification du transfert d’un ou plusieurs éléments entre le système et l’une de ses systèmes externes.
Réf. : CESAM
Flux organique
Un flux organique est la spécification du transfert d’un ou plusieurs éléments entre 2 sous-systèmes du système, ou entre un sous-système et un système externe.
Réf. : CESAM
Fonction
Une fonction est une description – à un niveau d’abstraction donné – du comportement statique du système, c’est-à-dire de la nature de la relation existant entre les entrées et les sorties du système. On l’écrit souvent sous la forme « faire quelque chose » dont le sujet implicite est le système.
Réf. : CESAM, INCOSE SEBoK
G
Gestion de configuration
Discipline garantissant l’intégrité et la traçabilité des produits et de leurs évolutions tout au long du cycle de vie.
Réf. : CESAM, ISO/IEC/IEEE 15288:2015
I
Ingénierie système
L’ingénierie système est une approche interdisciplinaire dont l’objectif est de permettre la réalisation de systèmes performants, d’un point de vue coût ou délai. Elle se concentre au début du cycle de développement d’un système sur la définition des besoins, des fonctionnalités induites et des exigences. La conception de l’architecture globale du système, puis sa vérification et sa validation reposent ensuite sur ces éléments.
L’ingénierie système relève de l’approche système : qui signifie « analyser de façon globale ».
Réf. : ISO/IEC/IEEE 15288:2015
Intégration
L’objectif du processus d’intégration est de synthétiser un ensemble d’éléments système dans un système réalisé (produit ou service) qui satisfait les exigences du système, l’architecture et la conception. ISO/IEEE 2008 : Un processus qui combine des éléments système pour former des configurations système complètes ou partielles afin de créer un produit spécifié dans les exigences du système.
Réf. : CESAM, ISO/IEC/IEEE 15288:2015
Interface
Une interface est la donnée d’une interaction, d’un échange, d’une influence ou d’une dépendance mutuelle entre au moins deux éléments (systèmes, composants ou fonctions).
Réf. : CESAM
M
MBSE
L’ingénierie système basée sur les modèles (MBSE) est l’application formalisée de la modélisation pour soutenir les activités de définition des exigences du système, de conception, d’analyse, de vérification et de validation, tout au long de son cycle de vie.
Réf. : INCOSE Handbook v4 (2022)
Mode fonctionnel (ou mode de fonctionnement)
Un mode fonctionnel représente une période de temps pendant laquelle le comportement du système – c’est-à-dire le sous-ensemble de fonctions disponibles et leurs niveaux de performance – est invariant.
Réf. : CESAM
Modèle
Un modèle est une représentation formelle abstraite d’un système (souvent décomposée selon des visions architecturales).
Réf. : ISO/IEC/IEEE 42010:2022
N
Notation
Une notation est une syntaxe concrète, généralement graphique, permettant de représenter des modèles créés avec certains langages. Différentes notations peuvent se concentrer sur différents aspects d’un même langage ou prendre en charge plusieurs langages.
Réf. : CESAM, ISO/IEC 24744:2014
P
Partie prenante
Une partie prenante est une personne légitime pour représenter un système externe et ainsi exprimer ses besoins vis-à-vis du système cible.
Réf. : CESAM, ISO/IEC/IEEE 42010:2022
Phase de vie
Voir Contexte Opérationnel
Réf. : CESAM
S
Scénario fonctionnel
Un scénario fonctionnel visualise, construit et documente la séquence d’interactions entre les fonctions du système et avec les systèmes externes, pour un cas d’utilisation considéré.
Réf. : CESAM
Scénario opérationnel
Un scénario opérationnel visualise, construit et documente la séquence d’interactions entre le système et ses systèmes externes, pour un cas d’utilisation considéré.
Réf. : CESAM, ISO/IEC/IEEE 29148:2018
Scénario organique
Un scénario organique visualise, construit et documente la séquence d’interactions entre les composants et avec les systèmes externes, pour un cas d’utilisation considéré.
Réf. : CESAM
Sous-système
Un sous-système d’un système est l’un des éléments qui composent le système. Il peut être matériel, logiciel, humain ou hybride.
Réf. : CESAM, ISO 24765:2017
Système
Un système désigne un ensemble d’éléments de nature matérielle, logicielle et/ou humaine organisés de manière à ce que leur intégration permette d’accomplir – au sein d’un environnent donné – les missions pour lesquelles il a été conçu.
Réf. : CESAM, ISO/IEC/IEEE 42010:2022
Système complexe
Un système complexe est un système qui, pris dans sa globalité, possède une ou plusieurs propriétés émergentes qui ne peuvent pas être déduites directement des propriétés de ses composants.
Réf. : CESAM
Système de systèmes
Un système de systèmes (SdS) est un système d’intérêt (SOI) dont les éléments sont eux-mêmes des systèmes. Un SdS rassemble un ensemble de systèmes pour une tâche qu’aucun système ne peut accomplir seul. Chaque système constitutif conserve sa propre gestion, ses propres objectifs et ses propres ressources, tout en se coordonnant au sein du SdS et en s’adaptant pour atteindre ses objectifs.
Réf. : CESAM, ISO/IEC/IEEE 15288:2015
Système d’intérêt
Le système d’intérêt (SOI ou simplement système) fait référence au système dont l’architecture est prise en compte dans la préparation d’une description d’architecture.
Réf. : CESAM, ISO/IEC/IEEE 42010:2022
Système externe
Un système externe est un système (matériel, informatique, humain, etc.) lié au système d’intérêt par une dépendance mutuelle, une interaction, un échange ou une influence.
Réf. : CESAM, ISO/IEC/IEEE 15288:2015
T
Traçabilité (lien de)
Capacité à relier bi-directionnellement besoins, exigences, éléments de modèles, tests et décisions.
Réf. : CESAM, ISO/IEC/IEEE 15288; 29148
V
Validation
Processus visant à fournir la preuve que le système répond aux exigences de ses parties prenantes en cohérence avec l’architecture opérationnelle.
Réf. : ISO 9000:2015
Vérification
Processus visant à fournir la preuve que le système répond à ses exigences organiques et fonctionnelles, en cohérence avec l’architecture fonctionnelle et organique.
Réf. : ISO/CEI 2008
Vue d’architecture
Une vue d’architecture est la représentation d’un système selon un point de vue particulier. Les vues du cadre CESAM s’obtiennent comme l’intersection d’un aspect du système (propriété attendue, état, élément statique, scénario ou flux) et d’une perspective donnée (environnement, comportement ou structure).
Réf. : CESAM
Ressources complémentaires
DOCUMENT [EN]
Pocket Guide
CESAMES Systems Architecting Method (CESAM) is a systems architecting & modeling framework which develops since 2003 in close interaction with many leading industrial companies in areas such as aeronautics, automotive, civil engineering, defense, energy, health, railway and space. It was initiated within the academic sphere in the context of the “Engineering of Complex Systems” industrial chair in France (Dassault Aviation – DCNS – DGA – Thales – Ecole Polytechnique). Nowadays the members of CESAM Community act however as the core developers & contributors of the CESAM framework which is presented in a light version in this pocket guide.
DOCUMENT [EN]
CESAM Systems Architecture Key Takeaways
Complex projects are characterized by the multiplicity of components, technologies, and stakeholders and above all by the number of interfaces to be controlled. Complex projects duration combined with the acceleration of processes and services evolutions mean that most of the phases studies will be initiated while many of the structuring parameters are not yet defined… which can lead to many pitfalls.
Systems architecture provides valuable guidance to guarantee efficient and sustainable development while de-risking the projects. The objective is to anticipate design risks during the early phases of the project to minimize systemic problems and thus save time and cost.
Discover the 13 fundamentals of system architecture.
DOCUMENT [FR]
Livre blanc : le rôle de l’architecte
Ce livre blanc vise à détailler les missions et les responsabilités de l’architecte en soulignant l’importance de la collaboration et de la coordination dans la réussite des projets complexes. Il explore les défis auxquels les architectes sont confrontés et les compétences nécessaires pour surmonter ces obstacles, tout en mettant en lumière l’impact crucial de l’architecte sur la performance et la compétitivité des entreprises modernes. Il est le reflet des expériences partagées des membres du groupe de travail « Le Cercle CESAM ».
Glossaire MBSE – Bilingue FR/EN
Définitions normalisées pour l’ingénierie système et le MBSE. Sources : ISO/IEC/IEEE 15288, 29148, 42010, INCOSE SEBoK, OMG SysML, CESAM.
- — A —
- Allocation / Allocation
-
Répartition de fonctions, performances ou exigences vers des éléments de solution (composants, sous-systèmes) afin de satisfaire des objectifs système.
EN: Assignment of functions, performance, or requirements to solution elements (components, subsystems) to meet system objectives.
Réf. : ISO/IEC/IEEE 15288; INCOSE SEBoK; CESAM.
- Analyse fonctionnelle / Functional Analysis
-
Décomposition des missions et fonctions du système, leurs interactions et contraintes, indépendante de la solution physique.
EN: Decomposition of system missions and functions, their interactions and constraints, independent of the physical solution.
Réf. : INCOSE SEBoK; CESAM.
- Architecture système / System Architecture
-
Organisation fondamentale d’un système, incarnée par ses éléments, leurs relations et les principes guidant sa conception et son évolution.
EN: Fundamental organization of a system, embodied in its elements, relationships, and guiding principles for design and evolution.
Réf. : ISO/IEC/IEEE 42010; CESAM.
- Artefact / Artifact
-
Produit tangible de l’ingénierie (document, modèle, code, test, rapport) utilisé comme preuve, entrée ou sortie d’un processus.
EN: Tangible engineering work product (document, model, code, test, report) used as evidence, input, or output of a process.
Réf. : INCOSE SEBoK.
- — B —
- Ligne de base (Baseline) / Baseline
-
Référence approuvée d’un ensemble d’artefacts, soumise au contrôle de configuration et servant de point de comparaison.
EN: Approved reference of a set of artifacts under configuration control, used as a comparison point.
Réf. : ISO/IEC/IEEE 15288; ISO 10007.
- Besoin / Need
-
Problème à résoudre ou opportunité à saisir, exprimé par les parties prenantes et servant d’origine aux exigences.
EN: Problem to solve or opportunity to seize, expressed by stakeholders and originating requirements.
Réf. : ISO/IEC/IEEE 29148.
- — C —
- Capacité / Capability
-
Aptitude du système à produire un effet attendu dans un contexte d’emploi donné, mesurable par des critères de performance.
EN: The system’s ability to deliver an intended effect in a given operational context, measurable via performance criteria.
Réf. : INCOSE SEBoK; ISO/IEC/IEEE 15288.
- Cas d’utilisation / Use Case
-
Description structurée d’une interaction entre un acteur et le système pour atteindre un objectif.
EN: Structured description of an interaction between an actor and the system to achieve a goal.
Réf. : OMG UML/SysML.
- Demande de changement / Change Request
-
Proposition formelle de modification d’artefacts sous configuration, nécessitant évaluation et approbation.
EN: Formal proposal to modify items under configuration, requiring evaluation and approval.
Réf. : ISO 10007; ISO/IEC/IEEE 15288.
- Concept d’opérations (ConOps) / Concept of Operations
-
Description de l’emploi du système dans son environnement opérationnel, du point de vue des utilisateurs.
EN: Description of how the system will be used in its operational environment, from users’ perspective.
Réf. : ISO/IEC/IEEE 29148; INCOSE.
- Conception logique / Logical Design
-
Structuration de la solution en éléments logiques et interfaces, indépendante de la technologie physique.
EN: Structuring the solution into logical elements and interfaces, independent of physical technology.
Réf. : CESAM; INCOSE SEBoK.
- Gestion de configuration / Configuration Management
-
Discipline garantissant l’intégrité et la traçabilité des produits et de leurs évolutions tout au long du cycle de vie.
EN: Discipline ensuring integrity and traceability of products and their changes across the lifecycle.
Réf. : ISO 10007; ISO/IEC/IEEE 15288.
- Contexte système / System Context
-
Ensemble des éléments externes (acteurs, environnements, systèmes voisins) en interaction avec le système étudié.
EN: Set of external elements (actors, environments, neighboring systems) interacting with the system under study.
Réf. : CESAM.
- — D —
- Décomposition / Decomposition
-
Subdivision d’un système en sous-systèmes ou composants pour maîtriser la complexité et allouer les exigences.
EN: Partitioning a system into subsystems or components to manage complexity and allocate requirements.
Réf. : INCOSE SEBoK.
- Diagramme (SysML) / Diagram (SysML)
-
Vue modélisée selon une notation standard (blocs, exigences, séquences, états, activités, paramétrique, etc.).
EN: Modeled view using a standard notation (blocks, requirements, sequence, state, activity, parametric, etc.).
Réf. : OMG SysML.
- — E —
- Élément système / System Element
-
Unité constitutive d’un système (matériel, logiciel, humain, procédure) participant à sa réalisation et à ses performances.
EN: Constituent unit of a system (hardware, software, human, procedure) contributing to realization and performance.
Réf. : ISO/IEC/IEEE 15288.
- Exigence / Requirement
-
Expression formelle d’un besoin, contrainte ou condition à satisfaire par le système, vérifiable.
EN: Formal, verifiable statement of a need, constraint, or condition to be met by the system.
Réf. : ISO/IEC/IEEE 29148.
- Exigence fonctionnelle / Functional Requirement
-
Décrit ce que le système doit faire (services, comportements, fonctions).
EN: Describes what the system shall do (services, behaviors, functions).
Réf. : ISO/IEC/IEEE 29148.
- Exigence non fonctionnelle / Non-functional Requirement
-
Contraintes de qualité ou d’environnement (performance, sûreté, sécurité, maintenabilité, ergonomie, etc.).
EN: Quality or environmental constraints (performance, safety, security, maintainability, usability, etc.).
Réf. : ISO/IEC/IEEE 29148.
- — F —
- Flux & Interface / Flow & Interface
-
Échanges d’informations, d’énergie ou de matière entre éléments via des interfaces spécifiées.
EN: Exchanges of information, energy, or matter between elements via specified interfaces.
Réf. : ISO/IEC/IEEE 42010; CESAM.
- — G —
- Gestion des risques / Risk Management
-
Identification, analyse, traitement et surveillance des risques et opportunités tout au long du cycle de vie.
EN: Identification, analysis, treatment, and monitoring of risks and opportunities across the lifecycle.
Réf. : ISO 31000; ISO/IEC/IEEE 15288.
- — H —
- Homologation / Certification & Approval
-
Reconnaissance officielle de conformité du système à des exigences réglementaires ou normatives.
EN: Official recognition that the system conforms to regulatory or normative requirements.
Réf. : Domaines spécifiques; ISO/IEC/IEEE 15288.
- — I —
- Ingénierie système / Systems Engineering
-
Approche interdisciplinaire pour concevoir, développer et gérer des systèmes complexes sur leur cycle de vie.
EN: Interdisciplinary approach to design, develop, and manage complex systems throughout the lifecycle.
Réf. : INCOSE SEBoK.
- Interface / Interface
-
Frontière d’échange entre éléments, spécifiant les modalités d’interaction.
EN: Boundary of exchange between elements, specifying interaction modalities.
Réf. : ISO/IEC/IEEE 42010; CESAM.
- — J —
- Justification / Rationale
-
Arguments et preuves supportant une décision d’ingénierie (choix d’architecture, d’allocation, etc.).
EN: Arguments and evidence supporting an engineering decision (architecture choice, allocation, etc.).
Réf. : INCOSE SEBoK.
- — K —
- Indicateur clé (KPI) / Key Performance Indicator
-
Mesure quantifiée permettant de piloter objectifs, performances et conformité du système ou du projet.
EN: Quantified measure used to steer objectives, performance, and compliance of the system or project.
Réf. : INCOSE; bonnes pratiques projet.
- — L —
- Cycle de vie / Lifecycle
-
Enchaînement des stades depuis l’expression du besoin jusqu’au retrait du service.
EN: Sequence of stages from need expression to retirement/disposal.
Réf. : ISO/IEC/IEEE 15288.
- Lien de traçabilité / Trace Link
-
Relation explicite entre artefacts (ex. : besoin→exigence→test) assurant cohérence et auditabilité.
EN: Explicit relationship between artifacts (e.g., need→requirement→test) ensuring coherence and auditability.
Réf. : ISO/IEC/IEEE 15288; 29148.
- — M —
- MBSE (ingénierie système basée modèle) / MBSE (Model-Based Systems Engineering)
-
Pratique fondée sur l’usage formel de modèles pour soutenir spécification, conception, analyse, VV et gouvernance.
EN: Practice based on the formal use of models to support specification, design, analysis, V&V, and governance.
Réf. : INCOSE; OMG SysML.
- Modèle / Model
-
Représentation abstraite et finalisée d’un système pour analyser, simuler, communiquer ou concevoir.
EN: Abstract, purpose-driven representation of a system for analysis, simulation, communication, or design.
Réf. : INCOSE; CESAM.
- Modélisation / Modeling
-
Activités de création, structuration, vérification et maintenance des modèles.
EN: Activities to create, structure, verify, and maintain models.
Réf. : INCOSE SEBoK; OMG SysML.
- — N —
- Notation / Notation
-
Système de symboles et règles pour exprimer des modèles (ex. : SysML).
EN: System of symbols and rules to express models (e.g., SysML).
Réf. : OMG SysML.
- — O —
- Objectif & Mission / Objective & Mission
-
Finalité du système et effets recherchés dans le contexte opérationnel.
EN: System’s purpose and intended effects in the operational context.
Réf. : INCOSE; CESAM.
- — P —
- Partie prenante / Stakeholder
-
Personne, groupe ou organisation ayant un intérêt direct ou indirect dans le système.
EN: Person, group, or organization with direct or indirect interest in the system.
Réf. : ISO/IEC/IEEE 15288.
- Performance / Performance
-
Niveau de service ou d’efficacité atteint par le système selon des critères mesurables.
EN: Level of service or effectiveness achieved by the system according to measurable criteria.
Réf. : INCOSE; ISO/IEC/IEEE 15288.
- Point de vue / Viewpoint
-
Spécification des conventions (langage, notations, modèles) pour construire des vues cohérentes.
EN: Specification of conventions (language, notations, models) to construct coherent views.
Réf. : ISO/IEC/IEEE 42010.
- Priorisation des exigences / Requirements Prioritization
-
Classement des exigences selon la valeur, le risque et la faisabilité pour orienter les décisions.
EN: Ranking requirements by value, risk, and feasibility to guide decisions.
Réf. : ISO/IEC/IEEE 29148; pratiques INCOSE.
- — Q —
- Qualité / Quality
-
Capacité d’un produit ou processus à satisfaire des exigences et attentes explicites ou implicites.
EN: Capability of a product or process to satisfy explicit or implicit requirements and expectations.
Réf. : ISO 9000; ISO/IEC/IEEE 15288.
- — R —
- Réalisation / Realization
-
Transformation des éléments de conception en solution implémentée et intégrée.
EN: Transformation of design elements into an implemented and integrated solution.
Réf. : ISO/IEC/IEEE 15288.
- Architecture de référence / Reference Architecture
-
Modèle d’architecture réutilisable pour une famille de systèmes, promouvant cohérence et standardisation.
EN: Reusable architectural model for a family of systems, promoting consistency and standardization.
Réf. : ISO/IEC/IEEE 42010; INCOSE.
- Élicitation des exigences / Requirements Elicitation
-
Activités visant à découvrir, analyser et clarifier besoins et contraintes auprès des parties prenantes.
EN: Activities to discover, analyze, and clarify needs and constraints with stakeholders.
Réf. : ISO/IEC/IEEE 29148.
- Risque / Risk
-
Effet de l’incertitude sur les objectifs (négatif ou opportunité), caractérisé par probabilité et impact.
EN: Effect of uncertainty on objectives (negative or opportunity), characterized by likelihood and impact.
Réf. : ISO 31000.
- — S —
- Scénario / Scenario
-
Séquence d’événements décrivant un comportement du système dans un contexte donné.
EN: Sequence of events describing system behavior in a given context.
Réf. : INCOSE; SysML séquences.
- Simulation / Simulation
-
Exécution d’un modèle pour étudier les comportements et performances et soutenir la décision.
EN: Executing a model to study behaviors and performance and support decision-making.
Réf. : INCOSE SEBoK.
- Spécification / Specification
-
Document ou modèle rassemblant exigences et contraintes applicables à une entité donnée.
EN: Document or model assembling requirements and constraints applicable to a given entity.
Réf. : ISO/IEC/IEEE 29148.
- Besoins des parties prenantes / Stakeholder Needs
-
Expression structurée des attentes des parties prenantes, base de l’ingénierie des exigences.
EN: Structured expression of stakeholder expectations, the basis for requirements engineering.
Réf. : ISO/IEC/IEEE 29148.
- Système / System
-
Ensemble d’éléments interagissant pour atteindre un objectif commun dans un contexte défini.
EN: Set of interacting elements organized to achieve a common purpose in a defined context.
Réf. : ISO/IEC/IEEE 15288; INCOSE.
- SysML / SysML OMG
-
Langage de modélisation pour l’ingénierie système (blocs, exigences, activités, états, séquences, paramétrique).
EN: Modeling language for systems engineering (blocks, requirements, activities, states, sequences, parametrics).
Réf. : OMG SysML v1/v2.
- — T —
- Traçabilité / Traceability
-
Capacité à relier bidirectionnellement besoins, exigences, modèles, tests et décisions.
EN: Ability to bidirectionally link needs, requirements, models, tests, and decisions.
Réf. : ISO/IEC/IEEE 15288; 29148.
- Cas de test / Test Case
-
Ensemble de conditions, entrées et résultats attendus pour évaluer une exigence ou une fonction.
EN: Set of conditions, inputs, and expected results to assess a requirement or function.
Réf. : Bonnes pratiques VV; ISO/IEC/IEEE 15288.
- — U —
- Utilisabilité (Ergonomie) / Usability
-
Degré selon lequel un système peut être utilisé avec efficacité, efficience et satisfaction par des utilisateurs ciblés.
EN: The degree to which a system can be used effectively, efficiently, and satisfactorily by target users.
Réf. : ISO 9241-11; exigences non fonctionnelles.
- — V —
- Validation / Validation
-
Le système répond-il aux besoins et à l’usage prévu ?
EN: Does the system meet stakeholder needs and intended use?
Réf. : ISO/IEC/IEEE 15288.
- Vérification / Verification
-
Le système a-t-il été construit correctement conformément aux exigences ?
EN: Was the system built right according to the specified requirements?
Réf. : ISO/IEC/IEEE 15288.
- Versionnage / Versioning
-
Gestion des versions d’artefacts pour tracer l’historique et les écarts entre versions.
EN: Managing artifact versions to track history and differences between versions.
Réf. : Gestion de configuration; ISO 10007.
- Vue / View
-
Représentation d’un système selon un point de vue particulier (fonctionnel, logique, physique, etc.).
EN: Representation of a system from a specific viewpoint (functional, logical, physical, etc.).
Réf. : ISO/IEC/IEEE 42010.
- — W —
- Structure de découpage du travail (SDT/WBS) / Work Breakdown Structure
-
Décomposition hiérarchique du travail du projet en lots maîtrisables et planifiables.
EN: Hierarchical decomposition of project work into manageable, plannable packages.
Réf. : PMI; ISO 21502; lien avec SE pour l’alignement exigences-lots.
- — X —
Pas d’entrée pour le moment.
- — Y —
Pas d’entrée pour le moment.
- — Z —
Pas d’entrée pour le moment.