Dealing with Non-Functional Requirements in Model-Driven Development: A Survey

Abstract

Managing Non-Functional Requirements (NFRs) in software projects is challenging, and projects that adopt Model-Driven Development (MDD) are no exception. Although several methods and techniques have been proposed to face this challenge, there is still little evidence on how NFRs are handled in MDD by practitioners. Knowing more about the state of the practice may help researchers to steer their research and practitioners to improve their daily work. Objective: In this paper, we present our findings from an interview-based survey conducted with practitioners working in 18 different companies from 6 European countries. From a practitioner's point of view, the paper shows what barriers and benefits the management of NFRs as part of the MDD process can bring to companies, how NFRs are supported by MDD approaches, and which strategies are followed when (some) types of NFRs are not supported by MDD approaches. Results: Our study shows that practitioners perceive MDD adoption as a complex process with little to no tool support for NFRs, reporting productivity and maintainability as the types of NFRs expected to be supported when MDD is adopted. But in general, companies adapt MDD to deal with NFRs. When NFRs are not supported, the generated code is sometimes changed manually, thus compromising the maintainability of the software developed. However, the interviewed practitioners claim that the benefits of using MDD outweight the extra effort required by these manual adaptations. Conclusion: Overall, the results indicate that it is important for practitioners to handle NFRs in MDD, but further research is necessary in order to lower the barrier for supporting a broad spectrum of NFRs with MDD. Still, much conceptual and tool implementation work seems to be necessary to lower the barrier of integrating the broad spectrum of NFRs in practice.

How do Practitioners Perceive the Relevance of Requirements Engineering Research?

“…• have different backgrounds and experiences to ensure the study design and execution are richer and less prone to bias; • allow for distribution of tasks in the data preparation and collection, e.g. emerging from the paper summarization, while increasing the validity by having the ability to cross-check the analysis results among the team; • transfer authors' experiences from similar studies on relevance to practitioners [7], [21], and on RE-related topics, including NaPiRE [25] and NFR4MDD [2]; and • gain access to a wider network of practitioners. Following previous work on authors' attribution and contribution [6], Table II summarizes the roles of the team members.…”

“…Despite their active research and promising contributions to the field, RE researchers still want to understand how their solutions apply to practical problems [2], [25]. Several authors have noted a mismatch between research and practice resulting in a gap between researchers and practitioners [13].…”

Automated fault tolerance augmentation in model-driven engineering for CPS

“…what the system does. Instead, it overlooked non-functional require-ments [4] like real-time, energy, security and dependability objectives, which have become increasingly essential in the design of CPS. This limitation of MBSE has been acknowledged and partially addressed, for instance, in the context of real-time control systems in [5,6].…”

“…Among the non-functional requirements, dependability, and especially safety and reliability, are identified as difficult ones to fulfill with MBSE [4]. Many works such as [10,11] have been proposed to model and assess the dependability of CPS, in the context of MBSE.…”

NFR‐aware prioritization of software requirements

“…Ignoring these aspects during the requirement prioritization of ISD may lead to software inconsistencies, besides additional costs due to the need for deep software refactoring. The lack of integration of NFRs and negligence of NFR conflicts while delivering functionalities have been observed in 3,4 to result in an overrun of project cost and increased time-to-market.…”