4.1.13 Identifying The Problem Boundary
Here it is necessary to reflect upon the systems engineering ‘Vee’ model described in the first chapter. That model describes top-down design and bottom-up building and progressive testing and model integration through to the completed model being validated against the needs of the key stakeholders (or client group).
The next step requires the problem boundary to be defined. This will enable a specification to be created of the overall model. This will be built bottom-up, progressively integrated (that is, assembled) and tested. The purpose of defining the model boundary is to enable each of the sectors (if the model is large enough to contain sectors), modules to be identified and parameters to be set correctly for modelling purposes. Further, to be applied to assure correct functioning can only be designed when the module is fully defined. Recall that a module is typically defined as shown in Figure 4-11.
When selecting those things to be included or excluded from the model we must make a clear distinction between exogenous and endogenous factors. Exogenous factors are those which exist or applied as forces from outside our defined problem space. Typically, we have no control (or, at best, very little control) over various factors—consequently we define then as exogenous. Endogenous factors are important in two respects. Firstly, we can expect to have some control over them. Secondly, we know from system dynamics research and analysis that the dynamic behaviour is very largely (and often exclusively) a product of endogenous factors, which in combination we know to form system dynamics structure.
Note that when an influence diagram equivalent to any stock-and-flow diagram (such as Figure 4-11) is drawn it is not intuitively obvious where the boundary should be drawn. However the problem boundary is generally drawn outside the rate- (flow)-controlling variables.

