(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.