|
Architecture du système (System architecture): Concepts ou propriétés fondamentales d’un système dans son environnement, inclus dans ses éléments constitutifs et dans les principes de sa conception et de son évolution (traduction de ISO/IEC 42010). L’architecture d’un système est définie à l’aide de plusieurs vues; typiquement une vue fonctionnelle, une vue comportementale, une vue temporelle, une vue physique ou organique, et d’autres vues optionnelles. |
| Architecture logique (Logical Architecture): Ensemble des vues ou architectures fonctionnelle, comportementale et temporelle d’un système. Ce terme est la contraction de “Vue logique de l’architecture du système”. |
| Architecture fonctionnelle (Functional Architecture): Ensemble des fonctions et de leurs sous fonctions qui définit les transformations d’entrées en sorties exécutées par le système pour accomplir sa mission. Ce terme est la contraction de “Vue fonctionnelle de l’architecture du système”. |
| Architecture comportementale (Behavioural Architecture): Structure ou arrangement des fonctions, de leurs sous fonctions et de leurs interfaces internes et externes qui définit la séquence d’exécution, les conditions du contrôle du flux des fonctions et des flux d’entrées sorties, et les performances pour satisfaire le référentiel des exigences techniques du système. (Adapté de ISO/IEC 26702). Ce terme est la contraction de “Vue comportementale de l’architecture du système”. |
| Architecture temporelle (Temporal Architecture): Classification temporelle des fonctions du système selon leur fréquence d’exécution. L’architecture temporelle inclut les aspects synchrones et asynchrones des fonctions. Le mécanisme de contrôle des décisions à l’intérieur du système suit la même classification temporelle, car les décisions sont liées au contrôle des fonctions. Ce terme est la contraction de “Vue temporelle de l’architecture du système”. |
| Architecture physique ou organique (Physical Architecture): Structure ou arrangement des constituants physiques du système et de leur liens physiques décrivant la solution conçue d’un système (produit, service, organisation), qui satisfait l’architecture logique et le référentiel des exigences techniques. (Adapté de ISO/IEC 26702 = ISO/IEC 24748-4). Ce terme est la contraction de “Vue physique de l’architecture du système”. |
| Architecturer le système (System architecting): Manipulation délibérée de structures pour établir le comportement et les propriétés souhaités d’un système. (Traduction de MIT-ESD) |
| Besoin (Need): Nécessité ou désir attendu par un utilisateur final, exprimé dans les termes d’un client, d’un utilisateur final ; service, objectif, capacité attendu du futur système par les utilisateurs finaux. Equivalent à “attente” ; inclut les exigences des utilisateurs. Un besoin peut ne pas être exprimé ou écrit formellement. |
| Concept opérationnel (Operational Concept): Une description générale de la façon dont un produit ou service ou une organisation est utilisé ou exploité. |
|
Conception du systeme (System Design): La conception du système est l’ensemble des activités pour concevoir un système qui répond à une finalité, en utilisant des principes et des concepts ; elle inclut les évaluations et les décisions de choix des éléments qui composent le système, qui correspondent à l’architecture du système, et qui satisfont les exigences du système négociées et acceptées. La conception du système est l’ensemble complet des modèles détaillés, des propriétés ou caractéristiques décrits sous une forme appropriée à la réalisation (construction physique). |
| Constituant (System Element): (1) Un membre de l’ensemble des éléments qui constituent un système. Un constituant est une partie discrète et concrète du système qui peut être réalisée pour satisfaire des propriétés de conception. Un constituant peut être du matériel, du logiciel, des données, des opérateurs humains, des processus (par exemple des processus pour fournir un service aux utilisateurs), des procédures (par exemple des instructions opérateur), des équipements ou installations d’infrastructure, des matériaux, et des éléments naturels (par exemple: eau, végétaux, minéraux), ou n’importe quelle combinaison de ces éléments. (Adapté de ISO/IEC 15288:2008). (2) Terme générique utilisé pour le système étudié, un système, un constituant. Un élément physique (rôle utilisateur ou opérateur, matériel, logiciel) qui compose un système. Un constituant peut être vu à son tour comme un système (i.e. sous système) et être développé dans un bloc système de niveau inférieur. |
| Contrainte (Constraint): (1) Exigence qui induit une limitation (physique, temporelle, économique) pour la conception d’un système. (2) Un type d’exigence ou de caractéristique de conception qui ne peut pas être négociée. (Traduction de ANSI/EIA 632) |
|
Exigence (Requirement): Expression d’un besoin ou d’une contrainte sous forme d’un langage (naturel, informatique, graphique, mathématique). Expression qui identifie une caractéristique attendue fonctionnelle, opérationnelle, contrainte d’un système (produit, service, organisation ou processus) qui est non ambiguë, vérifiable ou mesurable, et nécessaire pour l’acceptation du produit, service, organisation ou processus. (adapté de ISO/IEC 26702 = ISO/IEC 24748-4) |
| Exigence de partie prenante (Stakeholder Requirement): Nécessité ou désir attendu par un utilisateur final écrit formellement et exprimé dans les termes d’un client, d’un utilisateur final ; service, objectif, capacité attendu du futur système par les utilisateurs finaux. Equivalent à “attente” ; inclut les exigences des utilisateurs. |
| Exigence du système (System Requirement): (1) Exigence applicable à un système ; voir exigence. (2) Une proposition qui convertit une exigence de partie prenante en termes techniques utilisables pour les activités d’architecture et de conception en utilisant un code sémantique (langage naturel, expression mathématique, arithmétique, géométrique, langage de programmation, etc.). |
| Ingénierie (Engineering): L’application de connaissances scientifiques à des problèmes pratiques, ou à la création de choses utiles. Les domaines traditionnels de l’ingénierie mécanique, l’ingénierie électrique, etc. sont inclus dans cette définition. (Checkland, P. B. 1999) |
| Ingénierie de système (Systems Engineering): Application de la science des systèmes (principes, lois, règles) via un ensemble d’activités définies dans le but de répondre à des problèmes pratiques complexes, ou à la création d’opportunités, en structurant des concepts et en les réalisant. |
| Ingénierie des exigences (Requirements Engineering): Sous ensemble de l’ingénierie de système concernant la recherche, le développement, l’analyse, la validation, la communication et la gestion des exigences. (ISO/IEC 29148) |
| Interface (Interface): Généralement une interface inclut des éléments fonctionnels et physiques. Interfaces fonctionnelle et physique sont distinctes. |
| Interface physique (Physical Interface): Une interface physique est un constituant qui relie physiquement deux constituants. |
| Partie prenante (Stakeholder): Partie ayant un droit, une part ou une demande dans un système ou une de ses caractéristiques qui satisfait les besoins et attentes de cette partie (ISO/IEC 15288:2008). N.B.: Les parties prenantes peuvent être, mais non limité à cette liste, des utilisateurs finaux, des organisations destinatrices, des mainteneurs, développeurs, producteurs, formateurs, responsable de maintenance, de retrait de service, des clients, des opérateurs, des fournisseurs, des certifieurs. (ISO/IEC 29148) |
|
Système de systèmes (System of Systems): Un assemblage de constituants qui peuvent être vus individuellement comme des systèmes, et qui possèdent deux propriétés supplémentaires: – Indépendance opérationnelle des constituants système : si le système de systèmes est désassemblé en ses constituants système, ces constituants système doivent être capables de fonctionner indépendamment ; c’est à dire, le constituant système remplit sa mission par lui-même. – Indépendance managériale des constituants système: les constituants système peuvent fonctionner de façon dépendante mais aussi de façon indépendante ; les constituants système sont acquis et intégrés séparément, et ils maintiennent une existence opérationnelle continue indépendamment du système de systèmes. (Marc Maier 2009) |
| Processus d’analyse d’opportunités et de mission – Analyse d’une situation présente, identification des problèmes et/ou opportunités, définition de concepts opérationnels et/ou techniques supportés par un système potentiel, identification et analyse des éléments du contexte d’utilisation de ce système. |
| Processus de définition des besoins des parties prenantes du système – Identification de toutes les parties prenantes et définition formalisée de leurs besoins, exigences et contraintes applicables au futur système. |
| Processus de définition des exigences du système – Analyse et traduction des besoins des parties prenantes en exigences techniques (caractéristiques attendues) ; définition des exigences cohérentes et exhaustives du système, incluant les exigences induites par la solution conçue. |
| Processus de définition de l’architecture logique du système – Définition des éléments constitutifs des architectures ou vues fonctionnelle, comportementale, temporelle (fonctions, flux d’entrée-sortie, modes, transitions, déclencheurs, etc.) du système et de leur arrangement répondant à l’ensemble des exigences techniques fonctionnelles et comportementales. |
| Processus de définition de l’architecture physique du système – Définition des éléments constitutifs de l’architecture ou vue physique (constituants, interfaces physiques, connecteurs, etc.) du système et de leur arrangement répondant à l’architecture logique et à l’ensemble des exigences techniques non fonctionnelles et comportementales. |
| Processus d’analyse système (processus d’évaluation des propriétés du système) – Évaluations et choix des données d’ingénierie, en particulier des solutions architecturales et de leurs éléments, pour le meilleur équilibre entre l’ensemble des propriétés du système dont l’efficacité (performance, sûreté, sécurité, etc.), les coûts, les délais, les contraintes, les risques. |
| Processus d’intégration du système – Assemblage par agrégats et vérifications pour construire le système (produit, service, organisation, processus) à partir de ses constituants technologiques physiques. |
| Processus de validation du système – Confirmation que le système satisfait ses exigences techniques et les besoins des parties prenantes. |
| Processus de vérification du système – Confirmation que le système est conforme à ses caractéristiques d’architecture et de conception. |
| DOCUMENT DES BESOINS DES PARTIES PRENANTES SYSTEME (DBSys) – Contient l’ensemble des besoins, attentes, contraintes formalisées de toutes les parties prenantes du système. |
| DOCUMENT DES EXIGENCES TECHNIQUES SYSTEME (DESys) – Contient l’ensemble complet et cohérent des exigences techniques formalisées, quantifiées, vérifiables, applicables au systeme et qui traduisent le besoin en terme de fonctions, d’interfaces, de contraintes, d’opérations, de performances, etc. |
| DOCUMENT DES EXIGENCES D’INTERFACE SYTEME (DISys) – Regroupe toutes les exigences d’interface entre le système et les éléments de son contexte d’utilisation. |
| DOSSIER DE CONCEPTION DU SYSTÈME (DCSys) – Décrit les caractéristiques de la solution sous forme d’architecture ou vue logique, d’architecture ou vue physique, d’interfaces, de performances attendues, etc. |
| DOSSIER JUSTIFICATIF DU SYSTÈME (DJSys) – Contient les preuves que les vérifications, validations, justifications d’un système ont été effectuées; la justification des choix, les démonstrations, les résultats de simulation et d’essais, la trace amont et aval des exigences, etc. |
| PLAN D’INTÉGRATION ET DE VALIDATION DU SYSTÈME (PIVSys) – Décrit la démarche d’assemblage des constituants d’un système, ainsi que les moyens, conditions et résultats attendus des essais pour valider le système par rapport à ses exigences. |
| (System) Architecture: Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. (ISO/IEC 42010) – A system architecture is defined through several views, typically a functional view, a behavioural view, a temporal view, a physical view and other optional views. |
| (System) Architecting: The deliberate manipulation of structure to achieve desired system behaviour and properties. (MIT-ESD). |
| Behavioural Architecture: An arrangement of functions and their sub-functions and interfaces (internal and external) which defines the execution sequencing, conditions for control or data-flow and the performance requirements to satisfy the requirements baseline. (Adapted from ISO/IEC 26702).This term is the contraction of “Behavioural view of the system Architecture”. |
| Constraint: (1) A restriction, limit, or regulation imposed on a product, project, or process. (2) A type of requirement or design feature that cannot be traded off. (ANSI/EIA 632) |
|
(System) Design: (System) Design includes activities to conceive a system that answers an intended purpose, using principles and concepts; it includes assessments and decisions to select elements that compose the system, fit the architecture of the system, and comply traded-off System Requirements. (System) Design is the complete set of detailed models, properties or characteristics described into a form suitable for implementation. |
| Engineering: The application of scientific knowledge to practical problems, or the creation of useful things. The traditional fields of mechanical engineering, electrical engineering, etc. are included in this definition. (Checkland, P. B. 1999) |
| Functional Architecture: A set of functions and their sub-functions that defines the transformations of input flows into output flows performed by the system to achieve its mission. This term is the contraction of “Functional view of the system Architecture”. |
| Interface: An interface includes generally both functional and physical elements. Functional and physical interfaces are distinct. |
| Logical Architecture: The set of Functional view/Architecture, Behavioural view/Architecture and Temporal view/Architecture of a system. This term is the contraction of “Logical view of the system Architecture”. |
| Need: Necessity or desire expected by an “end user”, expressed in terms of a client, of an end user; service, objective, capability expected from the future system by the end users. Equivalent to expectation; includes user requirements. A need could not be formally expressed or drafted. |
| Operational Concept: A general description of the way in which a product or service or enterprise (organization) is used or operates. |
| Physical Architecture: An arrangement of physical elements, which provides the designed solution for a product, a service, an organization or an enterprise, intended to satisfy the logical architecture and the requirement baseline. (Adapted from ISO/IEC 26702 = ISO/IEC 24748-4) – This term is the contraction of “Physical view of the system Architecture”. |
| Physical Interface: A physical interface is a System Element that binds physically two System Elements. |
| Requirement: Statement that identifies an expected characteristic of a product, service, enterprise or process operational, functional, or constraint, which is unambiguous, testable or measurable, and necessary for product, service, enterprise or process acceptability. (adapted from ISO/IEC 26702 = ISO/IEC 24748-4) |
| Requirements Engineering: Subset of systems engineering concerned with discovering, developing, analysing, validating, communicating and managing requirements.” (ISO/IEC 29148) |
| Stakeholder: Party having a right, share or claim in a system or in its possession of characteristics that meets that party’s needs and expectations (ISO/IEC 15288:2008). N.B.: Stakeholders include, but are not limited to end users, end user organizations, supporters, developers, producers, trainers, maintainers, disposers, acquirers, customers, operators, supplier organizations and regulatory bodies. (ISO/IEC 29148) |
| Stakeholder Requirement: Necessity or desire expected by an end user, formally drafted and expressed in terms of a client, of and end user; service, objective, capability expected from the future system by the end users. Equivalent to expectation; includes user requirements. |
| System Element (component): (1) A member of a set of elements that constitutes a system. A system element is a discrete part of a system that can be implemented to fulfil design properties. A system element can be hardware, software, data, humans, processes (e.g., processes for providing service to users), procedures (e.g., operator instructions), facilities, materials, and naturally occurring entities (e.g., water, organisms, minerals), or any combination. (Adapted from ISO/IEC 15288:2008) (2) (Generic term used for System of Interest, system, System Element) A physical element (user or operator role, hardware, software) that composes a system. A system element may be seen in its turn as a system (i.e. sub-system) and be engineered in a system block at lower level. |
|
System of Systems: An assemblage of components which individually may be regarded as systems, and which possess two additional properties: – Operational Independence of the Components: if the system-of-systems is disassembled into its component systems the component systems must be able to usefully operate independently; that is, the components fulfil customer-operator purposes on their own. – Managerial Independence of the Components: the component systems not only can operate dependently, they do operate independently; the component systems are separately acquired and integrated but maintain a continuing operational existence independent of the system-of-systems. (Marc MAIER 2009) |
| System Requirement: (1) Requirement applicable to a system; see requirement. (2) A statement that converts a stakeholder requirement into technical, usable terms for architectural and design activities using a semantic code (natural language, mathematical express, arithmetic, geometric, or software language, etc.). |
| System(s) Engineering: The application of systems science (principles, rules, laws) through a set of defined activities to answer complex practical problems or opportunities creating, arranging concepts and implementing them. |
| Temporal Architecture: A temporal classification of the functions of the system depending on their frequency level of execution. The temporal architecture includes definition of synchronous and asynchronous aspects of functions. The decision monitoring inside a system follows the same temporal classification as decisions are related to monitoring of functions. This term is the contraction of “Temporal view of the system Architecture”. |
| Opportunities and Mission Analysis Process – Analysis of a current situation, identification of issues, problems and/or opportunities, definition of operational and/or technical concepts supported by a potential system of interest, identification and analysis of the elements of the context of use of this system of interest |
| System Stakeholder Requirements Definition Process – Identification of all stakeholders and formalized definition of their needs, expectations, requirements and constraints applicable to the expected system |
| System Requirements Definition Process – Analysis and translation of stakeholder requirements into technical system requirements (expected characteristics), definition of consistent, exhaustive set of system requirements, including requirements derived from the designed solution. |
| System Logical Architecture Definition Process – Definition of the elements constituting the functional, behavioral, temporal views or architectures of the system (functions, input-output flows, modes, transitions, triggers, etc.), and of their arrangement, satisfying the set of functional and behavioral requirements |
| System Physical Architecture Definition Process – Definition of the elements constituting the physical view or architecture of the system (system elements/components, physical interfaces, connectors, etc.), and of their arrangement fitting the logical architecture and satisfying the set of non-functional and non-behavioral requirements |
| System Analysis Process (system properties assessment process) – Assessment and selection of engineering data, in particular of architectural solutions and of their elements, to achieve the best balance between the set of system properties including effectiveness (performance, safety, security, etc.), costs, schedule, constraints, risks. |
| System Integration Process – Assembly of aggregates and verifications to build the system (product, service, enterprise, process) from its physical components (technological system elements) |
| System Validation Process – Confirmation that the system satisfies its system technical requirements and its stakeholder requirements |
| System Verification Process – Confirmation that the system satisfies its architectural and designed characteristics |
| SYSTEM STAKEHOLDER REQUIREMENTS DOCUMENT (SysStkRD) – Contains the formalized needs, expectations, constraints (called stakeholder requirements) of all stakeholders applicable to the system |
| SYSTEM REQUIREMENTS DOCUMENT (SysRD) – Contains the set of exhaustive, consistent, quantified and verifiable requirements applicable to the system, which translate the stakeholder requirements in terms of functions, interfaces, constraints, operational conditions, performances, etc. |
| SYSTEM INTERFACE REQUIREMENTS DOCUMENT (SysIRD) – Gather all interface requirements between the system and the elements of its context of use |
| SYSTEM DESIGN DOCUMENT (SysDD) – Describe the characteristics of the solution as a set of logical and physical views or architectures, including interfaces, performances, and all other design properties |
| SYSTEM JUSTIFICATION DOCUMENT (SysJD) – Contains evidence that verification, validation, justification actions have been made, rationales for selection, demonstrations, simulation and tests results, upwards and downwards traceability, etc. |
| SYSTEM INTEGRATION AND VALIDATION PLAN (SysIVP) – Describe the assembly of system elements/components approach, as well as means, conditions and expected tests results in order to validate the system (product, service, enterprise, process) against its requirements. |