195
5.2.7 Minimum set of Functionality Groups
A question that we often have received concerns the least common
denominator in terms of Functionality Groups of architectures that are derived
from the IoT ARM. In other words: what Functionality Groups are parts of any
conceivable IoT ARM architecture?
The core aspects of IoT are things and communication. The things, i.e, Physical
Entities (see Section 3.3) are accessed through devices, and data or the like
pertaining to the Physical Entities is relayed by means of communication.
Physical Entities are represented by Virtual Entities. Usually, one wants to
access this data etc. with an application. Since we stipulate a service-oriented
architecture framework in which the resources exposing data etc. about the
Virtual Entities (and hence the Physical Entities) are exposed by IoT services,
the minimum set of Functionality Groups is thus:
Application Functionality Group; IoT Service Functionality Group; Communication Functionality Group; Device Functionality Group.Please notice that this does not imply that other Functionality Groups (for
instance the Management Functionality Group) are optional. This rather means
that for certain requirement sets the latter Functionality Groups are not needed.
5.2.8 Usage of Unified Requirements
5.2.8.1 Introduction
This section proposes guidelines to system architects on how to use the
(already existing) Unified Requirement list (UNIs) during the Requirements
process activity of their IoT architecture-generation process (Figure 66 ). Such
usage is by no means mandatory, as Requirement Engineering can be
performed following the process described in Section 5.2.5– however the UNIs
list can serve as a helper tool to both the elicitation of requirements and to the
system specification.
It is well known to system designers that requirement engineering is a crucial
activity in system and software engineering. In the abundant documentation on
the topic (e.g. [Hull 2011], [Pohl 2010]), one can distinguish three main
steps where requirements play a role in designing complex systems:
requirements elicitation (generally based on stakeholders input); deriving the
system‘s specification from these requirements; and validating the implemented
architecture.
As part of the work on the IoT Architectural Reference Model, UNIs were
inferred and then published at http://www.iot-a.eu/public/requirements. For more
details on how these Unified Requirements were derived can be found