Business Analysts and Non-Functional Requirements—A Critical Industry Perspective

As a Performance Engineering Manager, I’ve seen first-hand how projects that fail to consider non-functional requirements (NFRs) early in the lifecycle end up firefighting performance, availability, and scalability issues later — sometimes at great cost. And time and again, I've seen one recurring pattern: non-functional requirements (NFRs) are either missing, vague, or arrive too late.

While functional requirements often arrive in neatly packaged user stories, NFRs tend to be fuzzy, undocumented, or assumed to be "handled by someone technical." And more often than not, that someone is not the Business Analyst (BA).

Curious to validate this perception, I turned to AI to get a neutral, synthesized view of how the industry views Business Analysts (BAs) with respect to defining and prioritizing NFRs. I wanted to validate what I’ve long suspected from real-world experience.

What I got back wasn’t surprising — but it was telling.

The AI painted a mixed picture:

• BAs are expected to be aware of NFRs, especially in regulated or complex environments.

• In practice, though, NFRs are often under-documented or deferred to architects or engineers.

• Agile frameworks sometimes bury NFRs under “definition of done” or user story acceptance criteria.

• Strong BAs who do capture NFRs well are seen as valuable outliers — not the norm.

In other words, what the industry expects vs. what actually happens are often two different things.

And that aligned with my own observations.

Why Is It This Way?

There are a few systemic reasons why BAs often fall short on NFRs:

1. Training Bias: Traditional BA training and certifications (even reputable ones like IIBA’s BABOK) focus heavily on functional requirements — what a system should do — while barely scratching the surface on how well it should do it.

2. Stakeholder Blindness: Business stakeholders tend to talk about features, not response times or throughput. If the BA isn’t trained to elicit NFRs, these crucial details never surface.

3. Role Ambiguity: In many orgs, there’s a blurry line between what the BA does vs. what the architect, QA, or Dev team is supposed to define. NFRs often fall through these cracks.

4. Lack of Accountability: No one chases a BA for vague performance goals… not even when something goes down in production.

Why It Matters

When NFRs aren’t captured early:

• Features get released that can't scale.

• Performance tuning becomes reactive and expensive.

• Security and compliance risks emerge late in the cycle.

• Customer experience suffers — and so does business credibility.

It’s not a flaw in the BA’s capabilities — it's a gap in role definition and expectation.

What Should the Industry Strive For?

Here is what needs to change in order to elevate BA role beyond "functional requirement gatherers" to strategic system thinkers:

1. Make NFR Elicitation a Core BA Responsibility

NFRs should be gathered alongside functional requirements — not left for architects to "fill in later." BAs should lead structured conversations around performance, availability, security, and usability with stakeholders and tech teams alike.

2. Use Standardized NFR Templates and Checklists

Give BAs tools to succeed. Templates that cover common NFR dimensions (latency, failover, throughput, encryption, etc.) ensure nothing critical is missed.

4. Empower BAs and POs to Educate the Business

Stakeholders may not understand why a "2-second response time" matters — BAs should be empowered to bridge that gap and advocate for system resilience.

5. Trace NFRs Through to Delivery and Testing

NFRs should not just be documented — they should be testable, traceable, and reviewed during sprint planning, QA, and release planning.

It’s time to shift from viewing BAs as just requirement gatherers to system thinkers and NFR advocates. Because a feature is only as valuable as how well it performs under pressure.