Are "Non-functional" Requirements really Non-functional?

1. INTRODUCTION

• The conventional distinction treats functional requirements as what a system does and NFRs as how it does it.An alternative view distinguishes behavioral properties from representational properties, with many NFRs describing behavior.Source: §1 · p. 1
• NFRs are often vague, unquantified, documented separately, and difficult to analyze and test.The paper also notes that they are often managed with little or no consequence analysis.Source: §1 · p. 1
• 75% of the 530 classified NFRs describe system behavior, while 25% describe system representation.The requirements were extracted from 11 industrial specifications; behavioral NFRs were further classified by system view and behavior theory.Source: §1 · p. 1
• The authors argue that many so-called NFRs can be handled similarly to functional requirements, while focusing on the practical separation rather than criticizing the term.They classify behavioral NFRs by system view and behavior theory, with implications for practices such as testing and design.Source: §1 · pp. 1–2

NFR classifications

• The study bases its NFR classes on ISO/IEC 9126 quality characteristics and excludes process requirements because they do not describe system properties.Source: §2 · p. 2
• Prior NFR definitions and classifications differ, and the notion of NFRs can depend on representation; the authors encountered all three issues in their study.The issues are definition, classification, and representation problems.Source: §2 · p. 2

NFRs and their implications on software development

• Prior studies report that NFRs are often vague, insufficiently prioritized, difficult to test, or handled separately from functional requirements.Other reported problems include imprecise or unsynchronized documentation and limited validation.Source: §2 · p. 2
• Existing proposals include a common model integrating functional and non-functional requirements, alongside approaches for particular NFR classes [11, 17].The paper positions its results as empirical support for integrating requirements with similar behavioral characteristics into a common system model.Source: §2 · p. 3
• The paper uses reported NFR-handling problems to motivate analyzing which NFR classes occur in practice and how they might be integrated into development.Earlier work also found NFRs were not integrated into development processes [25].Source: §2 · p. 3

3.1 Goal and Research Questions

• The research questions cover NFR classes by application domain and whether NFRs describe behavior or representation, which system views behavioral NFRs address, and which behavior theories express them.Source: §1 · p. 3

3.2 Study Object

• The study draws on 11 specifications from five companies and different application domains, collecting requirements labeled non-functional, quality, or as a quality attribute.The specifications vary in abstraction, detail, and completeness; the study reports 346 NFRs before preparation.Source: §3.2 · p. 3

3.3 Data Collection and Analysis Procedures

• Two authors with more than three years of relevant research experience prepared and classified the NFRs in a paired procedure.Source: §3.3 · p. 3

3.3.1 Data Preparation

• Preparation excluded 56 requirements, partially interpreted 76, split 97 into 337, and retained 117 as-is, yielding 530 requirements for classification.Source: §3.3.1 · p. 3

3.3.2 Data Classification

• NFRs were classified using ISO/IEC 9126 quality characteristics and Broy’s system views, separating representational requirements from behavioral requirements addressing interface, architecture, or state.Behavioral requirements were also classified by behavior theory, including syntactic, logical, timed, and probabilistic descriptions.Source: §3.3.2 · p. 4

3.3.3 Data Analysis Procedures

• The analysis examines NFR distributions across 27 and seven aggregated quality characteristics, plus application domain, behavioral versus representational type, system view, and behavior theory.Security is treated as a separate class in the aggregated list.Source: §3.3.3 · p. 5

RQ1: NFR Classes

• Functionality–Suitability and Functionality–Security account for 221 NFRs (≈41.7%), while Functionality, Security, and Reliability account for around 27%, 20%, and 16%.Source: RQ1: NFR Classes · p. 5

RQ2: Relation to Application Domain

• Business information systems skew toward Security or Functionality, embedded systems toward Reliability, and hybrid systems have a more balanced distribution, supporting domain-specific NFR handling.Source: RQ2: Relation to Application Domain · p. 5, Figure 2 · p. 6

4.2 Nature of NFR Classes

• 74.7% of NFRs describe system behavior, while 25.3% describe system representation.Source: RQ3: Amount of NFRs Describing System… · p. 6
• Interface behavior dominates several classes, Maintainability has the largest architectural share, and no NFR class is exclusively behavioral or representational.Security has a notable representational share partly because many such requirements reference standards.Source: RQ3: Amount of NFRs Describing System… · p. 6
• 68.9% of behavioral NFRs address the interface, 21.5% architecture, and 9.6% system state.Interface behavior is most common in Functionality, Usability, Reliability, Security, and Efficiency; Usability is the only class without architecture-classified NFRs.Source: Figure 4 · p. 7, RQ4: Distribution of Behavioral NFRs… · p. 7
• 69.9% of behavioral NFRs are logical, 18.2% timed and/or probabilistic, and 11.9% syntactic.Timed and probabilistic requirements are concentrated in Efficiency and Reliability.Source: Figure 5 · p. 7, RQ5: Distribution of Behavioral NFRs… · p. 7

4.3 Summary of Results

• Across classes, most NFRs address interface behavior and use logical or timed assertions; architectural aspects appear in all classes except Usability.Usability, Security, and Portability have relatively high portions of representational NFRs.Source: Figure 6 · p. 8, §4.3 · p. 8

5.1 Data Representativeness Problem

• The data cover selected industrial contexts, so representativeness of NFR specification and completeness are constrained; the authors could not mitigate this threat but consider the set sufficient for first conclusions.They note that relation to existing evidence strengthens their conclusions.Source: §5.1 · p. 8

5.2 NFR Selection Problem

• The study included only requirements explicitly labeled non-functional or quality, potentially missing relevant NFRs or including irrelevant ones; future work will classify the whole data set.Source: §5.2 · p. 8

5.3 Preparation Problem

• Excluding out-of-scope or unintelligible requirements could threaten conclusion validity, but the authors excluded about 16% and did not consider this a major threat.Source: §5.3 · p. 8

5.4 Classification Problem

• A pre-study found low inter-rater agreement, so researchers refined the classification dimensions, created a decision tree and pattern catalogue, and classified requirements in pairs.Source: §5.4 · p. 8

5.5 Representation Problem

• The representation problem threatens internal validity: classifying authentication as black-box interface behavior differs from classifying an authentication component as glass-box architecture.Source: §5.5 · p. 8

5.6 Contextualization Problem

• Conclusion reproducibility depends on clear contextual information, but NDAs limit disclosure; the authors anonymized data and disclosed what agreements permitted.Source: §5.6 · p. 9

• Most sampled NFRs describe functional behavior and can be handled like functional requirements; system test cases could be specified for almost 51.5% of them.The authors include behavior over the interface, including timing and probabilistic behavior, in this conclusion.Source: §6 · p. 9
• 22.1% of the NFR population were Functionality–Suitability requirements, meaning roughly one in five labeled NFRs eluded thorough analysis.The paper attributes this gap to the requirements being labeled NFRs, which were not tested and analyzed as thoroughly as functional requirements.Source: §6 · p. 9
• 68 of 530 NFRs referenced standards and were classified as representational because the authors could not access those standards.Such references can be concise but assume readers have knowledge of and access to the standards.Source: §6 · p. 9
• Only a few sampled NFRs explicitly addressed architecture, although interface- or state-view requirements may also affect architecture.Requirements classified as addressing the architecture view are considered architecturally significant; architects must judge whether other requirements have that impact.Source: §6 · p. 9
• NFR classes span multiple system views and behavior theories, while their relevance varies by application domain.The authors recommend basing specification, implementation, and testing choices on the system view and behavior theory, and customizing procedures for different domains.Source: §6 · p. 9
• NFRs ranged from high-level goals to detailed behavioral descriptions, so high-level goals need refinement into detailed functional requirements.The authors say an explicit approach is needed to relate high-level NFRs or quality goals to lower-level requirements.Source: §6 · p. 10

7. CONCLUSIONS

• The study classified 530 NFRs from 11 industrial specifications and found that most in the sample describe black-box interface behavior.The authors conclude that many so-called NFRs can be handled similarly to functional requirements and integrated into a seamless development process.Source: §7 · p. 10

7.1 Relation to Existing Evidence

• The findings provide empirical evidence that most sampled “non-functional” requirements describe functional aspects of a system.The authors report that their results resemble prior findings on frequently mentioned NFR classes and support the top four classes reported by Ameller et al., though in a different order.Source: §7.1 · p. 10

7.2 Impact/Implications

• The authors argue that the separation of NFRs from functional requirements is largely artificial, while noting that its development-process consequences have not been investigated empirically in detail.They envision holistic integration to improve traceability, progress control, validation, and verification.Source: §7.2 · p. 10

7.3 Future Work

• The analysis uses an inherently incomplete set of practical specifications, so the authors call for larger samples, more application domains, and functional requirements in future studies.Planned next steps include studying the remaining 1,495 functional requirements and investigating consequences of labeling requirements as NFRs.Source: §7.3 · p. 10