In order to overcome this design roadblock, we devised a step-by-step process
through which view requirements can be inferred from qualitative requirements.
First, one formulates the rationale of the qualitative requirements as business
principles. For a detailed discussion of business principles, see [Rozanski
2012]. Then one identifies concerns and thereto-related activities. As part of
this action, one identifies each of the qualitative requirements with one or more
architectural perspectives. Next, one chooses design tactics and then one
makes design choices (more on this in Section 5.2.10).
In case the requirement is a design constraint then it directly informs the design-
choice action.
From the design choices made it is then possible to formulate implications for
the functional view and others (see Section 5.2.10).
If the requirement is of the view type, it can later directly be mapped onto the
architecture description. We have found it very helpful to preliminarily map
Functional View requirements onto the functional decomposition (see Section
4.2.2) throughout the requirement process. By so doing it is easier to track what
parts of the system architecture already are covered by the requirements and
whether more requirements are needed.
Salient inputs to the requirement process come, of course, from the Physical-
Entity View. This view, among others, instructs the requirement engineer about
particularities about the ―things‖ and the device-thing relationship (see Section
5.2.4.1). Another important source of insight is the IoT Context View. It not only
provides an overview of the envisaged system, but, thanks due to the IoT
Domain Model, it also instructs the requirement engineer about the entities that
are part of the system, how they are called, and how they relate and interact
with each other.
5.2.5.2 View derivation
The remaining views are addressed in the activity ―derive other views‖. As can
be seen in Figure 67 , this activity consists at minimum of the derivation of the
Functional View, the Information View, the Operational View, and the
Deployment View. Where needed, other views can be addressed. Examples for
such views are the concurrency view, the enterprise view, and the engineering
view [Wikipedia 2013b]. As indicated in Figure 67 , this activity is contingent
on the requirement process and it is also guided by the Physical-Entity View
and the IoT Context View. For instance, the IoT Context View might indicate
that due to the different ownership of parts of the system, a communication
firewall is needed ( Functional View). In another example, the Physical-Entity
View might indicate that, due to the fragility of the Physical Entity, all attached
devices need to be installed all at once ( Deployment View).
In order to accommodate different architecting methodologies we have detailed the
dependence of each of the action in Figure 67 onto each other in the crib sheet in
Table 11. This table provides an overview of IoT architecting activities and actions (left