How Architects See Non-Functional Requirements: Beware of Modifiability

Poort, Eltjo; Martens, N.; Weerd, Inge van de; Vliet, Hans van

doi:10.1007/978-3-642-28714-5_4

Cited by 20 publications

(32 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Poort et al [18] found a statistical correlation between the verification of NFRs and project success. According to their results, the benefits of verification are also more significant if NFRs are verified in early stages of a project.…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

How Do Software Architects Specify and Validate Quality Requirements?

Caracciolo

Lungu

Nierstrasz

2014

Software Architecture

View full text Add to dashboard Cite

Software architecture is the result of a design effort aimed at ensuring a certain set of quality attributes. As we show, quality requirements are commonly specified in practice but are rarely validated using automated techniques. In this paper we analyze and classify commonly specified quality requirements after interviewing professionals and running a survey. We report on tools used to validate those requirements and comment on the obstacles encountered by practitioners when performing such activity (e.g., insufficient tool-support; poor understanding of user's needs). Finally we discuss opportunities for increasing the adoption of automated tools based on the information we collected during our study (e.g., using a business-readable notation for expressing quality requirements; increasing awareness by monitoring non-functional aspects of a system).

show abstract

Section: Related Workmentioning

confidence: 99%

“…Previous studies [7,8,13] propose solutions for specifying architectural invariants. Other studies [1,18,19,10] rank non-functional qualities (e.g., performance, usability, availability, etc.) by carrying out surveys.…”

Section: Introductionmentioning

confidence: 99%

How Do Software Architects Specify and Validate Quality Requirements?

Caracciolo

Lungu

Nierstrasz

2014

Software Architecture

View full text Add to dashboard Cite

show abstract

“…[13] [29,30] Elicitation E1 In requirements elicitation, the focus is on FRs, not on QRs. [5,4,31,24,32,27] E2 Many QRs remain undiscovered.…”

Section: Id Research Statement Pro Conmentioning

confidence: 99%

Views on quality requirements in academia and practice: commonalities, differences, and context-dependent grey areas

Vogelsang

Eckhardt

Méndez

et al. 2020

Information and Software Technology

View full text Add to dashboard Cite

Context: Quality requirements (QRs) are a topic of constant discussions both in industry and academia. Debates entwine around the definition of quality requirements, the way how to handle them, or their importance for project success. While many academic endeavors contribute to the body of knowledge about QRs, practitioners may have different views. In fact, we still lack a consistent body of knowledge on QRs since much of the discussion around this topic is still dominated by observations that are strongly context-dependent. This holds for both academic and practitioners' views. Our assumption is that, in consequence, those views may differ. Objective: We report on a study to better understand the extent to which available research statements on quality requirements, as found in exemplary peer-reviewed and frequently cited publications, are reflected in the perception of practitioners. Our goal is to analyze differences, commonalities, and contextdependent grey areas in the views of academics and practitioners to allow a discussion on potential misconceptions (on either sides) and opportunities for future research. Method: We conducted a survey with 109 practitioners to assess whether they agree with research statements about QRs reflected in the literature. Based on a statistical model, we evaluate the impact of a set of context factors to the perception of research statements. Results: Our results show that a majority of the statements is well respected by practitioners; however, not all of them. When examining the different groups and backgrounds of respondents, we noticed interesting deviations of perceptions within different groups that may lead to new research questions. Conclusions: Our results help identifying prevalent context-dependent differences about how academics and practitioners view QRs and pinpointing statements where further research might be useful.

show abstract

“…The research proposed by Vara et aI., [14] aims to gain new insights into the importance of NFR in industry, the results of the study provide novel empirical evidence about the perceived importance of NFR types in industry and how it may vary. Also, we can find a detailed study on NFR impact on project success or failure in [15] [16].…”

Section: B On Non-functional Requirementsmentioning

confidence: 99%

Towards a variable non-functional requirements integration for Component-Based Product Line a generic approach

Hammani

Rhanoui

Asri

2014

2014 Second World Conference on Complex Systems (WCCS)

View full text Add to dashboard Cite

Software Product Line and Component-Based Software Engineering are two expanding paradigms for developing critical and complex systems. Therefore, these two paradigms seem have complementary strengths. So, significant benefits can be gained from their integration. Despite the fact that Non-Functional Requirements (such as security, performance and reliability) are critical to software systems, and they must be taken into account at early stage of software development life cycle and should be explicitly specified as well as functional requirements; these NFR are overlooked in Software Product line and Component-Based Software Development Processes. So, our main objective is to discuss some recent approaches in the field and to propose a new extension to Software Product Line processes that supports Component Based Approaches, and integrates Non-Functional Requirement in domain requirements stage.

show abstract

How Architects See Non-Functional Requirements: Beware of Modifiability

Cited by 20 publications

References 13 publications

How Do Software Architects Specify and Validate Quality Requirements?

How Do Software Architects Specify and Validate Quality Requirements?

Views on quality requirements in academia and practice: commonalities, differences, and context-dependent grey areas

Towards a variable non-functional requirements integration for Component-Based Product Line a generic approach

Contact Info

Product

Resources

About