Structural Design

Non-Functional Requirement

A non-functional requirement describes a quality, constraint, or condition that a system, product, or service must satisfy, such as usability, accessibility, performance, reliability, security, privacy, maintainability, or data quality.

Concept facts

A non-functional requirement describes a quality, constraint, or condition that a system, product, or service must satisfy, such as usability, accessibility, performance, reliability, security, privacy, maintainability, or data quality.

Also known as
NFR, quality requirement, quality attribute, system quality requirement.
Used in
Requirements engineering, product quality, accessibility, security, performance planning, release readiness, design QA, and service governance.
Interpret with
Functional requirement, user requirement, business requirement, acceptance criteria, release readiness, accessibility regression, and implementation risk.

Plain-language explanation

A non-functional requirement describes how well a system or service must work, not only what it must do. NFRs often determine whether a service is usable, reliable, secure, accessible, and trustworthy in real conditions.

Why it matters

A system can technically perform the right function but still fail users if it is slow, inaccessible, confusing, unreliable, insecure, or difficult to maintain.

Use contexts

  • accessibility and assistive-technology support
  • performance and response time
  • reliability and availability
  • security and privacy expectations
  • usability and learnability
  • maintainability and scalability
  • data quality and auditability

Application guidance

Write quality requirements in measurable or assessable terms where possible. Connect the requirement to user or service consequence and use recognized quality models where appropriate.

Practical example

A health referral dashboard allows clinic staff to view urgent cases. Functionally, the dashboard works, but it loads slowly during peak clinic hours and does not preserve filters after refresh. A non-functional requirement sets response-time and filter-preservation expectations. The UX consequence is reduced staff workflow burden, lower risk of missed urgent cases, and better operational reliability.

Interpretive boundaries

Non-functional requirements are not secondary. They should not be written as vague aspirations, and some qualities may involve both functional and non-functional requirements.

Applied at Userhub

Userhub reviews non-functional requirements when evaluating release readiness, accessibility, service quality, and implementation risk. In UX Lab work, NFRs connect user experience with performance, accessibility, reliability, privacy, and operational conditions.

See Userhub UX Lab for applied UX research and evaluation context.

Sources and references

ISO/IEC/IEEE. (2018). ISO/IEC/IEEE 29148:2018 Systems and software engineering — Life cycle processes — Requirements engineering. International Organization for Standardization. https://www.iso.org/standard/72089.html

ISO/IEC. (2023). ISO/IEC 25010:2023 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model. https://www.iso.org/standard/78176.html

Wiegers, K., & Beatty, J. (2013). Software requirements (3rd ed.). Microsoft Press.

International Organization for Standardization. (2019). ISO 9241-210:2019 Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems. https://www.iso.org/standard/77520.html

Cite this entry

APA

Userhub. (2026). Non-Functional Requirement. UX Reference. https://userhub.com.bd/reference/non-functional-requirement/