Simply said, a non-functional requirement is a specification that describes the system?s operation capabilities and constraints that enhance its functionality. These may be speed, security, reliability, etc. We?ve already covered different types of software requirements, but this time we?ll focus on non-functional ones, and how to approach and document them.
If you?ve ever dealt with non-functional requirements, you may know that different sources and guides use different terminology. For instance, the ISO/IEC 25000 standards framework defines non-functional requirements as system quality and software quality requirements. BABOK, one of the main knowledge sources for business analysts, suggests the term non-functional requirements (NFR), which is currently the most common definition. Nevertheless, these designations consider the same type of matter ? the requirements that describe operational qualities rather than a behavior of the product.
The list of them also varies depending on the source. And, frankly, it may differ for different products. For instance, if you intend to collect any user data and your website operates in the EU, you must meet GDPR compliance rules. In some cases, this may not be relevant to you. Or you may have additional compliance requirements if you process payments.
In this article, we?ll cover only the most common types that should make it to your checklist. However, there may be hundreds of them. Usually, such sources as BABOK list non-functional requirements in an isolated manner. We grouped some of them since the approaches to documenting these requirements overlap and some can?t be estimated without the other ones:
Performance and scalability. How fast does the system return results? How much will this performance change with higher workloads?
Portability and compatibility. Which hardware, operating systems, browsers, and their versions does the software run on? Does it conflict with other applications and processes within these environments?
Reliability, availability, maintainability. How often does the system experience critical failures? and how much time is it available to users against downtimes?
Security. How are the system and its data protected against attacks?
Localization. Does the system match local specifics?
Usability. How easy is it for a customer to use the system?
Performance and scalability
Performance defines how fast a software system or its particular piece responds to certain users? actions under certain workload. In most cases, this metric explains how much a user must wait before the target operation happens (the page renders, a transaction is processed, etc.) given the overall number of users at the moment. But it?s not always like that. Performance requirements may describe background processes invisible to users, e.g. backup. But let?s focus on user-centric performance.
Scalability assesses the highest workloads under which the system will still meet the performance requirements.
