Non-Functional Requirements (NFRs) Framework for Software Systems - Glossary of Terms and Phrases
Non-Functional Requirements (NFRs) Framework for Software Systems
Chapter 4. Glossary of Terms and Phrases
Overview
This glossary defines important terms, phrases, abbreviations, and acronyms used throughout the Non-Functional Requirements (NFRs) Framework. It is intentionally placed near the front of the document so readers can interpret the framework consistently before applying it to software systems and solutions.
| Term or Phrase | Abbreviation or Acronym | Definition |
|---|---|---|
| Acceptance Criteria | Specific conditions that must be satisfied for a requirement, feature, test, control, or deliverable to be accepted. | |
| Accessibility | The degree to which a software system or solution can be used by people with disabilities, including users who rely on assistive technologies. | |
| Accessibility Conformance Level | A defined level of accessibility compliance or alignment, such as WCAG Level A, Level AA, or Level AAA, used to evaluate whether accessibility requirements have been satisfied. | |
| Agile Work Management System | A tool or platform used to manage Agile work items such as epics, features, user stories, tasks, defects, acceptance criteria, and delivery workflow. | |
| AI Agent | An AI-enabled software capability that can interpret input, reason over context, take actions, use tools, produce outputs, or participate in workflows with varying degrees of autonomy. | |
| AI Validation | The testing, review, evaluation, monitoring, evidence collection, and stakeholder approval used to determine whether an AI-enabled system satisfies its functional, non-functional, risk, safety, security, privacy, compliance, and governance expectations. | |
| AI-Enabled System | A software system or solution that incorporates Artificial Intelligence (AI), machine learning, generative AI, AI agents, model inference, retrieval, or automated decision support as part of its functionality. | |
| Anonymization | The process of transforming data so that individuals can no longer reasonably be identified from the data, either directly or indirectly. | |
| Application Portfolio Management | APM | The discipline of governing an application portfolio to improve value, cost, risk, quality, lifecycle decisions, and alignment with business and technology strategy. |
| Application Programming Interface | API | A defined interface that allows software systems, services, or components to communicate and exchange data or functionality. |
| Artifact Provenance | Information that identifies the origin, source, build process, dependencies, creator, integrity, and custody of a software artifact. | |
| Artifact Signing | The practice of cryptographically signing a software artifact so its origin and integrity can be verified. | |
| Artificial Intelligence | AI | Technology that can perform tasks normally associated with human intelligence, such as analysis, generation, classification, prediction, reasoning, or automation support. |
| Assistive Technology | Hardware, software, or devices used by people with disabilities to access, navigate, understand, or interact with digital content and software systems. | |
| Availability | The degree to which a software system, service, application, platform, or capability is accessible and usable when needed. | |
| Backup | A copy of data, configuration, software, or system state that can be used to restore a system or solution after loss, corruption, or failure. | |
| Backward Compatibility | The ability of a software system, interface, component, data structure, or configuration to continue working with older versions, consumers, clients, integrations, or dependencies. | |
| Business Continuity | The ability of an organization to continue critical business operations during or after a disruption. | |
| Coexistence | The ability of a software system or solution to perform required functions while sharing an environment, platform, network, database, runtime, resources, or dependencies with other systems without causing unacceptable impact. | |
| Compatibility | The degree to which a software system, component, service, interface, platform, or dependency can operate correctly with specified environments, technologies, versions, configurations, integrations, or coexisting systems. | |
| Compliance | The degree to which a software system or solution satisfies applicable laws, regulations, policies, standards, contractual obligations, and audit expectations. | |
| Consent Management | The capability to capture, manage, enforce, audit, and update user consent or privacy preferences related to data collection, processing, sharing, or retention. | |
| Continuous Integration / Continuous Delivery | CI/CD | Engineering practices and automation pipelines used to integrate, build, test, package, deploy, and release software changes. |
| Control Framework | A structured set of control objectives, control activities, requirements, or practices used to manage risk, compliance, governance, security, privacy, operations, quality, or audit expectations. | |
| Cross-Border Processing | The processing, transfer, access, storage, or use of data across national, regional, jurisdictional, or regulatory boundaries. | |
| Data Classification | The practice of categorizing data based on sensitivity, confidentiality, regulatory obligation, business criticality, or required protection level. | |
| Data Protection Impact Assessment | DPIA | A structured assessment used to identify, evaluate, document, and mitigate privacy and data protection risks associated with a system, process, product, service, or data processing activity. |
| Data Residency | The requirement or expectation that data be stored, processed, accessed, or retained within a specific country, region, jurisdiction, cloud region, or approved location. | |
| Data Sovereignty | The principle that data may be subject to the laws, regulations, controls, or government authority of the jurisdiction where it is collected, stored, processed, or accessed. | |
| Definition of Done | DoD | A shared set of criteria that must be satisfied before a work item, feature, release, or increment is considered complete. |
| Disaster Recovery | DR | The practices, capabilities, procedures, and technologies used to restore software systems, data, services, and operations after a significant disruption. |
| Elasticity | The ability of a software system or platform to dynamically scale resources up or down based on changing demand. | |
| Error Budget | The acceptable amount or rate of failure, unavailability, latency, error, or other NFR noncompliance allowed within a defined measurement window before corrective action, risk acceptance, or governance escalation is required. | |
| Evidence Source | A system, record, report, artifact, test result, dashboard, log, approval, or audit record used to prove that a requirement, control, or validation activity has been satisfied. | |
| Explainability | The degree to which an AI-enabled system can provide understandable reasons, factors, evidence, or logic that help stakeholders interpret how an output, recommendation, classification, or decision was produced. | |
| External Standard | A standard, framework, regulation, guideline, model, or reference source created outside the organization and used to guide, constrain, assess, validate, or govern requirements and solution decisions. | |
| Fail-Safe Behavior | The ability of a software system or solution to move to, remain in, or return to a safer state when a failure, exception, hazard, or abnormal condition occurs. | |
| Fairness | The degree to which an AI-enabled system avoids or manages harmful bias, discriminatory outcomes, or unacceptable differences in performance or treatment across relevant populations, contexts, or use cases. | |
| Forward Compatibility | The ability of a software system, interface, component, data structure, or configuration to tolerate, interact with, or be prepared for future versions, consumers, clients, integrations, or dependencies. | |
| Functional Requirement | A requirement that defines what a software system or solution must do, such as a feature, workflow, business rule, calculation, integration, or user interaction. | |
| Generative AI | GenAI | Artificial Intelligence (AI) that generates new content, outputs, code, images, text, summaries, recommendations, or other artifacts based on patterns learned from data and user-provided context. |
| Hazard | A condition, event, behavior, integration, dependency, or operating scenario that could contribute to unacceptable harm or loss. | |
| Human-in-the-Loop | HITL | A design or operating pattern in which a human reviews, approves, modifies, rejects, overrides, or supervises an AI-generated output, recommendation, decision, or action. |
| Infrastructure as Code | IaC | The practice of defining, provisioning, configuring, and managing infrastructure through machine-readable code or configuration files. |
| Internationalization | I18n | The design of software so it can support multiple languages, locales, formats, and regional conventions without major redesign. |
| Keyboard Navigation | The ability to access and operate software functionality using a keyboard or keyboard-like input without requiring a mouse, touch, or pointer device. | |
| Lawful Use | The use of data in a manner that is permitted by applicable law, regulation, policy, contract, consent, business purpose, or approved legal basis. | |
| Localization | L10n | The adaptation of software for a specific language, locale, country, region, currency, date format, time zone, or cultural expectation. |
| Measurement Window | The defined time period over which an indicator, target, threshold, service level, or NFR performance result is measured and evaluated. | |
| Model Drift | A change in model behavior, model performance, input patterns, output quality, or real-world context that causes an AI-enabled system to perform differently over time. | |
| Non-Functional Requirement | NFR | A requirement that defines a quality, constraint, operating expectation, validation expectation, or assurance criterion that a software system or solution must satisfy. |
| Observability | The ability to understand the internal state and behavior of a software system through logs, metrics, traces, events, dashboards, alerts, and health signals. | |
| Operability | The degree to which a software system or solution can be effectively deployed, monitored, administered, supported, troubleshot, and operated. | |
| Performance | The degree to which a software system or solution responds, processes, integrates, queries, or completes work within expected time, throughput, and resource targets. | |
| Personal Data | Data that identifies, relates to, describes, or can reasonably be linked to an identifiable individual. | |
| Platform as a Service | PaaS | A cloud service model that provides managed runtime, platform, and deployment capabilities for software applications. |
| Prompt Injection | An attack or misuse pattern in which user-provided, retrieved, embedded, or indirect input alters AI behavior or output in unintended or unauthorized ways. | |
| Pseudonymization | The process of replacing direct identifiers with alternate values so that individuals cannot be identified without additional separately protected information. | |
| Quality Assurance | QA | The practices, processes, and validation activities used to evaluate whether software satisfies requirements, quality expectations, and acceptance criteria. |
| Recoverability | The ability of a software system or solution to be restored after failure, outage, data loss, corruption, or disruption. | |
| Recovery Point Objective | RPO | The maximum acceptable amount of data loss, measured as the time between the last recoverable data point and the disruption. |
| Recovery Time Objective | RTO | The maximum acceptable amount of time required to restore a software system, service, capability, or process after a disruption. |
| Reference Architecture | A standardized architecture model, pattern, or guidance set used to inform solution design, technology selection, integration, governance, and implementation decisions. | |
| Reliability | The degree to which a software system or solution consistently performs correctly under expected and abnormal operating conditions. | |
| Requirements Document | A formal document that captures functional requirements, non-functional requirements, constraints, assumptions, acceptance criteria, stakeholders, validation methods, evidence expectations, and related delivery expectations. | |
| Resilience | The ability of a software system or solution to withstand, absorb, isolate, and recover from failures, overloads, dependency problems, and degraded conditions. | |
| Responsible AI | The discipline of designing, building, using, monitoring, and governing AI-enabled systems so they are valid, reliable, safe, secure, resilient, explainable, privacy-aware, fair, accountable, and aligned with intended use. | |
| Retrieval Source | A document, dataset, database, knowledge base, content repository, search result, or other information source used by an AI-enabled system to generate, ground, enrich, or validate output. | |
| Robust Implementation | The degree to which software content, markup, controls, and interaction patterns can be reliably interpreted by browsers, assistive technologies, and other user agents. | |
| Safe Integration | The degree to which a software system or solution can interact with other systems, devices, workflows, platforms, data sources, or operational processes without creating unacceptable safety risk. | |
| Safety | The degree to which a software system or solution avoids, prevents, detects, reduces, warns about, or recovers from conditions that could create unacceptable harm. | |
| Safety Validation | The testing, analysis, review, simulation, evidence collection, or approval activity used to confirm that safety-related requirements and controls have been satisfied. | |
| Scalability | The ability of a software system or solution to handle growth in users, transactions, data, integrations, workloads, or infrastructure demand. | |
| Secure Software Development Framework | SSDF | A NIST framework that defines secure software development practices that can be integrated into Software Development Lifecycle (SDLC) implementations. |
| Sensitive Data | Data that requires additional protection because disclosure, misuse, alteration, loss, or unauthorized access could harm individuals, organizations, operations, or compliance posture. | |
| Service Level Agreement | SLA | A formal agreement that defines service expectations, service targets, responsibilities, and consequences for not meeting agreed service levels. |
| Service Level Indicator | SLI | A specific metric used to measure the actual behavior or performance of a service or system against a defined service level objective. |
| Service Level Objective | SLO | A measurable target for a service quality attribute, such as availability, latency, throughput, or error rate. |
| Site Reliability Engineering | SRE | An engineering discipline focused on improving service reliability, availability, operability, observability, scalability, and incident response through automation and operational engineering practices. |
| Smoke Testing | A limited set of tests performed after deployment to confirm that critical functions, integrations, and access paths are working. | |
| Software as a Service | SaaS | A software delivery model in which applications are hosted and operated by a provider and accessed by users over a network. |
| Software Bill of Materials | SBOM | A structured inventory of software components, dependencies, libraries, and related metadata used to understand and manage software supply chain risk. |
| Software Development Lifecycle | SDLC | The lifecycle through which software is planned, designed, built, tested, validated, deployed, operated, improved, and retired. |
| Software Supply Chain Security | The discipline of protecting and validating the software lifecycle from source code and dependencies through build, packaging, release, deployment, and operation. | |
| Standards Alignment | The practice of mapping requirements, controls, designs, tests, evidence, and governance decisions to applicable internal or external standards, frameworks, models, or obligations. | |
| Supply-chain Levels for Software Artifacts | SLSA | A software supply chain security framework focused on preventing tampering, improving integrity, and securing software packages and infrastructure. |
| Supportability | The degree to which a software system or solution can be supported by help desk, operations, engineering, vendor, or service management teams. | |
| Systems Integration Testing | SIT | Testing that validates how multiple systems, services, components, interfaces, and data flows work together. |
| Technology Portfolio Management | TPM | The discipline of governing technologies, platforms, tools, and technical assets to improve value, cost, risk, lifecycle decisions, and strategic alignment. |
| Testability | The degree to which a software system, component, requirement, or control can be tested and verified. | |
| Third-Party Component | A software component, dependency, library, package, service, container image, tool, or artifact supplied by an external party. | |
| Traceability | The ability to link requirements to designs, decisions, controls, tests, validation methods, evidence, defects, risks, approvals, and operational outcomes. | |
| User Acceptance Testing | UAT | Testing performed to validate that a software system or solution satisfies user, business, workflow, and acceptance expectations. |
| User Experience | UX | The overall experience users have when interacting with a software system, including usability, clarity, efficiency, satisfaction, and accessibility. |
| Validation Method | A test, analysis, inspection, review, simulation, monitoring activity, audit, or other method used to determine whether a requirement has been satisfied. | |
| Web Content Accessibility Guidelines | WCAG | A widely used set of guidelines for making web content and applications more accessible to people with disabilities. |
How to cite this page
When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.
Example (informal web citation):
The International Foundation for Information Technology (IF4IT), LLC. Glossary of Terms and Phrases | Non-Functional Requirements (NFRs) Framework for Software Systems. https://if4it.org/best-practices/non-functional-requirements-nfrs-framework-for-software-systems/glossary-of-terms-and-phrases/ (accessed 2026-07-23).
See About Us for content governance and site-wide citation guidance.
Copyright for The International Foundation for Information Technology (IF4IT), LLC: 2008 - Present
Legal Disclaimers