Towards Continuous Quality: Measuring and Evaluating Feature-Dependent Non-Functional Requirements in DevOps

Haindl, Philipp; Plösch, Reinhold

doi:10.1109/icsa-c.2019.00024

Cited by 11 publications

(5 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…They calculate the consequences of uncertainty through Monte‐Carlo simulation and shortlist candidate architectures based on expected costs, benefits and risks. Another research 27 extends the QUAMOCO 28 quality model to specify feature dependent NFRs. The authors provide tool support for the operationalization of this quality model which is useful for DevOps contexts.…”

Section: Related Workmentioning

confidence: 99%

Minimising conflicts among run‐time non‐functional requirements within DevOps

Das,

Deb,

Chaki

et al. 2023

Systems Engineering

View full text Add to dashboard Cite

Significant contributions in the existing literature highlight the potential of softgoal interdependency graphs towards analyzing conflicting non‐functional requirements (NFRs). However, such analysis is often at a very abstract level and does not quite consider the run‐time performance statistics of NFR operationalizations. On the contrary, some initial empirical evaluations demonstrate the importance of the run‐time statistics. In this paper, a framework is proposed that uses these statistics and combines the same with NFR priorities for computing the impact of NFR conflicts. The proposed framework is capable of identifying the best possible set of NFR operationalizations that minimizes the impact of conflicting NFRs. A detailed space analysis of the solution framework helps proving the efficiency of the proposed pruning mechanism in terms of better space management. Furthermore, a Dynamic Bayesian Network (DBN) ‐ based system behavioral model that works on top of the proposed framework, is defined and analyzed. An appropriate tool prototype for the framework is implemented as part of this research.

show abstract

Section: Related Workmentioning

confidence: 99%

Minimising conflicts among run‐time non‐functional requirements within DevOps

Das,

Deb,

Chaki

et al. 2023

Systems Engineering

View full text Add to dashboard Cite

show abstract

“…NFRs are feature-centric. 39 The DependencyAssociation class captures relevant NFRs associated with functional features that are required to be satisfied. Specification of NFRs for each functionality ensures that it is realized in such a manner that the required non-functional properties can be satisfied.…”

Section: The Dsl Metamodelmentioning

confidence: 99%

“…Then the maximum of the most likely values of these two NFRs must match with the most likely value of NFR N601. The DependencyAssociation class is used to capture the associations between FunctionalRequirement and NonFunctionalRequirement. NFRs are feature‐centric 39 . The DependencyAssociation class captures relevant NFRs associated with functional features that are required to be satisfied.…”

Section: The Proposed Approachmentioning

confidence: 99%

SCARS: Suturing wounds due to conflicts between non‐functional requirements in autonomous and robotic systems

Roy,

Bag,

Deb

et al. 2023

Softw Pract Exp

View full text Add to dashboard Cite

In autonomous and robotic systems, the functional requirements (FRs) and non‐functional requirements (NFRs) are gathered from multiple stakeholders. The different stakeholder requirements are associated with different components of the robotic system and with the contexts in which the system may operate. This aggregation of requirements from different sources (multiple stakeholders) often results in inconsistent or conflicting sets of requirements. Conflicts among NFRs for robotic systems heavily depend on features of actual execution contexts. It is essential to analyze the inconsistencies and conflicts among the requirements in the early planning phase to design the robotic systems in a systematic manner. In this work, we design and experimentally evaluate a framework, called SCARS, providing: (a) a domain‐specific language extending the ROS2 Domain Specific Language (DSL) concepts by considering the different environmental contexts in which the system has to operate, (b) support to analyze their impact on NFRs, and (c) the computation of the optimal degree of NFR satisfaction that can be achieved within different system configurations. The effectiveness of SCARS has been validated on the iRobot Create3 robot using Gazebo simulation.

show abstract

“…Below we describe the design and execution of the systematic mapping study in a sequential manner: The need for the study emerged from our related activities in this field [28,29] pertaining to the extension of an operational software quality model to evaluate the fulfillment of NFRs on the level of software features, particularly in DevOps. The research questions (step 1, Figure 1) are elaborated in Section 3.1.…”

Section: Research Process and Stepsmentioning

confidence: 99%

Focus Areas, Themes, and Objectives of Non-Functional Requirements in DevOps: A Systematic Mapping Study

Haindl

Plösch

2020

2020 46th Euromicro Conference on Software Engineering and Advanced Applications (SEAA)

Self Cite

View full text Add to dashboard Cite

Context: Software non-functional requirements address a multitude of objectives, expectations, and even liabilities that must be considered during development and operation. Typically, these non-functional requirements originate from different domains and their concrete scope, notion, and demarcation to functional requirements is often ambiguous. Objective: In this study we seek to categorize and analyze relevant work related to software engineering in a DevOps context in order to clarify the different focus areas, themes, and objectives underlying non-functional requirements and also to identify future research directions in this field. Method: We conducted a systematic mapping study, including 142 selected primary studies, extracted the focus areas, and synthesized the themes and objectives of the described NFRs. In order to examine non-engineering-focused studies related to non-functional requirements in DevOps, we conducted a backward snowballing step and additionally included 17 primary studies. Results: Our analysis revealed 7 recurrent focus areas and 41 themes that characterize NFRs in DevOps, along with typical objectives for these themes. Overall, the focus areas and themes of NFRs in DevOps are very diverse and reflect the different perspectives required to align software engineering with technical quality, business, compliance, and organizational considerations. Conclusion: The lack of methodological support for specifying, measuring, and evaluating fulfillment of these NFRs in DevOps-driven projects offers ample opportunities for future research in this field. Particularly, there is a need for empirically validated approaches for operationalizing non-engineering-focused objectives of software.

show abstract

Towards Continuous Quality: Measuring and Evaluating Feature-Dependent Non-Functional Requirements in DevOps

Cited by 11 publications

References 12 publications

Minimising conflicts among run‐time non‐functional requirements within DevOps

Minimising conflicts among run‐time non‐functional requirements within DevOps

SCARS: Suturing wounds due to conflicts between non‐functional requirements in autonomous and robotic systems

Focus Areas, Themes, and Objectives of Non-Functional Requirements in DevOps: A Systematic Mapping Study

Contact Info

Product

Resources

About