Enterprise AI Project Wiki · Requirements and business scenarios
Non-functional requirement
Also calledNonfunctional requirement · NFR · Quality requirement · Quality-attribute requirement
A non-functional requirement is a normative statement about a quality characteristic, required quality level, or sourced implementation or operational constraint on a system, product, service, or environment. It states the object, context, load, time window, risk condition, measurable response, or justified boundary under which functions must operate, and it must be verifiable, traceable, allocatable, and change-controlled.
An NFR is a verifiable quality requirement or constraint, not an other-requirements bucket
Stable, secure, usable, and fast express concerns but name no object, condition, judge, measure, statistic, threshold, or failure boundary. They become manageable only when refined into a quality characteristic and a reproducible, measurable scenario.
The term is contested because security, recovery, and audit qualities often derive concrete functions, and what versus how is not a permanent divide. A project may retain NFR or manage named performance, security, and reliability classes directly. It must declare the taxonomy, prevent omissions, and still write necessary, verifiable obligations.
Quality is not decoration added after implementation. Capacity, isolation, recovery, accessibility, maintainability, and supplier exit shape architecture, data, interfaces, deployment, and operations. Late discovery can leave working features unusable under real load, risk, or maintenance conditions.
Quality and constraint classes commonly covered
When users say a service is difficult, they may mean slow, frequently interrupted, confusing about access, or unable to restore their work. Quality classes separate these problems. ISO/IEC 25010:2023 can expose omissions, but the project still selects relevant attributes from real context and risk rather than copying every category.
Performance efficiency and capacity
Response, throughput, concurrency, batch scale, resource use, and maximum capacity with workload, data size, observation point, window, and statistic.
Compatibility and interoperability
Coexist without harmful interference and exchange and use information with shared semantics, including format, protocol, version, and environmental conditions.
Interaction capability and accessibility
Specified users can recognise, learn, operate, prevent and recover from errors, and use assistive technology in a stated task and context—not merely enjoy a friendly interface.
Reliability, availability, and fault tolerance
Correct continuity over stated conditions and periods, permitted failures, service availability, isolation, graceful degradation, data recovery, and post-recovery integrity.
Security and privacy
Protection needs and risks refined into confidentiality, integrity, availability, authenticity, accountability, least privilege, privacy handling, incident response, and supply-chain requirements.
Maintainability and observability
Modularity, analysis, modification, test, release, monitoring, logs, diagnostics, and knowledge handover so a named team can maintain the system within its authority and target.
Flexibility, adaptability, and replaceability
Adaptation, scaling, installation, migration, replacement, and exit as environment, rules, languages, volume, and suppliers change—rather than unlimited scalability.
Safety and hazard control
Where failure can harm people, property, environment, or critical business outcomes, govern hazard prevention, fail-safe state, intervention, isolation, and recovery.
Operational and lifecycle constraints
Deployment region, residency, support hours, backup, retention, licences, standards, resources, energy, and retirement may be quality requirements or external constraints; identify the source.
Write quality as a reproducible and measurable scenario
“Respond quickly” means different things for ten people viewing short records and thousands processing long documents together. A quality scenario combines user, load, environment, stimulus, and observed response so a test can reproduce the conditions, not just measure a detached number.
Quality object
Name the end-to-end service, interface, batch, user task, model combination, support operation, or component. Component figures do not automatically represent service quality.
Stimulus source
Identify who or what creates the request, load, fault, attack, data change, maintenance action, or user error, and whether it is representative, peak, malicious, or rare.
Stimulus and input scale
Quantify event, rate, concurrency, size, distribution, complexity, and duration. Many users and complex documents are not reproducible.
Environment and state
State normal, peak, degraded, maintenance, recovery, or dependency-failure conditions, including region, resources, data version, and cache state.
Expected response
Say how the system continues, refuses, degrades, isolates, alerts, recovers, or remains safe, linking the affected function and role.
Response measure
Define observation point, instrument, start and end, unit, window, percentile or ratio, tolerance, exclusions, and minimum sample.
Threshold and failure class
Separate objective, minimum pass line, severe failure, and hard stop; define single versus sustained breach, approval authority, and waiver or reassessment.
What to record in a manageable NFR
A quality number has meaning only with its object, conditions, statistical method, and business consequence. The team also needs the measurement source, failures that an average must not hide, and the person who decides degradation or suspension when the target is missed.
Stable ID, attribute, and level
Name the quality class, system level, and configuration baseline so high availability does not drift between service, component, and infrastructure.
Source, rationale, and consequence
Trace to user needs, business outcome, risk, incident, regulation, contract, operations, or architecture, and explain who and what suffers if it is missed.
Applicable function and priority
Attach quality to critical functions, scenarios, data, and roles. Different paths can have justified levels rather than one unexplained maximum.
Complete quality scenario
Record object, stimulus source, stimulus, environment, response, and measure across peak, exception, attack, maintenance, dependency failure, and recovery.
Metric and sampling rule
Define formula, numerator and denominator, sample unit, source, window, percentile or confidence, and missing-data and outlier treatment.
Threshold, tolerance, and severe failure
Distinguish target, minimum, tolerance, sustained breach, and unacceptable single event. Keep unsupported values as owned, dated TBDs.
Verification and production monitoring
Select load test, fault injection, analysis, inspection, user evaluation, or security assessment and identify production evidence of continuing conformance.
Allocation, authority, and trade-off
Allocate across architecture, people, suppliers, and operations, recording implementation and verification owners, residual-risk authority, and attribute trade-offs.
Version, status, and change trigger
Link requirement, design, configuration, test, and monitoring versions and define revalidation after load, data, model, supplier, deployment, or criticality changes.
How to discover, quantify, and approve NFRs
A mature quality target rarely comes directly from one interview. It grows from user waiting, incident history, capacity data, regulatory boundaries, and recovery exercises, followed by measurement of the current state and comparison of feasible options. A target without evidence remains a value to validate, not an invented industry benchmark.
Begin with business consequence
Ask which functions must not be slow, wrong, unavailable, exposed, unrecoverable, or unmaintainable, who is affected, and what is irreversible.
Cover roles, scenarios, and lifecycle
Include users, operations, maintenance, security, privacy, interface owners, support, and retirement across normal, peak, failure, change, and recovery.
Use a quality model to find gaps
Check performance, compatibility, interaction, reliability, security, maintainability, flexibility, and safety, selecting only sourced attributes applicable to the system.
Collect baseline evidence
Use logs, demand, user research, incidents, tickets, regulation, interface commitments, supplier capability, and experiments. When no baseline exists, define how to obtain it.
Write the quality scenario
Define object, stimulus, environment, response, and measure by function and risk tier; agree the metric before negotiating a threshold.
Analyse feasibility and trade-offs
Architecture, operations, security, data, user, commercial, and business roles compare cost, complexity, supplier dependence, and quality conflicts with residual risk.
Approve threshold and evidence plan
Business and risk authority approve minimums and trade-offs; engineering confirms measurement feasibility; name environment, data, tools, witness, and failure disposition.
Baseline and recalibrate under control
Connect functions, architecture, tests, monitoring, and service responsibilities. Real production evidence can support a controlled change, not silently overwrite the requirement.
How to govern trade-offs among quality attributes
Stricter checks can add latency, longer log retention can increase privacy and cost pressure, and higher availability may need more infrastructure. Do not bury these trade-offs in implementation. Show effects on users, risk, and operations, then have the authorised owner approve the context and priority.
Identify non-negotiable boundaries
Applicable law, life safety, formal security policy, and contractual minimums can be hard constraints whose applicability and interpretation require authority.
Return the trade-off to a scenario
Stronger verification may slow a normal path but lower unauthorised high-risk action. Compare role, function, risk tier, and mode rather than security versus experience in the abstract.
Compare alternatives on one basis
Show performance, reliability, security, maintainability, cost, schedule, lock-in, and operational burden, including evidence scope and uncertainty.
Allow justified service tiers
Critical decisions and ordinary queries may use different availability, review, latency, or recovery levels, provided a low tier cannot bypass a control.
Record decision and residual risk
Preserve options, evidence, participants, authority, rationale, accepted risk, compensating controls, and review date. Engineering convenience cannot accept business risk.
Revisit with experiments and monitoring
Use capacity work, user research, resilience exercises, security assessment, or staged operation to reduce uncertainty and reopen decisions on a defined trigger.
Quality gates before approving an NFR baseline
An NFR can be grammatically complete and still impossible to verify because concurrency, observation window, or severe-failure definition is missing. Confirm that measurement is executable, the threshold matches business risk, and the test environment represents the intended operating conditions.
- Attribute, object, and source explicit?
Each item is an explainable quality or constraint on a named system and function and traces to need, risk, standard, contract, or evidence.
Inspect class, object, source, and rationale.
- Scenario and environment reproducible?
Stimulus, load, data, state, deployment, dependencies, and window allow reconstruction without averaging normal and exceptional conditions.
Inspect quality scenario and environment configuration.
- Metric unambiguous?
Start/end, tool, unit, sample, denominator, percentile, window, outlier, and exclusion rules replace near-real-time and most.
Inspect metric dictionary and worked calculation.
- Threshold evidenced and feasible?
Targets and minimums derive from consequence, baseline, experiment, standard, or contract and fit technical, commercial, staffing, and supplier conditions.
Inspect baseline, experiment, feasibility, and approval.
- Conflicts and residual risk decided?
Performance, security, reliability, experience, maintenance, cost, and schedule are transparently compared and approved by matching authority.
Inspect trade-off, risk acceptance, and compensating control.
- Verifiable before delivery and observable in production?
Test or analysis makes a clear decision, production uses consistent metrics, and access and privacy around measurements are controlled.
Inspect verification plan, dashboard definition, and response owner.
- Allocation, trace, and change triggers complete?
Functions, elements, suppliers, evidence, acceptance, and operations connect, and component, load, data, or risk change triggers analysis.
Inspect traceability, configuration, and change rules.
Constructed NFRs for a procurement-request service
This customer-independent procurement service shows measurable structures for waiting time, availability, recovery, and access protection. Values remain approval variables because a defensible threshold comes from the actual baseline, risk, and budget—not from borrowing another project's target.
NFR-PERF-01: readiness-check performance
For representative evidence size, rule count, and approved concurrency distribution in a named pre-production configuration and observation point, end-to-end readiness checks shall meet percentile threshold T1 approved from capacity evidence and business tolerance, while timeout and refusal rates are recorded.
NFR-REL-02: preserve state during dependency failure
When rules or evidence services fail during submission, the system shall create no partial submission or duplicate notice, preserve a recoverable draft and idempotency record, and enable authorised reprocessing within approved recovery objective R1.
NFR-SEC-03: isolate sensitive evidence
Across normal, export, log, cache, and support paths, evidence shall be available only to currently authorised subjects; unauthorised tests return neither content nor inferable sensitive values and create governed security evidence.
NFR-USE-04: recover from input errors
Representative applicant roles on approved devices and assistive technology shall recognise each blocker, locate correction, and continue without re-entering validated material; success, time, and severe-error thresholds require user-research approval.
NFR-MAINT-05: maintain rule versions
Authorised maintainers shall prepare, review, test, approve, and roll back rule versions without changing application code, with actor, difference, evidence, and effective time linked throughout.
NFR-OBS-06: observe critical paths
Submission, refusal, human routing, dependency failure, and state side effects shall emit correlated, access-controlled records enabling on-call staff to identify affected version, dependency, and request population within target diagnostic time D1.
How NFRs govern architecture, verification, acceptance, and operations
Quality requirements often drive architecture choices such as caching, scaling, backup, logging, and failure isolation, all with continuing cost. Acceptance proves performance only under named conditions. Production must monitor the same definitions to reveal when load, data, or supplier change begins to erode quality.
Quality register and scenario library
Maintain requirements, scenarios, metric dictionary, thresholds, sources, owners, and status by attribute instead of allowing proposal, contract, test, and chat definitions to diverge.
Architecture influence and allocation
Record which decisions, elements, suppliers, and operating processes jointly satisfy a quality and their assumptions. End-to-end quality does not belong to one code component.
Verification in a representative environment
Select capacity work, fault injection, recovery exercise, security assessment, user research, static analysis, or inspection and disclose differences from production.
Acceptance and service levels
Select delivery object, sample, environment, and pass line from the full baseline. An SLA may reuse metrics, but project acceptance does not prove every continuing service promise.
Deviation, waiver, and technical debt
Record requirement version, observation, impact, compensating control, owner, date, and authorised approval. Later optimisation is not automatic acceptance.
Production monitoring and capacity review
Observe trends, strata, and severe failures with consistent metrics and named alerts and response; revalidate after major load, architecture, data, model, or supplier change.
Handover and maintenance
Transfer the quality baseline, measurement scripts, dashboards, alerts, capacity model, recovery evidence, security and usability findings, known limits, and trade-offs.
Enterprise AI NFRs cover the composite, probabilistic behaviour, and continuing change
A model leaderboard score describes part of a capability under controlled conditions. A real service also passes through retrieval, access control, tools, and human queues across languages, evidence states, and risk levels. AI quality needs stratified scenarios and continuing observation of each composite version.
Evaluate the composite system
Name application, model, prompt, knowledge, retrieval, rules, tools, and human workflow versions. A model benchmark does not represent end-to-end task quality, authority, or reliability.
Functional correctness and task performance
Define correct, complete, appropriate, and severe error by task, scenario, language, evidence state, and risk tier with representative samples, labelling rules, repetitions, and statistics.
Robustness and boundary behaviour
Cover input variation, noise, long documents, prompt attacks, conflicting sources, distribution shifts, and supplier degradation with performance-drop, refusal, isolation, and stop thresholds.
Transparency, explanation, and evidence trace
For each user and decision owner, govern comprehensibility of source, version, uncertainty, limitation, rationale, and action record without exposing sensitive internals.
Controllability and intervenability
State when users or operators can correct context, cancel generation, block tools, request a person, override advice, suspend components, and roll back, including intervention time.
Fairness, privacy, security, and safety
Evaluate group differences and risk paths for data use, leakage, unauthorised action, abuse, hazard, and adversarial behaviour. Mean quality cannot cancel a severe individual or group failure.
Latency, capacity, cost, and resources
End-to-end response includes retrieval, model, tools, and human queues. Measure task time, throughput, concurrency, call cost, resources, and degradation rather than model latency alone.
Monitorability, reproducibility, and fallback
Within privacy bounds retain input class, composite version, result, severe failure, and human disposition for reproducible regression, staged rollout, rollback, and a non-AI path.
One good evaluation cannot replace observation after go-live
A pre-release result describes the samples and composite version used at that time. Production evidence, user phrasing, purpose, and supplier behaviour continue to change, so red-teaming, monitoring, incident feedback, and periodic review need comparable stratified measures. Material change triggers fresh evaluation and approval.
How NFRs differ from neighbouring concepts
An NFR is not a post-feature optimisation list, and an SLA is not its whole definition. It states how well the system must behave or which constraint applies under named conditions, shaping architecture, cost, test, and operation. Aspirations, design principles, and supplier claims do not replace verifiable requirements.
| Concept | Boundary from a non-functional requirement |
|---|---|
| Functional requirement | States what the system does and produces; an NFR states the quality level or quality and constraint boundary. Link them rather than choose one. |
| Quality attribute | Performance, reliability, and security are classification concepts. They become requirements only with object, condition, measure, and threshold. |
| Performance requirement | Governs time, throughput, capacity, and resources and is commonly a quality or NFR subtype; it needs separate depth and does not represent all NFRs. |
| Constraint | Limits design, implementation, or operation through a standard, region, licence, or interface. It can be classed as an NFR but needs an authoritative source and may not state a quality level. |
| System requirement | The system baseline contains functions, performance, interfaces, data, qualities, and constraints; NFRs are one quality-oriented subset. |
| Architecture and design | Choose how to realise qualities. NFRs drive and constrain alternatives; analysis can create derived requirements, but means are not the quality objective. |
| Service-level agreement | An operational or contractual arrangement covering measures, exceptions, responsibilities, and remedies. It may cite NFRs but has different scope and legal effect. |
| Acceptance criterion | Applies approved quality requirements to a named version, environment, sample, and pass decision. One acceptance event cannot establish all long-term quality. |
| Test objective and test case | Select a risk and define environment, load, procedure, and expectation for evidence. A test number should not reverse-create an unsupported requirement. |
| Monitoring metric and SLO | A metric observes production and an SLO sets a period objective. They can operationalise an NFR, but their existence does not prove threshold authority. |
| Project or process requirement | Budget, schedule, review, coding method, and delivery procedure constrain work; they are product NFRs only when they explicitly constrain product or service quality. |
| Compliance requirement | Law, regulation, contract, or policy can derive functional, quality, evidence, and process obligations. Comply with all laws is not one verifiable NFR. |
Sources and scope
This entry explains a non-functional requirement in systems and software requirements engineering: a normative quality or sourced constraint on a system or service, such as performance efficiency, compatibility, interaction capability, reliability, security, maintainability, flexibility, or safety. Usage is not uniform: IREB defines an NFR as a quality requirement or constraint, while some teams avoid the umbrella term and name the quality directly. This entry does not fully define functional or performance requirements, service-level agreements, architecture, design constraints, security, privacy, usability, reliability, maintainability, acceptance criteria, test strategy, or regulatory compliance, and it does not put every unclassified project matter into an NFR bucket. Authorised project roles must approve attributes, measures, thresholds, trade-offs, and applicability.
- ISO/IEC/IEEE 29148:2018: requirements engineering, well-formed characteristics, system and software specifications, validation, traceability, and change; confirmed current in 2024
- ISO/IEC/IEEE 15288:2023: system lifecycle processes spanning technical requirements, decomposition, architecture, verification, operation, maintenance, and retirement
- ISO/IEC 25010:2023: nine-characteristic product quality model for ICT and software products, supporting specification, measurement, evaluation, testing, and acceptance
- ISO/IEC 25059:2023: consistent terminology for specifying, measuring, evaluating, and checking AI-system quality requirements; this edition is under revision
- NASA Technical Requirements Definition: performance, environment, safety, human factors, and quality attributes join functions and interfaces in a complete technical baseline
- NASA How to Write a Good Requirement: performance, reliability, maintainability, and other requirements should be realistic, measurable, verifiable, and bidirectionally traceable
- NASA Software Requirements Specification: NFRs covering performance and timing, quality attributes, operational characteristics, resources, and sourced design constraints
- IREB CPRE Glossary: a non-functional requirement is a quality requirement or constraint, with performance treated as a quality subtype
- NIST SP 800-160 Vol. 1: engineering trustworthy, secure, survivable systems from stakeholder protection needs and risk throughout the lifecycle
- NIST AI RMF Core: intended use, risk tolerance, metrics, human oversight, transparency, fairness, security, resilience, and continuous monitoring