Hello! Welcome back to our series on mastering business analysis documentation.
In the last lesson, we focused on writing clear, concise, and testable functional requirements—defining what a system must do. You learned to translate business needs into specific instructions using formats like user stories and formal SHALL statements.
Today, we address the other side of the coin: non-functional requirements (NFRs). This lesson will teach you how to document the quality attributes of a system—how well it should perform its functions. This directly addresses the learning outcome: Document key non-functional requirements (e.g., performance, security, usability).
For anyone in a project management or operational role, you've likely experienced the fallout when these are ignored: a system that technically "works" but is too slow, too insecure, or too confusing to be useful. Mastering NFRs is a hallmark of a senior analyst and a key skill you'll be tested on in interviews.
What are Non-Functional Requirements?
Functional requirements specify what a system does (e.g., "The system shall allow users to upload a video"). Non-functional requirements specify the constraints and quality characteristics of the system (e.g., "The system shall process an uploaded video within 5 minutes").
To get a clear understanding of this distinction and why NFRs are often overlooked but critically important, let's start with a foundational article.
Writing Non-Functional Requirements That Developers ...
The article 'Writing Non-Functional Requirements That Developers Actually Use' from Modern Analyst provides a perfect introduction. It explains the practical difference between functional and non-functional requirements and why vague NFRs cause projects to fail.
Please read the introduction and the section 'Functional vs Non-Functional: A Practical View'. Focus on the core idea that NFRs turn a stakeholder's 'wish list' into a concrete specification.
As the article states, "We want it fast, secure, and easy to use" is not a specification; it’s a wish list. Your job as a Business Analyst is to translate these wishes into something measurable and testable.
NFRs fall into several common categories. The image below gives a great overview of the most frequent types you'll encounter.
From Vague Adjectives to Measurable Requirements
The most important skill in documenting NFRs is transforming abstract adjectives like "fast" or "secure" into concrete requirements that a developer can build against and a tester can verify. This requires adding context, numbers, and clear conditions.
A powerful template to achieve this is:
“In the context of [environment / usage], when [trigger], the system shall [response], measured by [metric / threshold].”
The following reading provides excellent, concrete examples of how to apply this thinking to the most common NFR categories.
Writing Non-Functional Requirements That Developers ...
Let's return to the 'Writing Non-Functional Requirements...' article. This time, we'll focus on the 'before and after' examples that show how to transform vague statements into actionable requirements.
Please read the sections 'Step 2 – Capture Scenarios, Not Adjectives', 'Step 3 – Turn Scenarios into Measurable Requirements', and 'Fixing Vague NFRs: A Before-and-After Clinic'. Pay close attention to the examples for Performance, Security, Usability, and Operability. These are your patterns for success.
Let's apply this to your domain of AdTech.
-
Vague Wish: "The campaign reporting dashboard should be fast."
-
Measurable NFR (Performance): "For 95% of requests during standard business hours (9 AM - 6 PM), the campaign reporting dashboard shall load all data and visualizations within 4 seconds for a user with up to 100 active campaigns."
-
Vague Wish: "The platform needs to be stable."
-
Measurable NFR (Availability): "The ad serving API endpoint shall achieve 99.98% availability, measured monthly, excluding scheduled maintenance windows announced 48 hours in advance."
-
Vague Wish: "We need good security."
-
Measurable NFR (Security): "User access to advertiser accounts shall be restricted by role. Users with the 'Analyst' role may view campaign data but are prohibited from editing campaign settings or budgets."
Test your understanding!
A stakeholder tells you, "First-time users find our platform confusing. It needs to be more intuitive."
How would you rewrite this as a specific, measurable usability NFR?
Show answer
Here's one possible answer:
"During usability testing, at least 80% of first-time users shall be able to successfully create and launch a new advertising campaign in under 15 minutes without external assistance."
This is a strong NFR because it is:
- Specific: It targets a clear user (first-time users) and a clear task (creating a campaign).
- Measurable: The success rate (80%) and time to completion (15 minutes) can be measured.
- Testable: This can be verified through a formal usability test.
NFRs as Business Decisions and Trade-offs
Defining NFRs isn't just a technical exercise; it's a business negotiation. Achieving higher levels of performance, availability, or security almost always increases development cost and complexity. As a BA, you must facilitate the conversation between business stakeholders and the technical team to find the right balance.
For example, is 99.9% availability sufficient, or does the business truly need (and be willing to pay for) 99.999% availability? The difference can be millions of dollars in infrastructure and engineering effort.
This video, while from a cloud architect's perspective, brilliantly illustrates this negotiation process.
Non-Functional Requirements - FULL guide with REAL Examples
In this video, 'Non-Functional Requirements - FULL guide with REAL Examples', the presenter discusses the negotiation around reliability and availability. This is a perfect example of the conversations a BA must lead.
Watch from 06:12 to 08:08. Focus on the discussion about negotiating the level of availability (e.g., 99% vs 99.999%) and how this is not just a technical decision, but a business one based on cost and priority.
How to Document NFRs
Now that you know how to write NFRs, where do they go? There are two common places.
-
In a Dedicated NFR Section: In formal documents like a BRD or FSD, you will often have a specific section listing all the global non-functional requirements (e.g., "General Performance Requirements," "General Security Requirements").
-
As Acceptance Criteria: For NFRs that apply to a specific feature, they can be included as acceptance criteria for that feature's user story. This keeps the quality attribute tied directly to the function it supports.
What are Non-functional Requirements and How Do They Work?
This short clip from 'What are Non-functional Requirements and How Do They Work?' explains how NFRs can be documented as acceptance criteria within your agile workflow.
Watch from 05:20 to 06:15. Notice how the global NFR 'load pages within one second' becomes an acceptance criterion for multiple user stories.
Example (combining functional and non-functional):
User Story: As an advertiser, I want to view a performance report for my campaign, so that I can analyze its effectiveness.
Acceptance Criteria (Gherkin):
- Given I am on the campaign dashboard
- When I click the "View Report" button for a selected campaign
- Then the system shall display the performance report with metrics for impressions, clicks, and spend.
- And the report page shall load completely in under 3 seconds. (This is the NFR)
Practice Exercise
Let's put it all together. You are a BA at an AdTech company. The product manager wants to build a new real-time dashboard that shows how much money is being spent on ads, second by second.
They give you this vague request: "The dashboard needs to be reliable and feel instantaneous to the user."
Your Task:
Write two distinct, measurable non-functional requirements based on this request.
- One for Availability.
- One for Performance (specifically, data freshness or latency).
Use the templates and principles from the lesson to make them specific and testable.
Show answer
Here are example answers. Your wording might differ, but the core elements of being specific, measurable, and testable should be present.
1. Availability NFR:
The Real-Time Spend Dashboard shall be available to users 99.95% of the time during business hours (9 AM - 6 PM local time), as measured over a calendar month.
Why it's good: It specifies a clear percentage (99.95%), a measurement period (calendar month), and a context (business hours). This is a testable requirement that the operations team can monitor.
2. Performance (Latency) NFR:
For the Real-Time Spend Dashboard, the 'Total Spend' value displayed on the screen shall update to reflect the latest data from the ad server within 5 seconds of the spend event occurring.
Why it's good: It avoids the vague word "instantaneous" and defines a precise, measurable time threshold (5 seconds) for data freshness. This gives the development team a clear target to build against.
Conclusion
Today we've demystified non-functional requirements. You've moved beyond vague wishes and learned how to define the critical quality attributes that determine a project's real-world success.
Key Takeaways:
- NFRs define how well a system does its job (e.g., its speed, reliability, security).
- The key skill is translating stakeholder adjectives ("fast," "easy," "secure") into specific, measurable, and testable statements with clear metrics and context.
- Defining NFRs is a business negotiation that involves balancing quality goals with cost and technical feasibility.
- NFRs are documented either in a dedicated section of an FSD/BRD or as acceptance criteria for a specific user story.
Preview of the Next Lesson:
We now have a toolkit for documenting both what a system should do (functional requirements) and how well it should do it (NFRs). This often results in a long list of requirements. In our next lesson, we will tackle the crucial question of "what's most important?" by learning how to apply prioritization techniques (e.g., MoSCoW, Kano) to a requirements backlog.