Non-Functional Requirements: How a System Should Be, Not Just What It Does

WHY IT EXISTS Functional requirements alone can produce a system that technically works but fails in the real world by being too slow, insecure, or unreliable. Non-Functional Requirements (NFRs) were created to capture these critical quality attributes, ensuring a system is not just correct, but also usable and robust.

THE MENTAL MODEL Think of building a car. Functional requirements are what it does: 'it must accelerate,' 'it must brake.' NFRs are how well it does those things: 'it must go from 0-60 mph in under 5 seconds' (performance), 'it must withstand a 30 mph collision' (safety/reliability), 'it must get 50 miles per gallon' (efficiency).

HOW IT WORKS NFRs are defined during the planning phase and specify measurable criteria for judging the system's operation. Instead of a vague goal like 'the system should be fast,' a proper NFR states '99% of API requests must complete in under 200ms.' These requirements are architecturally significant; a high-availability NFR might force the use of redundant servers across multiple regions, a decision that must be made early on.

WHEN TO USE IT NFRs are essential for any serious software system. They are especially critical where performance, reliability, security, or scalability are key business drivers. Examples include e-commerce sites where latency impacts sales, financial systems where security is paramount, and cloud services where availability is the core product.

WHEN NOT TO USE IT For simple scripts, disposable prototypes, or internal tools where 'good enough' is the goal, formally defining a long list of NFRs can be overkill. Even in these cases, however, implicit NFRs like 'it shouldn't crash my machine' or 'it should give an answer in a reasonable time' still exist.

ONE CANONICAL EXAMPLE A functional requirement for a photo app is 'a user can upload a photo.' The associated NFRs would be: the upload must complete within 5 seconds on a standard mobile connection (performance), the photo must never be lost once uploaded (durability/reliability), and only authorized users can view the photo (security). These NFRs dictate architectural choices like using a CDN for speed, replicated object storage for durability, and an access control system for security.