Non-functional requirements can cover a wide range of context areas and operating restrictions for delivering software systems, including:
Representatives of these context areas are stakeholders in the success of the product and should be treated in the same way as business process owners in determining the content of an Agile project’s product backlog.
Non-functional Stakeholders may include, but not limited to, Systems Architects, Security directors, Marketing, Database managers, Support teams in addition to customers and users of the product. These stakeholders should to have their requirements identified and captured by the Product Owner for inclusion in the product backlog.
However, non-functional requirements, once identified, fall into two distinct types: NFR stories and NFR Standards.
Standard NFRs cannot be implemented in isolation. Rather they are rules by which other stories must follow. Typically in Agile methodologies, they are captured as acceptance criteria and integrated into functional requirements and their design. The team’s definition of done can also be used to insure NFRs are met, for example, by determining that all stories must have support documentation written before being accepted as complete. Backlog management tools, such as Atlassian Jira, have several features that can support NFR management in this way.
The Agile approach promotes the idea of testing as early as possible in the development process, and crucially, this can be applied to NFRs also. Once standard NFRs have been identified to a useful detail (not necessarily finalized), functionality can be tested for compliance with NFRs while it is in development. In modern development practices, continuous integration systems can ensure the delivered product increments, even early in development, can be repeatedly tested against the defined NFRs. Any functions that do not meet the NFRs will be identified as early as possible. The tests and their results can be made visible to those stakeholders who defined them as well as the team developing the product.
This approach of capturing and testing NFRs early has many obvious advantages and there are several important steps to implement this model.
- Performance
- Security
- Usability
- Accessibility
- Scalability
Representatives of these context areas are stakeholders in the success of the product and should be treated in the same way as business process owners in determining the content of an Agile project’s product backlog.
Non-functional Stakeholders may include, but not limited to, Systems Architects, Security directors, Marketing, Database managers, Support teams in addition to customers and users of the product. These stakeholders should to have their requirements identified and captured by the Product Owner for inclusion in the product backlog.
However, non-functional requirements, once identified, fall into two distinct types: NFR stories and NFR Standards.
- NFR stories are very similar to functional requirements in defining how a particular function should behave. They are independent of other stories. E.g. “Passwords must be at least characters and include at least one punctuation symbol”
- NFR Standards set a standard for the behaviour of many parts of the product. They are not independent but must be included into other stories. E.g. “All data access to the accounts database must be audited”, “All web pages must load within 2 seconds”, “All web pages must conform to W3C’s WCAG 2.0 standard”
Standard NFRs cannot be implemented in isolation. Rather they are rules by which other stories must follow. Typically in Agile methodologies, they are captured as acceptance criteria and integrated into functional requirements and their design. The team’s definition of done can also be used to insure NFRs are met, for example, by determining that all stories must have support documentation written before being accepted as complete. Backlog management tools, such as Atlassian Jira, have several features that can support NFR management in this way.
The Agile approach promotes the idea of testing as early as possible in the development process, and crucially, this can be applied to NFRs also. Once standard NFRs have been identified to a useful detail (not necessarily finalized), functionality can be tested for compliance with NFRs while it is in development. In modern development practices, continuous integration systems can ensure the delivered product increments, even early in development, can be repeatedly tested against the defined NFRs. Any functions that do not meet the NFRs will be identified as early as possible. The tests and their results can be made visible to those stakeholders who defined them as well as the team developing the product.
This approach of capturing and testing NFRs early has many obvious advantages and there are several important steps to implement this model.
- The Product Owner and team need visibility of NFRs as early as possible, ideally before development begins.
- SMEs and stakeholders must be identified who can be responsible for defining NFRs.
- Suitable environments, data, test tools etc. must be available to allow any specific testing that is required – for example performance test environment.