Domain-specific functional analysis

In my blog post “Functional analysis – What are we actually doing?” (on February 9, 2024), I highlighted the general approach: the two-phase approach of model building and analysis of the model. Here comes the second idea:

The rules for modeling go back to a mechanical view of the world. Some TRIZ masters defend this view, while others try to develop functional analysis for the requirements of the software industry or management. But each time, universal rules for functional analysis are developed and people argue about who is right.

In my opinion, everyone is right. And for everyone to be right, we need to adapt the modeling rules to the domain in which the model is to be built: In domain-specific modeling, slightly different rules apply for a mechanical system than for electrical, electro-mechanical or information-heavy systems. Software or mechatronics may also have their own requirements for the model. Measuring systems have always caused problems for TRIZ specialists and I have never seen an attempt to create a functional model for chemical systems.

So how about if we say that our rules for functional analysis (components are substances or fields, interaction means contact and a parameter of the object must be changed) only apply to mechanical systems and we design different rules for the other domains?

Can you think of any other domains? Which rules should be set for which domain? What should be forbidden and what should be allowed?