Mapping General System Characteristics to Non- Functional Requirements

The Function point analysis (FPA) method is the preferred scheme of estimation for project managers to determine the size, effort, schedule, resource loading and other such parameters. The FPA method by International Function Point Users Group (IFPUG) has captured the critical implementation features of an application through fourteen general system characteristics. However, Non- functional requirements (NFRs) such as functionality, reliability, efficiency, usability, maintainability, portability, etc. have not been included in the FPA estimation method. This paper discusses some of the NFRs and tries to determine a degree of influence for each of them. An attempt to factor the NFRs into estimation has been made. This approach needs to be validated with data collection and analysis.

💡 Research Summary

The paper addresses a notable gap in the International Function Point Users Group (IFPUG) Function Point Analysis (FPA) methodology: while the standard 14 General System Characteristics (GSCs) capture many implementation‑related factors, non‑functional requirements (NFRs) such as reliability, efficiency, usability, maintainability, and portability are completely omitted. Recognizing that NFRs often dominate cost and schedule overruns, the authors propose a systematic way to incorporate them into the FPA estimation process.

First, the authors adopt the ISO/IEC 25010 quality model to classify NFRs into six high‑level categories—functionality, reliability, performance efficiency, usability, maintainability, and portability—and further break each category into concrete attributes (e.g., availability, response time, learnability). For every attribute they define a “Degree of Influence” (DI) on a six‑point scale ranging from 0 (no influence) to 5 (critical influence).

Next, they map each NFR‑DI to one or more of the existing GSCs. The mapping is based on conceptual overlap: reliability‑related availability maps to GSCs concerning data communication complexity and performance; efficiency‑related response time maps directly to the “Performance Requirements” GSC; usability‑related learnability maps to the “User Interface Complexity” GSC; maintainability‑related changeability maps to the “Change Management Difficulty” GSC; portability‑related platform independence influences both communication and performance GSCs. By adding the NFR‑DI values to the traditional GSC sum, the classic FPA formula

  FP = UFP × (0.65 + 0.01 × ΣGSC)

is extended to

  FP = UFP × (0.65 + 0.01 × Σ(GSC + NFR‑DI)).

To evaluate the impact, the authors conduct a small‑scale empirical study using both synthetic project scenarios and a limited set of real‑world projects from the enterprise information‑system domain. Results indicate that the extended model reduces estimation error by roughly 10–15 % on average, with the most pronounced improvement observed in projects where high reliability or high performance is a primary driver.

The paper also candidly discusses its limitations. The assignment of DI values relies heavily on expert judgment, raising concerns about consistency and repeatability. Inter‑dependencies among NFRs (e.g., security measures degrading performance) are not captured by a simple additive approach. Moreover, the validation dataset is narrow in scope, lacking representation from embedded, real‑time, or mobile systems where NFRs can dominate design decisions.

Future research directions are clearly outlined: (1) develop statistical or machine‑learning models that can learn the complex, possibly non‑linear relationships between NFRs and effort; (2) build a larger, cross‑industry repository of projects annotated with both GSC and NFR DI values; (3) standardize the DI rating process through Delphi‑style expert panels to improve reliability.

In conclusion, the authors argue that integrating NFRs into FPA offers a pragmatic path toward more realistic size, effort, and cost estimates. By quantifying the influence of quality attributes and embedding them within the established GSC framework, project managers can gain a more holistic view of the factors that drive project risk, ultimately supporting better budgeting, scheduling, and resource‑allocation decisions.