For our latest feature, we caught up with Swapnil Ruparelia to talk to us about Non-Functional Requirements (NFRs) and their impact on business projects.
In my experience, clear requirements both functional and non-functional are key to having a successful software delivery, and hopefully meeting customer expectations. But usually there is a lack of non-functional requirements (NFRs) on projects due to either:
- Not been considered
- Gaps – missing coverage
- Incorrect – not have considered organic or inorganic growth
So, what are non-functional requirements (NFRs), and why are they important?
Let’s start with functional requirements. Functional requirements define what a system or solution is supposed to do i.e. the functions it needs to perform. Non-functional performance on the other hand defines how a system does what it is supposed to do. In other words, they describe the performance and quality attributes of a system or solution. And this points to why NFRs are important: a system or solution that does everything you want it to do but takes too long to do it, or continuously crashes, or can’t cope with variable workloads will be rejected by users and therefore end up being a wasted investment.
Remember, if NFRs have been specified at the beginning, then these can be addressed and validated earlier in the development lifecycle. The longer we leave it, the complexity and cost to change increases due to the code needing to be rewritten. As a result, there is a greater chance of instability and therefore a greater need to apply changes to address this instability resulting in delivery times going out and costs escalating.
But more importantly, the vendor may not agree to implement the request for change or adhere to requirements stated late as, by that stage, they are after all ‘just’ a request.
In addition to this, NFRs are critical to the design of a system or solution and if they are insufficiently defined the design will likely be wrong and the cost of apply any change requests are likely to be significant as it often means a change to the underlying design of the system.
NFRs are best met by incorporating them into the base design of the solution – retrofitting extra NFRs at back end of development can be the equivalent of retrofitting a 3L turbocharged engine on a Fiat 500 or Renault Twingo.
A flavour of the NFR areas we need to think about are:
Branding and colours, help, error messages, language support, workflow etc. An example of this would be the requirement for using appropriate style guides for the UI and branding. A system that is difficult to use, even if it has superior functionality, is likely to be abandoned by users.
System growth, user volumes, performance levels, response times etc. Examples of NFRs for performance NFRs cover concurrent system users, the total number of users using the system or system response times. A system desired to react instantaneously need a response time of about 0.1 seconds, as NNGroup highlight in their article Response Time Limits. Systems that take a number of seconds to respond get frustrating and can lead to over-clicking and user errors.
Scalability and Capacity
Organic and inorganic growth volumes such as the solution increasing in data volumes per year over a period of a stated number of years, or during cycles of higher demand. We all remember the amount of time we needed to wait and try again and again to book London Olympics 2012 tickets – as great as the games were the system was not designed to take the volumes and in the end, seats were left empty. Therefore, validation of the testing will be required to prove that this requirement has been met and the system is able to scale.
Security standards that need to be addressed such as password policies, encryption, roles and permissions, and system access. Other examples will be covering system audits and the number and types of fields this covers. With increased cybersecurity threats, getting the security right is critical to any solution.
Coding standards, architectural standards, branding, and policy conformance. This protects the code base and promotes consistency.
Legal and Regulatory Requirements
Standards that the system/organisation needs to adhere to so that prevailing standards are maintained. Failure to meet some standards can lead to breaches. This in turn can impact reputation and create liability for fines and compensation. More than that, standards are important to ensure integration across an increasingly interconnected ecosystem of solutions.
Availability and Recoverability
Recoverability levels include backup and recovery tests, and system availability (hours of operation). These are tied together as organisations require reliable systems that don’t experience unplanned downtime – systems that are not can cause operational disruption and many of us have been caught up in banking, travel or other disruptions caused by system failures. Therefore, look at availability levels that suit the solution.
The higher the availability, increasingly being set at 99.9999% the more reliable the system. But availability comes with cost. Systems that are not needed for example at the weekends can be afforded a lower availability. This will still meet the needs of the business.
Data integrity is key to protecting the data within the database. Examples of requirements such as these could include not allowing the system to directly query the database. Therefore, maintain/protect system performance.
Systems need to remain online to serve their customers. But as failures, even of the most robust systems, can take place, there needs to be the capability for quick recovery. Also, provision of services while systems are not performing. Therefore, aspects such as backup and recovery testing will help protect and safeguard systems.
Let’s consider this early and not get compromised. Apart from saving unnecessary headaches. This will save your project both time and unnecessary cost escalation. Not only that, it’ll ensure the solutions delivered will meet the longer-term needs of the business.