Requirements Metamodeling for Self-Adaptive Embedded Systems

Introduction

Currently, most of self-adaptive embedded systems (SAES) are running in risk-critical applications and demand a high degree of reliability. It is interesting to note, however, that the system reliability is strongly related to the careful capturing of the adequate user requirements (Broy, 2003).

ES industry has grown remarkably in the last years, nevertheless existing ES development flows still undervalue ES requirements definition phase. For a successful ES industry, the authors think that the formal integration of requirements engineering into SAES development is of paramount importance.

‘Requirements engineering’ or ‘RE’ as it is commonly known, is a subdiscipline of system engineering and software engineering. RE is concerned with understanding what the system must do (the ‘what’), rather than ‘how’ it will do; which is the concern of the design and coding phases.

The process of RE is crucial to meet the time, cost, and quality of service constraints of the system. For ES it is typically a part of systems engineering.

For this reason, the ultimate objective of the authors will be to propose a requirements engineering process for self-adaptive embedded systems which will improve the development of intelligent embedded systems and their quality.

To achieve our objective, the authors:

• •

  Overview the state of the art and practice of requirements engineering for ES.

• •

  Overview the state of the art and practice of requirements engineering for SAES

• •

  Based on (Danny, 2021), Propose a conceptual model for SAES which introduces a basic vocabulary for the field of SAE

• •

  Propose a metamodel (MM4SAES) that defines concepts and relationships that must be taken into account in the development of SAES.

• •

  In the near future, propose a precise RE process for SAES called REP4SAES (Requirements Engineering Process for Self-Adaptive Embedded Systems).

The process used for RE of ES varies widely depending on the application domain, the people involved and the organization developing the requirements. Nevertheless, there are five common activities for RE which are: Elicitation or requirements discovery, Analysis, Specification, V&V (Verification and Validation), and management.

Figure 1.

RE Process

• •

  Requirements elicitation: is the process of identifying system or software requirements from a variety of sources like interviews, questionnaires, prototyping, and other techniques (Figure 2). Noted that, the term elicitation is used to raise the fact that good requirements cannot just be collected from the customer (requirements gathering). Additionally, requirements elicitation is not trivial because we can never be sure we get all requirements from the user and customer by just asking them what the system should do or not do (for safety and reliability).

Figure 2.

Requirements elicitation technique

• •

  Requirements Analysis: the role of this process is examining, understanding, and modeling the elicited requirements, and checking them for quality in terms of correctness, completeness, clarity, and consistency. In this step, we must distinguish between functional and non-functional requirements such as performance, scalability, availability, reliability, recoverability, maintainability, serviceability, security, regulatory, manageability, environmental, data integrity, usability, interoperability and so on.