In the world of software development and systems engineering, non-functional requirements (NFRs) often take a back seat to their functional counterparts. Yet, overlooking NFRs—especially the less common ones—can lead to serious consequences down the line. As a Business Analyst, your role in identifying and documenting these requirements is critical to the success of any project.
Performance
Works as designed, performs as defined.
F. Gracioppo [1]
Categories of NFRs
While some of the NFRs categories we introduce may initially seem irrelevant to your work environment or project, it’s important to consider each one before dismissing anything. For example, a brand-new fleet of ATMs being deployed around the globe may have very different Operational Environments. Some will be installed as standalone units in shopping malls, while others may face the exterior directly through the walls of branches. These ATMs could be located in northern Canada or downtown Cairo. By analyzing one type of NFR, other important factors such as Internationalization and Security may also come to light.
Frameworks
Why again ?
Want to Know More
More on NFR traceability here.
Acronyms, Abbreviations & Terms
Acronyms
Acronym | Definition | Details |
FURPS+ | Functionality, Usability. Reliability, Performance, and Supportability | [3] |
ISO | International Organization for Standardization, | |
RUP | Rational Unified Process | [4] |
SQuaRE | Software product Quality Requirements and Evaluation | The ISO/IEC 25000 series of standards, also known as SQuaRE (System and Software Quality Requirements and Evaluation), contains a framework to evaluate software product quality. ISO/IEC 25010 defines a set of eight software quality characteristics, or system “-ilities,” i.e. security, reliability, and maintainability.[2] |
Abbreviations
Abbreviation | Definition | Details |
IEC | (International Electrotechnical Commission |
Works Cited
[1] |
F. Gracioppo, “Capacity & Performance,” Jan. 2017.
|
|
[2] |
“Software Quality Standards – ISO 5055 – CISQ,” CISQ, Jan. 31, 2024. https://www.it-cisq.org/ (accessed Aug. 02, 2025).
|
|
[3] |
T. Nakajo, K. Sasabuchi, and T. Akiyama, “A Structural Approach to Software Defect Analysis,” Hewlett-Packard Journal, vol. 40, no. 2, p. 55, Apr. 1989. Accessed: Aug. 03, 2025. [Online]. Available: https://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1989-04.pdf
|
|
[4] |
P. Kruchten, The Rational Unified Process. Addison-Wesley Professional, 2000.
|
![]() |