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

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 (see as an exception our previous study on how software architects deal with NFRs). Knowing more about the state of the practice may help researchers to steer their research and practitioners to improve their daily work. In this paper, we present our findings from an interview-based survey conducted with practitioners working in 18 different companies from 6 European countries (at the time of starting the project I was still at Inria & École des Mines de Nantes, that’s why I appear as French team)

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. 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 outweigh the extra effort required by these manual adaptations. 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.

More specifically, the project aimed to answer the following research questions:

• RQ1 What benefits can the management of NFRs bring to companies as part of their MDD processes?
  • RQ1.1 Which types of NFRs are linked to the factors that motivate the adoption of MDD? (former RQ1.2)
  • RQ1.2 To what extent are NFRs relevant for those projects that adopt MDD? (former RQ1.3)
• RQ2 How do MDD approaches adopted by companies support NFRs?
  • RQ2.1 Which types of NFRs are supported by the  adopted MDD approaches?
  • RQ2.2 At which stages of the adopted MDD approach are these NFRs handled? (former RQ2.4)
• RQ3 How do companies deal with NFRs when the adopted MDD approach does not support them?
  • RQ3.1 How are MDD approaches customized to take into account the previously unsupported types of NFRs?
  • RQ3.2 How do companies deal with an NFR which is not supported by MDD?
  • RQ3.3 To what extent are the drawbacks of dealing with unsupported types of NFRs compensated by the benefits of adopting MDD?

that we managed to answer via the following key findings

• RQ1
  1. While near half of the respondents (7 out of 18) consider that NFRs are as important as functional requirements, the same amount still consider functional requirements more important than NFRs
  2. When adopting MDD,  the interviewees expect to achieve improvements in NFRs such as productivity, maintainability, and reusability. Other NFRs, such as obtaining high levels of performance or strong security needs, are perceived as harder to achieve when developing with MDD
• RQ2
  1.  More than half of the companies (11 out of 18) declared that their MDD approach requires adaptations to support the NFRs of the software produced
  2. After MDD approaches are adopted by the companies, performance, maintainability, quality of code and productivity are the supported NFR types mentioned most often (see Figure 4)
  3. The respondents reported three different stages to address NFRs: at modelling time, at code generation time and/or at testing time
  4. The interviewees use modelling and transformation functions as techniques for supporting NFRs when using MDD (see Figure 5)
• RQ3
  • Half of the respondents (9/18) declared that changing the code manually to satisfy NFRs is common practice, half did not
  • When code is manually modified, the changes are ad hoc and maintenance is seriously compromised
  • The benefits of using MDD overcome the extra effort required to make manual adaptations to support NFRs. Even the use of MDD excluding NFRs still pays

Looking at the results of this study, we can classify the management of NFRs in MDD processes into three categories: a) natively, where the MDD method is able to cope with (some selected types of) NFRs; b) through extensions, where the company adds or changes the languages or transformations to handle NFRs; c) ad hoc, where companies can modify the source code as they need. In most cases we have seen only partial support, and only for very specific types of NFRs. Even if there are different positions among the interviewees, modifying the generated code to support NFRs seems to be the most widely used solution so far. This approach may be suitable in some scenarios, such as building software prototypes. However, software products need to be compliant with all types of requirements and MDD seems to be not ready for such diversity of needs. In particular, the study has shown that software engineers expect MDD bringing benefits for some particular types of NFRs related to the development process, while companies adopt MDD approaches mainly to better support NFRs related to the system behaviour.

Retrofitting NFRs in MDD after the fact is in tune with the state of the practice in rather traditional engineering approaches, but it further has major impacts on inconsistencies when regenerations cause modifications to get lost. Therefore, new approaches and techniques need to be proposed by the research community to improve the NFR support in MDD and solve the problems enumerated above. Otherwise, NFRs remain a delicate by-product casually attached at the very end of the engineering cycle. In addition, mismatches between industry practices and MDD teaching should be solved.

To read the full details of our study, check the full version of the paper (or the free version).