Glossary

System

A man-made integrated set of elements that are capable of decision making and thus accomplish a defined objective.

System of Interest (SOI)

The System currently being discussed, analysed, developed etc. The SOI often requires the specification of the Variant.

Ideal System

The abstract System to be built. It comprises the Operational, Functional, and Logical Architectures. The Ideal System deliberately ignores physical Constraints, as they cannot apply to (logical) Components.

Real System

The physical System to be built from real Parts that can realise the Component specifications created by the Ideal System. The Real System must comply with all physical Constraints, as they do apply to all Parts and their combinations.

Sub-System

An abstract System element that requires further analysis and development (white box for the developers).

Requirement

A documented demand to be complied with.

Component

An abstract System element that does not require further analysis and development (black box for the developers).

Part

An real System element that can be sourced by purchase - e.g. (C)OTS, reuse, or (domain-level) development.

Complexity

Complexity characterizes the behaviour of a System that is capable of varying response. Its components interact in multiple ways following local rules, leading to non-linearity, randomness, collective dynamics, hierarchy, and emergence.

Model

A Model is an informative yet abstract representation of an object. It is intended to be limited by scope and level of detail to aid understanding of defined aspects of the object it represents.

Architecture

The System Architectures describes its logical and physical organisation by a) defining elements, their responsibilities and relationships to each other; b) providing all necessary information from analysis and decision making complete with associated assumptions and rationales, respectively; and c) specifying required components and mapping them to sourced part specs.

Perspective

A defined point of view on a challenge or system. It is used to frame and reframe them in different ways, allowing new kinds of solutions to emerge

Contextual Architecture

The Architecture to analyse the challenge Context and define how Stakeholders and external Systems connect to the SOI to be.

Operational Architecture

The Architecture to analyse and define the control logic of a System (sequence, timing, alternatives, decision making, comparing data, and interpreting information).

Functional Architecture

The Architecture to analyse and define how Objects flow through the Ideal System or change State as the result of a Function.

Logical Architecture

The Architecture to analyse and define the control logic of a System (sequence, timing, alternatives, decision making, comparing data, and interpreting information).

Physical Architecture

An arrangement of physical elements and their interfaces. It provides the design solution for an Ideal System realising the Component Specifications from the Logical Architecture and satisfying physical Constraints.

Logical Interface

The control element to define and manage the properties of Object or Control Flows exchanged between two elements of the Ideal System (Sub-System or Component).

Physical Interface

The control element to define and manage the properties shared between two or more elements of the Real System (Module or Part).

Constraint

The documented expectation how to realise a specific aspect of the System, e.g. painting it red, using redundant functionalities, non-magnetic parts etc.

Hazard

Any Object Flow can go wrong and cause a Hazard. Too much of one thing, or to little of another. Or the wrong Objects flowing, or the right one, but in a wrong state etc.

Stakeholder

Anyone with a valid relationship to the challenge. This can either be an interest in or an impact on the System to be. This can be the result of physical connections exchanging objects, technical or project reasons, regulations etc.

Architectural Frameworks

Architectural Frameworks are conventions, principles and practices for the description of architectures. They typically define a number of viewpoints that stakeholders are interested in or want to discuss.

Requirement Elicitation

Requirements Elicitation is the practice of researching and discovering the Requirements of a System. Effective Requirement Elicitation employs Systems Thinking (Systematic and Systemic) to aid perspective analysis, and to define a logical process and structure in which to record and maintain the information and relationships elicited.