text: Non-functional requirements (NFRs) are commonly distinguished from functional requirements by differentiating how the system shall do something in contrast to what the system shall do. This distinction is not only prevalent in research, but also influences how requirements are handled in practice. NFRs are usually documented separately from functional requirements, without quantitative measures, and with relatively vague descriptions. As a result, they remain difficult to analyze and test. Several authors argue, however, that many so-called NFRs actually describe behavioral properties and may be treated the same way as functional requirements. In this paper, we empirically investigate this point of view and aim to increase our understanding on the nature of NFRs addressing system properties. We report on the classification of 530 NFRs extracted from 11 industrial requirements specifications and analyze to which extent these NFRs describe system behavior. Our results suggest that most "non-functional" requirements are not non-functional as they describe behavior of a system. Consequently, we argue that many so-called NFRs can be handled similarly to functional requirements.
  @cite_18: Requirements engineering is the process of eliciting individual stakeholder requirements and needs and developing them into detailed, agreed requirements documented and specified in such a way that they can serve as the basis for all other system development activities. In this textbook, Klaus Pohl provides a comprehensive and well-structured introduction to the fundamentals, principles, and techniques of requirements engineering. He presents approved techniques for eliciting, negotiating and documenting as well as validating, and managing requirements for software-intensive systems. The various aspects of the process and the techniques are illustrated using numerous examples based on his extensive teaching experience and his work in industrial collaborations. His presentation aims at professionals, students, and lecturers in systems and software engineering or business applications development. Professionals such as project managers, software architects, systems analysts, and software engineers will benefit in their daily work from the didactically well-presented combination of validated procedures and industrial experience. Students and lecturers will appreciate the comprehensive description of sound fundamentals, principles, and techniques, which is completed by a huge commented list of references for further reading. Lecturers will find additional teaching material on the books website, www.requirements-book.com.
  @cite_2: Although the term 'non-functional requirement' has been in use for more than 20 years, there is still no consensus in the requirements engineering community what non-functional requirements are and how we should elicit, document, and validate them. On the other hand, there is a unanimous consensus that non-functional requirements are important and can be critical for the success of a project. This paper surveys the existing definitions of the term, highlights and discusses the problems with the current definitions, and contributes concepts for overcoming these problems.
summary: Pohl @cite_18 discusses the misleading use of the term non-functional'' and argues to use quality requirements'' for product-related NFRs that are not constraints. Glinz @cite_2 performs a comprehensive review on the existing definitions of NFRs, analyzes problems with these definitions, and proposes a definition on his own. He highlights three different problems with the current definitions: a definition problem, i.e., NFR definitions have discrepancies in the used terminology and concepts, a classification problem, i.e., the definitions provide very different sub-classifications of NFRs, and finally a representation problem, i.e., the notion of NFRs is representation-dependent. In our study, we faced all of the three problems: we motivate our study based on the definition and classification problem and during the execution of our study, we faced the representation problem (see also our discussion on threats to validity in ). Although we agree on the critique about the obsolete and misleading notion of the term non-functional'', it still dominates the way requirements are handled in practice, as reflected in our data.