Non-functional Requirements

"The Product Backlog is an emergent, ordered list of what is needed to improve the product." A non-functional requirement, by itself, is not something that is needed to improve the product. However, a deviation or gap from a non-functional requirement could be expressed as a Product Backlog Item. Some non-functional requirements could also be captured as part of the Definition of Done, but others may not lend itself well to this.

It may be useful to take a look at a few examples. Wikipedia has a (non-exhaustive) list of types of non-functional requirements.

If you have requirements to perform security analysis of the product, that would be something useful to include in your Definition of Done. Performance and response time requirements may also be part of the Definition of Done or as some other form of acceptance criteria for individual Product Backlog Items.

If a system deviates from a performance requirement, develops a security vulnerability that must be remediated, or needs changes to support something like fault tolerance or reliability, the specific changes could be captured in a Product Backlog Item and placed into the Product Backlog.

Escrow, data retention, and legal requirements may not be suitable for the Product Backlog or Definition of Done.

Should we add non-functional requirements to DoD or Product Backlog to make them visible?

The Developers are accountable for ensuring that all increments are Done and of immediately usable quality. To meet this accountability, they may stipulate that certain quality requirements are non-negotiable and essential to the Definition of Done.

Requirements that are thought to constitute negotiable scope may be ordered by the Product Owner on the Product Backlog for possible inclusion in future increments.

Can someone please briefly explain NFR and provide real cases for it?

Non Functional Requirements include performance, maintainability, reliability, feasibility, interoperability, integrateability, stability, testability, correctness, reusability, sustainability, enhanceability, and usability. They often describe qualities that are, or ought to be, invariant to the increment supplied and can often describe work necessary for an increment to be Done.

I agree with @Thomas Owens and @Ian Mitchell that non functional requirements do not have a place in the Product Backlog and are better made visible in the Definition of Done.



However work done to implement could have a place.  For example if there is a new non functional requirement that a product has to be load tested to a specific threshold there could be work that is needed to implement the ability to do the load testing. To me that is considered Technical Debt that would need to be addressed. Once that is addressed, the ongoing practice of ensuring the non functional requirement is met would be part of the Definition of Done.