5.2.5 Requirements process and « other views »
5.2.5.1 Requirements process
So far we have shed light on two of the views that constitute an IoT architecture:
Physical-Entity View and IoT Context View. Next, we discuss the remaining
mandatory activities for generating an architecture: the requirement process
and the derivation of ―other views‖ (see Figure 66 ). Figure 67 provides a deeper
look into the architecture activities. How exactly the IoT ARM contributes to
each of these actions is the topic of the next section.
As indicated in Figure 65 and discussed in the previous section, the context
view is expanded by the IoT Domain Model. Therefore, both the generation of
the ―traditional‖ context view (see Section 5.2.4.2) and the expansion of this
view in the IoT Domain Model are included in the creation of an IoT Context
View. As also explained in Section 5.2.4.2, the Physical-Entity View provides
input to the generation of the IoT context view.
With the input from the Physical-Entity View and the IoT Context View, one can
conduct a threat analysis. Such an analysis identifies potential weaknesses of
the envisaged system use case, and it also identifies design choices and in
some cases even functionalities that mitigate the risks identified. This analysis
also provides guidance for the requirement-engineering action (what security
risks need to be addressed by requirements).
The requirement process consists of many intermediate steps. The
requirement-engineering action generates a list of references that belong to
either one of three types: view requirements (i.e. requirements that directly
inform one of the architectural views), qualitative requirements, and design
constraints. Notice that we categorise the Unified Requirements (see Appendix
B and online at http://www.iot-a.eu/public/requirements)) along different
dimensions (functional requirement, non-functional requirement etc.). This was
done in order to increase the usability of UNIs for users who are not familiar
with the IoT ARM taxonomy of requirements. How to translate the UNIs
requirement types into IoT ARM-process types is described in the same Section
5.2.8.
In the prevalent approaches toward the translating qualitative requirements into
view-related requirements, one usually relies on an already available set of view
requirements. An example for such an approach is Quality-Function
Deployment [Erder 2003], which, among others, is a central part of the ISO
9000 standards suite [ISO 2009]. The assumption of an existing set of view
requirements is a reasonable one for straightforward product extensions or the
design of simple systems, but for most IoT systems such an approach is not
feasible. In other words, qualitative requirements cannot directly be translated
into view requirements. In the case typical IoT systems, complexity is not only
high, but there often exists a plethora of options of how to achieve the desired
performance of the system to be built. In other words, there are many sets of
view requirements that meet the same set of qualitative requirements.