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.
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.
@cite_18 @cite_2
2346441090 2100590236 2144634407 1984277393
In this paper, we describe a novel unsupervised approach for detecting, classifying, and tracing non-functional software requirements (NFRs). The proposed approach exploits the textual semantics of software functional requirements (FRs) to infer potential quality constraints enforced in the system. In particular, we conduct a systematic analysis of a series of word similarity methods and clustering techniques to generate semantically cohesive clusters of FR words. These clusters are classified into various categories of NFRs based on their semantic similarity to basic NFR labels. Discovered NFRs are then traced to their implementation in the solution space based on their textual semantic similarity to source code artifacts. Three software systems are used to conduct the experimental analysis in this paper. The results show that methods that exploit massive sources of textual human knowledge are more accurate in capturing and modeling the notion of similarity between FR words in a software system. Results also show that hierarchical clustering algorithms are more capable of generating thematic word clusters than partitioning clustering techniques. In terms of performance, our analysis indicates that the proposed approach can discover, classify, and trace NFRs with accuracy levels that can be adequate for practical applications. Non-functional characteristics of products can be essential for business success and are a key differentiator between a company and its competitors. This paper presents the application of a systematic, experience-based method to elicit, document, and analyze non-functional requirements. The objective of the method is to achieve a minimal and sufficient set of measurable and traceable non-functional requirements. The method gives clear guidance for the requirements elicitation, using workshops for capturing the important quality aspects and eliciting the non-functional requirements. This paper shows its application in three different settings, reporting the experience and lessons learned from industrial case studies that applied our NFR method. As the case studies were applied in different domains and performed with companies of various maturity, and since different quality attributes were considered, a set of interesting results has emerged. Therefore, each case study tells its own story about how the elicitation of NFR in industry can work. The paper discusses the different settings and gives a comparison of the different lessons we learned from the case studies. Nonfunctional requirements (NFRs) have been frequently neglected or forgotten in software design. They have been presented as a second or even third class type of requirement, frequently hidden inside notes. We tackle this problem by treating NFRs as first class requirements. We present a process to elicit NFRs, analyze their interdependencies, and trace them to functional conceptual models. We focus our attention on conceptual models expressed using UML (Unified Modeling Language). Extensions to UML are proposed to allow NFRs to be expressed. We show how to integrate NFRs into the class, sequence, and collaboration diagrams. We also show how use cases and scenarios can be adapted to deal with NFRs. This work was used in three case studies and their results suggest that by using our proposal we can improve the quality of the resulting conceptual models. Non-functional requirements (NFRs) determine the characteristics of a software product or service as a whole. The research described in this paper presents a quantitative framework involving respondents of both the project and the business organization, in order to determine the priority of a list of NFRs to be considered for implementation during a software development. The framework also provides a quantitative basis for evaluating the extent of value addition that can be achieved while deciding upon whether or not to consider a particular non-functional requirement for inclusion to the project's requirement set. The assessment process also indicates the extent to which different business values are perceived important by representatives of business organizations, and their perception of the importance of the different NFRs. The work distinguishes from others by explicitly considering dependencies among NFRs in the evaluation process. The final results are expected to be beneficial to both the business and the project organization by identifying and implementing the desired NFRs that contribute to business value in a cost-effective manner.