A non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system. Rather than specific behaviors. They are contrasted with functional requirements that define specific behavior or functions.
What are Non-Functional Requirements
Nonfunctional Requirements (NFRs) define system attributes such as security, reliability, performance, maintainability, scalability, and usability. They serve as constraints or restrictions on the design of the system across the different backlogs. Also known as system qualities, nonfunctional requirements are just as critical as functional Epics, Capabilities, Features, and Stories. They ensure the usability and effectiveness of the entire system. Failing to meet any one of them can result in systems that fail to satisfy internal business, user, or market needs, or that do not fulfill mandatory requirements imposed by regulatory or standards agencies.
NFRs are persistent qualities and constraints that, unlike functional requirements, are typically revisited as part of the Definition of Done (DoD) for each Iteration, Program Increment (PI), or release. NFRs exist in all backlogs: Team, Program, Solution, and Portfolio. Proper definition and implementation of NFRs is critical. Over-specify them, and the solution may be too costly to be viable; under-specify or underachieve them, and the system will be inadequate for its intended use. An adaptive and incremental approach to exploring, defining, and implementing NFRs is a vital skill for Agile teams.
Some Examples of Non-Functional Requirements
- Performance requirements: Requirements about resources required, response time, transaction rates, throughput, benchmark specifications or anything else having to do with performance.
- Operating constraints: List any run-time constraints. This could include system resources, people, needed software, etc.
- Accuracy and Precision: Requirements about the accuracy and likewise the precision of the data. Beware of 100% requirements. They often cost too much.
- Modifiability: Requirements about the effort required to make changes in the software. Often, the measurement is personnel effort (person- months).
- Portability: The effort required to move the software to a different target platform. The measurement is most commonly person-months or % of modules that need changing.
- Reliability: Requirements about how often the software fails. The definition of a failure must be clear. Also, do not confuse reliability with availability which is quite a different kind of requirement. Be sure to specify the consequences of software failure and also how to protect from failure. At the same time, a strategy for error detection, and a strategy for correction.
- Security: One or more requirements about protection of your system and also its data. Do not discuss solutions in a requirements document.
- Usability: Requirements about how difficult it will be to learn and at the same time operate the system.
- Legal: There may be legal issues involving privacy of information, intellectual property rights, export of restricted technologies.
In Conclusion
It is difficult to make a model of non-functional requirements. A measurable requirement is also a difficult task to make. Hence, we can measure how well it is meeting with what we want. It is not an easy task to put during development.
Non-functional requirements tell you how the system will run or work properly. In other words, they are the limitations on the functions available by the system which are limitations on timing, limitations on the development process and standards.