Nonfunctional requirements 101

Nonfunctional requirements 101 is a brief introduction to that often forgotten category of requirements – the nonfunctional requirements. Nonfunctional requirements (NFRs) define ‘how well’ the solution must perform, and apply to system, process and people aspects of a solution (BABOK v3). Nonfunctional requirements 101 complements the previous 2 part series of Requirements 101 – Part 1 and Requirements 101 – Part 2.

Categories

BABOK lists many common categories of NFRs in Section 10.30 (interestingly under Techniques rather than Knowledge Area):

• Availability: degree to which the solution is operable and accessible when required for use
• Compatibility: degree to which the solution operates effectively with other components in its environment
• Functionality: degree to which the solution functions meet user needs, including aspects of suitability, accuracy and interoperability
• Maintainability: ease with which a solution can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment
• Performance efficiency: degree to which a solution or component performs its designated functions with minimum consumption of resources
• Portability: ease with which a solution or component can be transferred from one environment to another
• Reliability: ability of a solution or component to perform its required functions under stated conditions for a specified period of time, such as mean time to failure of a device
• Scalability: degree with which a solution is able to grow or evolve to handle increased amounts of work
• Security: aspects of a solution that protect solution content or solution components from accidental or malicious access, use, modification, destruction, or disclosure
• Usability: ease with which a user can learn to use the solution
• Certification: constraints on the solution that are necessary to meet certain standards or industry conventions
• Compliance: regulatory, financial, or legal constraints which can vary based on the context or jurisdiction
• Localisation: requirements dealing with local languages, laws, currencies, cultures, spellings, and other characteristics of users, which requires attention to the context
• Service Level Agreements: constraints of the organisation being served by the solution that are formally agreed to by both the provider and the user of the solution
• Extensibility: the ability of a solution to incorporate new functionality

NFR or constraint?

As shown above, many of the NFR categories in BABOK can be considered constraints. Business constraints are part of Task 6.2 – Define Future State and are defined as:

Constraints describe aspects of the current state or aspects of the planned future state that may not be changed by the solution, or mandatory elements of the design.

NFR categories such as availability, compatibility, reliability, security, certification, compliance and localisation are frequently non-negotiable and could therefore be considered constraints. Security requirements in law enforcement are non-negotiable, as are compliance requirements in finance or accessibility requirements in the public sector – these are all constraints.

Remember – a requirement can be considered negotiable, whereas a constraint is non-negotiable. If the business analyst and customer agree on this fundamental difference, then it doesn’t really matter if you call it a NFR or a constraint, as long as you are honest about their true nature.

Reuse requirements

BABOK addresses the reuse of requirements in:

• 3.4 Plan Business Analysis Information Management – planning for reuse
• 5.2 Maintain Requirements – organising requirements for reuse

Requirements that are potential candidates for long-term use are those an organisation must meet on an ongoing basis such as regulatory requirements, contractual obligations, quality standards, service level agreements, business rules, business processes or requirements describing products the enterprise produces.

Clearly there is much overlap here with NFRs, constraints and requirements reuse. Per the BABOK definition, the organisation must meet compliance, quality, business rules, security and business continuity requirements on an ongoing basis and therefore these are all excellent candidates for requirements reuse.

Developing a library of NFRs for use and reuse on projects in an organisation is an excellent way for a business analyst to add value, save time and avoid many headaches.

Strengths

• “Clearly states the constraints that apply to a set of functional requirements” – here BABOK ties itself in knots again with the overlap of requirements and constraints
• “Provides measurable expressions of how well the functional requirements must perform, leaving it to the functional requirements to express what the solution must do or how it must behave. This will also have a strong influence on whether the solution is accepted by the users.” – this aspect illustrates the true power of NFRs – the ability to influence whether the solution is considered acceptable. Being able to demonstrate a solution that comprehensively meets NFRs/constraints is reassuring to both business analyst and customer.

Limitations

Not all limitations in BABOK are listed below – only those considered worthy of additional discussion.

• “A set of non-functional requirements may have inherent conflicts and require negotiation.” – consider whether you are negotiating on requirements or constraints (constraints are non-negotiable by definition)
• “Overly strict requirements or constraints can add more time and cost to the solution, which may have negative impacts and weaken adoption by users.” – it can be tempting to overspecify NFRs upfront, resulting in time and cost impacts. However, it can be even more costly to retrofit a solution with NFRs after it has been built. Getting the balance right is difficult – build to what you have to (constraints), and be prepared to negotiate on the negotiable (requirements)
• “Many non-functional requirements are qualitative and therefore may be difficult to be measured on a scale, and may garner a degree of subjectivity by the users as to how they believe the particular requirements ultimately meet their needs.” – a characteristic of a quality requirement or user story is that it is testable (see Requirements 101 – Part 2). Even NFRs or constraints should be testable – the requirement/constraint is met, or it’s not. If you find yourself trying to convince a customer that a qualitative requirement has been met – you probably have a poor quality requirement.

That brings Nonfunctional requirements 101 to a close and has built a foundational understanding of requirements. Stay tuned for more requirements deep dives – let me know in the comments what you would like to see.