Domänenspezifische Funktionsanalyse

In meinem Blogpost „Funktionsanalyse – Was tun wir da eigentlich?“ (am 92.2.2024) habe ich die generelle Vorgehensweise beleuchtet: die zweiphasige Herangehensweise aus Modellbildung und Analyse des Modells. Hier kommt der zweite Gedanke:

Die Regeln für die Modellbildung gehen auf eine mechanische Weltsicht zurück. Einige TRIZ-Master verteidigen diese Sicht, während andere versuchen, die Funktionsanalyse für die Anforderungen der Softwarebranche oder des Managements weiterzuentwickeln. Aber jedes Mal werden allgemeingültige Regeln für Funktionsanalysen entwickelt und man streitet sich, wer nun Recht hat.

Meiner Meinung nach haben alle Recht. Und damit alle Recht behalten können, müssen wir die Regeln für die Modellbildung an die Domäne anpassen, in der das Modell gebildet werden soll: Bei einer domänenspezifischen Modellbildung gelten für ein mechanisches System leicht andere Regeln als für elektrische, elektro-mechanische oder informationslastige Systeme. Software oder Mechatronik haben vielleicht ebenfalls eigene Anforderungen an das Modell. Messsysteme haben TRIZlern schon immer Probleme bereitet und für chemische Systeme habe ich noch gar keinen Versuch eines Funktionsmodells gesehen.

Wie wäre es also, wenn wir sagen, unsere Regeln für die Funktionsanalyse (Komponenten sind stofflich oder feldförmig, Interaktion bedeutet Berührung und es muss ein Parameter des Objekts verändert werden) gelten nur für mechanische Systeme und für die anderen Domänen entwerfen wir andere Regeln?

Fallen euch noch weitere Domänen ein? Welche Regeln sollte man für welche Domäne aufstellen? Was sollte man verbieten und was erlauben?