Validate Non-Functional Requirements

68 deploy-validate-non-funtional

Non-functional requirements play an important role in defining for an organization or a product what standards apply to the system as a whole, as opposed to a specific feature. The ideal state organization continually evaluates adherence to these requirements.

Explore More.


The integrated experience in a staging environment


Validation across organizational level and project level non-functional requirements

The Scaled Agile Framework® defines Non-Functional Requirements as:

Non-functional 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.1

For example, an organization may have standards about a specific level of accessibility compliance that apply to all digital products that the organization produces. Within this organization, a single project might have specific performance requirements on the response time of each core feature within the project. For NFR’s to be of any significant value to the organization, it requires that automated testing be implemented to validate adherence to the requirements within an environment that mirrors production.

For more information on the role of NFR’s within the context of the Scaled Agile Framework®, review the following abstract:

Common Pitfalls

For organizations and projects that have non-functional requirements, there are common pitfalls that should be avoided:

  • Not validating NFR’s: For NFR’s to be of any value, they have to be validated against a release candidate version of the digital product. These NFR’s should be validated with each release. Just as with any type of testing, if there is a period of time where the testing does not occur, it increases the risk that the effort and cost of moving the product back into adherence will grow.
  • Not making NFR validation tools available to developers: While validation does not occur at the team level, developers should have the ability to verify their specific work against the NFR validation toolset. In this manner, fewer issues will arise once the product has been deployed to staging.
  • Not updating organizational NFR’s: Technical, regulatory, and experience standards are all factors that could impact the NFR’s that an organization is enforcing across all of its products. While an organization should not be continually editing their NFR’s, there should be a body within the organization that regularly reviews these standards to ensure that they match the current landscape and the organization’s needs.
  • Creating non-measurable NFR’s: In some cases, with specific NFR’s such as performance and scalability, it can be easy to create NFR’s that cannot be validated. In these cases, these requirements are providing very little value to the organization. All NFR’s should have not only measurable criteria, they should also have tools available to validate the requirements for all of their digital products.


Depending on the type of Non-functional requirements that an organization is looking to validate, there are a plethora of tools that can be used. Most organizations will use a collection of commercial products, open source tools, and custom validation code.


  • Scaled Agile Inc., SAFe® 4.0 Glossary, Licensed Usage.