Page 72 -

5 Informal Approaches to Developing Simulation Models 67

Particularly in the early stages of constructing a model, it is common to make a
number of “assumptions” about various processes that are involved. In a sense, these
are not strictly assumptions—they are just necessary simplifications made in order
to get something running—but nevertheless are included here. The model builder
might, for example, include a random term to substitute for an unknown process, or
a particular value might be chosen for a constant without knowing if it is a suitable
value. The modeller must carefully document such decisions and be prepared to
revisit them and adjust them as necessary. This is particularly true if the model
starts to be used for purposes that go beyond what the model was initially intended
for (Chap. 29 in this volume).
The next type of assumption to consider is that which is “forced” by the
constraints of the programming system. This might be the simplification of a process
due to computational power limitations, restrictions forced upon the modeller due to
the data structures and/or algorithms available, or the desire to reuse another (sub-
)model. Again, such decisions must be documented. Whilst the modeller may feel
that these decisions have been forced, their documentation can serve two purposes.
Firstly, other modellers may have insights into the same programming system that
will allow them to suggest alternate approaches. Secondly, modellers who wish to
replicate the model using an alternate system may be able to better demonstrate the
impact of these assumptions.
The third type of assumption to consider is the choice of relevant objects
and processes. As mentioned previously, any modelling exercise is necessarily an
abstraction, and one must leave out much of the detail of the real world. Of course,
it is impractical to document every detail that has been omitted, but the modeller
should consider carefully which objects and processes may be relevant to the model
and document those that have been included and those that have been omitted. This
documentation will then prove invaluable in the consolidation phase (see Sect. 6),
when the modeller should explicitly test these assumptions.
The most difficult type of assumption to track and document is that which derives
from the modeller’s own personal biases or “common sense”. For example, the
modeller may have an innate “understanding” of some social process that is used
in the model without question. The modeller may also have been trained within a
particular school that embraces a traditional set of assumptions. Such traditional
assumptions may be so deeply ingrained that they are treated as fact rather than
assumption, making them difficult to identify from within.
This final class of assumption may be difficult for the modeller to identify
and document, but all others should be carefully documented. The documentation
can then be used in the exploration and consolidation phases (see below), when
the modeller checks these assumptions as much as possible, refining the model
as necessary. The assumptions should also be clearly stated and justified when
reporting the model and results.