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_30: Published software quality models either provide abstract quality attributes or concrete quality assessments. There are no models that seamlessly integrate both aspects. In the project Quamoco, we built a comprehensive approach with the aim to close this gap. For this, we developed in several iterations a meta quality model specifying general concepts, a quality base model covering the most important quality factors and a quality assessment approach. The meta model introduces the new concept of a product factor, which bridges the gap between concrete measurements and abstract quality aspects. Product factors have measures and instruments to operationalise quality by measurements from manual inspection and tool analysis. The base model uses the ISO 25010 quality attributes, which we refine by 200 factors and 600 measures for Java and C# systems. We found in several empirical validations that the assessment results fit to the expectations of experts for the corresponding systems. The empirical analyses also showed that several of the correlations are statistically significant and that the maintainability part of the base model has the highest correlation, which fits to the fact that this part is the most comprehensive. Although we still see room for extending and improving the base model, it shows a high correspondence with expert opinions and hence is able to form the basis for repeatable and understandable quality assessments in practice.
  @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_7: From the Publisher: Requirements engineering is the process of discovering, documenting and managing the requirements for a computer-based system. The goal of requirements engineering is to produce a set of system requirements which, as far as possible, is complete, consistent, relevant and reflects what the customer actually wants. Although this ideal is probably unattainable, the use of a systematic approach based on engineering principles leads to better requirements than the informal approach which is still commonly used. This book presents a set of guidelines which reflect the best practice in requirements engineering. Based on the authors' experience in research and in software and systems development, these guidelines explain in an easy-to-understand way how you can improve your requirements engineering processes. The guidelines are applicable for any type of application and, in general, apply to both systems and software engineering.
  @cite_23: 
  @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.
  @cite_17: In this presentation, overview of current 9126 and 14598 series are introduced followed by some problems to be solved. Then the concept and architecture of SQuaRE are discussed. Finally, new parts, i.e., Quality in Use, Quality Requirements, and Elementally Metrics are explained.
summary: NFR classifications. There exist several classification schemes for NFRs in literature (e.g., @cite_23 @cite_2 @cite_17 @cite_18 @cite_7 @cite_30 ). One example for such a classification, which is based on a quality model, is the @cite_17 . It defines external and internal quality of a software system and derives several quality characteristics (e.g., Functionality--Security or Portability--Installability ). Sommerville further provides a classification scheme based on a distinction between process requirements , product requirements , and external requirements @cite_7 . We base our distinction of NFR classes on the classification. Furthermore, we exclude process requirements from our study, as they do not describe properties of the system itself.