197
process and one needs to map the UNI categories onto that of the
process in order to utilise the UNIs for the generation of architectures.
Table 13 below provides this mapping information.
UNI requirement
type
IoT ARM
requirement type
Indicated by
Design constraint Design constraint --
Functional
requirement
View requirement --
Non-functional
requirement
View requirement Mapping of UNI onto a view.
Qualitative
requirement
Mapping of UNI onto one or
more Perspectives.
Table 13 : Translation table for UNI requirement types from and to IoT ARM
requirement types.
In a nutshell, the reader should keep in mind that the IoT ARM in general, and
the Unified Requirement list in particular, should rather be seen as an
inspirational than as a normative document.
5.2.8.2 Using Unified Requirements
The Unified Requirements (UNIs) can be used by system designers at two
stages of their work: requirement elicitation and system specification.
(Concrete system)
requirements
UNIfied
requirements
Concrete
Architecture
Reference
Architecture
IoT-A
ARM
Level
IoT
(concrete)
System
level
Views
(e.g. Functional)
Perspectives
(qualities)
Identifying
relevant
UNIs
Deriving
specific
requirements 2.a
1.
Use cases,
Topics ...
Assessing
impact of
requirementson
architecture
components
2.b
Figure 69 : Using IoT-A Unified Requirements and IoT ARM for concrete system
architecture work