WikiPedia defines the NFRs as
A non-functional requirement is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that define specific behavior or functions.
In general, functional requirements define what a system is supposed to do whereas non-functional requirements define how a system is supposed to be. Non-functional requirements are often called qualities of a system. Other terms for non-functional requirements are “constraints“, “quality attributes”, “quality goals” and “quality of service requirements”. Qualities, that is, non-functional requirements, can be divided into two main categories:
- Execution qualities, such as security and usability, which are observable at run time.
- Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the software system.
Many people would turn their head in anguish on the mention of Non Functional Requirements primarily because of 2 reasons
- Some like Tom Gilb do not like the term NFR and they would rather agree with the System qualities because there is nothing like non-functional in a system.
- Others would like to simply ignore this aspect of the system and concentrate on the Functional requirements. They would turn their energies towards NFRs when sh*t hits the fan!
Now considering this second category of people, why would they react the way they would?
- NFRs are inherently difficult to define and even more difficult to validate.
- Most of the times they do not depict any tangible result to the end user.
- Promotions would not be dependent on then though firings would be.
In a series of small posts we would try to see a few NFRs and how each of them could flow from the cycle of definition to validation.