On Non-Functional Requirements

Glinz, Martin

doi:10.1109/re.2007.45

Cited by 561 publications

(374 citation statements)

References 9 publications

Supporting

Mentioning

358

Contrasting

Unclassified

Order By: Relevance

“…However, different authors characterize this difference in informal and unequal definitions. For example, a series of such definitions is summarized in [10]: a) "Describe the non-behavioral aspects of a system, capturing the properties and constraints under which a system must operate. " b) "The required overall attributes of the system, including portability, reliability, efficiency, human engineering, testability, understandability, and modifiability."…”

Section: What Are Non-functional Requirements?mentioning

confidence: 99%

On Non-Functional Requirements in Software Engineering

Chung

Leite

2009

Lecture Notes in Computer Science

952

578

View full text Add to dashboard Cite

Abstract. Essentially a software system's utility is determined by both its functionality and its non-functional characteristics, such as usability, flexibility, performance, interoperability and security. Nonetheless, there has been a lop-sided emphasis in the functionality of the software, even though the functionality is not useful or usable without the necessary non-functional characteristics. In this chapter, we review the state of the art on the treatment of non-functional requirements (hereafter, NFRs), while providing some prospects for future directions.

show abstract

Section: What Are Non-functional Requirements?mentioning

confidence: 99%

On Non-Functional Requirements in Software Engineering

Chung

Leite

2009

Lecture Notes in Computer Science

952

578

View full text Add to dashboard Cite

show abstract

“…According to [8], "there is a unanimous consensus that nonfunctional requirements are important and can be critical for the success of a project".…”

Section: Introductionmentioning

confidence: 99%

How Architects See Non-Functional Requirements: Beware of Modifiability

Poort

Martens

Weerd

et al. 2012

Requirements Engineering: Foundation for Software Quality

View full text Add to dashboard Cite

Abstract. This paper presents the analysis and key findings of a survey about dealing with non-functional requirements (NFRs) among architects. We find that, as long as the architect is aware of the importance of NFRs, they do not adversely affect project success, with one exception: highly business critical modifiability tends to be detrimental to project success, even when the architect is aware of it. IT projects where modifiability is perceived to have low business criticality lead to consistently high customer satisfaction. Our conclusion is that modifiability deserves more attention than it is getting now, especially because in general it is quantified and verified considerably less than other NFRs. Furthermore, IT projects that applied NFR verification techniques relatively early in development were more successful on average than IT projects that did not apply verification techniques (or applied it relatively late in development).

show abstract

“…Other future directions are to integrate values more closely into RE methods by mappings to non-functional requirements [71]. The framework advances previous elicitation techniques by providing explicit taxonomies of values and motivations to guide discovery of socio-political issues.…”

Section: Future Directions and Conclusionmentioning

confidence: 99%

Value-based requirements engineering: method and experience

Thew

Sutcliffe

2017

Requirements Eng

View full text Add to dashboard Cite

'Socio-political' issues, such as emotions, values and people's feelings, are often cited as problems in the RE process. A method is described for analysing such issues. The method consists of a taxonomy of stakeholders' values, motivations and emotions (VME), with process guidance for eliciting and analysing these issues for the RE process and design implications. Values are personal attitudes or long-term beliefs which may influence stakeholder functional and non-functional requirements. Motivations are psychological constructs related to personality traits which may be viewed as stakeholders' long-term goals in RE. Emotions are cues to stakeholders' reactions arising from value/motivation conflicts. The method is supported by a website which illustrates the taxonomy with explanations and scenarios describing problems arising from value conflicts, and from poor understanding of stakeholder values. Two method validation studies were undertaken: first, an evaluation of the website and method by novices and RE experts; and second, case study applications of RE value analysis in real-world industrial practice. The method was used by all practitioners, although in different ways, some used it to create an agenda of issues for analysis while others employed the VMEs to interpret stakeholders' views and manage stakeholder negotiations. The validation studies provide evidence for the acceptability of the method for industrial practitioners, illustrating how valuerelated problems are identified and analysed effectively by the method. The utility of analysing VMEs is compared to other 'socio-political issues'-oriented methods in RE and methods which focus on monetized values in product requirements.

show abstract

On Non-Functional Requirements

Cited by 561 publications

References 9 publications

On Non-Functional Requirements in Software Engineering

On Non-Functional Requirements in Software Engineering

How Architects See Non-Functional Requirements: Beware of Modifiability

Value-based requirements engineering: method and experience

Contact Info

Product

Resources

About