Relativized Systemic Origin (24-05-2024)
Relativized Systemic & applications
RS
Public work related to Relativized Systemic EngineeringThe developments we have conducted for more than 20 years have been motivated by quite pragmatic consédérations. To meet our goals, we had to root them in the most fundamental science. This has resulted in a formal method that fundamentally challenges our way of conceiving the real: the Relativized Systemic (SR). Two applications have been jointly developed in this formalism: the Relativized System Engineering (ISR) and the Relativized Information Management (MRI).
This methodological framework has shown its full potential, through the development of a MBSE platform for mechatronic systems, a platform for an Agile organization and management of Product development, and the business applications these platforms made possible. It may be regarded as a unifying framework of sciences and human goals driven constructions. It is paticularly valuable when used to develop so called “complex systems" in critical conditions, characterized by multiple stakes and massively shared resources, most often embedded-software centered.
We hereafter expose our critical and constructive approach to Sytemic and System Engineering. We consider that, to be granted a scientific character, they must get a clear standing among other disciplins and rely on a formal corpus that actually implements their principles and makes possible rigourous implementation with proven added value.
In these articles, we question acordingly the scientific character of Systemic and System Engineering, as they are exposed and practiced. As a proposal, we mention RS and RSE that have strived to overcome this deadlock and have bridged straightforwardly a gap between the most fundamental science and the most operational realizations integrating human finalities.
We address below the notion of requirement that becomes in RSE a formally constructed concept that specializes the RS concept of anticipation, and that guides conformity assessments.
The notion of requirement is omnipresent in the industry when it comes to specifying or writing specifications. It is supposed both to express the expected and to constitute a reference to assess the conformity of the realized. In the MBSE approach, the specifying models are assumed to reflect the requirements that they dynamically illustrate through simulations.
The notion of requirement, however, has a paradoxical status. A requirement is usually expressed in natural language, contextual by nature, whereas it is supposed to constitute an autonomous, unambiguous reference, for activities such as modeling or tests of conformity, which are based on mathematized foundations.
Classical System Engineering has not overcome this paradox and has not even diagnosed it, despite repeated efforts to endow the notion of requirement with a rigorous character that allows it to fully integrate into the universe of technical disciplines. The many tools developed to build, manage and trace requirements have not changed things. They have increased costs and delays by inducing additional red tape, without noticeable efficiency, except a look and feel of mastered development.
The classical literature on requirements states wishful thinking, purely qualitative. One representative example is the list of characteristics that a "good requirement" must meet, as, typically, in “Getting Requirements Right”, 3rd Edition, Suzan & James Robertson, 01/08/2012 – Addison Wesley. Accorting to this book, a requirement needs to meet the following criteria to be considered as a “good requirement”:
“1.4 Characteristics of a Good Requirement
Besides these criteria for individual requirements, three criteria apply to the set of requirements. The set should be:
