luvv to helpDiscover the Best Free Online Tools
Topic 9 of 12

Non Functional Requirements

Learn Non Functional Requirements for free with explanations, exercises, and a quick test (for Business Analyst).

Published: December 20, 2025 | Updated: December 20, 2025

Table of Contents

Who this is for

  • Business Analysts, Product Owners, and aspiring BAs who need to capture quality expectations clearly.
  • Engineers and QA who want testable, measurable quality targets.
  • Stakeholders who approve scope and want fewer surprises late in delivery.

Prerequisites

  • Basic understanding of functional vs. non-functional requirements (NFRs).
  • Ability to talk to stakeholders and gather requirements.
  • Familiarity with user stories or use cases.

Why this matters

Projects fail tests, miss launch dates, or rack up costs when qualities like speed, uptime, or security are vague. As a Business Analyst, you will:

  • Turn "fast" or "secure" into measurable targets stakeholders can sign off on.
  • Align NFRs with capacity planning, SLAs/SLOs, budgets, and timelines.
  • Prevent rework by specifying acceptance criteria early.
  • Help QA derive tests and ensure releases meet expectations.

Concept explained simply

Non Functional Requirements describe how well the system must perform, not what features it has. They cover qualities like performance, availability, security, usability, and maintainability.

Mental model

Think of NFRs as the dials on a products quality control panel. Each dial has a target number (e.g., 95th percentile response time 3 seconds). Your job is to set and validate those numbers with stakeholders.

Quality Attribute Scenario (QAS) template you can reuse
  • Stimulus source: Who or what triggers it?
  • Stimulus: What happens?
  • Environment: In what conditions?
  • Artifact: What part of the system?
  • Response: What should the system do?
  • Response measure: How do we measure success (metric, threshold)?

Example structure: When user requests order history during peak hours, the web API returns a response in 95th percentile 3s, 99th 6s.

Typical NFR categories

  • Performance & scalability (latency, throughput, concurrency)
  • Availability & reliability (SLA/SLO, MTTR, failover)
  • Security & privacy (auth, encryption, audit)
  • Usability & accessibility (learnability, keyboard-nav, contrast)
  • Maintainability & supportability (time to fix, logging, diagnostics)
  • Compliance & auditability (records, retention)
  • Interoperability & portability (APIs, formats, environments)
  • Localization & internationalization (time zones, number/date formats)
  • Backup & disaster recovery (RPO/RTO)

Worked examples

1) Performance: Turning fast into a testable target

Vague: The app should be fast.

Context: Retail checkout page under peak load (Black Friday).

  • Stimulus source: Buyer
  • Stimulus: Clicks Place Order
  • Environment: Peak hour, 5,000 concurrent sessions
  • Artifact: Checkout API
  • Response: Returns order confirmation
  • Response measure: p95 latency 3s, p99 6s; throughput 100 req/s sustained for 10 minutes

Acceptance criteria: Under 5,000 concurrent sessions, 95% of Place Order requests complete within 3s and 99% within 6s; error rate < 0.5%.

2) Availability: From always up to a realistic SLO

Vague: Always up.

Clarified: Monthly availability 99.9% excluding a weekly 60-minute scheduled maintenance window Sundays 02:0003:00 local data center time. Automated failover within 2 minutes.

Acceptance criteria: Monitoring dashboard shows monthly uptime  99.9%; any single incident MTTR  30 minutes; maintenance notifications sent 48 hours prior.

3) Security: Concrete controls

Vague: Secure login.

  • Passwords: Minimum 12 chars; lock account after 5 failed attempts for 15 minutes.
  • Transport: TLS 1.2+ for all endpoints.
  • Data at rest: Customer PII encrypted with AES-256.
  • Audit: Log auth events with timestamp, user ID, IP, outcome; retain 180 days.

Acceptance criteria: All login endpoints refuse non-TLS connections; after 5 failed attempts in 5 minutes, further attempts return HTTP 429; audit log completeness >= 99% in daily checks.

4) Accessibility: Make it measurable

Vague: Accessible.

  • Keyboard navigation: 100% of controls reachable via Tab/Shift+Tab without traps.
  • Contrast: Text contrast ratio  4.5:1 for body text.
  • Forms: Screen reader announces labels and errors for all form fields.

Acceptance criteria: Automated checks show no critical contrast issues; manual test confirms end-to-end checkout without a mouse; 0 unlabeled buttons.

Elicitation questions you can ask

Performance & scale
  • What are peak and average usage patterns (concurrent users, requests/min)?
  • Which user journeys must remain responsive under peak? What slow feels unacceptable?
  • What percentile (p95/p99) should we hold ourselves to?
Availability & recovery
  • What downtime is acceptable per month? Are maintenance windows allowed?
  • Whats the maximum time to recover from an incident (MTTR)?
  • Do we need active-active or active-passive failover?
Security & privacy
  • Whats the sensitivity of data involved? Encryption requirements?
  • Access control rules and audit events needed?
  • What are breach notification or compliance obligations?
Usability & accessibility
  • Primary user profiles and critical tasks to optimize for?
  • Non-mouse usage needs (keyboard-only, screen readers)?
  • Any language or localization considerations?

Acceptance criteria templates

  • Performance: For [endpoint/task], under [load], [percentile] latency  [threshold], error rate  [threshold].
  • Availability: Monthly uptime  [SLO]% excluding [window]; MTTR  [minutes].
  • Security: [Data] encrypted [in transit/at rest]; [auth policy]; [audit events] retained [days].
  • Accessibility: Keyboard access for [flows]; contrast  [ratio]; [screen reader] announces [elements].
  • Recovery: RPO  [minutes]; RTO  [minutes].

Exercises

Do these exercises now. Your work will be used in the Quick Test.

  1. Exercise 1: Convert vague NFRs into measurable ones for an online ticketing platform. See instructions in the Exercises panel below.
  2. Exercise 2: Draft availability and scalability acceptance criteria and a simple test approach for a SaaS dashboard. See details below.

Checklist before sign-off

  • Each NFR has a metric, threshold, and context (load, environment).
  • Stakeholders agree on trade-offs (cost vs. quality levels).
  • Acceptance tests exist or are feasible to implement.
  • Dependencies (monitoring, logs, test data, failover) are identified.
  • Criteria cover peak and steady-state, not only happy path.

Common mistakes and how to self-check

  • Vague words (fast, secure, reliable). Fix: Replace with numbers and scenarios.
  • Ignoring peak load. Fix: Specify concurrency or traffic bursts.
  • Forgetting error budgets. Fix: Define acceptable failure rates.
  • Un-testable criteria. Fix: Ensure monitoring/logging can measure the metric.
  • One-size-fits-all NFRs. Fix: Prioritize critical user journeys.
Self-check mini audit
  • Can QA write a test for each NFR without asking you for more detail?
  • Would a dashboard or log show pass/fail objectively?
  • Do NFRs align with budget and timeline assumptions?

Practical projects

Project 1: Harden a checkout flow
  1. Pick a checkout or payment flow.
  2. List top 3 NFRs (performance, availability, security).
  3. Write acceptance criteria with metrics and environments.
  4. Outline monitoring signals and a load test plan.
  5. Get stakeholder sign-off.
Project 2: Accessibility pass on a form
  1. Choose a multi-step form.
  2. Define accessibility NFRs (keyboard-only, labels, contrast).
  3. Create a manual test script and record findings.
  4. Write defect tickets and updated NFRs.
Project 3: Disaster recovery target
  1. Identify critical data stores.
  2. Define RPO/RTO per store and a failover sequence.
  3. Draft acceptance criteria and a tabletop test plan.

Learning path

  • Before this: Stakeholder analysis, functional requirements, basic user stories.
  • Now: Non Functional Requirements using QAS and measurable metrics.
  • Next: Prioritization and trade-off analysis, acceptance testing strategy, and traceability from NFRs to monitoring.

Next steps

  • Rewrite one vague NFR in your current work using the QAS template.
  • Review with stakeholders and get agreement on numbers.
  • Take the Quick Test to check understanding.

Mini challenge

Pick any user journey and write exactly two NFRs: one for performance (with percentile and load) and one for availability (with SLO and MTTR). Keep each under 30 words.

Quick Test

Answer the questions below to check your knowledge. Everyone can take the test; only logged-in users have their progress saved.

Practice Exercises

2 exercises to complete

Instructions

Context: An online ticketing platform. Stakeholders say: The app should be fast and secure.

  • Turn this into 23 measurable NFRs using the QAS template (stimulus, environment, response, response measure).
  • Cover one performance case and one security case.
  • State acceptance criteria suitable for QA.
Expected Output
23 NFR statements with metrics (e.g., percentiles, thresholds) and clear acceptance criteria.
Functional RequirementsRequirements Prioritization

Have questions about Non Functional Requirements?

AI Assistant

Ask questions about this tool