{"id":59,"date":"2011-08-23T20:41:50","date_gmt":"2011-08-23T19:41:50","guid":{"rendered":"http:\/\/cluster010.ovh.net\/~mapsyste\/?page_id=59"},"modified":"2021-08-23T21:35:19","modified_gmt":"2021-08-23T20:35:19","slug":"glossaire","status":"publish","type":"page","link":"https:\/\/mapsysteme.com\/en\/glossaire\/","title":{"rendered":"Glossary"},"content":{"rendered":"

<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
QUELQUES TERMES TECHNIQUES<\/caption>\n
\n

Architecture du syst\u00e8me (System architecture)<\/strong>: Concepts ou propri\u00e9t\u00e9s fondamentales d\u2019un syst\u00e8me dans son environnement, inclus dans ses \u00e9l\u00e9ments constitutifs et dans les principes de sa conception et de son \u00e9volution (traduction de ISO\/IEC 42010).<\/p>\n

L\u2019architecture d\u2019un syst\u00e8me est d\u00e9finie \u00e0 l\u2019aide de plusieurs vues; typiquement une vue fonctionnelle, une vue comportementale, une vue temporelle, une vue physique ou organique, et d\u2019autres vues optionnelles.<\/p>\n<\/td>\n<\/tr>\n

Architecture logique (Logical Architecture)<\/strong>:\u00a0Ensemble des vues ou architectures fonctionnelle, comportementale et temporelle d\u2019un syst\u00e8me. Ce terme est la contraction de \u201cVue logique de l\u2019architecture du syst\u00e8me\u201d.<\/td>\n<\/tr>\n
Architecture fonctionnelle (Functional Architecture)<\/strong>: Ensemble des fonctions et de leurs sous fonctions qui d\u00e9finit les transformations d\u2019entr\u00e9es en sorties ex\u00e9cut\u00e9es par le syst\u00e8me pour accomplir sa mission. Ce terme est la contraction de \u201cVue fonctionnelle de l\u2019architecture du syst\u00e8me\u201d.<\/td>\n<\/tr>\n
Architecture comportementale (Behavioural Architecture)<\/strong>: Structure ou arrangement des fonctions, de leurs sous fonctions et de leurs interfaces internes et externes qui d\u00e9finit la s\u00e9quence d\u2019ex\u00e9cution, les conditions du contr\u00f4le du flux des fonctions et des flux d\u2019entr\u00e9es sorties, et les performances pour satisfaire le r\u00e9f\u00e9rentiel des exigences techniques du syst\u00e8me. (Adapt\u00e9 de ISO\/IEC 26702). Ce terme est la contraction de \u201cVue comportementale de l\u2019architecture du syst\u00e8me\u201d.<\/td>\n<\/tr>\n
Architecture temporelle (Temporal Architecture)<\/strong>: Classification temporelle des fonctions du syst\u00e8me selon leur fr\u00e9quence d\u2019ex\u00e9cution. L\u2019architecture temporelle inclut les aspects synchrones et asynchrones des fonctions. Le m\u00e9canisme de contr\u00f4le des d\u00e9cisions \u00e0 l\u2019int\u00e9rieur du syst\u00e8me suit la m\u00eame classification temporelle, car les d\u00e9cisions sont li\u00e9es au contr\u00f4le des fonctions.\u00a0Ce terme est la contraction de \u201cVue temporelle de l\u2019architecture du syst\u00e8me\u201d.<\/td>\n<\/tr>\n
Architecture physique ou organique (Physical Architecture)<\/strong>: Structure ou arrangement des constituants physiques du syst\u00e8me et de leur liens physiques d\u00e9crivant la solution con\u00e7ue d\u2019un syst\u00e8me (produit, service, organisation), qui satisfait l\u2019architecture logique et le r\u00e9f\u00e9rentiel des exigences techniques. (Adapt\u00e9 de ISO\/IEC 26702 = ISO\/IEC 24748-4). Ce terme est la contraction de \u201cVue physique de l\u2019architecture du syst\u00e8me\u201d.<\/td>\n<\/tr>\n
Architecturer le syst\u00e8me (System architecting)<\/strong>: Manipulation d\u00e9lib\u00e9r\u00e9e de structures pour \u00e9tablir le comportement et les propri\u00e9t\u00e9s souhait\u00e9s d\u2019un syst\u00e8me. (Traduction de MIT-ESD)<\/td>\n<\/tr>\n
Besoin (Need)<\/strong><\/strong>: N\u00e9cessit\u00e9 ou d\u00e9sir attendu par un utilisateur final, exprim\u00e9 dans les termes d\u2019un client, d\u2019un utilisateur final ; service, objectif, capacit\u00e9 attendu du futur syst\u00e8me par les utilisateurs finaux. Equivalent \u00e0 \u201cattente\u201d ; inclut les exigences des utilisateurs. Un besoin peut ne pas \u00eatre exprim\u00e9 ou \u00e9crit formellement.<\/td>\n<\/tr>\n
Concept op\u00e9rationnel (Operational Concept)<\/span><\/strong>: Une description g\u00e9n\u00e9rale de la fa\u00e7on dont un produit ou service ou une organisation est utilis\u00e9 ou exploit\u00e9.<\/span><\/td>\n<\/tr>\n
\n

Conception du systeme (System Design)<\/strong><\/strong>: La conception du syst\u00e8me est l\u2019ensemble des activit\u00e9s pour concevoir un syst\u00e8me qui r\u00e9pond \u00e0 une finalit\u00e9, en utilisant des principes et des concepts ; elle inclut les \u00e9valuations et les d\u00e9cisions de choix des \u00e9l\u00e9ments qui composent le syst\u00e8me, qui correspondent \u00e0 l\u2019architecture du syst\u00e8me, et qui satisfont les exigences du syst\u00e8me n\u00e9goci\u00e9es et accept\u00e9es.<\/p>\n

La conception du syst\u00e8me est l\u2019ensemble complet des mod\u00e8les d\u00e9taill\u00e9s, des propri\u00e9t\u00e9s ou caract\u00e9ristiques d\u00e9crits sous une forme appropri\u00e9e \u00e0 la r\u00e9alisation (construction physique).<\/p>\n<\/td>\n<\/tr>\n

Constituant (System Element)<\/strong>: (1) Un membre de l\u2019ensemble des \u00e9l\u00e9ments qui constituent un syst\u00e8me. Un constituant est une partie discr\u00e8te et concr\u00e8te du syst\u00e8me qui peut \u00eatre r\u00e9alis\u00e9e pour satisfaire des propri\u00e9t\u00e9s de conception. Un constituant peut \u00eatre du mat\u00e9riel, du logiciel, des donn\u00e9es, des op\u00e9rateurs humains, des processus (par exemple des processus pour fournir un service aux utilisateurs), des proc\u00e9dures (par exemple des instructions op\u00e9rateur), des \u00e9quipements ou installations d\u2019infrastructure, des mat\u00e9riaux, et des \u00e9l\u00e9ments naturels (par exemple: eau, v\u00e9g\u00e9taux, min\u00e9raux), ou n\u2019importe quelle combinaison de ces \u00e9l\u00e9ments. (Adapt\u00e9 de ISO\/IEC 15288:2008).\u00a0(2) Terme g\u00e9n\u00e9rique utilis\u00e9 pour le syst\u00e8me \u00e9tudi\u00e9, un syst\u00e8me, un constituant. Un \u00e9l\u00e9ment physique (r\u00f4le utilisateur ou op\u00e9rateur, mat\u00e9riel, logiciel) qui compose un syst\u00e8me. Un constituant peut \u00eatre vu \u00e0 son tour comme un syst\u00e8me (i.e. sous syst\u00e8me) et \u00eatre d\u00e9velopp\u00e9 dans un bloc syst\u00e8me de niveau inf\u00e9rieur.<\/td>\n<\/tr>\n
Contrainte (Constraint)<\/strong>: (1) Exigence qui induit une limitation (physique, temporelle, \u00e9conomique) pour la conception d\u2019un syst\u00e8me.\u00a0(2) Un type d\u2019exigence ou de caract\u00e9ristique de conception qui ne peut pas \u00eatre n\u00e9goci\u00e9e. (Traduction de ANSI\/EIA 632)<\/td>\n<\/tr>\n
\n

Exigence (Requirement)<\/strong>: Expression d\u2019un besoin ou d\u2019une contrainte sous forme d\u2019un langage (naturel, informatique, graphique, math\u00e9matique).<\/p>\n

Expression qui identifie une caract\u00e9ristique attendue fonctionnelle, op\u00e9rationnelle, contrainte d\u2019un syst\u00e8me (produit, service, organisation ou processus) qui est non ambigu\u00eb, v\u00e9rifiable ou mesurable, et n\u00e9cessaire pour l\u2019acceptation du produit, service, organisation ou processus. \u00a0(adapt\u00e9 de ISO\/IEC 26702 = ISO\/IEC 24748-4)<\/p>\n<\/td>\n<\/tr>\n

Exigence de partie prenante (Stakeholder Requirement)<\/strong>: N\u00e9cessit\u00e9 ou d\u00e9sir attendu par un utilisateur final \u00e9crit formellement et exprim\u00e9 dans les termes d\u2019un client, d\u2019un utilisateur final ; service, objectif, capacit\u00e9 attendu du futur syst\u00e8me par les utilisateurs finaux. Equivalent \u00e0 \u201cattente\u201d ; inclut les exigences des utilisateurs.<\/td>\n<\/tr>\n
Exigence du syst\u00e8me (System Requirement)<\/strong>: (1) Exigence applicable \u00e0 un syst\u00e8me ; voir exigence.\u00a0(2) Une proposition qui convertit une exigence de partie prenante en termes techniques utilisables pour les activit\u00e9s d\u2019architecture et de conception en utilisant un code s\u00e9mantique (langage naturel, expression math\u00e9matique, arithm\u00e9tique, g\u00e9om\u00e9trique, langage de programmation, etc.).<\/td>\n<\/tr>\n
Ing\u00e9nierie (Engineering)<\/strong><\/strong>: L\u2019application de connaissances scientifiques \u00e0 des probl\u00e8mes pratiques, ou \u00e0 la cr\u00e9ation de choses utiles. Les domaines traditionnels de l\u2019ing\u00e9nierie m\u00e9canique, l\u2019ing\u00e9nierie \u00e9lectrique, etc. sont inclus dans cette d\u00e9finition. (Checkland, P. B. 1999)<\/td>\n<\/tr>\n
Ing\u00e9nierie de syst\u00e8me (Systems Engineering)<\/strong><\/strong>: Application de la science des syst\u00e8mes (principes, lois, r\u00e8gles) via un ensemble d\u2019activit\u00e9s d\u00e9finies dans le but de r\u00e9pondre \u00e0 des probl\u00e8mes pratiques complexes, ou \u00e0 la cr\u00e9ation d\u2019opportunit\u00e9s, en structurant des concepts et en les r\u00e9alisant.<\/td>\n<\/tr>\n
Ing\u00e9nierie des exigences (Requirements Engineering)<\/strong>: Sous ensemble de l\u2019ing\u00e9nierie de syst\u00e8me concernant la recherche, le d\u00e9veloppement, l\u2019analyse, la validation, la communication et la gestion des exigences. (ISO\/IEC 29148)<\/td>\n<\/tr>\n
Interface (Interface)<\/strong>: G\u00e9n\u00e9ralement une interface inclut des \u00e9l\u00e9ments fonctionnels et physiques. Interfaces fonctionnelle et physique sont distinctes.<\/td>\n<\/tr>\n
Interface physique (Physical Interface)<\/strong>: Une interface physique est un constituant qui relie physiquement deux constituants.<\/td>\n<\/tr>\n
Partie prenante (Stakeholder)<\/strong>: Partie ayant un droit, une part ou une demande dans un syst\u00e8me ou une de ses caract\u00e9ristiques qui satisfait les besoins et attentes de cette partie (ISO\/IEC 15288:2008). N.B.: Les parties prenantes peuvent \u00eatre, mais non limit\u00e9 \u00e0 cette liste, des utilisateurs finaux, des organisations destinatrices, des mainteneurs, d\u00e9veloppeurs, producteurs, formateurs, responsable de maintenance, de retrait de service, des clients, des op\u00e9rateurs, des fournisseurs, des certifieurs. (ISO\/IEC 29148)<\/td>\n<\/tr>\n
\n

Syst\u00e8me de syst\u00e8mes (System of Systems)<\/strong>: Un assemblage de constituants qui peuvent \u00eatre vus individuellement comme des syst\u00e8mes, et qui poss\u00e8dent deux propri\u00e9t\u00e9s suppl\u00e9mentaires:<\/p>\n

– Ind\u00e9pendance op\u00e9rationnelle des constituants syst\u00e8me : si le syst\u00e8me de syst\u00e8mes est d\u00e9sassembl\u00e9 en ses constituants syst\u00e8me, ces constituants syst\u00e8me doivent \u00eatre capables de fonctionner ind\u00e9pendamment ; c\u2019est \u00e0 dire, le constituant syst\u00e8me remplit sa mission par lui-m\u00eame.<\/p>\n

– Ind\u00e9pendance manag\u00e9riale des constituants syst\u00e8me: les constituants syst\u00e8me peuvent fonctionner de fa\u00e7on d\u00e9pendante mais aussi de fa\u00e7on ind\u00e9pendante ; les constituants syst\u00e8me sont acquis et int\u00e9gr\u00e9s s\u00e9par\u00e9ment, et ils maintiennent une existence op\u00e9rationnelle continue ind\u00e9pendamment du syst\u00e8me de syst\u00e8mes. (Marc Maier 2009)<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n\n\n\n\n\n\n\n
QUELQUES PROCESSUS TECHNIQUES\u00a0<\/caption>\n
Processus d\u2019analyse d\u2019opportunit\u00e9s et de mission –\u00a0<\/strong>Analyse d\u2019une situation pr\u00e9sente, identification des probl\u00e8mes et\/ou opportunit\u00e9s, d\u00e9finition de concepts op\u00e9rationnels et\/ou techniques support\u00e9s par un syst\u00e8me potentiel, identification et analyse des \u00e9l\u00e9ments du contexte d\u2019utilisation de ce syst\u00e8me.<\/td>\n<\/tr>\n
Processus de d\u00e9finition des besoins des parties prenantes du syst\u00e8me –\u00a0<\/strong>Identification de toutes les parties prenantes et d\u00e9finition formalis\u00e9e de leurs besoins, exigences et contraintes applicables au futur syst\u00e8me.<\/td>\n<\/tr>\n
Processus de d\u00e9finition des exigences du syst\u00e8me –\u00a0<\/strong>Analyse et traduction des besoins des parties prenantes en exigences techniques (caract\u00e9ristiques attendues)\u00a0; d\u00e9finition des exigences coh\u00e9rentes et exhaustives du syst\u00e8me, incluant les exigences induites par la solution con\u00e7ue.<\/td>\n<\/tr>\n
Processus de d\u00e9finition de l\u2019architecture logique du syst\u00e8me –\u00a0<\/strong>D\u00e9finition des \u00e9l\u00e9ments constitutifs des architectures ou vues fonctionnelle, comportementale, temporelle (fonctions, flux d\u2019entr\u00e9e-sortie, modes, transitions, d\u00e9clencheurs, etc.) du syst\u00e8me et de leur arrangement r\u00e9pondant \u00e0 l\u2019ensemble des exigences techniques fonctionnelles et comportementales.<\/td>\n<\/tr>\n
Processus de d\u00e9finition de l\u2019architecture physique du syst\u00e8me –\u00a0<\/strong>D\u00e9finition des \u00e9l\u00e9ments constitutifs de l\u2019architecture ou vue physique (constituants, interfaces physiques, connecteurs, etc.) du syst\u00e8me et de leur arrangement r\u00e9pondant \u00e0 l\u2019architecture logique et \u00e0 l\u2019ensemble des exigences techniques non fonctionnelles et comportementales.<\/td>\n<\/tr>\n
Processus d\u2019analyse syst\u00e8me (processus d\u2019\u00e9valuation des propri\u00e9t\u00e9s du syst\u00e8me) –\u00a0<\/strong>\u00c9valuations et choix des donn\u00e9es d\u2019ing\u00e9nierie, en particulier des solutions architecturales et de leurs \u00e9l\u00e9ments, pour le meilleur \u00e9quilibre entre l\u2019ensemble des propri\u00e9t\u00e9s du syst\u00e8me dont l\u2019efficacit\u00e9 (performance, s\u00fbret\u00e9, s\u00e9curit\u00e9, etc.), les co\u00fbts, les d\u00e9lais, les contraintes, les risques.<\/td>\n<\/tr>\n
Processus d\u2019int\u00e9gration du syst\u00e8me –\u00a0<\/strong>Assemblage par agr\u00e9gats et v\u00e9rifications pour construire le syst\u00e8me (produit, service, organisation, processus) \u00e0 partir de ses constituants technologiques physiques.<\/td>\n<\/tr>\n
Processus de validation du syst\u00e8me –\u00a0<\/strong>Confirmation que le syst\u00e8me satisfait ses exigences techniques et les besoins des parties prenantes.<\/td>\n<\/tr>\n
Processus de v\u00e9rification du syst\u00e8me –\u00a0<\/strong>Confirmation que le syst\u00e8me est conforme \u00e0 ses caract\u00e9ristiques d\u2019architecture et de conception.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n\n\n\n\n
QUELQUES DOCUMENTS<\/caption>\n
DOCUMENT DES BESOINS DES PARTIES PRENANTES SYSTEME (DBSys) –\u00a0Contient l\u2019ensemble des besoins, attentes, contraintes formalis\u00e9es de toutes les parties prenantes du syst\u00e8me.<\/td>\n<\/tr>\n
DOCUMENT DES EXIGENCES TECHNIQUES SYSTEME (DESys) –\u00a0Contient l\u2019ensemble complet et coh\u00e9rent des exigences techniques formalis\u00e9es, quantifi\u00e9es, v\u00e9rifiables, applicables au systeme et qui traduisent le besoin en terme de fonctions, d\u2019interfaces, de contraintes, d\u2019op\u00e9rations, de performances, etc.<\/td>\n<\/tr>\n
DOCUMENT DES EXIGENCES D\u2019INTERFACE SYTEME (DISys) –\u00a0Regroupe toutes les exigences d\u2019interface entre le syst\u00e8me et les \u00e9l\u00e9ments de son contexte d\u2019utilisation.<\/td>\n<\/tr>\n
DOSSIER DE CONCEPTION DU SYST\u00c8ME (DCSys)\u00a0–\u00a0<\/strong>D\u00e9crit les caract\u00e9ristiques de la solution sous forme d\u2019architecture ou vue logique, d\u2019architecture ou vue physique, d\u2019interfaces, de performances attendues, etc.<\/td>\n<\/tr>\n
DOSSIER JUSTIFICATIF DU SYST\u00c8ME (DJSys) –\u00a0Contient les preuves que les v\u00e9rifications, validations, justifications d\u2019un syst\u00e8me ont \u00e9t\u00e9 effectu\u00e9es; la justification des choix, les d\u00e9monstrations, les r\u00e9sultats de simulation et d\u2019essais, la trace amont et aval des exigences, etc.<\/td>\n<\/tr>\n
PLAN D\u2019INT\u00c9GRATION ET DE VALIDATION DU SYST\u00c8ME (PIVSys) –\u00a0D\u00e9crit la d\u00e9marche d\u2019assemblage des constituants d\u2019un syst\u00e8me, ainsi que les moyens, conditions et r\u00e9sultats attendus des essais pour valider le syst\u00e8me par rapport \u00e0 ses exigences.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
SOME TECHNICAL TERMS<\/caption>\n
(System) Architecture:\u00a0<\/strong><\/strong>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\u00a042010) –\u00a0A system architecture is defined through several views, typically a functional view, a behavioural view, a temporal view, a physical view and other optional views.<\/span><\/td>\n<\/tr>\n
(System) Architecting:\u00a0<\/strong><\/strong>The deliberate manipulation of structure to achieve desired system behaviour and properties. (MIT-ESD).<\/td>\n<\/tr>\n
Behavioural Architecture:\u00a0<\/strong><\/strong>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 \u201cBehavioural view of the system Architecture\u201d.<\/span><\/td>\n<\/tr>\n
Constraint:\u00a0<\/strong><\/strong>(1) A restriction, limit, or regulation imposed on a product, project, or process.\u00a0(2) A type of requirement or design feature that cannot be traded off. (ANSI\/EIA\u00a0632)<\/td>\n<\/tr>\n
\n

(System) Design<\/strong>: (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.<\/p>\n

(System) Design is the complete set of detailed models, properties or characteristics described into a form suitable for implementation.<\/p>\n<\/td>\n<\/tr>\n

Engineering<\/strong><\/strong>: 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)<\/td>\n<\/tr>\n
Functional Architecture<\/strong>: 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.\u00a0This term is the contraction of \u201cFunctional view of the system Architecture\u201d.<\/td>\n<\/tr>\n
Interface<\/strong>: An interface includes generally both functional and physical elements. Functional and physical interfaces are distinct.<\/td>\n<\/tr>\n
Logical Architecture<\/strong>: The set of Functional view\/Architecture, Behavioural view\/Architecture and Temporal view\/Architecture of a system.\u00a0This term is the contraction of \u201cLogical view of the system Architecture\u201d.<\/td>\n<\/tr>\n
Need<\/strong>: <\/strong>Necessity or desire expected by an \u201cend user\u201d, 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.<\/td>\n<\/tr>\n
Operational Concept<\/strong>: A general description of the way in which a product or service or enterprise\u00a0(organization) is used or operates.<\/td>\n<\/tr>\n
Physical Architecture<\/strong>: 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) –\u00a0This term is the contraction of \u201cPhysical view of the system Architecture\u201d.<\/td>\n<\/tr>\n
Physical Interface<\/strong>: <\/strong>A physical interface is a System Element that binds physically two System Elements.<\/td>\n<\/tr>\n
Requirement<\/strong>:<\/strong> 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)<\/td>\n<\/tr>\n
Requirements Engineering<\/strong>: Subset of systems engineering concerned with discovering, developing, analysing, validating, communicating and managing requirements.\u201d (ISO\/IEC 29148)<\/td>\n<\/tr>\n
Stakeholder<\/strong>:<\/strong> Party having a right, share or claim in a system or in its possession of characteristics that meets that party\u2019s 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)<\/td>\n<\/tr>\n
Stakeholder Requirement<\/strong>: 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.<\/td>\n<\/tr>\n
System Element (component)<\/strong>: (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)\u00a0(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.<\/td>\n<\/tr>\n
\n

System of Systems<\/strong>: An assemblage of components which individually may be regarded as systems, and which possess two additional properties:<\/p>\n

– 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.<\/p>\n

– 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)<\/p>\n<\/td>\n<\/tr>\n

System Requirement<\/strong>: (1) Requirement applicable to a system; see requirement.\u00a0(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.).<\/td>\n<\/tr>\n
System(s) Engineering<\/strong><\/strong>: 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.<\/td>\n<\/tr>\n
Temporal Architecture<\/strong>: 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.\u00a0The decision monitoring inside a system follows the same temporal classification as decisions are related to monitoring of functions. This term is the contraction of \u201cTemporal view of the system Architecture\u201d.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n\n\n\n\n\n\n\n
SOME TECHNICAL PROCESSES\u00a0<\/caption>\n
Opportunities and Mission Analysis Process –\u00a0<\/strong>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<\/td>\n<\/tr>\n
System Stakeholder Requirements Definition Process –\u00a0<\/strong>Identification of all stakeholders and formalized definition of their needs, expectations, requirements and constraints applicable to the expected system<\/td>\n<\/tr>\n
System Requirements Definition Process –\u00a0<\/strong>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.<\/td>\n<\/tr>\n
System Logical Architecture Definition Process –\u00a0<\/strong>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<\/td>\n<\/tr>\n
System Physical Architecture Definition Process –\u00a0<\/strong>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<\/td>\n<\/tr>\n
System Analysis Process (system properties assessment process) –\u00a0<\/strong>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.<\/td>\n<\/tr>\n
System Integration Process –\u00a0<\/strong>Assembly of aggregates and verifications to build the system (product, service, enterprise, process) from its physical components (technological system elements)<\/td>\n<\/tr>\n
System Validation Process –\u00a0<\/strong>Confirmation that the system satisfies its system technical requirements and its stakeholder requirements<\/td>\n<\/tr>\n
System Verification Process –\u00a0<\/strong>Confirmation that the system satisfies its architectural and designed characteristics<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n\n\n\n\n\n\n
SOME DOCUMENTS<\/caption>\n
SYSTEM STAKEHOLDER REQUIREMENTS DOCUMENT (SysStkRD) –\u00a0Contains the formalized needs, expectations, constraints (called stakeholder requirements) of all stakeholders applicable to the system<\/td>\n<\/tr>\n
SYSTEM REQUIREMENTS DOCUMENT (SysRD) –\u00a0Contains 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.<\/td>\n<\/tr>\n
SYSTEM INTERFACE REQUIREMENTS DOCUMENT (SysIRD) –\u00a0Gather all interface requirements between the system and the elements of its context of use<\/td>\n<\/tr>\n
SYSTEM DESIGN DOCUMENT (SysDD) –\u00a0Describe the characteristics of the solution as a set of logical and physical views or architectures, including interfaces, performances, and all other design properties<\/td>\n<\/tr>\n
SYSTEM JUSTIFICATION DOCUMENT (SysJD) –\u00a0Contains evidence that verification, validation, justification actions have been made, rationales for selection, demonstrations, simulation and tests results, upwards and downwards traceability, etc.<\/td>\n<\/tr>\n
SYSTEM INTEGRATION AND VALIDATION PLAN (SysIVP) –\u00a0Describe 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.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

QUELQUES TERMES TECHNIQUES Architecture du syst\u00e8me (System architecture): Concepts ou propri\u00e9t\u00e9s fondamentales d\u2019un syst\u00e8me dans son environnement, inclus dans ses \u00e9l\u00e9ments constitutifs et dans les principes de sa conception et de son \u00e9volution (traduction de ISO\/IEC 42010). L\u2019architecture d\u2019un syst\u00e8me … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-59","page","type-page","status-publish","hentry"],"_links":{"self":[{"href":"https:\/\/mapsysteme.com\/en\/wp-json\/wp\/v2\/pages\/59","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mapsysteme.com\/en\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/mapsysteme.com\/en\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/mapsysteme.com\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mapsysteme.com\/en\/wp-json\/wp\/v2\/comments?post=59"}],"version-history":[{"count":35,"href":"https:\/\/mapsysteme.com\/en\/wp-json\/wp\/v2\/pages\/59\/revisions"}],"predecessor-version":[{"id":839,"href":"https:\/\/mapsysteme.com\/en\/wp-json\/wp\/v2\/pages\/59\/revisions\/839"}],"wp:attachment":[{"href":"https:\/\/mapsysteme.com\/en\/wp-json\/wp\/v2\/media?parent=59"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}