I think an argument can be made that this technique should more properly be called “scope determination” or “scope identification.” I also observe that determinations of scope happen during the conceptual modeling phase, when you discover what’s happening in an existing process, or during requirements and design, when defining aspects of the solution. However, since those can all be thought of as forms of modeling, maybe I can live with it.
I’ve discussed elements of scope determination previously (here and here). The BABOK goes into a lot of detail in its section on scope modeling, but in the end I think it really boils down to whether something is either in scope or out of scope of your work, or within one part or another of your work.
The BABOK mentions the contexts of control (who does or is responsible for what), need (who needs what), solution (what part of the system does what), and change (what does and does not change), and under relationships between logical components lists Parent-Child or Composition Subset, Function-Responsibility, Supplier-Consumer, and Cause-Effect, but I think of these as points of interface that fall out of the normal course of work. Knowing where to draw the boundaries between different components, functions, subsystems, organizations, teams, microservices, and so on is a crucial part of understanding and architecting systems.
The BABOK also lists emergent as a type of relationship, to describe the possibility that unexpected behaviors can arise from the interactions within complex systems. While this is undoubtedly true, I don’t see that it has much to do with scope.
Another aspect of scope, in my experience, has to do with the phase of assumptions, capabilities, and risks and impacts, which implicitly proceeds in conjunction with the conceptual model, requirements, and design phases. And this primarily concerns assumptions. An effect or data source may be within the accepted scope, but there may be valid reasons why you need to simplify mechanisms or assume values.