IoT-A Requirements

IoT-A Requirements

Welcome to the IoT-A Unified Requirements list!

PreambleRequirements in IoT-A are mainly targeted at supporting and validating the work onthe Architectural Reference Model (ARM). While requirement work within the projecttries to follow requirement best practices (by using as much as possible Voleremethodology, by using input from both potential end-users and developers),producing and exploiting requirements on a Reference Architecture (and Model) levelis somewhat different than for a concrete system (for which the state of the artmethodology is largely targeted). This results in a number of specifics that the readershould keep in mind:

Prioritization of requirements for the ARM is largely inapplicable – while it islargely considered best practice in concrete system specification.

Formulation (description field) of requirements expressed by external or internalstakeholder may sometimes refer directly to the ARM, but in most cases they applyto a concrete system. In that latter case, they express characteristics on the systemthat the ARM should enable to specify.

Mapping to perspective/views/functional groups and components is done on alowest common denominator basis – e.g. it indicates which aspect is definitelyimpacted by a given requirement, but the reader should keep in mind that in certain(concrete system) specific cases, other components may need to be considered.

How to use this list? The requirements are presented as a dynamic table, with the following fields for each requirement:

ID: Each requirement is uniquely identified by a three-digit number: UNI.klm. The numbering scheme indicates where requirements come from (e.g. all requirements with klm <200 are issued from stakeholders, those with klm > 200 are either based on state of the art or about our understanding of the IoT domain, with the 600 range being devoted to security and 700 devoted to management) and is not continuous due to discards/merges.

Requirement Type: Type of requirement among the three categories Functional Requirements / Non-Functional Requirements / Design Constraints.

Category: general keywords applicable to the requirement to ease their grouping regardless of ARM specificities (e.g. allows to tag all requirements that impact privacy regardless of their origin) Description: The description is the intent of the requirement. It is a statement about what the system has to fulfil according to the rationale.

Rationale: The rationale is the reason behind the requirement’s existence. It explains why the requirement is important and how it contributes to the system’s purpose. It typically refers to direct stakeholder input for stakeholder-originated requirements, or an explanation/reference for internally-originated requirements.

View: One or several ARM Views to which the requirement is related. Functionality Group: One or several Functionality Groups in the functional decomposition of the ARM to which the requirement is related.

Functional Component: One or several Functional Components in the functional decomposition of the ARM to which the requirement is related. These functional components are part of the groups listed in the functionality-group field.

Domain Model: One or several Domain Model entities to which the requirement is related.

Perspective: One or several Perspectives to which a requirement is related.



Filtering The table is highly dynamic, with the possibility to perform a global search, as well as filter for each column. For example, one can perform a global search on the word 'communication' (search all columns box), or filter all requirements categorized with the tag privacy (Category column filter), or those which apply to the Management Functionality Group (Functionality Group column filter). I'm missing an important requirement in the list...

We have put a lot of care in building this list based on many different sources. If you think an important aspect is missing, please contact us.

For details on the requirement gathering process and complete list with more characteristics (e.g. business originating scenarios, fit criterions, etc), please refer to the deliverable D6.3