Functionality of the Non Functional Requirements
Software development is mainly to encapsulate the business requirements (a.k.a functional requirements) into a program (software code) and make it available for the end users to use.
However, the importance of requirements that are not tied with business are often neglected. These are some of the implicit requirements.
A non-functional requirement (NFR) defines the characteristics attribute of a software system. It includes Scalability Capacity, Availability, Reliability, Recoverability, Data Integrity, etc.
However, I am not a big fan of calling them non-functional. Yes, they may not have direct business mappings but these requirements are super functional.
Data integrity is an example of NFR but without data integrity, it is not possible for us to imagine a software system running as expected by the business. Similarly, aspects like high availability, portability and accessibility / user experience are super important for a software to be usable.
In this series of NFR, I plan to pick one NFR at a time and talk about it. I may not go very deep to into the topic but will also not stay superficial.
Following are some of the NFR I plan to cover in each article under the theme of NFR.
Reliability, Robustness & Resilience
Maintainability & Reusability
Scalability & Elasticity
Messaging / Queueing (for scalability & reliability)
Data integrity, retention
The above list may not be an exhaustive & comprehensive one and some can be broken even further to add more NFR.
May I request the readers to share your thoughts around the list (and feel free to add more to it using the comment section).
In coming articles, I will cover, "what", "why", "where", "when", "who" and "how" questions for each of the NFR along with a real like scenario.
Share your comments and feedback on the theme of NFR.