Page 104 -

100 P.-O. Siebers and F. Klügl

Defining the Scope

At this stage we are interested in specifying the model scope. This requires some
initial knowledge gathering. We did this through a literature review and observation
of the existing system. With the help of the knowledge gathered, we were then
able to define the scope of the model. Decisions were made through focus group
discussions. To guide the discussion and to document the decisions made in
a more formal way, we used an adaptation of the conceptual modelling scope
table proposed by Robinson (2004) specially tailored towards ABSS modelling.
The general categories we consider are “Actor”, “Physical environment” and
“Social/Psychological aspects”.
In order to make decisions about including or excluding different elements within
these categories, we asked ourselves, amongst others, the following questions:

• What is the appropriate level of abstraction for the objective(s) stated before?
– This would define the level of abstraction acceptable.
• Do the elements have a relevant impact on the overall dynamics of the system?
– Then they should be included.

• Do the elements show similar behaviour to other elements?
– Then they should be grouped.
After some discussions within the focus group, we decided that “transparency”
would be the key driver for our decision-making and that we want to
abstract/simplify as much as possible while still keeping a realistic model (i.e.
we aimed to explicitly follow the KISS principle mentioned in Sect. 6.2.1). In
order to have easy access to data, we decided to use our own offices (University of
Nottingham; School of Computer Science) as the data source. Table 6.1 presents
the resulting scope table in which we state for every element whether we want to
include or exclude it and why we decided either way.

Defining Key Activities

Interaction can take place between actors and between an actor and the physical
environment it is in. Capturing these at a high level can be done with the help
of UML use case diagrams. In software engineering, UML use case diagrams are
used to describe a set of actions (use cases) that some system or systems (subject)
should or can perform in collaboration with one or more external users of the
system (actors). These diagrams do not attempt to represent the order or number
of times that the systems actions and subactions should be executed. The relevant
components of a use case diagram are depicted and described in Table 6.2.