196
elsewhere in the literature (see D6.3 Deliverable and [IoT-A UNIs]. As these
requirements do not apply to a concrete system, but rather to a Reference
Architecture and a Reference Model applicable to all potential IoT systems, the
reader needs to keep in mind a number of specifics before considering these
Unified Requirements as input for the process of architecture translation:
The Unified Requirement list should be seen as a basis and a living
document. Although it tries to cover the whole spectrum of requirements
families that could be applied to the IoT domain, it cannot be considered
to be exhaustive, as, for instance, future regulation and legislation could
impose requirements unforeseen at the time of publication. Additionally,
Unified Requirements are often formulated on a quite high abstraction
level (something largely avoided in concrete system‘s requirement
engineering), resulting in requirements that are, for instance, mapped
onto one or several views and possibly perspectives (again, something
that concrete system designers tend to avoid); Formulation of requirements expressed by external or internal
stakeholders (description field in the used Volere template) may
sometimes apply directly to the IoT ARM (e.g. UNI.094 ―The Reference
Architecture shall support any IoT business scenario‖), but in most cases
they apply to a concrete system that can be implemented using the IoT
ARM. In that latter case, they express characteristics on the system that
the IoT ARM should enable to specify, meaning they require to be
interpreted by the reader/system designer to see how they apply to their
own case – hence the wording ―the system shall...‖ generally used. Let
us take for instance UNI.021 ―The user shall be able to control the radio
activity of the system‖: depending on the actual usage of radio
communication, on the role of the user and on the importance of
controlling the radio activity of the system in the concrete architecture,
this requirement may be dropped, or specialised. In any case
reinterpreting Unified Requirements is necessary (more on this in the
following); Mapping to perspectives/views/functional groups and components is
done on a lowest-common-denominator basis – e.g. it indicates which
aspects are definitely impacted by a given Unified Requirement, but the
reader should keep in mind that in certain (concrete system) specific
cases, additional components may need to be considered. For instance,
the Device Functionality Group is out of scope of the IoT ARM (see
Section 4.2.2) and is therefore not listed in mapping of functional Unified
Requirements, while it clearly needs to be considered when devising a
concrete IoT system. Another instance is the lack of differentiation of the
data plane vs. management plane in the IoT ARM, as this is a clear
design choice (see Section 5.2.10). As pointed out in Section 5.2.5 and for the reasons explained there, the
categorisation of the UNIs does not fully match that of the IoT ARM