Non-functional requirements are defined as quality attributes that are usually linked with the system solutions and organizational processes.
They identify criteria that can be used to assess the performance of a system rather than certain behaviours which are known as functional requirements.
Business analysts use non-functional requirements to describe how well the functional requirements must perform.
They enhance the functional requirements of a solution, identify limitations on those requirements, and explain quality features that a solution must have when functional requirements are being used.
Non-functional requirements are usually described in descriptive statements. These descriptive non-functional requirements statements will usually have a limiting factor on them.
For example, the X number of users must be able to concurrently access the system, transactions must be at least X% processed after S seconds, or the system must be available X% of the time.
Non-functional requirements have some components, which include:
1. Categories of non-functional requirements: Common categories of non-functional requirements include the following:
• Availability: This is the point to which the solution is functional and attainable and it is usually expressed in terms of the percent of time the solution is available.
• Compatibility: This is the point to which the solution works effectively with other elements in its domain, such as how one process works with another process.
• Functionality: This is the point to which the solution functions fulfill the user requirements such as the solution’s suitability, accuracy, and ability.
• Maintainability: This is the ease with which a solution or its component can be altered to fix faults, enhance performance, or adjust to an altered environment.
• Performance efficiency: This is the point to which a solution or its component does its defined functions with minimum use of its resources. It can be described based on the period, such as high-peak, mid peak or off-peak usage.
• Portability: This is the ease with which a solution or its component can be moved from one domain to another.
• Reliability: This is the potential of a solution or its component to do its required functions, such as the average time for the device failure.
• Scalability: This is the point to which a solution is able to grow in order to
handle more work.
• Security: These are features of a solution that safeguard the solution or its components from incidental or hostile access, use, modification, destruction, or disclosure.
• Usability: This is the simplicity with which a user can learn to use the solution.
• Certification: These are the limitations on the solution which are essential to meet specific standards or industry conventions.
• Compliance: These are regulatory, financial, or legal constraints which can differ based on the domain or geographical location.
• Localization: These are requirements that need to be fulfilled to ensure that the end users can use the solution. They include the local languages, laws, currencies, cultures and spellings.
• Service level agreements (SLA’s): These are terms of agreements on the availability and usability of the solution. The agreement is between the service provider and the organization who are the end users of the solution.
• Extensibility: This is the capability of a solution to integrate new functionality
2. Measurement of non-functional requirements: Non-functional requirements are used to describe quality features in hazy terms,
such as “the process must be easy to learn”, or “the system must respond
quickly”.
But nonfunctional requirements must be measurable whenever possible, so it is important that suitable measures of success are provided to ensure that they are verification.
For example:
• “The process must be easy to learn” can be defined as “95% of operators must be able to use the new process after no more than eight hours of training”.
• “The system must respond quickly” can be defined as “The system must provide 95% of responses in no more than three seconds”.
Measurement of the other classification of non-functional requirements are directed by the source of the requirement.
For example:
• certification requirements are normally defined in measurable detail by the organization setting the standard, such as ISO Certification standards.
• compliance requirements and localization requirements are defined in
measurable detail by their providers.
• effective service level agreements describe clearly the measures of success
needed.
• an organization’s enterprise architecture normally describes the solution
environment requirements and defines exactly which platform or other
features of the environment are needed.
3. Context of non-functional requirements: Based on the category of non-functional requirements, the domain may have to be examined. For example, a regulatory agency may impose domain affecting compliance and security requirements.
The organizational domain is always evolving and the non-functional requirements may need to be modified or totally removed. Business analysts should think about the relative stability of the domain when assessing the non-functional requirements.
Non functional requirements have both their strengths and limitations, which include:
Strengths
• It clearly defines the limitations that apply to a set of functional requirements.
• It provides measurable expressions of how well the functional requirements must perform, leaving it to the functional requirements to define what the solution must do or how it must behave. Which would also affect if the solution is accepted by the users.
Limitations
• The simplicity and usefulness of a non-functional requirement depends on what the stakeholders know about the needs for the solution and how well they can communicate those needs.
• The needs of multiple users may be quite different, and agreeing on the quality attributes may be difficult. For example, what might be ‘too fast’ to one user might be ‘too slow’ to another.
• A set of non-functional requirements may have intrinsic conflicts and need some negotiation. For example, some security requirements may require compromises on performance requirements.
• Really strict requirements can add more time and cost to the solution, which may have negative effects and weaken buy-in by the users.
• It may be difficult to measure non-functional requirements on a scale, and measurements may be subjective based on the individual user needs.