Hubbry Logo
Non-functional requirementNon-functional requirementMain
Open search
Non-functional requirement
Community hub
Non-functional requirement
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Non-functional requirement
Non-functional requirement
Non-functional requirement
View on Wikipedia
from Wikipedia

In systems engineering and requirements engineering, a non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviours. They are contrasted with functional requirements that define specific behavior or functions. The plan for implementing functional requirements is detailed in the system design. The plan for implementing non-functional requirements is detailed in the system architecture, because they are usually architecturally significant requirements.[1]

In software architecture, non-functional requirements are known as "architectural characteristics". Note that synchronous communication between software architectural components entangles them, and they must share the same architectural characteristics.[2]

Definition

[edit]

Broadly, functional requirements define what a system is supposed to do and non-functional requirements define how a system is supposed to be. Functional requirements are usually in the form of "system shall do <requirement>", an individual action or part of the system, perhaps explicitly in the sense of a mathematical function, a black box description input, output, process and control functional model or IPO model. In contrast, non-functional requirements are in the form of "system shall be <requirement>", an overall property of the system as a whole or of a particular aspect and not a specific function. The system's overall properties commonly mark the difference between whether the development project has succeeded or failed.

Non-functional requirements are often called the "quality attributes" of a system. The emergent properties[Note 1] of a system are classified as non-functional requirements. Other terms for non-functional requirements are "qualities", "quality goals", "quality of service requirements", "constraints", "non-behavioral requirements",[3] or "technical requirements".[4] Informally these are sometimes called the "ilities", from attributes like stability and portability. Qualities—that is non-functional requirements—can be divided into two main categories:

  1. Execution qualities, such as safety, security and usability, which are observable during operation (at run time).
  2. Evolution qualities, such as testability, maintainability, extensibility and scalability, which are embodied in the static structure of the system.[5][6]

As non-functional requirements are all requirements that do not fall into the functional requirements category, they also include both characteristics of the functions and constraints on the system such as non-design items of statutory, regulatory, standards and protocols, or other external requirements.

It is important to specify non-functional requirements in a specific and measurable way.[7][8]

Classification of non-functional requirements

[edit]

Common non-functional classifications, relevant for all types of systems include [9]

Specific type of systems explicitly enumerate categories of non-functional requirements in their standards[to be determined]

  • Hardware systems
  • Embedded systems
  • Safety-critical systems
  • Software systems

Examples

[edit]

A system may be required to present the user with a display of the number of records in a database. This is a functional requirement. How current this number needs to be, is a non-functional requirement. If the number needs to be updated in real time, the system architects must ensure that the system is capable of displaying the record count within an acceptably short interval of the number of records changing.

Sufficient network bandwidth may be a non-functional requirement of a system. Other examples include:

See also

[edit]

References

[edit]

Notes

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Non-functional requirement

View on Grokipedia
from Grokipedia
A non-functional requirement (NFR) is a attribute or constraint on a that specifies criteria for its operation and , such as , reliability, and , distinct from functional requirements that define the specific behaviors or functions the system must provide. In , NFRs play a critical role in ensuring the overall and suitability of a system by addressing how it operates under various conditions, rather than solely what it does, thereby influencing decisions, testing strategies, and user satisfaction throughout the development lifecycle. They are essential for balancing trade-offs, such as between and , and for mitigating risks like system failures or vulnerabilities that could undermine project success. The International Organization for Standardization (ISO) provides a widely adopted framework for NFRs through ISO/IEC 25010:2023, which defines a product quality model comprising nine primary characteristics: functional suitability, performance efficiency, compatibility, interaction capability, usability, reliability, security, maintainability, and portability. Each characteristic includes sub-attributes—for instance, performance efficiency encompasses time behavior and resource utilization—to enable precise specification and evaluation of system qualities. Despite their importance, NFRs present challenges in elicitation and specification, often due to their subjective nature, vagueness, or conflicts with functional requirements, leading to inconsistencies in terminology and practices across projects. Research indicates that NFR analysis is predominantly focused on the requirements engineering phase of the software development lifecycle (SDLC), with limited attention to later stages like design and implementation, highlighting a need for improved traceability and integration methods.

Fundamentals

Definition

Non-functional requirements (NFRs) specify the quality attributes, constraints, and operational behaviors of a or other engineered system, emphasizing criteria for evaluating its , reliability, , and other non-behavioral aspects rather than defining specific functions or features. These requirements guide system design by establishing standards for how the system operates under various conditions, such as load or environmental factors, ensuring it meets stakeholder expectations for overall effectiveness and suitability. The concept of NFRs traces its roots to early efforts focused on quality attributes, evolving from "quality requirements" introduced in IEEE standards during the and , including IEEE Std 730-1981 on plans, which emphasized verifiable criteria for system attributes like and portability. The specific term "non-functional requirements" emerged in academic literature in the early , with one of the earliest documented uses appearing in a 1980 survey on by R. T. Yeh and Pamela Zave, and gained widespread adoption in the 1990s through influential standards and texts that distinguished them from functional specifications. A key milestone was IEEE Std 830-1998, which formalized the inclusion of quality attributes such as , , and design constraints in specifications. NFRs exhibit distinct characteristics that set them apart in : they are typically measurable via quantitative metrics, such as response times under load or error rates, allowing for objective verification; they are , influencing multiple interconnected parts of the system rather than being confined to isolated components; and they are often emergent properties, arising from complex interactions among system elements rather than being directly implementable in a single module. These traits make NFRs challenging to elicit and integrate but essential for achieving holistic system quality.

Distinction from Functional Requirements

Functional requirements specify the behaviors, functions, services, inputs, outputs, and features that a must provide to meet user needs. For instance, a functional requirement might state: "The shall authenticate users via username and password and grant access to authorized profiles upon successful validation." These requirements focus on the "what" of the —what it does in response to inputs or events—often expressed in use cases or detailed specifications. In contrast, non-functional requirements address the "how" of the system—its operational qualities, constraints, and characteristics, such as reliability, , or efficiency—without prescribing specific behaviors. A key distinction lies in verifiability: functional requirements are typically discrete and testable through targeted methods like unit tests or integration tests, confirming whether a particular function executes correctly (e.g., does the process succeed?). Non-functional requirements, however, are often continuous or threshold-based, evaluated via holistic assessments like for or audits for , measuring overall system attributes rather than isolated actions. The boundary between the two can blur in practice, particularly when a non-functional aspect implies or constrains a specific behavior. For example, a requirement for real-time processing, such as "The system shall process transactions in under 100 milliseconds," combines a functional action (processing a transaction) with a non-functional threshold (response time), making it challenging to classify purely. Empirical analysis of industry requirements documents reveals that many items labeled as non-functional actually describe observable system behaviors, suggesting that the traditional dichotomy may oversimplify requirements engineering and that some "NFRs" function as behavioral constraints akin to functional ones. This distinction profoundly affects : functional requirements guide the implementation of core features and logic, shaping the 's primary workflows and user interactions. Non-functional requirements, meanwhile, steer architectural decisions, technology selections, and trade-offs to ensure the meets standards, often requiring early consideration to avoid costly rework. Neglecting non-functional aspects can lead to systems that function correctly but fail in or , underscoring their role in holistic viability.

Classification

Performance Requirements

Performance requirements constitute a vital of non-functional requirements, delineating the speed, efficiency, and with which a must operate to meet user expectations and workload demands. These requirements emphasize quantitative criteria for behavior under varying loads, ensuring and capacity without compromising other qualities. Unlike functional , they address "how well" the system performs its tasks, often expressed through measurable thresholds that guide design and implementation decisions. A primary subtype is response time, which quantifies the elapsed duration for the to and return results for an operation, from request submission to completion. This includes both user-perceived latency and backend processing delays. The average response time serves as a key metric, computed as the sum of all individual response times divided by the total number of requests: Average Response Time=Total Response TimeNumber of Requests\text{Average Response Time} = \frac{\text{Total Response Time}}{\text{Number of Requests}} Requirements typically mandate maximum values, such as 100-500 milliseconds for interactive web applications, to maintain user satisfaction and prevent perceived sluggishness. Throughput represents another core subtype, measuring the volume of work the system can handle over a defined period, often in terms of successful transactions or operations per second. It is calculated as the number of completed tasks divided by the elapsed time interval: Throughput=Number of TasksTime Interval\text{Throughput} = \frac{\text{Number of Tasks}}{\text{Time Interval}} This metric is crucial for or concurrent user scenarios, where requirements might specify a minimum throughput to support operational . Resource utilization focuses on the efficient consumption of system resources, including CPU, , and network bandwidth, to avoid waste and ensure . Metrics here often set upper limits on resource usage during peak loads, promoting balanced hardware provisioning. Effective management of these prevents degradation from bottlenecks and supports long-term cost control. Balancing requirements with costs involves inherent trade-offs, as enhancing speed or capacity—through advanced caching or distributed architectures—can escalate development complexity and infrastructure expenses. Engineers must optimize algorithms and configurations to achieve specified thresholds, such as sub-2-second response times, without unnecessary over-engineering that inflates budgets beyond business needs. In high-load environments like e-commerce platforms, performance requirements gain heightened importance during peak traffic events, such as holiday sales, where systems must sustain elevated throughput and low response times to accommodate sudden user surges and avoid revenue loss from downtime or slow loading.

Security and Reliability Requirements

Security requirements in non-functional requirements (NFRs) encompass mechanisms to protect systems from unauthorized access, data breaches, and other threats, ensuring confidentiality, integrity, and availability of information. These requirements specify protections such as authentication to verify user identities, authorization to control access based on roles, encryption to safeguard data in transit and at rest, and auditability to log activities for accountability. For instance, multi-factor authentication (MFA) requires users to provide multiple verification factors, such as a password combined with a biometric or token, to mitigate risks from compromised credentials. Role-based access control (RBAC) enforces permissions by assigning users to roles with predefined privileges, limiting exposure in complex environments. Data encryption often adheres to standards like the Advanced Encryption Standard (AES), which uses symmetric keys of 128, 192, or 256 bits to encrypt 128-bit blocks, providing robust protection against interception. Auditability involves maintaining logs of security events to enable detection and investigation of incidents, supporting compliance and forensic analysis. Reliability requirements focus on the system's ability to operate consistently without failure, even under adverse conditions, by addressing , , and recoverability. targets, such as 99.9% uptime (or "three "), ensure the system is operational for at least 43.2 minutes of per month, minimizing disruptions in critical applications. employs mechanisms, like duplicated hardware components or clustering, to detect and handle errors without service interruption. Recoverability specifies metrics for restoration, such as restoration time, to return the system to full operation after a . Key metrics include (MTBF), calculated as total operating time divided by the number of , which quantifies expected operational intervals before issues arise. percentage is derived from the formula: Availability=(MTBFMTBF+MTTR)×100\text{Availability} = \left( \frac{\text{MTBF}}{\text{MTBF} + \text{MTTR}} \right) \times 100 where MTTR is the mean time to repair or recover. These requirements often tie to regulatory standards for compliance; for security, the General Data Protection Regulation (GDPR) mandates technical measures like encryption and access controls to protect personal data, ensuring a level of security appropriate to the risks involved. In safety-critical systems, such as automotive electronics, ISO 26262 provides a framework for functional safety, including reliability requirements to mitigate hazards from system malfunctions through fault-tolerant designs and verification processes.

Usability and Maintainability Requirements

Usability requirements in focus on ensuring that systems are intuitive and user-friendly, thereby enhancing the overall without altering core functionalities. These non-functional requirements are typically defined through established standards such as ISO 9241-11, which characterizes as the extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in a specified context of use. Key subtypes include learnability, which measures how quickly users can become proficient with the system, often assessed by the time required to reach a certain level of task performance; efficiency, evaluating the level of effort or resources needed to complete tasks, such as task completion rates under normal conditions; and satisfaction, gauging users' subjective comfort and acceptability, commonly measured using the (SUS), a 10-item questionnaire yielding scores from 0 to 100, where scores above 68 indicate above-average usability. A specific metric for usability is the error rate, calculated as the number of errors divided by the total number of actions performed during user tasks, helping to quantify the frequency of user mistakes and informing design improvements. requirements also align with human-computer interaction (HCI) principles, particularly Jakob Nielsen's ten heuristics, which provide guidelines for evaluating interface design, such as visibility of system status and user control and freedom, to prevent usability issues proactively. Maintainability requirements address the ease with which a can be modified, tested, or extended over its lifecycle, ensuring long-term and adaptability. According to ISO/IEC 25010, encompasses subcharacteristics like modifiability, which assesses the effort required to make changes, often through code change impact analysis to predict ripple effects; , measuring how easily components can be isolated and verified, typically via thresholds aiming for at least 80% branch coverage in critical modules; and extensibility, facilitating the addition of new features through principles that promote and high cohesion. A core metric for evaluating is , introduced by Thomas McCabe, which quantifies the complexity of a program's to predict maintenance effort and potential fault-proneness. It is computed using the formula: V(G)=E−N+2PV(G) = E - N + 2P where EE is the number of edges, NN is the number of nodes, and PP is the number of connected components in the ; values below 10 are generally considered maintainable, while higher scores indicate increased risk.

Scalability and Portability Requirements

Scalability requirements specify how a must accommodate growth in demand, such as increased user loads or data volumes, without compromising functionality or introducing excessive costs. A typical example is the requirement that "Application should be able to handle 1000 concurrent users," which in TCS iQMS assessments is classified as a non-functional requirement of the performance/scalability type. These requirements are essential for ensuring long-term viability in dynamic environments, where systems may need to expand resources efficiently. Vertical scalability involves enhancing the capacity of existing nodes by adding resources like CPU, , or storage to a single server, which is suitable for workloads that benefit from higher performance on fewer machines but may face hardware limits. Horizontal scalability, in contrast, achieves growth by distributing the across additional nodes or servers, enabling nearly linear expansion for distributed systems. Load balancing complements these approaches by dynamically allocating among nodes to handle surges in users, such as distributing requests in a to prevent bottlenecks during peak usage. Scalability can be assessed by measuring the system's ability to handle increased loads while maintaining , often evaluating elasticity through the growth in sustainable workload relative to a baseline. Portability requirements address a system's ability to operate effectively across diverse environments, minimizing adaptation efforts when migrating or deploying. Subtypes include platform independence, achieved through adherence to standards like , which ensures portability across operating systems by defining consistent APIs and behaviors. Interoperability focuses on seamless integration with other systems via compatible APIs or protocols, allowing data exchange without custom modifications. Installability emphasizes ease of deployment, often quantified by limits on setup time or resource needs, such as completing installation within a specified duration on target hardware. Portability can be evaluated through testing in virtualized setups, using metrics like container startup time to verify rapid deployment across environments; for example, Docker containers typically achieve startup in 1-2 seconds, far outperforming traditional virtual machines at 30-45 seconds, thus supporting efficient portability in heterogeneous clouds. In the cloud era, and portability requirements increasingly integrate with architectures and technologies like Docker and , enabling elastic horizontal scaling through automated orchestration of services across clusters, which facilitates dynamic for fluctuating demands. This approach enhances overall system adaptability while briefly relating to sustained under scale, as outlined in performance requirements.

Specification and Evaluation

Elicitation and Documentation

Elicitation of non-functional requirements (NFRs) involves systematic techniques to gather qualities such as , , , and from stakeholders during the phase. Stakeholder interviews are a primary method, where requirements analysts engage directly with users, domain experts, and other parties to uncover implicit NFRs through targeted questions about system constraints and expectations. Workshops facilitate collaborative discussion among stakeholders, often using structured templates to identify and prioritize NFRs, achieving high stability in elicited requirements after sessions as short as 1.5 hours each. The Volere requirements specification template supports elicitation by providing dedicated sections for non-functional attributes, guiding analysts to document properties like and alongside functional requirements. Use case extensions integrate NFRs by appending quality constraints to behavioral descriptions, such as specifying response times or reliability thresholds within primary scenarios. Prototyping aids validation by creating low-fidelity models that stakeholders interact with to reveal and issues early, influencing requirement refinement through feedback loops. Documentation of NFRs follows standards that ensure clarity and traceability in software requirements specifications (SRS). The FURPS+ model, developed by Robert Grady at Hewlett-Packard, categorizes NFRs into functionality, usability, reliability, performance, supportability, and additional attributes like design constraints, providing a framework for complete specification. These categories are incorporated into SRS documents as distinct sections, detailing system-wide qualities separate from functional behaviors to support architectural decisions. This structured approach allows for atomic requirements statements, each with rationale, fit criteria, and supporting measurements, enhancing verifiability. For example, in TCS iQMS assessments, the statement "Application should be able to handle 1000 concurrent users" is treated as an atomic non-functional requirement (performance/scalability type) and is typically documented in the Requirement Specification document rather than in the Contract or Change Request. Best practices for documenting NFRs also recommend placing architecturally significant NFRs in the software architecture document (SAD), often in a dedicated section such as "Quality Requirements" or "Quality Attributes" to ensure prominence and influence on design decisions. In templates like arc42, top critical quality goals are outlined in Chapter 1 (Introduction and Goals), with detailed quality scenarios and a quality tree in Chapter 10 (Quality Requirements). For detailed guidance on placement and scenario-based specification (using stimuli, environments, responses, and measures), refer to the Best Practices section. Requirements management tools streamline elicitation and documentation by enabling and collaboration. Jira supports NFR tracking through custom issue types and plugins like easeRequirements, which add hierarchical structures for categorizing and linking qualities to user stories. Engineering Requirements Management DOORS (DOORS NG) offers advanced features for formal NFR specification, including impact analysis and integration with development workflows to maintain consistency across the project lifecycle. Both tools facilitate and stakeholder review, reducing documentation overhead in team environments. Best practices emphasize eliciting NFRs early in the life cycle (SDLC) to inform and avoid costly rework, typically during the or elaboration phases. Iterative refinement occurs throughout subsequent SDLC stages, with ongoing stakeholder input and testing to adapt NFRs as project needs evolve. This timing ensures NFRs, such as those related to or reliability, are aligned with emerging functional requirements from categories like or .

Metrics and Measurement

Non-functional requirements (NFRs) are assessed through a combination of quantitative and qualitative metrics to ensure systems meet specified attributes such as , , and . Quantitative metrics provide objective, numerical data, such as response times or error rates, while qualitative metrics capture subjective aspects like user satisfaction via scales. The ISO/IEC 25010:2023 standard defines a product model with nine characteristics: functional suitability, efficiency, compatibility, interaction capability (formerly ), reliability, , , flexibility (formerly portability), and ; each is associated with specific sub-characteristics and measures to facilitate . Quantitative approaches often rely on benchmarks and key performance indicators (KPIs) to validate NFRs. For performance, tools like simulate load conditions to measure throughput and latency, establishing benchmarks such as or average response time under peak loads. Monitoring KPIs, including (percentage of uptime) and error rates (incidents per million requests), enables ongoing assessment post-deployment, often integrated into agreements (SLAs). criteria define pass/fail thresholds, such as a maintaining 99.9% or processing requests within 2 seconds, derived from elicited NFRs to confirm fulfillment during testing phases. Qualitative metrics complement these by addressing harder-to-quantify NFRs like and . Usability is frequently evaluated using Likert scales in questionnaires, where users rate statements on agreement from 1 (strongly disagree) to 5 (strongly agree), aggregating scores to assess satisfaction and ease of use. For security and reliability, qualitative audits review compliance with standards, supplemented by metrics like (MTBF) for reliability. These methods ensure a balanced , prioritizing conceptual alignment over exhaustive data. Verification of NFRs involves specialized testing and audits tailored to the requirement type. Non-functional testing includes stress testing for scalability, where systems are pushed beyond normal loads to measure breaking points and recovery times using tools like JMeter, identifying metrics such as maximum concurrent users before degradation. Security verification employs penetration testing and audits to quantify vulnerabilities, often tracking metrics like successful attack rates or compliance scores against frameworks like NIST. Reliability is verified through endurance testing, monitoring failure rates over extended periods to ensure adherence to MTBF thresholds. Traceability links these metrics directly back to original NFRs, enabling validation across development models. In waterfall methodologies, a requirements traceability matrix (RTM) formally maps metrics to requirements, facilitating comprehensive verification at each phase. In agile environments, is achieved through practices like tagging and sprint retrospectives, where KPIs are reviewed iteratively to confirm NFR alignment without rigid documentation. This approach supports adaptive validation while maintaining accountability.

Challenges and Approaches

Common Challenges

Non-functional requirements (NFRs) are frequently articulated in qualitative and subjective terms, such as "the system must respond quickly" or "the interface should be user-friendly," which introduces vagueness and ambiguity that hinder precise interpretation by development teams and stakeholders. This lack of specificity often results in inconsistent implementations, as different parties may interpret the same requirement differently, leading to deviations from intended system qualities. For instance, a performance requirement described as "fast enough" fails to define measurable thresholds, exacerbating misunderstandings during design and testing phases. Another prevalent challenge arises from inherent conflicts among NFRs, where satisfying one attribute compromises others, necessitating difficult trade-offs. A classic example is the tension between and : implementing robust to meet security demands can impose computational overhead, slowing down response times and violating performance goals. Such conflicts extend to other pairs, like versus , where intuitive designs may complicate code modifications, requiring project teams to prioritize based on business priorities without clear resolution mechanisms. These interdependencies amplify decision complexity, particularly in resource-constrained environments. Underestimation of NFRs during initial project phases often leads to their neglect, resulting in extensive rework and escalated costs later in the development lifecycle. Poor handling of requirements, including NFRs, is linked to significant inefficiencies, with inadequate contributing to development cost increases due to repeated revisions across all phases. Studies indicate that overlooking NFRs early correlates with higher failure rates, as unaddressed quality attributes surface as defects during integration or deployment, demanding disproportionate resources to rectify. The evolving nature of NFRs presents ongoing maintenance difficulties, as they must adapt to shifting regulatory landscapes and technological advancements. For example, new data privacy regulations like GDPR may impose stricter security NFRs post-initial specification, while such as cloud migration can alter scalability expectations, requiring continual updates to requirement documentation. This dynamism complicates and consistency, as changes propagate through the system design, often straining agile processes that emphasize iterative but not always comprehensive NFR reviews.

Best Practices

A fundamental best practice for managing non-functional requirements (NFRs) is their effective documentation and placement within the software architecture document (SAD). Best practices recommend dedicating a specific section to NFRs, often titled "Non-Functional Requirements," "Quality Requirements," or "Quality Attributes," typically positioned early in the document after the introduction, constraints, and business context but before detailed architectural views or diagrams. This placement ensures NFRs remain prominent and guide design decisions throughout the architecture process. The arc42 template exemplifies this approach by addressing quality requirements in two main sections. In Chapter 1 (Introduction and Goals), the top 3-5 critical quality goals are presented with concrete scenarios to prioritize stakeholder concerns and influence architectural decisions. More detailed specifications, including quality scenarios and a quality tree, are provided in Chapter 10 (Quality Requirements). NFRs should be quantified, precise, measurable, and testable to support effective evaluation. They must align with business goals, avoid vague statements, and reference external documentation (such as requirements specifications) when applicable. Quality attribute scenarios are recommended for specification, detailing stimuli, environments, responses, and measures to make requirements concrete and verifiable. Some guidelines suggest a "Non-functional View" section to summarize architecturally significant NFRs. Effective prioritization of non-functional requirements (NFRs) is essential to balance competing quality attributes such as and against project constraints. One established technique is the , originally developed for agile prioritization but adapted to categorize NFRs into Must-have (critical for system viability), Should-have (important but not essential), Could-have (desirable if resources allow), and Won't-have (deferred). This approach ensures stakeholders focus on high-impact NFRs early, reducing risks in . For more structured analysis, the (ATAM), developed by the , employs quality attribute utility trees to hierarchically decompose and prioritize NFRs. Stakeholders generate scenarios representing quality goals (e.g., "The system must handle 1,000 concurrent users with <2-second response time"), assign priorities, and evaluate architectural decisions for tradeoffs and risks through steps like business driver identification and scenario brainstorming. This method reveals sensitivities and non-risks, enabling informed prioritization before implementation. Integrating NFRs into development lifecycles enhances compliance and quality. In agile environments, embedding NFRs into the Definition of Done (DoD) ensures they are verified at the iteration or increment level; for instance, global NFRs like "pages load in under 2 seconds on 4G" apply across all user stories, while specific ones (e.g., data masking for privacy) can be itemized in acceptance criteria. This practice promotes consistent enforcement without overloading individual backlog items. In pipelines, continuous monitoring of NFRs is achieved through automated metrics collection and testing integrated into workflows. Key metrics include (system uptime percentage), latency (response time percentiles), and scores for user satisfaction, with tools enabling real-time alerts and optimization to meet thresholds like peak load handling. This approach supports proactive adjustments, such as scaling resources to maintain reliability. A notable case study is NASA's application of NFRs in mission-critical software, where standards like NPR 7150 mandate rigorous specification of , reliability, and attributes to mitigate risks in space systems. For example, measures ensure software meets strict timing and fault-tolerance goals, contributing to successful outcomes in programs like the Mars rovers by embedding NFR verification into engineering processes. Looking to 2025 advancements, AI-driven tools are emerging for NFR prediction and automated testing, leveraging to classify and anticipate quality needs from requirements documents or historical data. frameworks, for instance, automate multi-class NFR with high accuracy, while AI-enhanced testing predicts defects and generates self-healing scripts for and validation, reducing manual effort by up to 50% in complex systems. These trends promise more efficient incorporation of NFRs in AI-augmented development pipelines.

References

  1. https://ieeexplore.ieee.org/document/4384163/
  2. https://ieeexplore.ieee.org/document/9787463/
  3. https://www.iso.org/standard/78176.html
  4. https://www.mdpi.com/2073-431X/13/12/308
  5. https://www.altexsoft.com/blog/non-functional-requirements/
  6. https://framework.scaledagile.com/nonfunctional-requirements/
  7. http://www.math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
  8. https://dl.acm.org/doi/10.1145/1774088.1774153
  9. https://link.springer.com/chapter/10.1007/978-3-642-02463-4_19
  10. https://cs.ccsu.edu/~stan/classes/CS410/notes16/04-Requirements.html
  11. https://www.jamasoftware.com/requirements-management-guide/writing-requirements/functional-vs-non-functional-requirements/
  12. https://www.altexsoft.com/blog/functional-and-non-functional-requirements-specification-and-types/
  13. https://arxiv.org/abs/1611.08868
  14. https://maddevs.io/blog/functional-vs-non-functional-requirements/
  15. https://www.perforce.com/blog/alm/what-are-non-functional-requirements-examples
  16. https://www.blazemeter.com/blog/key-test-metrics-to-track
  17. https://www.splunk.com/en_us/blog/learn/performance-testing.html
  18. https://speedscale.com/blog/determine-throughput-performance-testing/
  19. https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/performance-test
  20. https://builtin.com/software-engineering-perspectives/non-functional-requirements
  21. https://business.adobe.com/blog/how-to/the-5-ps-of-peak-season-performance-a-guide-to-preparing-your-infrastructure-for-high-traffic
  22. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197-upd1.pdf
  23. https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nbsspecialpublication500-121.pdf
  24. https://gdpr-info.eu/art-32-gdpr/
  25. https://www.iso.org/standard/68383.html
  26. https://measuringu.com/iso-9241/
  27. https://www.nngroup.com/articles/usability-101-introduction-to-usability/
  28. https://digital.ahrq.gov/sites/default/files/docs/survey/systemusabilityscale%252528sus%252529_comp%25255B1%25255D.pdf
  29. https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
  30. https://www.perforce.com/blog/qac/what-is-iso-25010
  31. https://learn.microsoft.com/en-us/visualstudio/code-quality/code-metrics-cyclomatic-complexity?view=vs-2022
  32. https://queue.acm.org/detail.cfm?id=1394128
  33. https://dl.acm.org/doi/10.1145/3592598
  34. https://www.mitre.org/sites/default/files/pdf/obenland_posix.pdf
  35. https://www.iso.org/standard/35733.html
  36. https://sarcouncil.com/download-article/SJECS-192-_2025-575-580.pdf
  37. https://www.devzero.io/blog/microservices-best-practices
  38. https://www.redhat.com/en/blog/nonfunctional-requirements-architecture
  39. https://ieeexplore.ieee.org/document/9371679
  40. https://ieeexplore.ieee.org/document/6894844
  41. https://www.volere.org/templates/volere-requirements-specification-template/
  42. https://www.researchgate.net/publication/260678650_Elicitation_and_Modeling_Non-Functional_Requirements_-_A_POS_Case_Study
  43. https://dl.acm.org/doi/10.1145/1005959.1005964
  44. https://pdfs.semanticscholar.org/f3bb/91080c4573f6f78f30bc5b48bda3ef252bf2.pdf
  45. https://dl.acm.org/doi/pdf/10.5555/771322.771361
  46. https://arc42.org/overview
  47. https://marketplace.atlassian.com/apps/1213064/easerequirements-requirements-management-for-jira-r4j
  48. https://marketplace.atlassian.com/apps/1237857/ibm-doors-ng-integration-for-jira
  49. https://www.inflectra.com/tools/requirements-management/best-requirements-management-tools
  50. https://clockwise.software/blog/functional-and-nonfunctional-requirements/
  51. https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/metrics-for-non-functional-testing.html
  52. https://www.nngroup.com/articles/rating-scales/
  53. https://www.browserstack.com/guide/stress-testing
  54. https://www.inflectra.com/Ideas/Topic/Requirements-Traceability.aspx
  55. https://ietresearch.onlinelibrary.wiley.com/doi/full/10.1049/sfw2.12037
  56. https://www.researchgate.net/publication/336752736_Tradeoff_Analysis_for_Conflicting_Software_Non-Functional_Requirements
  57. https://ewh.ieee.org/r2/southern_nj/BarbacciOct03.pdf
  58. https://ieeexplore.ieee.org/document/6897177
  59. https://www.researchgate.net/publication/361184121_Role_of_Non-functional_Requirements_in_projects%27_success
  60. https://docs.arc42.org/section-1/
  61. https://docs.arc42.org/section-10/
  62. https://www.workingsoftware.dev/the-ultimate-guide-to-write-non-functional-requirements/
  63. https://www.modernanalyst.com/Careers/InterviewQuestions/tabid/128/ID/651/What-is-MoSCoW-and-how-is-it-beneficial-for-prioritizing-requirements.aspx
  64. https://www.sei.cmu.edu/library/architecture-tradeoff-analysis-method-collection/
  65. https://www.scrum.org/resources/blog/how-handle-non-functional-requirements-nfrs
  66. https://swehb.nasa.gov/display/SWEHBVD/SWE-199%2B-%2BPerformance%2BMeasures
  67. https://nasa.github.io/progpy/npr7150.html
  68. https://www.nature.com/articles/s41598-024-52802-0
  69. https://qualizeal.com/the-future-of-test-automation-trends-and-predictions-for-2025-and-beyond/
Add your contribution
Related Hubs
User Avatar
No comments yet.