Non-functional requirements (NFRs) don’t often get the spotlight in requirements workshops – but they quietly determine whether your system will succeed or suffer.
What if filling in an input form is a daily, frequent task – but each time it takes a few minutes just to load?
What if your web app works beautifully on Chrome – but most of your users are on Edge, and it doesn’t work quite right there?
What if you design a clean dashboard with plenty of white space – but your Private Credit team, working on ultrawide monitors, expects to see 40 key data fields side by side in one view, not hidden behind tabs and clicks?
What if the system desperately requires non-repudiation – but as a BA you don’t specify which actions must be logged, how long those logs should be retained, or who should be able to view them?
These gaps may seem small, but they can derail adoption or leave users frustrated. That’s why BAs must go beyond what a system does to define how well it must do it – because NFRs are not extras, they’re what make a solution truly work.
With that in mind, let’s explore the two main ways NFRs show up in real projects.
Two Categories of NFRs – Know the Difference
From an implementation perspective, NFRs fall into two main categories:
1. NFRs Fulfilled Through Technical Design and Architecture
These NFRs set quality standards like performance, scalability, or availability – and they’re typically enforced through design, not features.
Example: “The response time must be less than 3 seconds under normal conditions (No complex logic or formula processing, Reasonable data payload (e.g., < 200KB),..)”
Achieved via caching, payload tuning, and architecture – not by adding a button.
➤ These NFRs are typically designed and addressed by Technical Architects (TAs), validated by QAs/Testers, and measured through tuning or infrastructure-level controls. However, BAs often need to balance the “fancy” side of functional features against non-functional priorities like performance, scalability, or reliability — ensuring the product delivers the best overall value rather than just the most eye-catching features.
2. NFRs Fulfilled Through Supporting Functional Features
Some NFRs can only be met if they’re backed by functional requirements – e.g. logging and auditing
Example: “All sensitive actions must be logged.”
Requires functional stories like:
“System must log login attempts.” “System must log fund transfers.”
➤ In these cases, BAs need to be aware of the NFR and define the relevant functional requirements to ensure the quality goal is met in practice – especially when working on a bidding or discovery project, where these requirements must be fleshed out so that estimation and cost can be considered thoroughly. Keeping this point in mind is critically important for BAs in such situations.
Where Do NFRs Come From?
NFRs may originate from:
- Stakeholder expectations
- Product constraints
- Legal, security, or compliance standards
- Your company’s internal NFR Standard List
Even if NFRs are already listed in a provided document (e.g., BID files, requirement specs), the BA should work closely with the TA and the team to ensure each NFR is:
- Applicable – Is this NFR relevant to the current solution?
- Feasible – Can this NFR realistically be achieved, given technical, time, and resource constraints?
- Defined at the appropriate level of detail
- And ideally, measurable and verifiable (the “two ables”)
The BA also helps communicate back to stakeholders when clarification or re-alignment is needed.
BA Mindset: Awareness & Applicability
In NashTech’s BA training on NFRs, we emphasize two guiding principles:
✔ Awareness
Know the typical NFR categories.
Know what’s architectural and what’s feature-driven.
✔ Applicability
Apply this knowledge continuously – from early discovery to refinement.
Recognize when NFRs are vague, missing, or need to be transformed into functional stories.
What If an NFR Isn’t Testable?
Not everything can be tested directly in UAT. For example:
“User passwords must be hashed and securely stored.”
This can’t be tested through the UI. But it can be verified through technical review – and agreed upon via documented TA sign-off.
The BA plays a key role in negotiating this kind of validation path.
Final Thought
When BAs treat NFRs as part of their core analysis mindset, they help shape systems that truly deliver – not just on features, but on real-world performance and quality.
Don’t treat NFRs as a separate checklist. Embed them into how you think, ask, and write – and you’ll unlock true solution quality.
And remember..
Good BAs don’t wait for someone else to raise NFRs. They notice them, ask the right questions, and ensure they are handled – technically or functionally.