Search Results
5319 results were found. |
Print Results |
|
-ilities.
(1)
developmental, operational, and support requirements a program addresses
(ISO/IEC/IEEE 24765l:2024)
Note: named because they typically end in "ility", such as availability, maintainability, vulnerability, reliability, supportability
|
|
1GL.
(1)
first-generation language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: machine language
|
|
2GL.
(1)
second-generation language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assembly language
|
|
3D.
(1)
three-dimensional
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
Syn: 3-D
|
|
3GL.
(1)
third-generation language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: high order language
|
|
4GL.
(1)
fourth-generation language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
5GL.
(1)
fifth-generation language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A-profile.
(1)
Application profile
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
A/B testing.
(1)
technique to determine the effectiveness of minor changes in a product or design where "A" represents the original version and "B" represents the modified version
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.1)
(2)
statistical testing approach that allows testers to determine which of two systems or components performs better
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.1)
Syn: split-run testing
|
|
A/IS.
(1)
autonomous/intelligent system
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.2)
|
|
A/IS creator.
(1)
person or entity that designs, develops, engineers, programs or similarly creates an autonomous/intelligent system (A/IS)
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.1)
|
|
Aa.
(1)
achieved availability
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
ABAC.
(1)
attribute-based access control
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
ABC.
(1)
activity-based costing
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
abend.
(1)
abnormal end
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
ability.
(1)
acquired or natural capacity or talent that enables an individual to perform a particular task
(INCOSE Systems Engineering Handbook, 5th ed.)
See Also: capability
|
|
abnormal end (abend).
(1)
termination of a process prior to completion
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
uncommanded cessation of software execution, typically resulting in a terminal failure
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Syn: abnormal termination, blue screen, panic
See Also: crash, exception
|
|
absent variant.
(1)
variant that is not determined or developed at the specific time
(ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.1)
|
|
absolute address.
(1)
address that is permanently assigned to a device or storage location and that identifies the device or location without the need for translation or calculation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: explicit address, specific address
See Also: relative address, relocatable address, symbolic address, absolute assembler, absolute code, absolute instruction
|
|
absolute assembler.
(1)
assembler that produces absolute code
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: relocating assembler
|
|
absolute code.
(1)
code in which all addresses are absolute addresses
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: specific code
See Also: relocatable code
|
|
absolute instruction.
(1)
computer instruction in which all addresses are absolute addresses
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: direct instruction, effective instruction, immediate instruction, indirect instruction
|
|
absolute loader.
(1)
loader that reads absolute machine code into main memory, beginning at the initial address assigned to the code by the assembler or compiler, and performs no address adjustments on the code
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: relocating loader
|
|
absolute time.
(1)
tick in a generally agreed chronological frame of reference
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Example: a calendar date and time of day in a given reference time zone, such as Coordinated Universal Time (UTC)
See Also: relative time, natural unit
|
|
abstract behavior.
(1)
description, model, or other general characterization of similar behaviors
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Example: use cases, protocol message types, sequence diagram messages, interface control documents
Syn: abstract behaviour
|
|
abstract class.
(1)
class that cannot be instantiated independently
(ISO/IEC/IEEE 24765n:2025, 3.1.1)
Note: That is, instantiation is accomplished via a subclass. A class for which every instance is also an instance of a subclass in the cluster (a total cluster) is called an abstract class with respect to that cluster.
|
|
abstract data type.
(1)
data type for which only the properties of the data and the operations to be performed on the data are specified, without concern for how the data are represented or how the operations are implemented
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
abstract design.
(1)
generic form that needs specialization (further design work) to produce concrete designs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
design aimed at producing designs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
abstraction.
(1)
view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information
(ISO/IEC/IEEE 24765l:2024)
(2)
process of suppressing irrelevant detail to establish a simplified model, or the result of that process
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 6.3)
See Also: data abstraction
|
|
AC.
(1)
actual cost
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
access control
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
acceptability.
(1)
exposure to loss (financial or otherwise) that an organization is willing to tolerate from a risk
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
extent to which a human response is favorable when accepting or installing a product, system, or service software tool designed to perform some frequently used function
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.2.3)
Note: Risk acceptability can apply to an individual risk or to a collection of risks, such as the totality of risks confronting a project or enterprise. Acceptability can differ for different categories of risk and can depend on the cost of treatment or other factors.
|
|
acceptability criteria.
(1)
documented set of characteristics of a program's work products that if satisfied, forms a sufficient basis for judging each product's content to be acceptable to support a successful review or audit
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.1)
|
|
acceptable.
(1)
meeting stakeholder expectations that can be shown to be reasonable or merited
(ISO/IEC/IEEE 24765c:2014)
|
|
acceptance.
(1)
action by an authorized representative of the acquirer by which the acquirer assumes ownership of products as partial or complete performance of an agreement
(ISO/IEC/IEEE 24748-5:2017 Systems and software engineering--Life cycle management--Part 5: Software development planning, 3.1)
|
|
acceptance criteria.
(1)
criteria that a system or component is required to satisfy to be accepted by a user, customer, or other authorized entity
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.1)
(2)
set of conditions that is required to be met before deliverables are accepted
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: requirement, test criteria
|
|
acceptance test.
(1)
test of a system or functional unit usually performed by the purchaser on his premises after installation with the participation of the vendor to help ensure that the contractual requirements are met
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
See Also: acceptance testing, validation test
|
|
acceptance test-driven development (ATDD).
(1)
development method in which team members with various backgrounds [developers, testers and business analysts] jointly write the acceptance tests before development of the relevant functionality
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.1)
Note: Test-driven development focuses on driving development by writing unit tests first; ATDD focuses on driving development by writing acceptance tests first.
|
|
acceptance testing.
(1)
testing conducted to determine whether a system satisfies its acceptance criteria and to enable the customer to determine whether to accept the system
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3)
(2)
formal testing conducted to enable a user, customer, or other authorized entity to determine whether to accept a system or component
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
See Also: acceptance test, validation test
|
|
access.
(1)
to obtain the use of a resource
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
access facility.
(1)
set of service primitives that allow a stub objects to negotiate the abstract and transfer syntax to be used for the operation data to be transmitted over the channel
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.1)
|
|
access method.
(1)
technique to obtain the use of data, the use of storage in order to read or write data, or the use of an input-output channel to transfer data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
access routine.
(1)
routine that provides access to a data structure that is hidden, usually because it is a global variable or used in an abstract data type.
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
access transparency.
(1)
distribution transparency which masks differences in data representation and invocation mechanisms to enable interworking between objects
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.4.1.1)
|
|
accessibility.
(1)
extent to which products, systems, services, environments, and facilities can be used by people from a population with the widest range of user needs, characteristics, and capabilities to achieve identified goals in identified contexts of use
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.1.14)
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.1)
(2)
degree to which a product or system can be used by people with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use
(ISO/IEC 25010:2011 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--System and software quality models, 4.2.4.6)
(3)
usability of a product, service, environment, or facility by people with the widest range of capabilities
(ISO/IEC 25062:2025 Systems and software engineering -- Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Common Industry Format (CIF) for reporting usability evaluations, 4.1)
(4)
consideration of a product, service, environment, or facility by people with the widest range of capabilities
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.2)
(5)
degree to which an IT service can be used by people with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.2.5)
(6)
extent to which products, systems, services, environments, and facilities can be used by people from a population with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use
(ISO/IEC 25064:2013 Systems and software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Common Industry Format (CIF) for usability: User needs report, 4.1)
(7)
for a cloud service, degree to which it can be accessed by a variety of client devices over a network through standard mechanisms
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.3.1)
Note: Although "accessibility" typically addresses users who have disabilities, the concept is not limited to disability issues. The range of capabilities includes disabilities associated with age. Accessibility for people with disabilities can be specified or measured either as the extent to which a product or system can be used by users with specified disabilities to achieve specified goals with effectiveness, efficiency, freedom from risk and satisfaction in a specified context of use, or by the presence of product properties that support accessibility [ISO 25063:2014]. Context of use includes direct use or use supported by assistive technologies.
|
|
accessibility testing.
(1)
type of usability testing used to measure the degree to which a test item can be operated by users with the widest possible range of characteristics and capabilities
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.2)
|
|
accident.
(1)
unplanned event or series of events that results in death, injury, illness, environmental damage, or damage to or loss of equipment or property
(IEEE 1228-1994 (R2002) IEEE Standard for Software Safety Plans, 3.1.1)
|
|
accountability.
(1)
capability of a product to enable actions of an entity to be traced uniquely to the entity
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.6.4)
|
|
accuracy.
(1)
qualitative assessment of correctness, or freedom from error
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
in machine learning, a performance metric used to evaluate a classifier, which measures the proportion of classifications predictions that were correct
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.2)
(3)
Within the quality management system, accuracy is an assessment of correctness
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(4)
quality of information that it is correct and consistent with a product
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.2)
See Also: precision
|
|
accuracy of measurement.
(1)
closeness of the agreement between the result of a measurement and the true value of the measurand
(ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.1)
Note: Accuracy is a qualitative concept. The term precision is not a synonym for "accuracy". [ISO/IEC Guide 99:2007 International vocabulary of metrology -- Basic and general concepts and associated terms] A true value is a value consistent with the definition of a given particular quantity and this is a value that would be obtained by a perfect measurement. In contexts where perfect measurement is not practically feasible, a conventional true value is a value attributed to a particular quantity and accepted, sometimes by convention, as having an uncertainty appropriate for a given purpose. 'Conventional true value', in the same reference, is sometimes called assigned value, best estimate of the value, conventional value or reference value. The accuracy can be expressed in terms of the Mean magnitude of relative error.
|
|
ACIA.
(1)
asynchronous communication interface adapter
(ISO/IEC/IEEE 24765d:2015)
|
|
ACID.
(1)
Atomicity Consistency Isolation Durability
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
acknowledged system of systems.
(1)
system of systems (SoS) with recognized objectives, a designated manager, and resources for the SoS
(ISO/IEC/IEEE 21841:2019 Systems and software engineering--Taxonomy of systems of systems, 3.2.1)
Note: Constituent systems retain their independent ownership, objectives, funding, and development and sustainment approaches. Changes in the systems are based on cooperative agreements between the SoS and the system.
Syn: acknowledged SoS
|
|
acquirer.
(1)
stakeholder that acquires or procures a product or service from a supplier
(ISO/IEC TS 33064:2025, Information technology Process assessment Process assessment model for safety processes, 4.1)
(2)
person or organization that acquires or procures a system, software product, or software service (which can be part of a system) from a supplier
(ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.13)
(3)
stakeholder that acquires or procures a system, product, or service from a supplier
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.1)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.1)
Example: buyer, owner, purchaser, internal/organizational sponsor
See Also: customer
|
|
acquisition.
(1)
process of obtaining a system, product, or service
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.2)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.2)
Note: Acquisition of a product can involve, but does not necessarily require, a legal contract or a financial transaction between the acquirer and supplier.
|
|
acquisition strategy.
(1)
specific approach to acquiring products and services that is based on considerations of supply sources, acquisition methods, requirements specification types, contract or agreement types, and related acquisition risks
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
action.
(1)
element of a step that a user performs during a procedure
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.3)
(2)
description of an operation to be taken in the formulation of a solution
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.7)
(3)
something which happens
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.3)
(4)
user behavior that a system accepts as a request for a particular operation
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.2.4)
|
|
action entry.
(1)
indication of the relevance of an action to a particular rule
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.9)
|
|
action of interest.
(1)
action in a transaction which leads to a state change of significance to the transaction
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 13.7.1.2)
|
|
action signature.
(1)
specification of an action that comprises the name for the action, the number, names and types of its parameters, and an indication of the causality of the object that instantiates the action template
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.14)
|
|
action stub.
(1)
list of all the actions to be taken in the solution of a problem
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.11)
|
|
activation.
(1)
one occurrence of a function's transformation of some subset of its inputs into some subset of its outputs
(ISO/IEC/IEEE 24765m:2024, 2.1.3)
|
|
activation constraint.
(1)
function's requirement for the presence of a non-empty object set in a particular arrow role as a precondition for some activation of the function
(ISO/IEC/IEEE 24765m:2024, 2.1.4)
|
|
activation function.
(1)
<neural network> formula associated with a node in a neural network that determines the output of the node (activation value) from the inputs to the neuron
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.3)
Syn: transfer function
|
|
activation value.
(1)
output of an activation function of a node in a neural network
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.4)
|
|
active area.
(1)
(on-screen documentation) area that responds to user input
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.4)
Example: A hot-spot on a graphic, a hyperlink in text, a button in a screen display
|
|
active enterprise object.
(1)
enterprise object that is able to fill an action role
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.3.1)
|
|
active interconnection.
(1)
physical interaction mechanism allowing the action of one thing to cause a change or to stimulate an action in another thing
(ISO/IEC/IEEE 24765i:2020)
|
|
active redundancy.
(1)
in fault tolerance, the use of redundant elements operating simultaneously to prevent, or permit recovery from, failures
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: standby redundancy
|
|
active text.
(1)
text displayed on the screen that responds to user input
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
active white space.
(1)
area around textual or graphical elements, not including margins, which breaks up text, separates topic and subtopic groupings, indicates hierarchical and topical relationships, highlights information, or makes text easier to read
(ISO/IEC/IEEE 24765a:2011)
|
activity.
(1)
set of cohesive tasks of a process
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.3)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.3)
(2)
set of cohesive tasks of a process, which transforms inputs into outputs
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
(3)
order submitted to the system under test (SUT) by a user or an emulated user demanding the execution of a data processing operation according to a defined algorithm to produce specific output data from specific input data and (if requested) stored data
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.1)
(4)
set of actions that consume time and resources and whose performance is necessary to achieve, or contribute to, the realization of one or more outcomes
(ISO/IEC TR 24766:2009 Information technology--Systems and software engineering--Guide for requirements engineering tool capabilities, 3.1)
(5)
single-headed directed acyclic graph of actions, where occurrence of each action in the graph is made possible by the occurrence of all immediately preceding actions (i.e., by all adjacent actions which are closer to the head)
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.6)
Note: An activity normally has an expected duration, cost, and resource requirements. Activities are often subdivided into tasks.
 process flow |
|
activity group.
(1)
set of related activities
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
activity list.
(1)
a documented tabulation of schedule activities that shows the activity description, activity identifier, and a sufficiently detailed scope of work description so project team members understand what work is to be performed
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
activity type.
(1)
classification of activities defined by the execution of the same algorithm
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.2)
|
|
activity-based costing (ABC).
(1)
cost accounting method that allocates overhead costs based on specific production activities rather than allocating from a single overhead pool
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
activity-oriented WBS.
(1)
work breakdown structure in which activities and tasks are denoted by verbs that indicate work to be accomplished
(Software Extension to the PMBOK(R) Guide Fifth Edition)
Note: Each task name includes the work product or work products to be produced by that task.
|
|
actor.
(1)
role (with respect to that action) in which the enterprise object fulfilling the role participates in the action
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.3.2)
(2)
organization or CASE tool that supplies or acquires SEE services
(ISO/IEC 15940:2013 Systems and software engineering--Software Engineering Environment Services, 2.10)
(3)
in UML, someone or something outside the system that interacts with the system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: It can be of interest to specify which actor initiates that action.
|
|
actual cost (AC).
(1)
realized cost incurred for the work performed on an activity during a specific time period
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: actual cost of work performed (ACWP)
See Also: earned value management, earned value technique
|
|
actual depreciation.
(1)
true loss in value of an asset, determined only when the asset is sold
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
actual dollar analysis.
(1)
addressing inflation or deflation by using cash-flow amounts that represent actual amounts of money at the time of the cash flow
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: constant dollar analysis
|
|
actual results.
(1)
set of behaviors or conditions of a test item, or set of conditions of associated data or the test environment, observed as a result of test execution
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.1)
Example: outputs to screen, outputs to hardware, changes to data, reports, and communication messages sent
Syn: actual result
|
|
ACWP.
(1)
actual cost of work performed
(ISO/IEC/IEEE 24765c:2014)
|
|
ad hoc reviewing.
(1)
unstructured independent review technique
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.1)
|
|
adaptability.
(1)
ability of a system to react to changes in its environment in order to continue meeting both functional and non-functional requirements
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.5)
(2)
capability of a product to be effectively and efficiently adapted for or transferred to different hardware, software or other operational or usage environments
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.8.1)
Note: Adaptability can enable a system to function in limited operation mode with reduced energy supplies or no communication network connectivity due to an accident or a disaster.
See Also: flexibility, functional adaptability
|
|
adaptation data.
(1)
data used to adapt a program to a given installation site or to given conditions in its operational environment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
adaptation parameter.
(1)
variable that is given a specific value to adapt a program to a given installation site or to given conditions in its operational environment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: the variable Installation_Site_Latitude
|
|
adapter.
(1)
software or device that allows incompatible systems to be interfaced
(ISO/IEC/IEEE 24765l:2024)
Example: device charger that converts electrical current, object adapter that connects an application to various databases
|
|
adaptive approach.
(1)
development approach in which the requirements are subject to a high level of uncertainty and volatility and are likely to change throughout the project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
adaptive maintenance.
(1)
modification of a software product, performed after delivery, to keep a software product usable in a changed or changing environment
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.1.1)
Example: An upgrade to the operating system results in changes in the applications.
Note: Adaptive maintenance provides enhancements necessary to accommodate changes in the environment in which a software product operates. These changes help keep pace with the changing environment.
|
|
adaptive strategy.
(1)
technique that people with disabilities use to improve interaction with the web
(ISO/IEC 29110-5-1-2:2025 Systems and software engineering Life cycle profiles for very small entities (VSEs) Part 5-1-2: Software engineering guidelines for the generic Basic profile, 3.4)
Example: Increasing the font size in a common browser
|
|
adaptive support.
(1)
modification of an in-service system of interest performed after installation to keep it usable in a changed or changing runtime environment
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
See Also: additive support, perfective support
|
|
added source statements.
(1)
count of source statements that were created specifically for the software product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
additive maintenance.
(1)
modification of a software product performed after delivery to add functionality or features to enhance the usage of the product
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.1.2)
Note: Additive maintenance can be excluded from the definition of maintenance in the context of dependability that addresses recovery of a system to previous operational, functional and performance level, e.g. definition, monitor or measurement of availability, recoverability, or MTBF (mean time between failure). Additive maintenance provides additional new functions or features to improve software usability, performance, maintainability, or other software attributes for the future. It adds functionality or features with relatively large additions or changes on software for improving software attributes after delivery with identified opportunities to negotiate any of additions or changes on maintenance strategy, methods, resources, agreements, or service levels between suppliers and acquirers. Additions or enhancements can be handled through the maintenance process, while larger changes can involve a new development effort.
See Also: additive support, perfective maintenance
|
|
additive support.
(1)
modification of an in-service system performed after installation to add functionality or features to a system instance
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: In contrast to perfective support, additive support results in new functions or features.
See Also: adaptive support, additive maintenance, perfective support
|
|
additive weighting.
(1)
assignment of different values to increase the importance of selected decision attributes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: compensatory decision technique, nondimensional scaling, analytic hierarchy process
|
|
address.
(1)
number, character, or group of characters that identifies a given device or storage location
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to refer to a device or storage location by an identifying number, character, or group of characters
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
to deal with, to take into consideration; (specifically) to decide whether and when a defined documentation topic is to be included, either directly or by reference to another document; to decide whether an item is to be recorded prior to the test execution (in a tool or not in a tool), recorded during the test execution, recorded post-test execution, not recorded (addressed by the process), or excluded
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
address field.
(1)
field of a computer instruction that contains addresses, information necessary to derive addresses, or values of operands
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: address part
See Also: operation field
|
|
address format.
(1)
number and arrangement of address fields in a computer instruction.
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
number and arrangement of elements within an address, such as the elements needed to identify a particular channel, device, disk sector, and record in magnetic disk storage
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: n-address instruction, n-plus-one address instruction
|
|
address modification.
(1)
arithmetic, logical, or syntactic operation performed on an address
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: effective address, indexed address, relative address, relocatable address
|
|
address space.
(1)
addresses that a computer program can access
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
number of memory locations that a central processing unit can address
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: In some systems, this is the set of physical storage locations that a program can access, disjoint from other programs, together with the set of virtual addresses referring to those storage locations, which are accessible by other programs.
|
|
addressing exception.
(1)
exception that occurs when a program calculates an address outside the bounds of the storage available to it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: data exception, operation exception, overflow exception, protection exception, underflow exception
|
|
addressing mode.
(1)
method to search operand position in the instruction set architecture for a central processing unit
(ISO/IEC/IEEE 24765d:2015)
|
|
addressing range.
(1)
address space specified and used by the instruction system of a computer
(ISO/IEC/IEEE 24765d:2015)
Note: An addressing range depends on the bits of address lines and addressing mode.
|
|
ADF.
(1)
architecture description framework
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.5)
|
|
adjusted size.
(1)
a size based on the functional size multiplied by the technical complexity adjustment
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
Note: This measure does not represent functional size.
|
|
ADL.
(1)
architecture description language
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.6)
|
|
adoption process.
(1)
set of activities by which an organization brings CASE tools into widespread use
(ISO/IEC TR 14471:2007 Information technology--Software engineering--Guidelines for the adoption of CASE tools, 2.1.2)
|
|
advanced profile.
(1)
profile targeted at very small entities (VSEs) which want to sustain and grow as a competitive system or software development organization
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.3)
|
|
adversarial attack.
(1)
deliberate use of adversarial examples to cause a machine learning model to fail
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.6)
Note: Typically targets machine learning models in the form of a neural network
|
|
adversarial example.
(1)
input to a machine learning model created by applying small perturbations to a working example that results in the model outputting an incorrect result with high confidence
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.7)
Example: Typically applies to machine learning models in the form of a neural network
|
|
adversarial testing.
(1)
testing approach based on the attempted creation and execution of adversarial examples to identify defects in a machine learning model
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.8)
Note: Typically applied to machine learning models in the form of a neural network
|
|
AE(I).
(1)
Application Entity (Invocation)
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
(2)
architecture evaluation
(ISO/IEC/IEEE 42030:2019 Software, systems, and enterprise--Architecture evaluation framework, 3.4)
|
|
affect.
(1)
feelings felt by humans
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.1)
(2)
change the attitude of a user or other stakeholder regarding a decision to acquire or use a system
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.1.1)
(3)
internal state experienced or expressed by a subject, such as emotion, mood, or cognition
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: Positive affect comprises positive feelings such as feeling calm, contented, happy, joyful, pleasant; and negative affect comprises negative feelings such as feeling afraid, angry, bad, unpleasant, stressed.
Syn: affective state
|
|
affective computing.
(1)
study and development of systems and devices that can recognize, interpret, process, and simulate human affect
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
|
|
affective rights.
(1)
normative rights attributed to all humanity which directly relate to communication, thought, conviction, and emotion, and the privacy generally afforded to their development and expression
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
|
|
afferent.
(1)
pertaining to a flow of data or control from a subordinate module to a superordinate module in a software system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: efferent
|
|
affinity diagram.
(1)
diagram that shows large numbers of ideas classified into groups for review and analysis
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
affinity grouping.
(1)
process of classifying items into similar categories or collections on the basis of their likeness
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
agency.
(1)
for users, data subjects, and other stakeholders, the nature and extent of the autonomy, freedom, access, and decision-making capacity with respect to the system
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: Alternatively, agency can refer to the power of a given system to affect individuals or groups of users, data subjects, or other stakeholders.
|
|
agent.
(1)
active enterprise object that has been delegated something (authorization, responsibility, provision of a service, etc.) by, and acts for, a party (in exercising the authorization, carrying out the responsibility, providing the service, etc.)
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.8)
Note: An agent can be a party or can be the ODP system or one of its components. Another system in the environment of the ODP system can also be an agent. The delegation can have been direct, by a party, or indirect, by an agent of the party having authorization from the party to so delegate.
|
|
aggregate.
(1)
result of combining one or more physical, logical, or both, system elements
(ISO/IEC/IEEE 24748-6:2023 Systems and software engineering Life cycle management Part 6: System and software integration, 3.1.1)
|
|
aggregate responsibility.
(1)
broadly stated responsibility that is eventually refined as specific properties and constraints
(ISO/IEC/IEEE 24765n:2025, 3.1.3)
|
|
aggregated resource utilization.
(1)
degree to which a service utilizes efficiently aggregated resources from resource pooling in order to support multi-tenancy
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.1.2)
|
|
aggregation.
(1)
derived relationship between two elements that are groups of other elements that represents all individual relationships between the grouped elements of the two groups
(ISO/IEC/IEEE 24765l:2024)
|
|
aggregation method.
(1)
method that combines a set of measurement values to create a composite value
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.1)
Note: Aggregation methods are based on compensatory or non-compensatory models.
|
|
agile.
(1)
approach to development, delivery, and maintenance of products and services by enabling rapid response to feedback
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.2)
Note: The specification for the software under development is elaborated with specific requirements only when the work is started. This lean principle is meant to avoid waste of work and to provide the agile team with means of prioritizing their work
|
|
agile concept.
(1)
fundamental building block of agile
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.3)
|
|
agile development.
(1)
development approach based on iterative development, frequent inspection and adaptation, and incremental deliveries, in which requirements and solutions evolve through collaboration in cross-functional teams and through continual stakeholder feedback
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.4)
(ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 3.1)
(2)
software development approach based on iterative development, frequent inspection and adaptation, and incremental deliveries, in which requirements and solutions evolve through collaboration in cross-functional teams and through continuous stakeholder feedback
(ISO/IEC/IEEE 24748-1:2024, Systems and software engineering--Life cycle management--Part 1: Guidelines for life cycle management, 3.4)
|
|
agile environment.
(1)
organizational culture, infrastructure, and methodologies that support agile development
(ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 4.2)
|
|
agile maturity.
(1)
extent to which an organization, department, project, or team consistently applies agile values and principles that contribute to the achievement of its business needs
(ISO/IEC TR 24587:2021, Software and systems engineering--Agile development--Agile adoption considerations, 3.2)
|
|
agile team.
(1)
organization or team using agile development methods and approaches
(ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 3.3)
(2)
small cross-functional group of people who collaborate on the development of a product, within an agile methodology
(ISO/IEC TR 24587:2021, Software and systems engineering--Agile development--Agile adoption considerations, 3.3)
Note: A common agile team size is 3 to 10 people. The team typically includes roles such as team lead, project manager, user or user representative, software and information developers, and testers.
|
|
agile team lead.
(1)
individual responsible for ensuring an agile team (3.3) adheres to the organization's agile principles, practices, values, and processes
(ISO/IEC TR 24587:2021, Software and systems engineering--Agile development--Agile adoption considerations, 3.4)
Note: The agile team lead is a facilitator rather than a manager.
|
|
agreement.
(1)
mutual acknowledgment of terms and conditions under which a working relationship is conducted
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.5)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.4)
Example: contract, memorandum of agreement
See Also: contract
|
|
AHP.
(1)
analytic hierarchy process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
AI.
(1)
artificial intelligence
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.2)
(2)
inherent availability (Ai)
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
(3)
abandon installation
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
AIS.
(1)
artificial intelligence system
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3)
|
|
algebraic language.
(1)
programming language that permits the construction of statements resembling algebraic expressions, such as Y = X + 5
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: FORTRAN
See Also: algorithmic language, list processing language, logic programming language
|
|
algorithm.
(1)
finite set of well-defined rules for the solution of a problem in a finite number of steps
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
sequence of operations for performing a specific task
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
finite ordered set of well-defined rules for the solution of a problem
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(4)
an algorithm used to create a machine learning model from the training data
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems)
Example: a complete specification of a sequence of arithmetic operations for evaluating sine x to a given precision. ML algorithms include linear regression, logistic regression, decision tree, support vector machine (SVM), Naive Bayes, k-nearest neighbors (kNN), K-means, and random forest
|
|
algorithmic drift.
(1)
drift that occurs during learning or technical enhancements with a change in the systems processing of the same data
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: This phenomenon leads the system to provide different results when fed the same pre-drift data.
|
|
algorithmic language.
(1)
programming language designed for expressing algorithms
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: ALGOL
See Also: algebraic language, list processing language, logic programming language
|
|
alias.
(1)
alternate name for a construct, such as a class, responsibility, entity, or domain
(ISO/IEC/IEEE 24765l:2024)
|
|
aligned.
(1)
group agreement and alliance to one or more shared objectives
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
Note: Key concepts are that each member understands critical inputs (i.e., information, context, and constraints), acts according to a plan that is communicated to all members, accepts responsibility for their part in requisite activities and tasks, and harmoniously collaborates with other members and external resources.
|
|
allocated baseline.
(1)
approved requirements for a product, subsystem or component, describing the functional, performance, interoperability, and interface requirements that are allocated from higher-level requirements and the verifications required to demonstrate achievement of those requirements, as established at a specific point in time and documented in the allocated configuration documentation
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.1)
See Also: developmental configuration, functional baseline, product baseline, allocated configuration identification
|
|
allocated configuration identification.
(1)
in configuration management, the current approved specifications governing the development of configuration items that are part of a higher-level configuration item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Each specification defines the functional characteristics that are allocated from those of the higher-level configuration item, establishes the tests required to demonstrate achievement of its allocated functional characteristics, delineates necessary interface requirements with other associated configuration items, and establishes design constraints, if any.
See Also: functional configuration identification, product configuration identification. allocated baseline
|
|
allocated requirement.
(1)
requirement that levies all or part of the performance and functionality of a higher-level requirement on a lower-level architectural element or design component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
allocation.
(1)
distribution of requirements, resources, or other entities among the components of a system or program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
result of the distribution of requirements, resources, or other entities among the components of a system or program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Allocation can be made entirely to hardware, software, or humans, or to some combination to be resolved upon further functional decomposition.
|
|
allocation of an entitlement.
(1)
process of assigning some or all of a given entitlement to a subsidiary or other associated organizational unit which manages its own entitlement schema library
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.1)
Note: The entitlement schema enables the recording of entitlement allocations.
|
|
ALM.
(1)
application life cycle management
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
|
|
alpha testing.
(1)
first stage of testing before a product is considered ready for commercial or operational use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: often performed only by users within the organization developing the software
See Also: beta testing
|
|
alphanumeric.
(1)
pertaining to data that consists of letters, digits, and usually other characters, such as punctuation marks, as well as to processes and functional units that use the data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
ALS.
(1)
Application Layer Structure
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
alternate flow.
(1)
part of a use case that describes its alternative implementations
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: It is also used to describe error conditions, since errors can be considered a kind of alternative.
Syn: alternate path
|
|
alternate key.
(1)
candidate key of an entity other than the primary key
(ISO/IEC/IEEE 24765n:2025, 3.1.5)
Note: [key style]
|
|
alternatives analysis.
(1)
method used to evaluate identified options in order to select the options or approaches to use to perform the work of the project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
ambiguity.
(1)
state of being unclear, having difficulty in identifying the cause of events, or having multiple options from which to choose
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
analog.
(1)
pertaining to continuously variable physical quantities or to data presented in a continuous form, as well as to processes and functional units that use the data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
analog computer.
(1)
computer whose operations are analogous to the behavior of another system and that accepts, processes, and produces analog data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Example: an abacus
|
|
analogous estimating.
(1)
a technique for estimating the duration or cost of an activity or a project using historical data from a similar activity or project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
analysis.
(1)
process of studying a system by partitioning the system into parts (functions, components, or objects) and determining how the parts relate to each other
(ISO/IEC/IEEE 24765e:2015)
(2)
investigation and collection phase of development that aims to specify types of users and their information needs
(ISO/IEC/IEEE 26512:2018 Systems and software engineering--Requirements for acquirers and suppliers of information for users, 4.2)
Example: test
See Also: system analysis
|
|
analyst.
(1)
member of the technical community who is skilled and trained to define problems and to analyze, develop, and express algorithms
(ISO/IEC/IEEE 24765e:2015)
Example: systems engineer, business analyst
|
|
analytic hierarchy process (AHP).
(1)
use of matrixes to manage pair-wise relationships in decision-making
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: additive weighting, nondimensional scaling, compensatory decision technique
|
|
analytical model.
(1)
model that describes mathematical relationships, such as differential equations that support quantifiable analysis about the system parameters
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.1)
See Also: dynamic model, static model
|
|
analyzability.
(1)
capability of a product to be effectively and efficiently assessed regarding the impact of an intended change to one or more of its parts, to diagnose it for deficiencies or causes of failures, or to identify parts to be modified
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.7.3)
(2)
degree of effectiveness and efficiency with which an IT service can be analyzed for deficiencies, gaps, and failures
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.8.1)
Note: Implementation can include providing mechanisms for the product or system to analyze its own faults and provide reports before or after a failure or other event.
Syn: analysability
See Also: modifiability
|
|
ancestor (of a class).
(1)
generic ancestor of the class or a parent of the class or an ancestor of a parent of the class
(ISO/IEC/IEEE 24765n:2025, 3.1.6)
See Also: generic ancestor, reflexive ancestor
|
|
ancestral box.
(1)
box related to a specific diagram by a hierarchically consecutive sequence of one or more parent/child relationships
(ISO/IEC/IEEE 24765m:2024, 2.1.6)
|
|
ancestral diagram.
(1)
diagram that contains an ancestral box
(ISO/IEC/IEEE 24765m:2024, 2.1.7)
|
|
anchor point.
(1)
a milestone in software scheduling at which a major project life cycle transition occurs
(Software Extension to the PMBOK(R) Guide Fifth Edition)
|
|
annotate.
(1)
command used for listing the latest version of each program's source code line, along with the date, the file version it was introduced, and the person who committed it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
annotated topic list (ATL).
(1)
list of all topics to be included in an information-development project with annotations that can include writer, where used, file name, and additional data
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.2)
|
|
annotation.
(1)
further documentation accompanying a requirement
(ISO/IEC/IEEE 24765e:2015)
(2)
label represented as text near to the object it is associated with
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.1)
Example: background information or descriptive material
|
|
announcement.
(1)
interaction (invocation) initiated by a client object, resulting in the conveyance of information from that client object to a server object, requesting a function to be performed by that server object
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.3)
Example: the initiation of the sending of a message in a messaging system
|
|
annual equivalent.
(1)
representation of a cash flow as a series of equal annual payments (at a stated interest rate) over the planning horizon
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: AE(i)
See Also: future worth, present worth
|
|
annual percentage rate (APR).
(1)
nominal annual interest rate
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
annuity.
(1)
amount of a series of equal payments at regular intervals over a planning horizon
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
anomaly.
(1)
anything observed in the documentation or operation of a system that deviates from expectations based on previously verified system, software, or hardware products or reference documents
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
(2)
judgment that a systems behavior or artifact deviates from expectations based on the systems high-level goals for outcomes, similar requirements, development or operational documentation; applicable standards, regulations, or laws; or an observers perceptions or experiences
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: An anomaly can reveal an implicit requirement.
|
|
ANSI.
(1)
American National Standards Institute
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
anticipatory buffering.
(1)
buffering technique in which data are stored in a buffer in anticipation of a need for the data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: dynamic buffering, simple buffering
|
|
anticipatory paging.
(1)
storage allocation technique in which pages are transferred from auxiliary storage to main storage in anticipation of a need for those pages
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: demand paging
|
|
Ao.
(1)
operational availability
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
AOA.
(1)
analysis of alternatives
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
Syn: AoA
|
|
AON.
(1)
Activity-on-Node
(ISO/IEC/IEEE 24765c:2014)
See Also: precedence diagramming method
|
|
AP.
(1)
alignment processor
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
AP(I).
(1)
Application Process (Invocation)
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
aperiodic task.
(1)
task activated on demand
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: asynchronous task
|
|
API.
(1)
application program interface
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
(2)
application programming interface
(ISO/IEC 19770-2:2015 (corr 2017), Information technology -- Software asset management -- Part 2: Software identification tag, 3.2)
|
|
applicability to a functional domain.
(1)
the ability of an FSM method to take into account the characteristics of functional user requirements (FUR) which are pertinent to FSM in a functional domain
(ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.2)
|
|
applicant.
(1)
person who has submitted an application to be admitted into the certification process
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.1)
|
|
application.
(1)
system for collecting, saving, processing, and presenting data by means of a computer
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.1)
(2)
coherent collection of automated procedures and data supporting a business objective
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
(3)
cohesive collection of automated procedures and data supporting a business objective, consisting of one or more components, modules, or subsystems
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.2)
Example: accounts payable, accounts receivable, payroll, procurement, shop production, assembly line control, air search radar, target tracking, weapons firing, flight line scheduling and passenger reservations
Syn: application system, automated information system
See Also: application software, information system
|
|
application administration function.
(1)
functions performed by users which include installation, configuration, application backup, maintenance (patching and upgrading) and de-installation
(ISO/IEC 25051:2014 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, 4.1.3)
|
|
application architecture.
(1)
architecture including the architectural structure and rules (e.g. common rules and constraints) that constrains a specific member product within a product line
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.1)
(2)
architecture concept, including the architectural structure and rules (e.g. common rules and constraints), and architecture artifacts (such as descriptions) that constrains a specific member product within a product line
(ISO/IEC 26552:2019 Software and systems engineering--Tools and methods for product line architecture design, 3.1)
Note: The application architecture captures the high-level design of a specific member product of a product line.
|
|
application area.
(1)
group of applications that have common components or characteristics, such as similar technologies or production methods, similar customers (i.e., internal versus external, government versus commercial) or a common industry sector (i.e., utilities, automotive, aerospace, information technologies)
(ISO/IEC/IEEE 24765g:2018)
|
|
application asset.
(1)
output of a specific application engineering process (e.g. application realization) that can be exploited in other lifecycle processes of application engineering and can be adapted as a domain asset based on a product management decision
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.2)
Note: Application asset encompasses requirements, an architectural design, components, and tests.
|
|
application assets in requirements.
(1)
application-specific artifacts produced during application requirements engineering, such as application requirements specifications and application requirements models
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.1)
|
|
application component.
(1)
component that is selected, reused or newly developed for a member product
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.1)
|
|
application configuration.
(1)
derivation for member product specific executables from domain assets in realization
(ISO/IEC 26557:2016 Software and systems engineering -- Methods and tools for variability mechanisms in software and systems product line, 3.1)
(2)
composition results of an application by both binding variability and adding application specific variability
(ISO/IEC 26558:2017 Software and systems engineering -- Methods and tools for variability modelling in software and systems product line, 3.1)
(3)
structure of a member product, including application components and application interfaces
(ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.2)
|
|
application design.
(1)
process of application engineering where a single application architecture conforming to the domain architecture is derived
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.3)
|
|
application domain.
(1)
well-defined set of applications
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.1)
|
|
application engineering.
(1)
life cycle consisting of a set of processes in which the application assets and member products of the product line are implemented and managed by reusing domain assets in conformance to the domain architecture and by binding the variability of the platform
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.4)
|
|
application engineering process.
(1)
processes for developing a member product in a product line
(ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.1)
|
|
application frameworks.
(1)
subsystem design made up of a collection of abstract and concrete classes and interfaces between them
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Frameworks are often instantiation of a number of patterns.
|
|
application function point count.
(1)
a count that provides a measure of the functionality the application provides to the end-user
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
(2)
activity of applying ISO/IEC 20926:2009 to measure the functional size of an application
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.4)
Note: i.e., the functionality already provided to the user or that is still to be provided. With it, the effort required to support the realized application can also be determined.
|
|
application functional size.
(1)
measure of the functionality that an application provides to the user, determined by the application function point count
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.3)
|
|
application generator.
(1)
code generator that produces programs to solve one or more problems in a particular application area
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a payroll generator
|
|
application interface.
(1)
interface that is selected, reused or newly developed by a member product
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.3)
|
|
application management.
(1)
domain responsible for all of the tasks and activities that are aimed at managing, supporting, maintaining, and renewing existing applications and related data structures
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.2)
Note: Application management includes all of the tasks, responsibilities, and activities that serve to bring applications into a state where they meet the requirements and needs of their owners throughout the entire life cycle of the business processes that are supported by the applications.
|
|
application management organization.
(1)
organizational unit that is responsible for application management for one or more applications
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.3)
Note: An application management organization can be an internal or external unit in relation to the user organization.
|
|
application object.
(1)
component that is directly related to or forms part of an application
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.4)
Example: Programs, sources, databases, documentation, data structures, test files, and scripts.
|
|
application portfolio.
(1)
collection of applications managed by an application management organization or an entity within that application management organization
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.5)
Note: The scope of the application portfolio can be the entire portfolio of that application management organization, but it can also be the applications of one or some customer organizations of entity within part of a certain customer organization.
|
|
application problem.
(1)
problem submitted by an end user and requiring information processing for its solution
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
application program interface (API) management platform.
(1)
proxy for client requests to protect the back-end of an online server from being disabled from too many queries
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
Note: An API management platform can limit the number of queries for each entity per second or per day. Generally, API management platforms include analytics and usage reporting, API key and authorization management, and live updated documentation.
Syn: application program interface management platform
API management platform:
|
|
application programming interface (API).
(1)
set of functions, protocols, parameters, and objects of different formats, used to create software that interfaces with the features or data of an external system or service
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.6)
Example: The interface to a suite of service subroutines, a set of dedicated URLs that return data in response, or a suite of commands that can be issued to a physical device, such as a robot on an assembly line.
Note: APIs can take several forms. In general terms, an API is a set of clearly defined methods of communication among various components. An API specifies the information and methods that are needed to communicate with another application. Information for users of an API is of two main types: reference information, which contains information about all elements of the API) and developer guide (which explains how to use the API).
|
|
application realization.
(1)
process of application engineering that develops application assets, some of which can be derived from domain assets, and member products based on the application architecture and the sets of application assets and domain assets
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.5)
(2)
one of the application engineering processes that includes detailed design and implementation
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.4)
|
|
application requirements analysis.
(1)
subprocess that understands all application specific requirements, scrutinizes incorrect and inconsistent application requirements through modelling, and then analyses and negotiates application requirements that cannot be satisfied through the domain requirements
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.3)
|
|
application requirements elicitation.
(1)
subprocess for identifying stakeholders relevant to an application, eliciting application specific requirements, and binding the appropriate variants
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.2)
|
|
application requirements management.
(1)
subprocess that manages traceability and changes on application requirements
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.6)
|
|
application requirements specification.
(1)
subprocess that documents the application specific requirements and integrates it with the domain requirements specification whose variants are bound
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.4)
|
|
application requirements verification and validation.
(1)
subprocess that confirms that the application specific requirements are consistent and feasible and helps ensure that the bound variants satisfy the specific product's requirements
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.5)
|
|
application software.
(1)
software designed to help users perform particular tasks or handle particular types of problems, as distinct from software that controls the computer itself
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary, 4.5)
(2)
software or a program that is specific to the solution of an application problem
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(3)
software designed to fulfill specific needs of a user
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
software of an application
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.6)
Note: Application software is the software that the application management organization produces, services, and maintains. There is also system software: the software to produce and maintain the application software and to run the application software on its platform. The application management organization is one of the users of the system software.
See Also: application
|
|
application specific integrated circuit (ASIC).
(1)
integrated circuit customized for a particular use
(ISO/IEC/IEEE 24765d:2015)
Syn: application-specific integrated circuit
|
|
application test asset.
(1)
application-specific test asset that has reuse potential
(ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.3)
|
|
application testing.
(1)
sub-process of application engineering where domain test artefacts are reused to uncover evidence of defects in the application
(ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.2)
|
|
application variability model.
(1)
variability model for a particular application including variability binding results, application specifically modified variability and application specifically added variability
(ISO/IEC 26558:2017 Software and systems engineering -- Methods and tools for variability modelling in software and systems product line, 3.2)
|
|
application-oriented language.
(1)
computer language with facilities or notations applicable primarily to a single application area
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a language for computer-assisted instruction or hardware design
See Also: authoring language, specification language, query language
|
|
application-specific component.
(1)
component that is developed for a specific member product
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.5)
|
|
application-specific requirements.
(1)
requirements specific to an application or requirements not covered in domain requirements
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.9)
Syn: application specific requirements
|
|
apportioned effort.
(1)
an activity where effort is allotted proportionately across certain discrete efforts and not divisible into discrete efforts
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: Apportioned effort is one of three earned value management (EVM) types of activities used to measure work performance.
See Also: discrete effort
|
|
appraisal findings.
(1)
results of an appraisal that identify the most important issues, problems, or opportunities for process improvement within the appraisal scope
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Appraisal findings are inferences drawn from corroborated objective evidence.
|
|
appraisal participants.
(1)
members of the organizational unit who participate in providing information during an appraisal
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
appraisal team leader.
(1)
person who leads the activities of an appraisal and has satisfied qualification criteria for experience, knowledge, and skills defined by the appraisal method
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
appropriateness recognizability.
(1)
capability of a product to be recognized by users as appropriate for their needs
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.4.1)
(2)
degree to which an IT service provides results that are appropriate for the user needs
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.2.1)
Note: Appropriateness recognizability depends on initial impressions of the product or system's functions from initial impressions of the product or system or associated documentation. The information can be provided by the product to assist users in making decisions about the adoption, acquisition, or use of products prior to the start of full-scale use, through demonstrations, tutorials, documentation or, for a website, the information on the home page.
See Also: functional appropriateness
|
|
approval.
(1)
notification by an authorized representative that an information item appears to satisfy requirements and is complete
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.1)
Note: Such approval does not shift responsibility from the supplier to meet requirements under a two-party situation.
|
|
approval authority.
(1)
person (or persons) or organization (or organizations) responsible for approving activities, artifacts, and other aspects of the system during its life cycle
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.5.2)
(ISO/IEC/IEEE 24765h:2019)
Note: The approval authority can include multiple entities, e.g. individuals or organizations. These can include different entitles with different levels of approval and/or different areas of interest. In two-party situations, approval authority often rests with the acquirer. In regulatory situations, the approval authority can be a third party such as a governmental organization or its agent. In other situations, e.g. the purchase of off-the-shelf products developed by a single-party, the independence of the approval authority can be a relevant issue to the acquirer.
|
|
approved modification.
(1)
disposition of one or more proposed changes authorizing change to any SCIs
(ISO/IEC/IEEE 24765i:2020)
Note: There can be a many-to-many relationship of "proposed change" to "approved modification". A proposed change can cause modifications in several SCIs (even if only to the code and its test case). A modification can originate from several proposed changes, approved simultaneously or over a period of time while the modification is still in progress.
|
|
arc.
(1)
directed edge of a net which can connect a place to a transition or a transition to a place, normally represented by an arrow
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 2.1.1)
|
|
arc annotation.
(1)
expression that can involve constants, variables and operators used to annotate an arc of a net
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 2.1.1.3)
Note: The expression evaluates to a multiset over the type of the arc's associated place.
|
|
architect.
(1)
person, team, or organization responsible for systems architecture
(ISO/IEC/IEEE 24765e:2015)
|
|
architecting.
(1)
conceiving, defining, expressing, documenting, communicating, certifying proper implementation of, maintaining and improving an architecture throughout the life cycle of an entity of interest
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.1)
Note: Architecting takes place in the context of an organization or a project. The entity to be architected can be of several kinds, as illustrated in the following examples: system, enterprise, solution, business, data, application, information technology, mission, product, service, software.
|
|
architectural design.
(1)
definition of a collection of hardware and software components and their interfaces to establish the framework for the development of a computer system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: functional design
|
|
architectural design phase.
(1)
life-cycle phase in which a system's general architecture is developed, thereby fulfilling the requirements laid down by the software requirements document and detailing the implementation plan in response to it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
architectural design review.
(1)
joint acquirer-supplier review to evaluate the technical adequacies of the software architectural design as depicted in the software design descriptions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
architectural structure.
(1)
physical or logical layout of the components of a system design and their internal and external connections
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: function-oriented (structured) design, object-oriented design, and data structure-oriented design
|
|
architectural style.
(1)
definition of a family of systems in terms of a pattern of structural organization
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
characterization of a family of systems that are related by sharing structural and semantic properties
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: pipes and filters, layers, rule-based systems, and blackboards
|
|
architecture.
(1)
fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.6)
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.3)
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.2)
(2)
set of rules to define the structure of a system and the interrelationships between its parts
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 6.6)
(3)
fundamental concepts or properties of a system in its environment and governing principles for the realization and evolution of this system and its related life cycle processes
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.5)
Note: Architectures can address a wide range of concerns, expressed, for example, through architecture views and models, associated with particular kinds of architectures such as security architecture, functional architecture, physical architecture, resilience architecture.
See Also: component, module, subprogram, routine
|
|
architecture collection.
(1)
group of architectures held by an organization that is subject to governance and management by the organization as a whole
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.4)
Note: The architectures in the collection can have relationships with each other (as in the case of product lines). The architectures in the collection can be based on the same reference architecture.
|
|
architecture description (AD).
(1)
work product used to express an architecture
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.3)
Note: An architecture description is a tangible representation of information provided to the stakeholders.
Syn: architectural description
|
|
architecture description element.
(1)
identified or named part of an architecture description
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.4)
Example: stakeholders, concerns, stakeholder perspectives, aspects, architecture description languages, architecture description frameworks, correspondences, correspondence methods, architecture views, view components, architecture viewpoints, model kinds
Note: An architecture description can be considered as a corresponding architecture description element in another architecture description.
Syn: AD element
|
|
architecture description framework (ADF).
(1)
conventions, principles, and practices for the description of architectures established within a specific domain of application or community of stakeholders
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.7)
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.5)
Example: Generalized Enterprise-Referencing Architectures Modelling Framework (GERAM), Reference Model of Open Distributed Processing (RM-ODP), Unified Architecture Framework (UAF), and NATO Architecture Framework
Note: Architecture description frameworks promote structured organization, consistency of description, greater potential for reuse, and completeness of architecture views and models.
Syn: architecture framework
See Also: architecture framework
|
|
architecture description language (ADL).
(1)
means of expression, with syntax and semantics, consisting of a set of representations, conventions, and associated rules intended to be used to describe an architecture
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.6)
Example: Architecture Analysis and Design Language (AADL), ArchiMate, UML, SysML, UAF Profile
|
|
architecture entity.
(1)
thing being considered, described, discussed, studied or otherwise addressed during the architecting effort
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.6)
(2)
thing being characterized by an architecture
(ISO/IEC/IEEE 42030:2019 Software, systems, and enterprise--Architecture evaluation framework, 3.3)
Example: The following are kinds of architecture entities that can be dealt with by the architecture processes: enterprise, organization, solution, system (including software systems), subsystem, business, data (as a data element or data structure), application, information technology (as a collection), mission, product, service, software item, hardware item, product line, family of systems, system of systems, collection of systems, collection of applications.
Note: When referring to the architecture itself of these architecture entities, it is common practice to place the name of the kind of entity in front of the word architecture. For example, the phrase system architecture is used when the thing being dealt with during the architecting effort is a system. The fundamental concepts or properties of the architecture entity are usually intended to be embodied in the entity's components, the relationships between components, and the relationships between the entity and its environment.
|
|
architecture evaluation (AE).
(1)
individual responsible for ensuring an agile team (3.3) adheres to the organization's agile principles, practices, values, and processes
(ISO/IEC TR 24587:2021, Software and systems engineering--Agile development--Agile adoption considerations, 3.4)
Example: Various kinds of judgments can be made during an architecture evaluation, such as validating that architectures address the concerns of stakeholders, assessing the quality of architectures with respect to their intended purpose, assessing the value of architectures or architecture entities to their stakeholders, determining whether architecture entities address their intended purpose, providing knowledge and information about architecture entities and identifying risks and opportunities associated with architectures.
|
|
architecture evaluation framework.
(1)
conventions, principles and practices for evaluating architectures in a consistent and repeatable manner
(ISO/IEC/IEEE 42030:2019 Software, systems, and enterprise--Architecture evaluation framework, 3.5)
Example: Architecture Tradeoff Analysis Method (ATAM), the Method Framework and QUASAR method and Analysis of Alternatives (AoA).
Note: The framework can be generic in nature or specific to a domain of application, a collection of concerns to be examined or a methodology. The evaluation framework can consist of different sub-architecture frameworks for an entity with many layers or levels. These can be defined and consolidated as part of the comprehensive architecture framework package.
|
|
architecture framework.
(1)
conventions, principles and practices for the description of architectures established within a specific domain of application or community of stakeholders
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.7)
(2)
conventions, principles and practices for use by architecture-related activities that have been established within a specific domain of application or community of stakeholders
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.7)
Example: Generalised Enterprise Reference Architecture and Methodologies (GERAM) [ISO 15704], Reference Model of Open Distributed Processing (RM-ODP) [ISO/IEC 10746]
See Also: architecture description framework
|
|
architecture view.
(1)
information part comprising portion of an architecture description
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.8)
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.7)
Note: An Information or Data View addresses information-relevant concerns framed by an Information viewpoint. It contains as view components, a conceptual data model, a data management model and a data access model and correspondences linking those components together.
See Also: architecture viewpoint
|
|
architecture viewpoint.
(1)
set of conventions for the creation, interpretation, and use of an architecture view to frame one or more concerns
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.9)
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.8)
Note: A viewpoint is a frame of reference for the concerns determined by the architect as relevant to the purpose of the architecture description. The conventions of an architecture viewpoint are documented in a specification of that viewpoint. The identification of a viewpoint is often the result of prior knowledge, experience, and praxis in the domain to which the viewpoint applies, indicating the information relevant to addressing the concern
Syn: view specification
See Also: architecture view
|
|
archival page.
(1)
content that is preserved as a record and not expected to change
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.1)
Note: Due to technology upgrades, some archival pages cannot be readily rendered unless they are upgraded along with active pages.
|
|
archive.
(1)
Location of system elements that are no longer present in runtime environments, but are available for examination for audit, regulatory, and other processes
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
|
|
archiving.
(1)
process of placing a version of a document in a less frequently used storage area
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.3)
|
|
argument.
(1)
independent variable
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
specific value of an independent variable
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
constant, variable, or expression used in a call to a software module to specify data or program elements to be passed to that module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: the variable m in the equation E = mc2
|
|
ARIA.
(1)
accessible rich internet application
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
arity.
(1)
number of roles that participate in a relationship
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: A binary relationship has an arity of two. An n-ary relationship has an arity of n. (n>2) sometimes known as the "degree" of a relationship.
|
|
arranging.
(1)
activity of sequencing attributes in a transactional function
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.5)
|
|
array.
(1)
n-dimensional ordered set of data items identified by a single name and one or more indices, so that each element of the set is individually addressable
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a matrix, table, or vector
|
|
arrow.
(1)
directed line, composed of one or more connected arrow segments in a single diagram from a single source (box or diagram boundary) to a single use (box or diagram boundary)
(ISO/IEC/IEEE 24765m:2024, 2.1.8)
(2)
graphic presentation of a logical relationship between schedule activities in the precedence diagramming method
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: arrow segment, boundary arrow, internal arrow
|
|
arrow label.
(1)
noun or noun phrase associated with an arrow segment to signify the arrow meaning of the arrow segment
(ISO/IEC/IEEE 24765m:2024, 2.1.9)
Note: Specifically, an arrow label identifies the object type set that is represented by an arrow segment.
|
|
arrow meaning.
(1)
object types of an object type set, regardless of how these object types can be collected, aggregated, grouped, bundled, or otherwise joined within the object type set
(ISO/IEC/IEEE 24765m:2024, 2.1.10)
(2)
a review conducted to evaluate the manner in which the requirements for a system have been allocated to configuration items, the system engineering process that produced the allocation, the engineering planning for the next phase of the effort, manufacturing considerations, and the planning for production engineering
Example: a physical thing, a data element
|
|
arrow role.
(1)
relationship between an object type set represented by an arrow segment and the activity represented by the box to which the arrow segment is attached
(ISO/IEC/IEEE 24765m:2024, 2.1.12)
Note: There are four arrow roles: input, control, output, and mechanism.
|
|
arrow segment.
(1)
directed line that originates at a box side, arrow junction (branch or join), or diagram boundary and terminates at the next box side, arrow junction (branch or join), or diagram boundary that occurs in the path of the line
(ISO/IEC/IEEE 24765m:2024, 2.1.13)
|
|
artifact.
(1)
work product that is produced and used during a project to capture and convey information
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.10)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.6)
(2)
role (with respect to an action) in which the enterprise object fulfilling the role is referenced in the action
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.3.3)
Example: template, document, output, or project deliverable
Note: An enterprise object that is an artifact in one action can be an actor in another action.
Syn: artefact
|
|
artificial intelligence (AI).
(1)
branch of computer science devoted to developing data processing systems that perform functions normally associated with human intelligence, such as reasoning, learning, and self-improvement
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
capacity of computers or other machines to exhibit or simulate intelligent behavior
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.1)
(3)
capability of an engineered system to acquire, process and apply knowledge and skills
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.7)
(4)
set of methods or automated entities that together build, optimize and apply a model, so that the system can, for a given set of predefined tasks, compute predictions, recommendations, or decisions
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3)
|
|
artificial intelligence effect.
(1)
situation when a previously labelled artificial intelligence (AI) system is no longer considered to be AI as technology advances
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.10)
Syn: AI effect
|
|
artificial intelligence quality metamodel.
(1)
metamodel intended to ensure the quality of artificial intelligence (AI)-based systems
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.11)
Syn: AI quality metamodel
|
|
artificial intelligence system (AIS).
(1)
engineered system that generates outputs such as content, forecasts, recommendations or decisions for a given set of human-defined objectives
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3)
|
|
artificial intelligence-based system.
(1)
system including one or more components implementing artificial intelligence (AI)
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.9)
Syn: AI-based system
|
|
ASIC.
(1)
application-specific integrated circuit
(ISO/IEC/IEEE 24765d:2015)
|
|
ask.
(1)
combination of a specific activity; a demanded execution time, defined by a specific timeliness function; a specific task mode
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.19)
|
|
ASO.
(1)
Application Service Object
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
ASOI.
(1)
autonomous system of interest
(IEEE 7009-2024, Fail-Safe Design of Autonomous and Semi-Autonomous Systems, 3)
|
|
aspect.
(1)
part of an entitys character or nature
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.9)
(2)
special consideration within product line engineering process groups and tasks with which specialized methods and tools can be associated
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.6)
(3)
special consideration within product line engineering process groups and tasks to which one can associate specialized methods and tools
(ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.4)
(4)
special consideration within product line engineering process groups and tasks to associate specialized methods and tools
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.7)
Example: functional, structural, and informational aspects of an entity
Note: A particular aspect can be used for capturing the relevant features of the entity of interest as a refinement of one or more concerns under examination with respect to some part of its character. Aspects enable the architect to analyze, address, and structure concerns. In general, there is a many-to-many relation between aspects and concerns.
|
|
ASR.
(1)
alternative systems review
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
assemble.
(1)
to translate a computer program expressed in an assembly language into its machine language equivalent
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: compile, disassemble, interpret
|
|
assemble-and-go.
(1)
operating technique in which there are no stops between the assembling, linking, loading, and execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
assembled origin.
(1)
address of the initial storage location assigned to a computer program by an assembler, a compiler, or a linkage editor
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
See Also: loaded origin, offset, starting address
|
|
assembler.
(1)
computer program that translates programs expressed in assembly language into their machine language equivalents
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: absolute assembler, compiler, cross-assembler, interpreter, relocating assembler
|
|
assembly code.
(1)
computer instructions and data definitions expressed in a form that can be recognized and processed by an assembler
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: assembler code
See Also: compiler code, interpretive code, machine code
|
|
assembly language.
(1)
programming language that corresponds closely to the instruction set of a given computer, allows symbolic naming of operations and addresses, and usually results in a one-to-one translation of program instructions into machine instructions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: assembler language, low-level language, second-generation language
See Also: fifth-generation language, fourth-generation language, high order language, machine language.
|
|
assertion.
(1)
logical expression specifying a program state that exists or a set of conditions that program variables satisfy at a particular point during program execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
function or macro that complains loudly if a design assumption on which the code is based is not true
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Types include input assertion, loop assertion, output assertion.
See Also: invariant, proof of correctness
|
|
assessment.
(1)
action of applying specific documented criteria to a specific software module, package or product for the purpose of determining acceptance or release of the software module, package or product
(ISO/IEC 14102:2008 Information Technology - Guideline for the evaluation and selection of CASE tools, 3.1)
(2)
process that evaluates a person's fulfillment of the requirements of the certification scheme
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.2)
(3)
action of comprehensively evaluating the target entity based on documented criteria for a specific purpose
(ISO/IEC 25040:2024 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Quality evaluation framework, 3.1)
|
|
assessment body.
(1)
body that performs an assessment
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.1)
Note: A body can be an organization or part of an organization that performs the assessment.
|
|
assessment constraint.
(1)
restriction placed on the use of the assessment outputs or on the assessment team's freedom of choice regarding the conduct of the assessment
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.2)
|
|
assessment indicator.
(1)
sources of objective evidence used to support the assessors' judgment in rating process attributes
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.1)
Example: work products, practice, or resource
|
|
assessment input.
(1)
information required before a process assessment can commence
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.3)
|
|
assessment output.
(1)
tangible results from an assessment
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.4)
See Also: assessment record
|
|
assessment participant.
(1)
individual who has responsibilities within the scope of the assessment
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.5)
Example: the assessment sponsor, assessors, and organizational unit members
|
|
assessment purpose.
(1)
statement, provided as part of the assessment input, which defines the reasons for performing the assessment
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.6)
|
|
assessment record.
(1)
orderly, documented collection of information which is pertinent to the assessment and adds to the understanding and verification of the process profiles generated by the assessment
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.7)
|
|
assessment scope.
(1)
definition of the boundaries of the assessment, provided as part of the assessment input, encompassing the boundaries of the organizational unit for the assessment, the processes to be included, the quality level for each process to be assessed, and the context within which the processes operate
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.8)
|
|
assessment sponsor.
(1)
individual or entity, internal or external to the organizational unit being assessed, who requires the assessment to be performed, and provides financial or other resources to carry it out
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.9)
|
|
assessment team.
(1)
one or more individuals who jointly perform a process assessment
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.10)
|
|
assessor.
(1)
individual who participates in the rating of process attributes
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.11)
|
|
asset.
(1)
item, thing, or entity that has potential or actual value to an organization
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.2)
(2)
item that has been designed for use in multiple contexts
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1.3)
(3)
item, such as design, specifications, source code, documentation, test suites, or manual procedures, that has been designed for use in multiple contexts
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
Example: requirements documents, source code modules, measurement definitions
Note: Physical assets usually refer to equipment, inventory and properties owned by the organization. Physical assets are the opposite of intangible assets, which are non-physical assets, such as leases, brands, digital assets, use rights, licenses, intellectual property rights, reputation or agreements. A grouping of assets referred to as an asset system can also be considered as an asset.
|
|
asset base.
(1)
reusable assets produced from both domain and application engineering
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.6)
|
|
asset life.
(1)
period from asset creation to asset end-of-life
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.2)
|
|
asset management.
(1)
coordinated activity of an organization to realize value from assets
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.3)
|
|
asset management plan.
(1)
documented information that specifies the activities, resources and timescales required for an individual asset, or a grouping of assets, to achieve the organization's asset management objectives
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.4)
|
|
asset management system.
(1)
management system for asset management whose function is to establish the asset management policy and asset management objectives
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.5)
|
|
asset portfolio.
(1)
assets that are within the scope of the asset management system
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.6)
Note: A portfolio is typically established and assigned for managerial control purposes. Portfolios for physical assets can be defined by category (e.g. plant, equipment, tools, land). Software portfolios might be defined by software publisher or by platform (e.g. PC, server, mainframe).
|
|
asset proposal.
(1)
artifact that includes major assets (functional areas and high-level common and variable features of all applications) that can be included in a product line with their quantified costs and benefits, and estimate results
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.8)
|
|
asset protection.
(1)
for services, degree to which a service has processes to protect physical facilities used to provide the covered services from loss of data, connectivity, and availability of necessary infrastructure and IT equipment, and to secure the covered services during operation
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.5.6)
|
|
asset scoping.
(1)
process of identifying the potential domain assets and estimating the returns of investments in the assets
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.7)
Note: Information produced during asset scoping, together with the information produced by product scoping and domain scoping, can be used to determine whether to introduce a product line into an organization.
|
|
asset system.
(1)
set of assets that interact or are interrelated
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.7)
|
|
asset type.
(1)
grouping of assets having common characteristics that distinguish those assets as a group or class
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.8)
Example: Physical assets, information assets, intangible assets, critical assets, enabling assets, linear assets, information and communications technology (ICT) assets, infrastructure assets, moveable assets.
|
|
assignment.
(1)
for a set of variables, the association of a value (of correct type) to each variable
(ISO/IEC/IEEE 24765i:2020)
See Also: binding
|
|
assignment statement.
(1)
computer program statement that assigns a value to a variable
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: Y = X - 5
See Also: control statement, declaration, clear, initialize, reset
|
|
assistive technologies.
(1)
hardware or software that is added to or incorporated within a system that increases accessibility for an individual
(ISO/IEC/IEEE 24765n:2025)
Example: Braille displays, screen readers, screen magnification software, and eye tracking devices
|
|
assistive technology.
(1)
equipment, product, system, hardware, software, or service that is used to increase, maintain or improve capabilities of individuals
(ISO/IEC 29110-5-1-2:2025 Systems and software engineering Life cycle profiles for very small entities (VSEs) Part 5-1-2: Software engineering guidelines for the generic Basic profile, 3.6)
Note: Assistive technology can include assistive services, and professional services needed for assessment, recommendation and provision.
|
|
association.
(1)
in UML, a relationship between an actor and a use case that indicates that the actor interacts with the system by means of the use case
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
relationship (binding) between protocol objects (or between a protocol object and an interceptor) that is established independently of the protocol exchanges that support a particular computational interaction
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.2)
|
|
association management facility.
(1)
set of service primitives which support the management of an association between protocol objects
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.3)
|
|
associative class.
(1)
class introduced to resolve a many-to-many relationship
(ISO/IEC/IEEE 24765n:2025, 3.1.7)
|
|
associative entity.
(1)
entity used to represent a relationship between other entities
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: An associative entity is used when a relationship does not otherwise provide sufficient mechanisms.
|
|
associative entity type.
(1)
entity type that contains attributes which further describe a many-to-many relationship between two other entity types
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.6)
See Also: entity type
|
|
associative literal.
(1)
literal that denotes an instance in terms of its value
(ISO/IEC/IEEE 24765n:2025, 3.1.8)
Note: The form of expression used to state an associative literal is className with propertyName: propertyValue.
|
|
assumption.
(1)
factor in the planning process that is considered to be true, real, or certain, without proof or demonstration
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
assumption and constraint analysis.
(1)
assessment to help ensure that assumptions and constraints are integrated into the project plans and documents, and that there is consistency among them
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: modified, changed "that ensures" to "to help ensure"
|
|
assumption log.
(1)
project document used to record all assumptions and constraints throughout the project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
assurance.
(1)
grounds for justified confidence that a claim has been or will be achieved
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.1.1)
Note: Assurance is about a claim or a conjunction of more than one claim.
|
|
assurance argument.
(1)
artifact that links tangible evidence and assumptions to provide a convincing and valid argument of a claim under a given context
(ISO/IEC/IEEE 15026-4:2021, Systems and software engineering Systems and software assurance Part 4: Assurance in the life cycle, 3.2)
Note: An argument is valid if and only if it is necessary that if all of the premises are true, then the conclusion is true. An argument is sound if and only it is valid and contains only true premises.
|
|
assurance case.
(1)
reasoned, auditable artifact created that supports the contention that its top-level claim (or set of claims), is satisfied, including systematic argumentation and its underlying evidence and explicit assumptions that support the claim(s)
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.1.3)
(2)
representation of a claim or claims, and the support for these claims
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
(3)
auditable artifact that provides a convincing and sound argument for a claim on the basis of tangible evidence under a given context
(ISO/IEC/IEEE 15026-2:2022, Systems and software engineering Systems and software assurance Part 2: Assurance case, 3.1.1)
Note: An assurance case contains the following and their relationships: one or more claims about properties; arguments that logically link the evidence and any assumptions to the claim(s); a body of evidence and possibly assumptions supporting these arguments for the claim(s); justification of the choice of top-level claim and the method of reasoning
|
|
assurance case report.
(1)
auditable artifact that provides the claim of an assurance case and a complete index of the argument and evidence of the assurance case such that the assurance case of interest can be assembled from the index
(ISO/IEC/IEEE 15026-2:2022, Systems and software engineering Systems and software assurance Part 2: Assurance case, 3.1.2)
Note: An assurance case report is an introduction to the assurance case. Its content varies from one case to another. For simple and/or small assurance cases a report can be superfluous. For larger or more complex assurance cases the report can include a system description, some of the argument and its supporting evidence e.g. the higher-level arguments and their supporting evidence. Assurance case reports are often issued as periodic updates to the assurance case at pre-agreed points such as at the end of a life cycle stage. They report on results of assurance activities done so far, an assessment of overall progress and a review of assurance activities performance. Assurance case reports can be used at decision gates for stage exit/entry by suppliers and for project monitoring by acquirers.
|
|
assurance claim.
(1)
claim for which assurance is considered
(ISO/IEC/IEEE 15026-4:2021, Systems and software engineering Systems and software assurance Part 4: Assurance in the life cycle, 3.3)
|
|
assurance information.
(1)
information including a claim about a system, evidence supporting the claim, an argument showing how the evidence supports the achievement of the claim, and the context for these items
(ISO/IEC/IEEE 15026-4:2021, Systems and software engineering Systems and software assurance Part 4: Assurance in the life cycle, 3.4)
Note: The sub-claims included in the argument of assurance information can be about the life cycle of the system of interest when, for example, the top-level claim implies continuous achievement of some property.
|
|
assure.
(1)
to promise or state with certainty by one person to another person or group
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
See Also: ensure
|
|
asynchronous.
(1)
pertaining to two or more processes that do not depend upon the occurrence of specific events such as common timing
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
asynchronous communication interface adapter (ACIA).
(1)
functional unit to connect interfaces for asynchronous communications
(ISO/IEC/IEEE 24765d:2015)
|
|
asynchronous I/O device.
(1)
I/O device that generates an interrupt after producing some input or generating some output
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
asynchronous I/O device interface task.
(1)
task that interfaces to an I/O device and is activated by interrupts from that device
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
asynchronous message communication.
(1)
communication in which a producer task sends a message to a consumer task and does not wait for a response
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: A message queue can build up between the tasks.
Syn: loosely coupled message communication
|
|
ATDD.
(1)
acceptance-test driven development
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.1)
|
|
ATL.
(1)
annotated topic list
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)
|
|
atomic type.
(1)
data type, each of whose members consists of a single, nondecomposable data item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: primitive type
See Also: composite type
|
|
atomicity.
(1)
entity at a given level of abstraction that cannot be subdivided at that level of abstraction
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 6.4)
|
|
attached process.
(1)
process definitions how each asset will be used in application
(ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.2)
|
|
attack.
(1)
malicious action or interaction with the system or its environment that has the potential to result in a fault or an error (and thereby possibly in a failure) or an adverse consequence
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.4.7)
|
|
attribute.
(1)
inherent property or characteristic of an entity that can be distinguished quantitatively or qualitatively by human or automated means
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.1)
(2)
label that governs the form or shape of the object it is associated with, which, in contrast to an annotation, is typically not shown as text
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.2)
(3)
unique item of information about an entity
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
(4)
observable characteristic or property of the system or system element
(INCOSE Systems Engineering Handbook, 5th ed.)
(5)
single-valued characteristic of an entity or relationship
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Example: people, objects, places, events, ideas, or combinations of things
Note: can refer either to general characteristics, such as reliability, maintainability, and usability, or to specific features of a software product. An attribute expresses some characteristic that is generally common to the instances of a class.
|
|
attribute name.
(1)
role name for the value class of the attribute
(ISO/IEC/IEEE 24765n:2025, 3.1.10)
|
|
attributed relationship.
(1)
relationship that has attributes
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
attributive entity type.
(1)
entity type that further describes one or more attributes of another entity type
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.7)
See Also: entity
|
|
ATWS.
(1)
anticipated transient without scram
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
AUC.
(1)
area under curve
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
audience.
(1)
category of users sharing the same or similar characteristics and needs (for example, purpose in using the information for users, tasks, education level, abilities, training, and experience) that determine the content, structure, and use of the intended information
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.2)
Note: There can be different audiences for information for users, (for example, management, data entry, maintenance, engineering, business professionals).
See Also: persona
|
|
audience research.
(1)
planned activity of interviewing representative users and analyzing interview records and personnel records
(ISO/IEC/IEEE 24765a:2011)
Note: The purpose of audience research is to determine the abilities, training, experience, limitations, prejudices and preferences of the intended readers of a document.
|
|
audit.
(1)
independent examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.11)
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 3.10)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.7)
(2)
systematic, independent and documented process for obtaining audit evidence and evaluating it objectively to determine the extent to which audit criteria are fulfilled
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.9)
(3)
independent, continuous examination of a work product or set of work products to assess compliance with specifications, standards, contractual agreements, or other criteria for the purpose of providing assurance against risk
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
Note: An audit can be an internal audit (first party) or an external audit (second party or third party), and it can be a combined or integrated audit (combining two or more disciplines). An audit results in a clear indication of whether the audit criteria have been met. The scope can include professional and industry codes of practice. Whilst "audit" applies to management systems, "assessment" applies to conformity assessment bodies as well as more generally. Generating evidence of information technology (IT) controls that support audit is often
automated where practical.
|
|
audit team.
(1)
one or more auditors conducting an audit, supported if needed by technical experts
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.13)
Note: One auditor of the audit team is appointed as the audit team leader. The audit team can include auditors-in-training.
|
|
auditability.
(1)
for a service, degree to which it collects and provides available necessary evidential information related to the operation and use of the service, for the purpose of conducting an audit
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.8.2)
(2)
ability to access, open, inspect, and verify content, data, and implementations of autonomous and intelligent systems
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
|
|
auditee.
(1)
organization being audited
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.11)
|
|
auditor.
(1)
person who conducts an audit
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.12)
|
|
augmented reality system.
(1)
view of the physical world that is supplemented by computer-generated text, images, data, or other media
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.4)
|
|
authenticity.
(1)
capability of a product to prove that the identity of a subject or resource is the one claimed
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.6.5)
|
|
author check.
(1)
informal review performed by the author of the work product
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.2)
|
|
authoring environment.
(1)
toolset used to create, store, and manage content units
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.5)
|
|
authoring language.
(1)
high-level programming language used to develop courseware for computer-assisted instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: authoring system
|
|
authoring system.
(1)
programming system that incorporates an authoring language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
authority.
(1)
right to apply project resources, expend funds, make decisions, or give approvals
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
authorization.
(1)
action indicating that a particular behavior is not prevented
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.4)
Note: Modified, "shall not be" changed to "is not".
Unlike a permission, an authorization is an empowerment.
|
|
authorized individual.
(1)
individual identified by an organization to make decisions, allocate resources, and accept risk, within a domain of responsibility
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
automate.
(1)
to make a process or equipment automatic
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
automated systems process.
(1)
systems or software process that is performed either fully or partially supported by CASE tools
(ISO/IEC 15940:2013 Systems and software engineering--Software Engineering Environment Services, 2.2.3, 2.9)
Syn: assisted process, assisted software process, assisted systems process, automated process, automated software process
|
|
automated verification system.
(1)
software tool that accepts as input a computer program and a representation of its specification and produces, possibly with human help, a proof or disproof of the correctness of the program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
software tool that automates part or all of the verification process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
automatic.
(1)
pertaining to a process or equipment that, under specified conditions, functions without human intervention
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
automation.
(1)
conversion of processes or equipment to automatic operation, or the results of the conversion
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
autonomous system.
(1)
system capable of working without human intervention for sustained periods
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.14)
See Also: autonomous/intelligent system
|
|
autonomous/intelligent system (A/IS).
(1)
semi-autonomous or autonomous computer-controlled system programmed to carry out some task with or without limited human intervention, capable of decision making by independent inference and successfully adapting to its context
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.1)
See Also: autonomous system
|
|
autonomy.
(1)
ability of a system to work for sustained periods without human intervention
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.15)
|
|
autonomy-based improvement.
(1)
self-motivated and self-determined professional process improvement with an understanding of the work (process) objectives, latest technology, and outcomes from product use
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.14)
|
|
AV.
(1)
autonomous vehicle
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.2)
|
|
availability.
(1)
capability of a product to be operational and accessible when required for use
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.5.2)
(2)
ratio of uptime divided by the sum of uptime plus downtime
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
(3)
degree to which a cloud service is accessible and usable upon demand by an authorized entity
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.4.1)
(4)
degree to which an IT service is available to users when needed
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.4.3)
(5)
ability of an application object to perform its required function at an agreed instant or over an agreed period of time
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.7)
Example: uptime/(uptime + downtime)
Note: Availability is a quantitative component of dependability, expressed as a requirement parameter (threshold), as a probability (prediction or estimate), or as a measurement obtained during test or in-service operation (observation).
See Also: error tolerance, fault tolerance, reliability, robustness
|
|
AVI.
(1)
availability threshold
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
awareness requirement.
(1)
reference to other requirements or domain assumptions and their success or failure
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
|
|
BABOK.
(1)
Business Analysis Book of Knowledge
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 3.2)
|
|
BAC.
(1)
budget at completion
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
back matter.
(1)
material that appears at the end of printed documentation, such as an index
(ISO/IEC/IEEE 24765a:2011)
|
|
back-to-back testing.
(1)
testing in which two or more variants of a program are executed with the same inputs, the outputs are compared, and errors are analyzed in case of discrepancies
(ISO/IEC TR 19759:2016 Software Engineering -- Guide to the Software Engineering Body of Knowledge (SWEBOK), 4.2.2.9)
(2)
approach to testing whereby an alternative version of the system is used to generate expected results for comparison from the same test inputs
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.10)
Syn: differential testing
See Also: mutation testing
|
|
background.
(1)
in job scheduling, the computing environment in which low-priority processes or those not requiring user interaction are executed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: foreground. background processing
|
|
background processing.
(1)
execution of a low-priority process while higher priority processes are not using computer resources, or the execution of processes that do not require user interaction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: foreground processing
|
|
backlog.
(1)
collection of agile features or stories of both functional and nonfunctional requirements that are typically sorted in an order based on value priority
(ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 3.4)
(2)
set of software features awaiting development in a subsequent iteration
(Software Extension to the PMBOK(R) Guide Fifth Edition)
(3)
ordered list of work to be done
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(4)
collection of features or stories of both functional and nonfunctional requirements that are typically sorted in an order based on value priority
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.9)
Note: work that is not yet scheduled or started
See Also: product backlog, sprint backlog
|
|
backlog refinement.
(1)
progressive elaboration of the content in the backlog and (re)prioritization of it to identify the work that can be accomplished in an upcoming iteration
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
backout.
(1)
to undo the effects of a commit
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: often by introducing a new commit that restores things to their previous state
|
|
backup.
(1)
system, component, file, procedure, or person available to replace or help restore a primary item in the event of a failure or externally caused disaster
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to create or designate a system, component, file, procedure, or person as a replacement
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: back-up
|
|
backup and recovery testing.
(1)
type of reliability testing that measures the degree to which system state can be restored from backup within specified parameters of time, cost, completeness, and accuracy in the event of failure
(ISO/IEC/IEEE 24765k:2022)
|
|
backup programmer.
(1)
assistant leader of a chief programmer team
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Responsibilities include contributing significant portions of the software being developed by the team, aiding the chief programmer in reviewing the work of other team members, substituting for the chief programmer when necessary, and having an overall technical understanding of the software being developed.
See Also: chief programmer
|
|
Backus-Naur Form.
(1)
formal meta-language used for defining the syntax of a language in a textual format
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.1)
|
|
backward propagation.
(1)
method used in artificial neural networks to determine the weights to be used on the network connections based on the computed error at the output of the network
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.17)
Note: Used to train deep neural networks
|
|
backward recovery.
(1)
reconstruction of a file to a given state by reversing all changes made to the file since it was in that state
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
type of recovery in which a system, program, database, or other system resource is restored to a previous state in which it can perform required functions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: forward recovery
|
|
bag.
(1)
a collection class whose members are unordered but in which duplicates are meaningful
(ISO/IEC/IEEE 24765n:2025, 3.1.11)
See Also: list, set
|
|
ball grid array (BGA).
(1)
surface-mounted integrated circuit package with multiple connections in a grid pattern on the bottom surface
(ISO/IEC/IEEE 24765c:2014)
Note: provides more connections than on packages with connectors on the edges only
|
|
base address.
(1)
address used as a reference point to which a relative address is added to determine the address of the storage location to be accessed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: indexed address, relative address, self-relative address
|
|
base choice.
(1)
input parameter value that is normally selected based on being a representative or typical value for the parameter
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.11)
Syn: base value
|
|
base class.
(1)
relationship between a template class CB of instances of B and template class CA of instances of A, where template A is an incremental modification of template B
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.24)
See Also: derived class
|
|
base functional component (BFC).
(1)
an elementary unit of functional user requirements defined by and used by an FSM method for measurement purposes
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.1)
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.8)
(ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 3.1)
Example: A functional user requirement "Maintain Customers" consists of the following BFCs: "Add a new customer", "Report Customer Purchases", and "Change Customer Details". A collection of logically related business data is maintained by the software as "Customer Details".
Syn: functional service, function type
|
|
base functional component type (BFC type).
(1)
defined category of Base Functional Component
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.2)
|
|
base measure.
(1)
measure defined in terms of an attribute and the method for quantifying it
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.3)
Note: A base measure is functionally independent of other measures.
|
|
base practice (BP).
(1)
activity that, when consistently performed, contributes to achieving a specific process purpose
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.2)
|
|
base standard.
(1)
approved International Standard or Telecommunication Standardization Sector of the International Telecommunications Union (ITU-T) Recommendation
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.17)
|
|
baseline.
(1)
formally approved version of a configuration item, regardless of media, formally designated and fixed at a specific time during the configuration item's life cycle
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.12)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.8)
(2)
formally controlled and maintained set of data that serves as the basis for defining change
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.1)
(3)
agreement or result designated and fixed at a given time, from which changes require justification and approval
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
(4)
snapshot of the state of a service or individual configuration items at a point in time
(5)
[verb] to establish and approve a set of data
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.1)
(6)
approved version of a work product, used as a basis for comparison to actual results
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(7)
agreed-to description of the attributes of a product at a point in time, which serves as a basis for defining change
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: Some baselines are project deliverables while others provide the basis for further work. A baseline, together with all approved changes to the baseline, represents the current approved configuration. The term is thus used to refer to a particular version of a configuration item that has been agreed on, e.g., as a stable base for further development or to mark a specific project milestone. Baselines can be modified between formal decision gates by mutual consent through the change control process.
|
|
baseline data.
(1)
data collected at the beginning of a process and used for comparison to subsequently collected data
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.1)
|
|
baseline design.
(1)
system design that has been agreed on by all stakeholders interested in the system development
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
baseline document.
(1)
system or software document that defines a work product that has been placed under configuration management
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: design specifications, requirements specifications, system specifications
|
|
baseline function point count.
(1)
application function point count taken of the functionality at a point in time, from which changes can be measured
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
|
|
baseline management.
(1)
in configuration management, the application of technical and administrative direction to designate the documents and changes to those documents that formally identify and establish baselines at specific times during the life cycle of a configuration item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
basic assumption.
(1)
assumption in a collection of claims shared by assurance cases in a specific field
(ISO/IEC/IEEE 15026-2:2022, Systems and software engineering Systems and software assurance Part 2: Assurance case, 3.1.3)
Note: corresponds to an axiom in formal systems of logic.
|
|
basic engineering object.
(1)
engineering object that requires the support of a distributed infrastructure
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.1)
Example: null
Syn: BEO
|
|
basic flow.
(1)
part of a use case that describes its most common implementation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The basic flow is written assuming that no errors or alternatives exist.
Syn: basic path, happy day scenario
|
|
basic interworking facility.
(1)
a set of service primitives which have a direct correspondence with computational signals which model computational operations
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.4)
|
|
basic maturity level.
(1)
lowest level of achievement in a scale of organizational process maturity
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.3)
|
|
basic process set.
(1)
set of processes, which help ensure the achievement of the basic maturity level
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.4)
|
|
basic profile.
(1)
profile targeted at very small entities (VSE) developing a single product by a single work team
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.18)
|
|
basic symbol.
(1)
symbol used when the precise nature or form of, for example, the process or data media is not known or when it is not necessary to depict the actual medium
(ISO 5807:1985 Information processing -- Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts, 3.1)
|
|
basis of estimates.
(1)
supporting documentation outlining the details used in establishing project estimates such as assumptions, constraints, level of detail, ranges, and confidence levels
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: basis of estimate
|
|
basis set.
(1)
set of objects used to create a multiset
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 2.1.4)
|
|
BAT.
(1)
best available technique
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.2)
|
|
batch.
(1)
pertaining to a system or mode of operation in which inputs are collected and processed all at one time, rather than being processed as they arrive, and a job, once started, proceeds to completion without additional input or user interaction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: conversational, interactive, online, real time
|
|
bathtub curve.
(1)
graph of the number of failures in a system or component as a function of time
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The name is derived from the usual shape of the graph: a period of decreasing failures (the early-failure period), followed by a relatively steady period (the constant-failure period), followed by a period of increasing failures (the wearout-failure period).
|
|
Bayes' rule.
(1)
statistical formula that relates the conditional probability P(A | B) to the inverse conditional probability P(B | A)
(ISO/IEC/IEEE 24765j:2021)
|
|
BCWP.
(1)
budgeted cost of work performed
(ISO/IEC/IEEE 24765c:2014)
|
|
BCWS.
(1)
budgeted cost of work scheduled
(ISO/IEC/IEEE 24765c:2014)
|
|
BDD.
(1)
behavior-driven development
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.5)
|
|
BDIR.
(1)
biometric data interchange record
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
behavior.
(1)
observable activity of a system, measurable in terms of quantifiable effects on the environment whether arising from internal or external stimulus
(2)
of an object, a collection of actions with a set of constraints on when they may occur
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.7)
(3)
peculiar reaction of a thing under given circumstances
(4)
observable sequence of inputs and outputs for a system, sufficient to evaluate compliance with its requirements, or for an observer to identify an anomaly
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
(5)
aspect of an instance's specification that is determined by the state-changing operations it can perform
(ISO/IEC/IEEE 24765n:2025, 3.1.12)
Syn: behaviour
|
|
behavior-driven development (BDD).
(1)
development method in which team members with various backgrounds [developers, testers and business analysts] jointly describe the behavior of the intended functionality prior to development of the relevant functionality
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.5)
Syn: behaviour-driven development
|
|
behavioral compatibility.
(1)
identical behavior of two objects, such that one object can replace the other with respect to a set of criteria without the environment being able to notice the difference in the objects' behavior on the basis of the set of criteria
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.4)
|
|
benchmark.
(1)
reference point against which comparisons can be made
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.1)
(2)
set of tests used to compare the performance of alternatives
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.18)
|
|
benchmark suite.
(1)
collection of tests used to compare the performance of alternatives
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.18)
|
|
benchmarking.
(1)
activity of comparing objects of interest to each other or against a benchmark to evaluate characteristic(s)
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.2)
(2)
comparison of actual or planned products, processes, and practices to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
benchmarking analyst.
(1)
person or organization that conducts benchmarking activity
(ISO/IEC 29155-3:2015 Systems and software engineering--Information technology project performance benchmarking framework--Part 3: Guidance for reporting)
|
|
benchmarking experience base.
(1)
information store that contains the evaluation of the information products and the benchmarking activity, as well as any lessons learned during benchmarking and analysis
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.3)
|
|
benchmarking method.
(1)
logical sequence of general steps to describe the process of comparing one or more attributes against a reference attribute with respect to a specified scale
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.4)
|
|
benchmarking report.
(1)
document of the results of an instance of benchmarking
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 3.7)
Note: Document usually consists of various formats (e.g. textual descriptions, numeric values, statistical charts and tables), and is exchanged via various media (e.g. electronic documents, electronic data set, printed documents, and embedded data within specific computer software).
|
|
benchmarking repository.
(1)
organized and persistent data storage which is designated for benchmarking
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 3.8)
|
|
benchmarking user.
(1)
person or organization that utilizes the outcome of benchmarking
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.5)
|
|
beneficialness.
(1)
extent of benefit resulting from the use of a product, system, or service
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.2.1)
See Also: value
|
|
benefit.
(1)
positive outcome that is voluntarily or involuntarily created by a system or process
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
Note: Benefits correspond to one or more underlying desired values.
|
|
benefit cost analysis.
(1)
in not-for-profit decision analysis, evaluating the desirability of an alternative on the ratio of the net benefits to the population to the net costs to the sponsor
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
benefits management plan.
(1)
documented explanation defining the processes for creating, maximizing, and sustaining the benefits provided by a project or program
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
beta test.
(1)
second stage of testing when a product is in limited production use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: often performed at a customer site
See Also: alpha testing
|
|
BFC class.
(1)
defined group of BFC types
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, 3.1)
|
|
BFC Type.
(1)
a defined category of BFCs
(ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 3.2)
Example: 'External Inputs', 'External Outputs' and 'Logical Transactions', and data stores such as 'Internal Logical Files'
|
|
BGA.
(1)
ball grid array
(ISO/IEC/IEEE 24765c:2014)
|
|
bias.
(1)
in machine learning (ML), a measure of the distance between the predicted value provided by the ML model and a desired fair prediction
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.19)
|
|
bid documents.
(1)
documents used to solicit information, quotations, or proposals from prospective sellers
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
bidder conference.
(1)
meetings with prospective sellers prior to the preparation of a bid or proposal to help ensure all prospective vendors have a clear and common understanding of the procurement
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Example: Also known as contractor conferences, vendor conferences, or pre-bid conferences
Note: Modified, changed "to ensure" to "to help ensure"
|
|
bidirectional traceability.
(1)
association among two or more logical entities that is discernible in either direction (to and from an entity)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: requirements traceability
|
|
big-bang testing.
(1)
type of integration testing in which software elements, hardware elements, or both are combined all at once into an overall system, rather than in stages
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
bill of materials (BOM).
(1)
documented formal hierarchical tabulation of the physical assemblies, subassemblies, and components needed to fabricate a product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
bill-of-features.
(1)
specification for a member product in the product line, rendered in terms of the specific features from the feature catalogue that are chosen for that member product
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.1)
Syn: bill of features
|
|
bill-of-features portfolio.
(1)
specification for a member product in the product line, rendered in terms of the specific features from the feature catalogue that are chosen for that member product
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.2)
|
|
binary digit (bit).
(1)
unit of information that can be represented by either a zero or a one
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
element of computer storage that can hold a unit of information as in (1)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
numeral used to represent one of the two digits in the binary numeration system; zero (0) or one (1)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
bind.
(1)
to assign a value to an identifier
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: to assign a value to a parameter or to assign an absolute address to a symbolic address in a computer program
See Also: dynamic binding, static binding
|
|
binder.
(1)
engineering object in a channel, which maintains a distributed binding between interacting basic engineering objects
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.10)
|
|
binding.
(1)
contractual context resulting from a given establishing behavior
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.5.2)
(2)
task to make a decision on relevant variants, which will be application assets, from domain assets using the domain variability model and from application assets using the application variability model
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.8)
(3)
task for making a decision on relevant variants using a domain variability model and decision tables
(ISO/IEC 26557:2016 Software and systems engineering -- Methods and tools for variability mechanisms in software and systems product line, 3.3)
See Also: assignment
|
|
binding behavior.
(1)
establishing behavior between two or more interfaces, and hence between their supporting objects
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.5.1)
|
|
binding endpoint identifier.
(1)
identifier, in the naming context of a capsule, used by a basic engineering object to select one of the bindings in which it is involved, for the purpose of interaction
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.15)
Example: a memory address (for a data structure representing an engineering interface)
Note: The same form of binding endpoint identifier can be used, whether the binding involved is either local or distributed.
|
|
binding object.
(1)
computational object which supports a binding between a set of other computational objects
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.14)
|
|
binding precondition.
(1)
set of conditions required for the successful execution of a binding behavior
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.5.3)
|
|
binding time.
(1)
moment of variability resolution
(ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.3)
Note: The choice of binding time is independent from variability modelling. It is the consequence of decisions made from requirements through run time. Demands for flexibility and the support of tools allow late binding times or even the use of variable binding times.
|
|
binding time decision.
(1)
selection for variability defined in platforms in accordance with the functional distinction between variability in time and variability in space
(ISO/IEC 26557:2016 Software and systems engineering -- Methods and tools for variability mechanisms in software and systems product line, 3.5)
|
|
binding time of variability.
(1)
stage when the value of variability is determined
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.7)
|
|
biometric characteristic.
(1)
biological and behavioural characteristic of an individual from which distinguishing, repeatable biometric features can be extracted for the purpose of biometric recognition
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.1)
Example: Galton ridge structure, face topography, facial skin texture, hand topography, finger topography, iris structure, vein structure of the hand, ridge structure of the palm, retinal pattern, handwritten signature dynamics
|
|
biometric data.
(1)
biometric sample or aggregation of biometric samples at any stage of processing
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.2)
Example: Biometric reference, biometric probe, biometric feature or biometric property
Note: Biometric data need not be attributable to a specific individual, e.g. Universal Background Models.
|
|
biometric feature.
(1)
number or label extracted from biometric samples and used for comparison
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.3)
|
|
biometric identification.
(1)
process of searching against a biometric enrollment database to find and return the biometric reference identifiers attributable to a single individual
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.4)
|
|
biometric probe.
(1)
biometric sample or biometric feature set input to an algorithm for biometric comparison to a biometric reference
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.5)
Example: In a duplicate enrollment check, a biometric reference is used as the subject for comparisons against all other biometric references in the database.
Note: Typically in a biometric comparison process, incoming biometric samples serve as the subject of comparisons against objects stored as biometric references in a database. In some comparisons, a biometric reference can be used as the subject of the comparison with other biometric references or incoming biometric samples used as the objects of the comparisons.
Syn: biometric query
|
|
biometric recognition.
(1)
automated recognition of individuals based on their biological and behavioral characteristics
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.6)
(2)
data relating to a human subject, or group of humans, for use in empathic technology, particularly physiological data, e.g., heart rate, facial movement, or gait
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: Biometric recognition encompasses biometric identification and biometric verification. Automated recognition implies that a machine-based system is used for the recognition, either for the full process or assisted by a human being.
Syn: biometrics
|
|
biometric reference.
(1)
one or more stored biometric samples, biometric templates, or biometric models attributed to a biometric data subject and used as the object of biometric comparison
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.7)
Example: Face image stored digitally on a passport, fingerprint minutiae template on a national ID card, or Gaussian Mixture Model for speaker recognition in a database; in a duplicate enrollment check, a biometric reference used as the subject for comparison against all other biometric references in the database
Note: A biometric reference can be created with implicit or explicit use of auxiliary data, such as Universal Background Models. The subject/object labelling in a comparison can be arbitrary. In some comparisons, a biometric reference can potentially be used as the subject of the comparison with other biometric references or incoming samples and input to a biometric algorithm for comparison
|
|
biometric reference adaptation.
(1)
automatic incremental updating of a biometric reference
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.8)
Note: Biometric reference adaptation can be used to improve performance (e.g. adapting the reference to take account of variability of an individuals biometric characteristics and to mitigate performance degradation (e.g. due to changes in biometric characteristics over time).
|
|
biometric sample.
(1)
analogue or digital representation of biometric characteristics prior to biometric feature extraction
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.9)
Example: record containing the image of a finger
|
|
biometric system.
(1)
system for the purpose of the biometric recognition of individuals based on their behavioral and biological characteristics
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.10)
|
|
biometric template.
(1)
set of stored biometric features comparable directly to a biometric probe
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.11)
Note: A biometric reference consisting of an image or other captured biometric sample in its original, enhanced, or compressed form, is not a biometric template. The biometric features are not considered to be a biometric template unless they are stored for reference.
Syn: reference biometric feature set
|
|
biometric verification.
(1)
process of confirming a biometric claim through comparison
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.12)
|
|
bit.
(1)
either of the digits 0 or 1 when used in the binary numeration system
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
binary digit
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
built-in test
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
Syn: BIT
|
|
bit steering.
(1)
microprogramming technique in which the meaning of a field in a microinstruction is dependent on the value of another field in the microinstruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: immediate control
See Also: residual control, two-level encoding
|
|
black box.
(1)
system or component whose inputs, outputs, and general function are known but whose contents or implementation are unknown or irrelevant
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
external view of the system (attributes)
(INCOSE Systems Engineering Handbook, 5th ed.)
Syn: closed box, opaque box
See Also: glass box
|
|
block.
(1)
group of contiguous storage locations, computer program statements, records, words, characters, or bits that are treated as a unit
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to form a group
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: block-structured language, delimiter
|
block diagram.
(1)
diagram of a system in which the principal parts or functions are represented by blocks connected by lines that show the relationships of the blocks
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
diagram of a system, computer, or device in which the principal parts are represented by suitably annotated geometrical figures to show both the functions of the parts and their functional relationships
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: configuration diagram, system resources chart
See Also: box diagram, bubble chart, flowchart, graph, input-process-output chart, structure chart
 |
|
block-structured language.
(1)
design or programming language in which sequences of statements, called blocks, are defined, usually with begin and end delimiters, and variables or labels defined in one block are not recognized outside that block
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: Ada, ALGOL, PL/I
See Also: structured programming language
|
|
blocking bug.
(1)
software defect that obstructs further work on a particular task or feature until it is resolved
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
blocking factor.
(1)
number of records, words, characters, or bits in a block
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
BMP.
(1)
bitmap image file
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.2)
|
|
BMT.
(1)
Bench Mark Test
(ISO/IEC 14102:2008 Information Technology - Guideline for the evaluation and selection of CASE tools, 8.2)
|
|
body metadata.
(1)
elements in the body of an HTML document providing administrative or navigational facilities for the user or administrator
(ISO/IEC/IEEE 24765l:2024)
|
|
body of knowledge.
(1)
collection of knowledge items or areas generally agreed to be essential to understanding a particular subject
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.11)
Syn: BOK
|
|
BOK.
(1)
body of knowledge
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.11)
|
|
BOM.
(1)
bill of materials
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.2)
|
|
Boolean expression.
(1)
expression that evaluates to true or false
(ISO/IEC/IEEE 24765i:2020)
|
|
Boolean signature.
(1)
signature where one of the sorts is Bool, corresponding to the carrier Boolean in any associated algebra, and one of the constants is true sub Bool, corresponding to the value true in the algebra
(ISO/IEC/IEEE 24765i:2020)
|
|
boot.
(1)
to initialize a computer system by clearing memory and reloading the operating system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: derived from bootstrap
|
|
boot mode.
(1)
initialized mode of program operations when a computer is turned on
(ISO/IEC/IEEE 24765d:2015)
|
|
bootstrap.
(1)
short computer program that is permanently resident or easily loaded into a computer and whose execution brings a larger program, such as an operating system or its loader, into memory
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to use a program to bring up a larger program, such as an operating system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
|
|
bootstrap loader.
(1)
short computer program used to load a bootstrap
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
bottom-up.
(1)
pertaining to an activity that starts with the lowest-level components of a hierarchy and proceeds through progressively higher-levels
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
pertaining to a method or procedure that starts at the lowest level of abstraction and proceeds towards the highest level
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Example: bottom-up design, bottom-up estimating, bottom-up testing
See Also: top-down. critical piece first
|
|
bottom-up design.
(1)
design approach in which low-level pieces of a system are combined into an overall design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
designing a system by identifying low-level components, designing each component separately, and then designing a structure to integrate the low-level components into larger and larger subsystems until the design is finished
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
boundary.
(1)
conceptual interface between the software under study and its users
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.9)
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, 3.2)
(2)
conceptual interface between the software being measured and its functional users
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.3)
Note: The boundary provides the measurement analyst(s) with a solid delimiter to distinguish, without ambiguity, what is included inside the measured software from what is part of the measured software's operating environment. The boundary defines what is external to the application; it indicates the border between the software being measured and the user; it acts as a "membrane" through which data processed by transactions pass into and out of the application; it is dependent on the user's external business view of the application; it is independent of non-functional and/or implementation considerations. The boundary is identical when assessing the functional size and the non-functional size.
|
|
boundary arrow.
(1)
arrow with one end (source or use) not connected to any box in a diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.14)
See Also: internal arrow
|
|
boundary value.
(1)
data value that corresponds to a minimum or maximum input, internal, or output value specified for a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: stress testing
|
|
boundary value analysis.
(1)
specification-based test design technique based on exercising the boundaries of equivalence partitions
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.12)
|
|
box.
(1)
rectangle containing a box name, a box number, and possibly a box detail reference and representing a function in a diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.16)
|
|
box detail reference.
(1)
square enclosure encompassing a box number, which indicates that the box is decomposed or detailed by a child diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.17)
|
box diagram.
(1)
control flow diagram consisting of a rectangle that is subdivided to show sequential steps, if-then-else conditions, repetition, and case conditions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: Chapin chart, Nassi-Shneiderman chart
See Also: block diagram, bubble chart, flowchart, graph, input-process-output chart, program structure diagram, structure chart
 |
|
box ICOM code.
(1)
ICOM code that maps a tunneled boundary arrow to an arrow attached to some ancestral box
(ISO/IEC/IEEE 24765m:2024, 2.1.18)
|
|
box name.
(1)
verb or verb phrase placed inside a box that names the modeled function
(ISO/IEC/IEEE 24765m:2024, 2.1.19)
Note: A box takes as its box name the function name of the function represented by the box.
See Also: function name
|
|
box number.
(1)
single digit (0, 1, 2, ..., 9) placed in the lower right corner of a box to uniquely identify that box in a diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.20)
Example: null
Note: The only box that can be numbered 0 is the box that represents the A0 function in A-0 and A-1 context diagrams.
|
|
BPMN.
(1)
business process model and notation
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
brainstorming.
(1)
data-gathering and creativity technique that can be used to identify risks, ideas, or solutions to issues by using a group of team members or subject-matter experts
(ISO/IEC/IEEE 24765h:2019)
|
|
branch.
(1)
computer program construct in which one of two or more alternative sets of program statements is selected for execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
point in a computer program at which one of two or more alternative sets of program statements is selected for execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
junction at which a root arrow segment (going from source to use) divides into two or more arrow segments
(ISO/IEC/IEEE 24765m:2024, 2.1.21)
(4)
any of the alternative sets of program statements in (1)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(5)
set of evolving source file versions
(ISO/IEC TR 19759:2016 Software Engineering -- Guide to the Software Engineering Body of Knowledge (SWEBOK), 6.1.3)
(6)
deviation from the main development line for a configuration item, which allows different persons to work on the same item at the same time
(ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.3)
Note: Every branch is identified by a tag. Often, a branch identifies the file versions that have been or will be released as a product release. It can denote unbundling of arrow meaning, i.e., the separation of object types from an object type set. Also refers to an arrow segment into which a root arrow segment has been divided.
See Also: case, jump, go to, if-then-else
|
|
branch condition combination testing.
(1)
structure-based test case design technique based on exercising combinations of Boolean values of conditions within a decision
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.4)
|
|
branch condition testing.
(1)
structure-based test case design technique based on exercising Boolean values of the conditions within decisions and the decision outcomes
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.5)
|
|
branch testing.
(1)
testing designed to execute each outcome of each decision point in a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
structure-based test case design technique based on exercising branches in the control flow of the test item
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.6)
See Also: path testing, statement testing
|
|
branching.
(1)
method of development in which a set of components is duplicated so the components may be modified in parallel and optionally synchronized at a later time
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.2)
|
|
breadcrumb trail.
(1)
navigational aid with a displayed series of links which lead from the home page or another page to the current page
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.3)
|
|
break-even analysis.
(1)
analysis of two or more objective functions to find where, if at all, they have the same value
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
breakpoint.
(1)
point in a computer program at which execution can be suspended to permit manual or automated monitoring of program performance or results
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Types include code breakpoint, data breakpoint, dynamic breakpoint, epilog breakpoint, programmable breakpoint, prolog breakpoint, static breakpoint. A breakpoint is said to be set when both a point in the program and an event that will cause suspension of execution at that point are defined; it is said to be initiated when program execution is suspended.
|
|
brownfield system engineering.
(1)
development of future system or system elements in the presence of an existing or legacy system or system elements
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: A brownfield approach is usually used to extend, improve, or replace a system that is in use or to reuse system elements that are not impacted by the desired changes. The new system architecture takes into account the existing system elements and functions, which can impose constraints on the overall system definition.
See Also: greenfield system engineering
|
|
browser.
(1)
application allowing a person to retrieve and read hypertext, to view the contents of hypertext nodes (Web pages), to navigate from one web page to another, and to interact with the content, such as changing the visual appearance of the displayed content
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.4)
|
|
BRS.
(1)
business requirements specification
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.2)
|
bubble chart.
(1)
data flow, data structure, or other diagram in which entities are depicted with circles (bubbles) and relationships are represented by links drawn between the circles
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: block diagram, box diagram, flowchart, graph, input-process-output chart, structure chart
 |
|
buddy check.
(1)
informal review performed independently by a colleague of the author
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.3)
See Also: peer review
|
|
budget.
(1)
approved estimate for the project or any work breakdown structure component or any schedule activity
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: often used also to refer to work effort as well as, or instead of, money.
See Also: estimate
|
|
budget at completion (BAC).
(1)
sum of all the budgets established for the work to be performed
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
buffer.
(1)
device, routine, or storage area used to store data temporarily to compensate for differences in rates of data flow, time of occurrence of events, or amounts of data that can be handled by the devices or processes involved in the transfer or use of the data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
build.
(1)
operational version of a system or component that incorporates a specified subset of the capabilities that the final product will provide
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(2)
process of generating (archiving) an executable and testable system from source versions or baselines
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.4)
(3)
to perform the steps required to produce an instance of the product
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
Note: In software, this means processing source files to derive target files. In hardware, this means assembling a physical object. The build needs to compile and link the various versions in the correct order. The build tools can be integrated into a configuration management tool.
|
|
built-in random access memory (RAM).
(1)
RAM embedded in a microcontroller unit (MCU) chip
(ISO/IEC/IEEE 24765e:2015)
Syn: built-in RAM
|
|
built-in read only memory.
(1)
read-only memory embedded in a microcontroller unit (MCU) chip
(ISO/IEC/IEEE 24765d:2015)
Syn: built-in ROM
|
|
bundle.
(1)
grouping of products which is the result of a marketing/licensing strategy to sell entitlements to multiple products as one purchased item
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.5)
(2)
arrow segment that collects multiple meanings into a single construct or abstraction, i.e., an arrow segment that represents an object type set that includes more than one object type
(ISO/IEC/IEEE 24765m:2024, 2.1.22)
(3)
to combine separate arrow meanings into a composite arrow meaning, expressed by joining arrow segments, i.e., the inclusion of multiple object types into an object type set
(ISO/IEC/IEEE 24765m:2024, 2.1.22)
Note: A bundle can be referred to as a suite, if the products are closely related and typically integrated (such as an office suite containing a spreadsheet, word processor, presentation and other related items). Bundles can also refer to software titles that are less closely related such as a game, a virus scanner and a utility bundled together with a new computer, or to groups of entitlements, such as multiple entitlements for a backup software product.
|
|
burn chart.
(1)
graphical representation of the work remaining in a timebox or the work completed toward the release of a product or project deliverable
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
burndown.
(1)
indicator of the work completed and an estimate of remaining work to be completed or remaining effort needed to complete a product development iteration cycle
(Software Extension to the PMBOK(R) Guide Fifth Edition)
Note: Work is measured as all work done to deliver story points, stories, features, functions, function points, user stories, use cases, or requirements during a product development iteration.
See Also: burnup
|
|
burndown chart.
(1)
graph that represents the work remaining to do on a project
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.6)
|
|
burndown rate.
(1)
the number of software story points, features, functions, user stories, use cases, or requirements completed per work unit (week or iteration)
(Software Extension to the PMBOK(R) Guide Fifth Edition)
See Also: velocity
|
|
burnup.
(1)
indicator of the number of story points, features, functions, user stories, use cases, or requirements completed and the work remaining or remaining effort needed to complete a product development iteration cycle
(Software Extension to the PMBOK(R) Guide Fifth Edition)
Note: Work is measured as all work done to deliver story points, features, functions, user stories, use cases, or requirements during a product development iteration
Syn: burn-up
See Also: burndown
|
|
bus.
(1)
data communication path in a computer or system
(ISO/IEC/IEEE 24765c:2014)
|
|
business case.
(1)
value proposition for a proposed project that may include financial and non-financial benefits
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
business critical product.
(1)
product that is essential to the operation of a business or organization, whose sustained failure would result in significant business impacts e.g., loss of revenue or loss of reputation
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.21)
|
|
business impact analysis.
(1)
process of analyzing the impact over time of a disruption on the organization
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.8)
Note: The outcome is a statement and justification of business continuity requirements.
|
|
business information management.
(1)
domain responsible for all of the tasks and activities that are aimed at supporting the end users in the use of the application and at acting as the customer of the IT organizations
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.8)
Note: Business information management represents the business as the customer organization or client of the application management and IT infrastructure management organizations in maintaining the functionality of the information provisioning and the information systems. It is the demand side of the information provisioning. An information system can have non-automated elements, such as forms and user guides. Those elements are usually maintained by the business information management organization.
|
|
business model canvas.
(1)
one-page visual summary that describes the value proposition, infrastructure, customers, and finances
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: often used in lean startup situations
|
|
business objective.
(1)
strategy designed by senior management to help ensure an organization's continued existence and enhance its profitability, market share, and other factors influencing the organization's success
(ISO/IEC/IEEE 41062:2024, Software engineering Life cycle processes Software acquisition, 3.1.4)
|
|
business process.
(1)
partially ordered set of enterprise activities that can be executed to achieve some desired end-result in pursuit of a given objective of an organization
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.13)
|
|
business requirement.
(1)
business need that the organization aims to meet
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
(2)
requirement that describes in business terms what needs to be delivered or accomplished
(ISO/IEC/IEEE 41062:2024, Software engineering Life cycle processes Software acquisition, 3.1.5)
|
|
business requirements specification (BRS).
(1)
structured collection of the requirements (business or mission problem or opportunity definition, concepts, and required conditions of solutions) of the business or mission and its relation to the external environment
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 3.1.4)
|
|
business value.
(1)
net quantifiable benefit derived from a business endeavor that may be tangible, intangible, or both
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
strategic priorities set forth by the business as it relates to revenue, cost, risk, security, privacy, ethics, and compliance
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
|
|
busy.
(1)
pertaining to a system or component that is operational, in service, and in use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: down, idle, up
|
|
busy time.
(1)
in computer performance engineering, the period of time during which a system or component is operational, in service, and in use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: operational, in service, and in use
See Also: down time, idle time, set-up time, up time
|
|
byte.
(1)
group of adjacent binary digits operated upon as a unit and usually shorter than a computer word
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
element of computer storage that can hold a group of bits
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
string that consists of a number of bits, treated as a unit, and usually representing a character or a part of a character
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: frequently connotes a group of eight bits
|
|
C4I.
(1)
command, control, communications, computer, and intelligence
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
cache.
(1)
temporary storage in computer memory, to improve operations by having frequently used data readily available for retrieval
(ISO/IEC/IEEE 24765c:2014)
(2)
RAM with very high operating speed used for data storage within a processor
(ISO/IEC/IEEE 24765c:2014)
|
|
CAD.
(1)
Computer Aided Design
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
cadence.
(1)
frequency of performing a periodic activity, such as incremental product release
(Software Extension to the PMBOK(R) Guide Fifth Edition)
(2)
rhythm of activities conducted throughout the project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
CAE.
(1)
claims arguments evidence
(ISO/IEC/IEEE 15026-2:2022, Systems and software engineering Systems and software assurance Part 2: Assurance case, 3.2)
|
|
CAI.
(1)
critical application item
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
calculator.
(1)
device that is suitable for performing arithmetic operations, but that requires human intervention to alter its stored program, if any, and to initiate each operation or sequence of operations
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: A calculator performs some of the functions of a computer, but usually operates only with frequent human intervention.
|
|
calendar unit.
(1)
smallest unit of time used in scheduling a project
(ISO/IEC/IEEE 24765c:2014)
Note: Calendar units are generally in hours, days, or weeks, but can also be in quarter years, months, shifts, or even in minutes.
|
|
call.
(1)
transfer of control from one software module to another, usually with the implication that control will be returned to the calling module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
computer instruction that transfers control from one software module to another and often specifies the parameters to be passed to and from the module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
to transfer control from one software module to another as in (1) and, often, to pass parameters to the other module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
request for service(s) or action(s) with respect to an application or a related service
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.9)
Note: A call can concern a request for service, information or advice; disruption or error reporting (incident); request for change; assignment (for instance an instruction to start an off-schedule production run); and complaint.
See Also: go to
|
|
call by name.
(1)
method for passing parameters, in which the calling module provides to the called module a symbolic expression representing the parameter to be passed, and a service routine evaluates the expression and provides the resulting value to the called module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: Because the expression is evaluated each time its corresponding formal parameter is used in the called module, the value of the parameter can change during the execution of the called module.
See Also: call by reference, call by value
|
|
call by reference.
(1)
a method for passing parameters, in which the calling module provides to the called module the address of the parameter to be passed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: With this method, the called module has the ability to change the value of the parameter stored by the calling module.
Syn: call by address, call by location
See Also: call by name, call by value
|
|
call by value.
(1)
method of passing parameters, in which the calling module provides to the called module the actual value of the parameter to be passed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: With this method, the called module cannot change the value of the parameter as stored by the calling module.
See Also: call by name, call by reference
|
call graph.
(1)
diagram that identifies the modules in a system or computer program and shows which modules call one another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The result is not necessarily the same as that shown in a structure chart.
Syn: call tree, tier chart
See Also: structure chart, control flow diagram, data flow diagram, data structure diagram, state diagram
 |
|
call list.
(1)
ordered list of arguments used in a call to a software module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
call reference.
(1)
page reference attached to a call arrow
(ISO/IEC/IEEE 24765m:2024, 2.1.24)
|
|
called diagram.
(1)
decomposition diagram invoked by a calling box and identified by a page reference attached to a call arrow
(ISO/IEC/IEEE 24765m:2024, 2.1.25)
|
|
calling box.
(1)
box that is detailed by a decomposition diagram that is not the box's child diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.26)
Note: A call arrow is attached to the bottom of a calling box.
|
|
calling sequence.
(1)
sequence of computer instructions and, possibly, data necessary to perform a call to another module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
CAN.
(1)
controller area network
(ISO/IEC/IEEE 24765d:2015)
|
|
candidate.
(1)
applicant who has fulfilled prerequisites and has been admitted to the certification process
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3,3)
|
|
candidate FSM method.
(1)
documented software size measurement method submitted for conformity evaluation
(ISO/IEC 14143-2:2011 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1, 3.1)
|
|
candidate key.
(1)
attribute, or combination of attributes, of an entity for which no two instances agree on the values
(ISO/IEC/IEEE 24765n:2025, 3.1.14)
Note: [key style]
|
|
CAPA.
(1)
corrective and preventative actions
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
capability.
(1)
ability to do something useful under a particular set of conditions
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.14)
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.3)
(2)
expression of a system, product, function, or process ability to achieve a specific objective under stated conditions
(INCOSE Systems Engineering Handbook, 5th ed.)
(3)
quality of being able to perform a given activity
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.2)
(4)
measure of capacity and the ability of an entity (system, person or organization) to achieve its objectives
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.10)
See Also: ability
|
|
capability maturity model.
(1)
model that contains the essential elements of effective processes for one or more disciplines and describes an evolutionary improvement path from ad hoc, immature processes to disciplined, mature processes with improved quality and effectiveness
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
capability requirement.
(1)
requirement that specifies a condition or behavior that a system is to achieve under stated conditions
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
See Also: dependability requirement
|
|
capable process.
(1)
process that can satisfy specified product quality, service quality, and process-performance objectives
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: stable process, standard process, statistically managed process
|
|
capacity.
(1)
capability of a product to meet requirements for the maximum limits of a product parameter
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.2.3)
(2)
for a service, degree to which the maximum limits of a service's parameters meet requirements in the SLA (Service Level Agreement)
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.1.3)
(3)
maximum multiset of tokens a capacity place can hold
(ISO/IEC 15909-3:2021. Systems and software engineering--High-level Petri nets--Part 3: Extensions and structuring mechanisms, 3.1)
Note: Parameters can include the number of items that can be stored, the number of concurrent users, the communication bandwidth, throughput of transactions, and the size of a database. Parameters of capacity for a cloud service can include the limit of simultaneous cloud service connections, the limit of available cloud service resources, cloud service throughput, and cloud service bandwidth.
|
|
capacity place.
(1)
special kind of place that can hold no more than a specified capacity
(ISO/IEC 15909-3:2021. Systems and software engineering--High-level Petri nets--Part 3: Extensions and structuring mechanisms, 3.2)
|
|
capacity testing.
(1)
type of performance efficiency testing conducted to evaluate the level at which increasing load (of users, transactions, data storage, etc.) compromises a test item's ability to sustain required performance
(ISO/IEC/IEEE 24765k:2022)
|
|
capital expenditure.
(1)
spending by an enterprise to acquire tangible infrastructure or facilities items, such as furniture, computers, and the like
(ISO/IEC/IEEE 24765a:2011)
Note: Based upon accounting standards and organization policy, capital expenditure usually relates to relatively large (material) expenditure, which has benefits that are expected to last for more than 12 months. It does not include acquisition of consumable supplies or of items to be included in finished products for sale.
Syn: CapEx
|
|
capsule.
(1)
configuration of engineering objects forming a single unit for the purpose of encapsulation of processing and storage
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.4)
Example: a virtual machine (e.g. a process)
|
|
capsule manager.
(1)
engineering object which manages the engineering objects in a capsule
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.5)
|
|
captured biometric sample.
(1)
biometric sample resulting from a biometric capture process
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.13)
|
|
CARD.
(1)
cost analysis requirements description
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
cardinality.
(1)
constraint on the number of entity instances that are related to the subject entity through a relationship
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
(2)
specification of how many instances of a first class can or are required to exist for each instance of a second (not necessarily distinct) class, and how many instances of a second class can or are required to exist for each instance of a first class
(ISO/IEC/IEEE 24765n:2025, 3.1.15)
Note: For each direction of a relationship, the cardinality can be constrained.
See Also: cardinality constraint
|
|
cardinality constraint.
(1)
constraint that limits the number of instances that can be associated with each other in a relationship
(ISO/IEC/IEEE 24765n:2025, 3.1.16)
(2)
constraint that limits the number of members in a collection
(ISO/IEC/IEEE 24765n:2025, 3.1.16)
See Also: cardinality
|
|
carrier.
(1)
set of a many-sorted algebra
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.4)
|
case.
(1)
single-entry, single-exit multiple-way branch that defines a control expression, specifies the processing to be performed for each value of the control expression, and returns control in all instances to the statement immediately following the overall construct
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
Computer Aided Software Engineering
(ISO/IEC 14102:2008 Information Technology - Guideline for the evaluation and selection of CASE tools, 4)
Syn: multiple exclusive selective construct
See Also: go to, jump, if-then-else. multiple inclusive selective construct
 |
|
CASE needs.
(1)
organizational requirements which are met by CASE tool characteristics
(ISO/IEC TR 14471:2007 Information technology--Software engineering--Guidelines for the adoption of CASE tools, 2.1.3)
Note: These characteristics are detailed in ISO/IEC 14102:1995. They include management process, development process, maintenance, documentation, configuration management, quality assurance, verification, validation, environment needs, CASE tool integrability, quality characteristics, acquisition needs, implementation needs, support indicators, and certification requirements.
|
|
CASE tool.
(1)
software product that can assist software and system engineers by providing automated support for software and system engineering life-cycle activities
(ISO/IEC 15940:2013 Systems and software engineering--Software Engineering Environment Services, 2.3)
(2)
software product that can assist software engineers by providing automated support for software life-cycle activities
(ISO/IEC 14102:2008 Information Technology - Guideline for the evaluation and selection of CASE tools, 3.2)
Note: A CASE tool can provide support in only selected functional areas or in a wide variety of functional areas.
|
|
cast.
(1)
to treat an object of one type as an object of another type
(ISO/IEC/IEEE 24765n:2025, 3.1.17)
See Also: coerce
|
|
catastrophic failure (CF).
(1)
failure of critical software
(ISO/IEC/IEEE 24765n:2025)
|
|
categorization.
(1)
specific way to allocate a target system into a category
(ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.5)
See Also: generalization
|
|
categorization scheme.
(1)
orderly combination of views and categories related to software
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
categorization space.
(1)
universal set of systems and software which has one or more classification axes as its individual dimension, by which stakeholder's concerns on categorization are expressed
(ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.6)
|
|
category.
(1)
specifically defined division or grouping of software based upon one or more attributes or characteristics
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
subset of categorization space, which the stakeholders are interested in, specified using a combination of one or more equivalence classes
(ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.9)
|
|
category entity.
(1)
entity whose instances represent a subtype or subclassification of another entity (generic entity)
(ISO/IEC/IEEE 24765n:2025, 3.1.21)
Note: [key style]
See Also: subclass, subtype
|
|
causal analysis.
(1)
analysis of a defect to determine its cause
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
cause-and-effect diagram.
(1)
visual representation that helps trace an undesirable effect back to its root cause
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
cause-effect graph.
(1)
graphical representation of decision rules between causes (inputs described as Boolean conditions) and effects (outputs described as Boolean expressions)
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.8)
|
|
cause-effect graphing.
(1)
specification-based test case design technique based on exercising decision rules in a cause-effect graph
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.9)
|
|
caution.
(1)
hazardous situation which, if not avoided, can result in minor or moderate injury
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.5)
See Also: danger, warning, note
|
|
CBa.
(1)
conduct benchmarking activity
(ISO/IEC 29155-2:2013 Systems and software engineering--Information technology project performance benchmarking framework--Part 2: Requirements for benchmarking, 4)
|
|
CBT.
(1)
computer-based training
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)
|
|
CCB.
(1)
configuration control board
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2)
(2)
change control board
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2)
|
|
CCMS.
(1)
component content management system
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.4)
|
|
CCTV.
(1)
closed-circuit television
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
CD.
(1)
compact disk
(ISO/IEC/IEEE 24765a:2011)
(2)
continuous delivery
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
(3)
continuous deployment
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
|
|
CD-ROM.
(1)
compact disc, read-only memory
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2)
Syn: CD ROM
|
|
CDD.
(1)
capability development document
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
CDIF.
(1)
CASE Data Interchange Format (originally)
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 5.2)
|
|
CDIF clear text encoding.
(1)
clear text file encoding of a CDIF transfer file
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
CDIF exporter.
(1)
tool that creates a CDIF transfer file
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
CDIF family of standards.
(1)
set of standards that, when used together, provide a standard definition for the interchange of information between modeling tools
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
CDIF graphical notation.
(1)
set of rules governing the representation of CDIF modeling concepts in diagrams
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
CDIF identifier.
(1)
attribute that uniquely identifies an object in the model section of a transfer
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
CDIF importer.
(1)
tool that reads a CDIF transfer file and uses it to create or modify a model
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
CDIF meta-metamodel.
(1)
description of the set of concepts and notations used to define a metamodel
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: Specifically, the CDIF meta-metamodel defines an Entity-Relationship-Attribute model that is used to construct and define both metamodels and the CDIF meta-metamodel itself.
|
|
CDIF metaidentifier.
(1)
meta-meta-attribute that uniquely identifies a meta-object in the metamodel section of a transfer
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
CDIF semantic metamodel.
(1)
description of the set of concepts and notations used to define a model
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: The CDIF semantic metamodel defines an Entity-Relationship-Attribute model that is used to construct and define models used in systems development.
|
|
CDIF transfer.
(1)
combination of a particular syntax, a particular encoding of that syntax, and a metamodel
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: In other words, a complete definition of the format and contents of a transfer.
|
|
CDIF transfer file.
(1)
transfer file conforming to ISO/IEC 15475
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.1)
|
|
CDIF transfer format.
(1)
combination of a particular syntax and a particular encoding of that syntax which together provides a complete definition of the transfer format
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
CDIF transfer syntax and encoding.
(1)
standard vehicle format supported by CDIF
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: The combination of SYNTAX.1 and ENCODING.1 forms the initial CDIF transfer syntax and encoding.
|
|
CDR.
(1)
critical design review
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
CDRL.
(1)
contract data requirements list
(ISO/IEC/IEEE 16326:2019 Systems and software engineering -- Life cycle processes -- Project management, 3)
|
|
CE.
(1)
Conformite' Europe'enne
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)
|
|
CEN.
(1)
European Committee for Standardization
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.2)
Note: In French, Committee Europee'n de Normalisation
|
|
CENELEC.
(1)
European Committee for Electrotechnical Standardization
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.2)
Note: in French, Comite' Europe'en de Normalisation E'lectrotechnique
|
|
central processing unit (CPU).
(1)
functional unit that consists of one or more processors and their internal storage
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
central tendency.
(1)
property of the central limit theorem predicting that the data observations in a distribution will tend to group around a central location
(ISO/IEC/IEEE 24765h:2019)
Note: The three typical measures of central tendency are the mean, median, and mode.
|
|
certificant.
(1)
recipient or holder of a certification
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.4)
|
|
certificate.
(1)
attestation document issued by an independent third-party certification body
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.3)
(2)
document issued by a certification body, indicating that the named person has fulfilled the certification requirements
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.5)
|
|
certification.
(1)
third-party attestation related to an object of conformity assessment, with the exception of accreditation
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.22)
Example: written authorization that a computer system is secure and is permitted to operate in a defined environment
Note: Certification is applicable to all objects of conformity assessment except for conformity assessment bodies themselves, to which accreditation is applicable. Certification of a management system is sometimes also called registration.
|
|
certification artifact.
(1)
tangible results from a certification process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: inspection checklists, metrics, problem reports
|
|
certification body.
(1)
third-party conformity assessment body operating certification schemes
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.23)
Note: A certification body can be non-governmental or governmental (with or without regulatory authority).
|
|
certification criteria.
(1)
set of standards, rules, or properties to which an asset conforms in order to be certified to a certain level
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: Certification criteria are defined by a certification policy. Certification criteria can be specified as a set of mandatory certification properties.
|
|
certification process.
(1)
activities by which a certification body determines that a person fulfils certification requirements, including application, assessment, decision on certification, recertification and use of certificates and logos/marks
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.6)
(2)
process of assessing whether an asset conforms to predetermined certification criteria appropriate for that class of asset
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
certification property.
(1)
a statement about some feature or characteristic of an asset that can be assessed as being true or false during a certification process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: Properties can relate to what an asset is, what it does, or how it relates to its operating environment. An assessment of a certification quality factor is accomplished by assessing the underlying certification properties.
|
|
certification requirements.
(1)
set of specified requirements, including requirements of the scheme to be fulfilled in order to establish or maintain certification of a candidate
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.7)
|
|
certification scheme.
(1)
competence and other requirements related to specific occupational or skilled categories of persons
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.8)
(2)
certification system related to specified products, to which the same specified requirements, specific rules, and procedures apply
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.24)
Note: [ISO/IEC 17024] A certification scheme addresses a candidate's knowledge, skill, competence or proficiency, but it also includes requirements for certified person's ongoing maintenance of proficiency. A specific scheme also contains declarations concerning scope and title; the criteria for assessment of the certified person; and declarations regarding validation of the scheme. The scheme is documented.
|
|
certification scheme owner.
(1)
person or organization that is responsible for developing and maintaining a specific certification scheme
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.25)
Note: The certification scheme owner can be the certification body itself, a governmental authority, trade association, group of certification bodies, or other.
|
|
CFD.
(1)
cumulative flow diagram
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
CFP.
(1)
COSMIC function point
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 3)
(2)
call for proposals
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 3.2)
|
|
CFR.
(1)
Code of Federal Regulations (US)
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
chain.
(1)
one or more tasks submitted to the SUT in a defined sequence
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.3)
(2)
sequence of actions within an activity where, for each adjacent pair of actions, occurrence of the first action is necessary for the occurrence of the second action
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.1.1)
|
|
chain of custody.
(1)
process of maintaining and documenting the handling of evidence
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
Note: involves keeping a detailed log showing who collected, handled, transferred, or analyzed evidence (e.g., PII breach data) during an investigation
|
|
chain type.
(1)
classification of chains which is defined by the sequence of tasks types
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.4)
Note: The emulated users submit only chains of specified chain types to the SUT.
|
|
change.
(1)
modification to any formally controlled deliverable, project management plan component, or project document
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
modification of an existing application comprising additions, changes and deletions
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
See Also: enhancement
|
|
change control.
(1)
process whereby modifications to documents, deliverables, or baselines associated with the project are identified, documented, approved, or rejected
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
actions taken to identify, document, review, and authorize changes to a product that is being developed
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.9)
See Also: configuration control, version control
|
|
change control board (CCB).
(1)
formally chartered group responsible for reviewing, evaluating, approving, delaying, or rejecting changes to a project, and for recording and communicating such decisions
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: change authority
See Also: configuration control board
|
|
change control plan.
(1)
component of the project management plan that establishes the change control board, documents the extent of its authority, and describes how the change control system will be implemented
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
change control system.
(1)
set of procedures that describes how modifications to the project deliverables and documentation are managed and controlled
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
change dump.
(1)
selective dump of those storage locations whose contents have changed since some specified time or event
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: differential dump
See Also: dynamic dump, memory dump, postmortem dump, selective dump, snapshot dump, static dump
|
|
change log.
(1)
comprehensive list of changes submitted during the project and their current status
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
change management.
(1)
judicious use of means to effect a change, or a proposed change, to a product or service
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
comprehensive, cyclic, and structured approach for transitioning individuals, groups, and organizations from a current state to a future state with intended business benefits
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: configuration management
|
|
change package.
(1)
collection of objects that have been changed and approved and will be transferred to the production environment
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.10)
|
|
change project function point count.
(1)
a count that measures the work-output arising from modifications to an existing application that add, change or delete user functions delivered when the project is complete
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
|
|
change record.
(1)
record containing details of which configuration items are affected and how they are affected by an authorized change
(ISO/IEC/IEEE 24765a:2011)
|
|
change request.
(1)
formal proposal to modify a document, deliverable, or baseline
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
formal procedure for submitting a request for an adjustment of a configuration item
(ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.5)
See Also: modification request, request for change
|
|
change set.
(1)
collection of objects which can undergo change as the result of a release
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.11)
|
|
changeover system.
(1)
temporary information processing system used to facilitate the transition from an operational system to its successor
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
channel.
(1)
approach to distributing products and services from the original supplier to the end-user organization
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.3)
(2)
configuration of stubs, binders, protocol objects and interceptors providing a binding between a set of interfaces to basic engineering objects, through which interaction can occur
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.8)
Note: Typical channels for software include direct, VAR, OEM, reseller, and educational reseller.
Bindings that require channels are referred to as distributed bindings in the engineering language; bindings between engineering objects that do not require channels (e.g. between engineering objects in the same cluster) are referred to as local bindings.
Syn: distribution channel
|
|
channel capacity.
(1)
maximum amount of information that can be transferred on a given channel per unit of time; usually measured in bits per second or in baud.
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: memory capacity, storage capacity
|
|
channel partner.
(1)
person or entity working with a software licensor or another person/entity within the channel who facilitates the sale of software to the end-user
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.4)
Example: original equipment manufacturer (OEM), reseller, vendor
|
|
character.
(1)
letter, digit, or other symbol that is used to represent information
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
member of a set of elements that is used for the representation, organization, or control of data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
character set.
(1)
collection of characters used in an encoding to represent terminal symbols
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: The character set used is significant in the encoding of text and string meta-attributes for a CDIF transfer.
|
|
character type.
(1)
data type whose members can assume the values of specified characters and can be operated on by character operators, such as concatenation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: enumeration type, integer type, logical type, real type
|
|
characteristic entity.
(1)
meta-entity that provides additional attribution for another meta-object
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: Each instance of a characteristic meta-entity is logically only related to one instance of one other meta-object, therefore an importer can incorporate the meta-attributes of a characteristic meta-entity with those of the 'owning' meta-object, where the owning meta-object is the one to which the characteristic meta-entity is related with a cardinality of 1:1.
Syn: attributive entity. dependent entity
|
|
characteristic of FUR.
(1)
a distinctive property of the FUR that is important for identifying the functional domain to which a specific set of FUR belongs
(ISO/IEC TR 14143-5:2004 Information technology -- Software measurement -- Functional size measurement -- Part 5: Determination of functional domains for use with functional size measurement, 3.1)
|
|
chart of accounts.
(1)
numbering system used by a project or organization to identify costs by category, such as labor, supplies, materials, and equipment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: code of accounts
|
|
check sheet.
(1)
tally sheet that can be used as a checklist when gathering data
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: checksheet
|
|
checklist-based reviewing.
(1)
review technique guided by a list of questions or required attributes
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.4)
|
|
checkout.
(1)
testing conducted in the operational or support environment to help ensure that a software product performs as required after installation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
checkpoint.
(1)
point in a computer program at which program state, status, or results are checked or recorded
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
object template derived from the state and structure of an engineering object that can be used to instantiate another engineering object, consistent with the state of the original object at the time of checkpointing
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.20)
|
|
checkpointing.
(1)
creating a checkpoint
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.21)
Note: Checkpoints can only be created when the engineering object involved satisfies a pre-condition stated in a checkpointing policy.
|
|
chief programmer.
(1)
leader of a chief programmer team; a senior-level programmer whose responsibilities include producing key portions of the software assigned to the team, coordinating the activities of the team, reviewing the work of the other team members, and having an overall technical understanding of the software being developed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: backup programmer, chief programmer team
|
|
chief programmer team.
(1)
software development group that consists of a chief programmer, a backup programmer, a secretary/librarian, and additional programmers and specialists as needed, and that employs procedures designed to enhance group communication and to make optimum use of each member's skills
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: backup programmer, chief programmer, egoless programming
|
|
child box.
(1)
box in a child diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.27)
|
|
child diagram.
(1)
decomposition diagram related to a specific box by exactly one child/parent relationship
(ISO/IEC/IEEE 24765m:2024, 2.1.28)
|
|
child entity.
(1)
entity in a specific relationship whose instances can be related to zero or one instance of the other entity (parent entity)
(ISO/IEC/IEEE 24765n:2025, 3.1.22)
|
|
CI.
(1)
configuration item
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
(2)
continuous integration
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
|
|
CI/CD.
(1)
continuous integration/continuous delivery
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.2)
|
|
CIA.
(1)
confidentiality, integrity, availability
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.2)
|
|
CIM.
(1)
Computer Integrated Manufacturing
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
CIR.
(1)
configuration item record
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
clabject.
(1)
dual entity that is a class and an object at the same time
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.13)
Note: Because of their dual nature, clabjects exhibit a class facet and an object facet, and can work as either at any time. Instances of powertypes are usually viewed as clabjects, since they are objects (because they are instances of a type, the powertype) and also classes (subtypes of the partitioned type).
|
|
claim.
(1)
true-false statement about the limitations on the values of an unambiguously defined property--called the claim's property--and limitations on the uncertainty of the property's values falling within these limitations during the claim's duration of applicability under stated conditions
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.1.2)
Note: A claim potentially contains the following: property of the system-of-interest; limitations on the value of the property associated with the claim (e.g., on its range); limitations on the uncertainty of the property value meeting its limitations; limitations on duration of claim's applicability; duration-related uncertainty; limitations on conditions associated with the claim; and condition-related uncertainty.
|
|
class.
(1)
abstraction of the knowledge and behavior of a set of similar things
(ISO/IEC/IEEE 24765n:2025, 3.1.23)
(2)
static programming entity in an object-oriented program that contains a combination of functionality and data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
of <X>s, the set of all <X>s satisfying a type
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.10)
Note: Classes are used to represent the notion of "things whose knowledge or actions are relevant."
See Also: type
|
|
class hierarchy.
(1)
ordering of classes, in which a subclass is a specialization of its superclass
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: A class inherits attributes and relationships from its superclass and can define additional attributes and relationships of its own.
|
|
class-level attribute.
(1)
mapping from the class itself to the instances of a value class
(ISO/IEC/IEEE 24765n:2025, 3.1.24)
|
|
class-level operation.
(1)
mapping from the (cross product of the) class itself and the instances of the input argument types to the (cross product of the) instances of the other (output) argument types
(ISO/IEC/IEEE 24765n:2025, 3.1.25)
|
|
class-level responsibility.
(1)
responsibility that represents some aspect of the knowledge, behavior, or rules of the class as a whole
(ISO/IEC/IEEE 24765n:2025, 3.1.26)
Example: The total registeredVoterCount is a class-level property of the class registeredVoter; there can be only one value of registeredVoterCount for the class as a whole.
See Also: instance-level responsibility
|
|
classification.
(1)
machine learning function that predicts the output class for a given input
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.20)
|
|
classification axis.
(1)
total range of a mapping of systems and software for categorizing them from a particular perspective
(ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.7)
|
|
classification tree.
(1)
hierarchical tree model of the input data to a program in which the inputs are represented by distinct classifications (relevant test aspects) and classes (input values)
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.10)
|
|
classification tree method.
(1)
specification-based test case design technique based on exercising classes in a classification tree
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.11)
|
|
classifier.
(1)
machine learning model used for classification
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.20)
|
|
clear.
(1)
to set a variable, register, or other storage location to zero, blank, or other null value
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: initialize, reset
|
|
clear text file encoding.
(1)
class of techniques for representing data based on first defining a human readable representation using some specific character repertoire and then defining an encoding for that repertoire
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.1)
|
|
client.
(1)
entity, code or process that invokes an operation on an object or requests a service from the server
(ISO/IEC/IEEE 24765l:2024)
(2)
in certification, the organization or person responsible to a certification body for ensuring that certification requirements, including product requirements, are fulfilled
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.27)
|
|
client object.
(1)
object which requests that a service be performed by another object
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.4.5)
|
|
client-side.
(1)
node, cluster or capsule, which: a) contains a basic engineering object corresponding to a computational client object; and b) contains, or is potentially capable of containing, stub, binder and protocol objects in a channel supporting operations involving the client object
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.5)
|
|
clock pulse generator (CPG).
(1)
electronic unit to produce uniform timed signals
(ISO/IEC/IEEE 24765d:2015)
Example: embedded in an MCU
|
|
cloning.
(1)
instantiating a cluster from a cluster checkpoint
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.24)
|
|
closed loop.
(1)
loop that has no exit and whose execution can be interrupted only by intervention from outside the computer program or procedure in which the loop is located
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: UNTIL, WHILE
|
|
closed subroutine.
(1)
subroutine that is stored at one given location rather than being copied into a computer program at each place that it is called
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: open subroutine
|
|
closed term.
(1)
term comprising constants and operators but no variables
(ISO/IEC/IEEE 24765i:2020)
Syn: ground term
|
|
cloud application portability.
(1)
degree to which a cloud service provides the ability to migrate their applications from one cloud service to another
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1.7.2)
|
|
cloud computing.
(1)
paradigm for enabling network access to a scalable and elastic pool of shareable physical or virtual resources with self-service provisioning and administration on-demand
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.3.1)
Example: Examples of resources include servers, operating systems, networks, software, applications, and storage equipment.
|
|
cloud data portability.
(1)
degree to which a cloud service provides the ability to move data from one cloud service to another
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.7.1)
|
|
cloud interoperability.
(1)
degree to which a cloud service interacts with the cloud service customer's (CSC's) systems, or interacts with other cloud services, by exchanging information according to a prescribed method to obtain predictable results
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.2.1)
|
|
cloud service.
(1)
one or more capabilities offered via cloud computing invoked using a defined interface
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.3.2)
|
|
cloud service customer (CSC).
(1)
party which is in a business relationship for the purpose of using cloud services
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.3.2)
Note: A business relationship does not necessarily imply financial agreements.
|
|
cloud service partner.
(1)
party which is engaged in support of, or auxiliary to, activities of either the cloud service provider or the cloud service customer, or both
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.3.5)
|
|
cloud service provider (CSP).
(1)
party which makes cloud services available
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.3.4)
|
|
cluster.
(1)
configuration of basic engineering objects forming a single unit for the purposes of deactivation, checkpointing, reactivation, recovery and migration
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.2)
Example: a segment of virtual memory containing objects
|
|
cluster checkpoint.
(1)
cluster template containing checkpoints of the basic engineering objects in a cluster
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.22)
|
|
cluster manager.
(1)
engineering object which manages the basic engineering objects in a cluster
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.3)
|
|
cluster template.
(1)
object template for a configuration of objects and any activity required to instantiate those objects and establish initial bindings
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.19)
|
|
clustering.
(1)
grouping of a set of objects such that objects in the same group (i.e. a cluster) are more similar to each other than to those in other clusters
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.22)
|
|
CM.
(1)
configuration management
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
|
|
CM service.
(1)
abstract description of work done by CM tools
(ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.8)
Syn: configuration management service
|
|
CM tool.
(1)
software product that can assist software engineers by providing automated support for configuration management activities
(ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.9)
Syn: configuration management tool
|
|
CMC.
(1)
cumulative match characteristic
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
CMDB.
(1)
configuration management database
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2)
|
|
CMIP.
(1)
Common Management Information Protocol
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
CMIS.
(1)
Common Management Information Service
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
CMP.
(1)
configuration management plan
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2)
(2)
content management platform
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
|
|
CMS.
(1)
configuration management system
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2)
(2)
content management system
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)
|
|
co-existence.
(1)
capability of a product to perform its required functions efficiently while sharing a common environment and resources with other products, without detrimental impact on any other product
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.3.1)
Syn: coexistence
|
|
code.
(1)
in software engineering, computer instructions and data definitions expressed in a programming language or in a form output by an assembler, compiler, or other translator
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to express a computer program in a programming language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
character or bit pattern that is assigned a particular meaning
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a status code
See Also: source code, object code, machine code, micro code
|
|
code breakpoint.
(1)
breakpoint that is initiated upon execution of a given computer instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: control breakpoint
See Also: data breakpoint, dynamic breakpoint, epilog breakpoint, programmable breakpoint, prolog breakpoint, static breakpoint
|
|
code data.
(1)
substitutable data, which provide a list of valid values that a descriptive attribute may have
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.4)
Example: state, state code, state name, payment type, payment type code, payment description
Note: Typically, the attributes of the code data are Code, Description or other "standard" attributes describing the code. When codes are used in the business data, it is necessary to have a means of translating to convert the code into something more recognizable to the user. In order to satisfy non-functional user requirements, e.g., usability, readability, maintainability, developers often create one or more tables containing the code data.
Syn: list data, translation data
|
|
code freeze.
(1)
period during which non-critical changes to the code are not allowed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
code generator.
(1)
software tool that accepts as input the requirements or design for a computer program and produces source code that implements the requirements or design generator
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: application
|
|
code of ethics standard.
(1)
standard that describes the characteristics of a set of moral principles dealing with accepted standards of conduct by, within, and among professionals
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
code review.
(1)
meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
activity where one or more developers establish the quality of the source code by going through it
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.9)
See Also: design review, formal qualification review, requirements review, test readiness review
|
|
code tuning.
(1)
making statement-level changes to a program to make it more efficient
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
making changes to program source code to optimize performance, usually to increase speed or reduce memory usage
(3)
changes made to program source code for the purpose of optimizing performance, usually to increase speed or reduce memory usage
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
coding.
(1)
in software engineering, expressing a computer program in a programming language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
transforming of logic and data from design specifications (design descriptions) into a programming language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
coerce.
(1)
to treat an object of one type as an object of another type by using a different object
(ISO/IEC/IEEE 24765n:2025, 3.1.28)
See Also: cast
|
|
cognitive walkthrough.
(1)
usability evaluation in which one or more evaluators (or users) step through a use scenario identifying usability problems from a user's perspective that are associated with successful completion of the scenario using the interactive system
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.4.3)
|
|
cohesion.
(1)
manner and degree to which the tasks performed by a single software module are related to one another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
in software design, a measure of the strength of association of the elements within a module
(ISO/IEC TR 19759:2016 Software Engineering -- Guide to the Software Engineering Body of Knowledge (SWEBOK))
Note: Types include coincidental, communicational, functional, logical, procedural, sequential, and temporal.
Syn: module strength
See Also: coupling
|
|
COI.
(1)
conflict of interest
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
Syn: CoI
|
|
coincidental cohesion.
(1)
type of cohesion in which the tasks performed by a software module have no functional relationship to one another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: communicational cohesion, functional cohesion, logical cohesion, procedural cohesion, sequential cohesion, temporal cohesion
|
|
collaboration.
(1)
cooperative exchange of requests among classes and instances in order to achieve some goal
(ISO/IEC/IEEE 24765n:2025, 3.1.29)
|
|
collaborative system of systems.
(1)
system of systems (SoS) in which component systems interact more or less voluntarily to fulfill agreed-upon central purposes
(ISO/IEC/IEEE 21841:2019 Systems and software engineering--Taxonomy of systems of systems, 3.2.2)
Note: Constituent systems collectively decide how to provide or deny service, thereby providing means of enforcing and maintaining consistency.
Syn: collaborative SoS
|
|
collapse.
(1)
to terminate development on one branch by integrating it with another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
collection cardinality.
(1)
specification, for a collection-valued property, of how many members the value of the property, that is, the collection, can or is required to have for each instance
(ISO/IEC/IEEE 24765n:2025, 3.1.30)
See Also: cardinality constraint
|
|
collection class.
(1)
class in which each instance is a group of instances of other classes
(ISO/IEC/IEEE 24765n:2025, 3.1.31)
|
|
collection-valued.
(1)
value that is complex
(ISO/IEC/IEEE 24765n:2025, 3.1.33)
Note: That is, having constituent parts.
See Also: scalar
|
|
collection-valued class.
(1)
class in which each instance is a collection of values
(ISO/IEC/IEEE 24765n:2025, 3.1.34)
See Also: scalar-valued class
|
|
collection-valued property.
(1)
property that maps to a collection class
(ISO/IEC/IEEE 24765n:2025, 3.1.35)
Syn: collection property
See Also: scalar-valued property
|
|
combinatorial testing.
(1)
closed-box test design technique in which test cases are designed to execute specific combinations of values of several parameters
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.23)
(2)
class of specification-based test design techniques based on exercising combinations of parameter-value (P-V) pairs
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.18)
Example: Pairwise testing, all combinations testing, each choice testing, base choice testing
Syn: combinatorial test design technique
|
|
command.
(1)
expression that can be input to a computer system to initiate an action or affect the execution of a computer program
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.11)
Example: the 'logon' command to initiate a computer session
|
|
command language.
(1)
language used to express commands to a computer system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: command-driven
|
|
command-driven.
(1)
pertaining to a system or mode of operation in which the user directs the system through commands
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: command driven
See Also: menu-driven
|
|
comment.
(1)
information embedded within a computer program, job control statements, or a set of data that provides clarification to human readers but does not affect machine interpretation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
commercial-off-the-shelf (COTS).
(1)
[software or hardware] product available for purchase and use without the need to conduct development activities
(ISO/IEC/IEEE 90003:2018 Software engineering -- Guidelines for the application of ISO 9001:2015 to computer software, 3.4)
Note: A COTS software product includes information for users such as the product description, website information, installation instructions and instructions for use, and the software contained on a computer-sensible media disk, CD-ROM, or downloadable. COTS can also include product descriptions, information for users, and software which is produced and supported as separate manufactured goods, but for which typical commercial fees and licensing considerations do not apply.
Syn: commercial off the shelf, Commercial-Off-The-Shelf
See Also: software product
|
|
commissioning.
(1)
procedures prior, or related, to the handing over of a product ready to be placed into service
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.2)
Note: Commissioning may include final acceptance testing, the handing over of relevant documentation for the supported product, or instructing personnel.
|
|
commit.
(1)
to integrate the changes made to a developer's private view of the source code into a branch accessible through the version control system's repository
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
commit message.
(1)
explanatory message accompanying a commit
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: often contains a brief description of the change and its rationale; names of contributors, reviewers, or approvers; a reference to third-party software from which the change was obtained; a schedule for integrating it to other branches; and a reference to the issue identifier associated with the change
|
|
commit privileges.
(1)
person's authority to commit changes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Sometimes privileges are associated with a specific part of the product (for example, artwork or documentation) or a specific branch.
|
|
commit war.
(1)
series of conflicting and mutually reversing commits introduced by developers who disagree on how a particular element is being coded
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: sometimes starts with a hostile backout.
|
|
commit window.
(1)
period during which commits are allowed for a specific branch
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
|
|
commitment.
(1)
action resulting in an obligation by one or more of the participants in the act to comply with a rule or perform a contract
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.2)
Note: The enterprise object(s) participating in an action of commitment can be parties or agents acting on behalf of a party or parties. In the case of an action of commitment by an agent, the principal becomes obligated.
|
|
committer.
(1)
developer with commit privileges
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
common ancestor constraint.
(1)
constraint that involves two or more relationship paths to the same ancestor class and states either that a descendent instance is related to the same ancestor instance through each path or that it is related to a different ancestor instance through each path
(ISO/IEC/IEEE 24765n:2025, 3.1.36)
|
|
common cause.
(1)
source of variation of a process that exists because of normal and expected interactions among components of a process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: On a control chart, it appears as part of the random process variation (i.e., variation from a process that would be considered normal or not unusual), and is indicated by a random pattern of points within the control limits.
Syn: random cause
See Also: special cause
|
|
common configuration item.
(1)
entity within a configuration that is common to all products
(ISO/IEC 26563:2022. Software and systems engineering Methods and tools for product line configuration management, 3.2)
|
|
common storage.
(1)
portion of main storage that can be accessed by two or more modules in a software system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: common area, common block
See Also: global data
|
|
common-environment coupling.
(1)
type of coupling in which two software modules access a common data area
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: common coupling, common environment coupling
See Also: content coupling, control coupling, data coupling, hybrid coupling, pathological coupling
|
|
commonality.
(1)
set of functional and non-functional characteristics that is shared by all applications belonging to the product line
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.9)
(2)
functional and nonfunctional characteristics that can be shared with all member products within a product line
(INCOSE Systems Engineering Handbook, 5th ed.)
|
|
commonality index.
(1)
index that captures the level of commonality of a feature, subsystem, component or a product line
(ISO/IEC 26564:2022, Software and systems engineering Methods and tools for product line measurement, 3.2)
Note: Commonality index is calculated as a formula such as measure or combination of measures (function). The formula for calculating the commonality index reflects the relative size, effort, complexity, or importance of features, subsystems, components, or a product line as weights. Function point is one of the candidate cost estimation methods used to calculate efforts required for establishing core assets or product line development. A commonality index is used in conjunction with a function point.
|
|
communication constraints.
(1)
restrictions on the content, timing, audience, or individual who will deliver a communication, usually stemming from specific legislation or regulation, technology, or organizational policies
(ISO/IEC/IEEE 24765h:2019)
|
|
communication interface.
(1)
interface of a protocol object that can be bound to an interface of either an interceptor object or another protocol object at an interworking reference point
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.14)
|
|
communication management.
(1)
management of objects which support the communication between objects within an ODP system
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 14.2)
|
|
communication management plan.
(1)
a component of the project, program, or portfolio management plan that describes how, when, and by whom information about the project will be administered and disseminated
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: communications management plan
|
|
communicational cohesion.
(1)
type of cohesion in which the tasks performed by a software module use the same input data or contribute to producing the same output data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: coincidental cohesion, functional cohesion, logical cohesion, procedural cohesion, sequential cohesion, temporal cohesion
|
|
communications domain.
(1)
set of protocol objects capable of interworking
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.13)
|
|
communications planning.
(1)
defining how to meet the information and communication needs of the stakeholders: who needs what information, when they need it, and how it will be given to them
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
community.
(1)
configuration of objects formed to meet an objective
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 5.1.1)
Note: The objective is expressed as a contract which specifies how the objective can be met.
|
|
community object.
(1)
composite enterprise object that represents a community
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.2.2)
Note: Components of a community object are objects of the community represented
|
|
compact disc read only memory (CD-ROM).
(1)
optical disk which can be read, but not erased or rewritten
(ISO/IEC/IEEE 24765c:2014)
|
|
compaction.
(1)
in microprogramming, converting a microprogram into a functionally equivalent microprogram that is faster or shorter than the original
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: local compaction, global compaction
|
|
comparator.
(1)
software tool that compares two computer programs, files, or sets of data to identify commonalities or differences
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Typical objects of comparison are similar versions of source code, object code, database files, or test results.
|
|
comparison.
(1)
in biometric analysis, estimation, calculation or measurement of similarity or dissimilarity between biometric probes and biometric references
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.14)
|
|
compatibility.
(1)
capability of a product to exchange information with other products, or to perform its required functions while sharing the same common environment and resources
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.3)
(2)
ability of two or more systems or components to exchange information
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
capability of a functional unit to meet the requirements of a specified interface without appreciable modification
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
compatibility testing.
(1)
type of testing that measures the degree to which a test item can function satisfactorily alongside other independent products in a shared environment (co-existence), and where necessary, exchanges information with other systems or components (interoperability)
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.19)
|
|
compensatory decision technique.
(1)
multiple-attribute decision technique that allows better performance in some of the attributes to compensate for lower performance in one or more of the other attributes; use of trade-offs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: noncompensatory decision technique, additive weighting, analytic hierarchy process, nondimensional scaling
|
|
compensatory model.
(1)
multiple-criteria decision-making model, in which a composite measure is composed of individually weighted terms and where criteria (also referred to as attribute terms) with a high value can compensate for those of a low value in proportion to each weight
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.2)
Note: A compensatory model suggests that improving the more important measures (those with a higher weighting) is more likely to increase or improve the overall composite value than improving the less important ones. This model assumes that the weight (influence level) of criteria remains the same regardless of the measured level of the criteria.
|
|
competence.
(1)
ability to apply knowledge and skills to achieve intended results
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.11)
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.9)
(2)
ability to demonstrate and apply the combination of knowledge, formal and informal skills, training, experience, and behavioral attributes to achieve intended organizational and technical results
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
(3)
measure of specified ability to do something well
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: Results are defined with respect to tasks, functions or responsibilities, which in turn are job/role/title-related. Competence can be used to refer to general ability (e.g. overall competence), while competency can be used to refer to a specific ability (e.g. competency in design of user interfaces).
See Also: competent, competency
|
|
competency.
(1)
observable, measurable set of skills, knowledge, abilities, behaviors, and other characteristics an individual needs to successfully perform work roles or occupational functions
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: Competencies are typically required at different levels of proficiency depending on the specific work role or occupational function.
See Also: competent, competence
|
|
competent.
(1)
having the combination of knowledge, formal and informal skills, training, experience, and behavioral attributes required to perform a task or role
(ISO/IEC/IEEE 24765c:2014)
See Also: competence
|
|
competent assessor.
(1)
assessor who has demonstrated the competencies to conduct an assessment and to monitor and verify the conformance of a process assessment
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.12)
Syn: lead assessor
|
|
competent person.
(1)
person who has acquired through training, qualifications or experience, or a combination of these, the knowledge and skills enabling that person to perform a specified task
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.3)
See Also: skilled person
|
|
compile.
(1)
to translate a computer program expressed in a high-order language into its machine language equivalent
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assemble, decompile, interpret
|
|
compile-and-go.
(1)
operating technique in which there are no stops between the compiling, linking, loading, and execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
compiler.
(1)
computer program that translates programs expressed in a high-order language into their machine language equivalents
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assembler, interpreter, cross-compiler, incremental compiler, root compiler
|
|
compiler code.
(1)
computer instructions and data definitions expressed in a form that can be recognized and processed by a compiler
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assembly code, interpretive code, machine code
|
|
compiler directive source statement.
(1)
source statement that defines macros, or labels, or directs the compiler to insert external source statements (for example, an include statement), or directs conditional compilation, or is not described by one of the other type attributes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
compiler generator.
(1)
translator or interpreter used to construct part or all of a compiler
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: compiler compiler, metacompiler
|
|
complaint.
(1)
record of perceived non-compliance with a service level agreement or customer dissatisfaction with service
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.2)
|
|
complete.
(1)
<documentation> including all critical information and any necessary, relevant information for the intended audience
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.2)
|
|
complete ICOM code.
(1)
diagram feature reference in which dot notation joins an ICOM code to a diagram reference
(ISO/IEC/IEEE 24765m:2024, 2.1.29)
|
|
complete procedure.
(1)
all those activities which commence with entry to the procedure and conclude with exit from the procedure
(ISO/IEC/IEEE 24765a:2011)
|
|
complete table.
(1)
decision table where for all combinations of condition entries there exists a satisfying rule
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.17)
Example: null
Note: In practical terms extended entry tables include limited entries and are therefore mixed entry tables. Any extended or mixed entry table can be transformed into a limited entry table
|
|
completeness.
(1)
degree to which an IT service supports all the goals, objectives, and data specified by the user
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.1.1)
|
|
completion code.
(1)
code communicated to a job stream processor by a batch program to influence the execution of succeeding steps in the input stream
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
completion criteria.
(1)
conditions under which the testing activities are considered complete
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.2)
|
|
completion time theorem.
(1)
real-time scheduling theorem
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: For a set of independent periodic tasks, if each task meets its first deadline when all tasks start at the same time, the deadlines will be met for any combination of start times.
|
|
complex programmable logic device (CPLD).
(1)
hardware component with a fully programmable AND/OR gate array
(ISO/IEC/IEEE 24765d:2015)
|
|
complexity.
(1)
degree to which a system's design or code is difficult to understand because of numerous components or relationships among components
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
degree to which a system or component has a design or implementation that is difficult to understand and verify
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
characteristic of a program or project or its environment that is difficult to manage due to human behavior, system behavior, and ambiguity
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: simplicity
|
|
compliance.
(1)
doing what has been asked or ordered, as required by rule or law
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
(2)
continual fulfillment of internal and external requirements, rules, and regulations
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
(3)
adherence to laws and regulations
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
(4)
extent to which a user or other stakeholder has confidence that a product, system, software, or service in use meets requirements, as required by rules or laws
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.2.3.3)
Example: comply with a regulation
See Also: conformance
|
|
component.
(1)
entity with discrete structure, such as an assembly or software module, within a system considered at a particular level of analysis
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.1.3)
(2)
one part that makes up a system
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
(3)
object that encapsulates its own template, so that the template can be interrogated by interaction with the component
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.26)
(4)
object with a discrete information type that is stored in a component content management system, such as a topic, prerequisite, section, image, or video
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.3)
(5)
product used as a constituent in an assembled product, system or plant
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.4)
Note: A component can be hardware or software and can be subdivided into other components. Component refers to a part of a whole, such as a component of a software product or a component of a software identification tag. The terms module, component, and unit are often used interchangeably or defined to be subelements of one another in different ways depending upon the context. The relationship of these terms is not standardized. A component can be independently managed or not from the end-user or administrator's point of view.
See Also: element, unit
|
|
component content management system (CCMS).
(1)
content management system that supports the entire information-development life cycle from writing through review and publishing, including the reuse of modular content
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.4)
Note: In case the modular content is XML-based, the individual XML elements available for management are defined by the XML schema or DTD. It is not necessary to specify numerous markup languages.
|
|
component implementation.
(1)
activity of realizing a component, including unit test
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.8)
|
|
component integration test.
(1)
testing of groups of related components
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
component standard.
(1)
standard that describes the characteristics of data or program components subdivided into other components
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
component testing.
(1)
testing of individual hardware or software components
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
|
|
composite key.
(1)
key comprising of two or more attributes
(ISO/IEC/IEEE 24765n:2025, 3.1.38)
Note: [key style]
|
|
composite keyword.
(1)
keyword that comprises two or more other keywords
(ISO/IEC/IEEE 29119-5:2024 Software and systems engineering--Software testing--Part 5: Keyword-driven testing, 3.2)
|
|
composite measure.
(1)
variable derived from a set of operations of a construct's multi-item measures defined according to a construct specification (either reflective or formative) that is the way in which the latent variable representing the construct of interest is linked to its measures
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.4)
|
|
composite object.
(1)
object expressed as a composition
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.2)
|
|
composite task.
(1)
task containing nested objects
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
composite type.
(1)
data type each of whose members is composed of multiple data items
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a data type called PAIRS whose members are ordered pairs (x,y)
See Also: atomic type
|
|
composition.
(1)
combination of two or more objects yielding a new object, at a different level of abstraction
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.1.a)
(2)
combination of two or more behaviors yielding a new behavior
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.1.b)
See Also: decomposition
|
|
computation data use.
(1)
use of the value of a variable in any type of statement
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.7)
Syn: c-use
|
|
computational component.
(1)
component specified in a computational viewpoint that has a control interface and declared sets of (a) operation interfaces in which it plays a server role (facets), (b) operation interfaces in which it plays a client role (receptacles), (c) operation interfaces originating announcements carrying notifications of typed events (event sources), (d) operation interfaces consuming announcements carrying notifications of typed events (event sinks), (e) operation interfaces supporting accessors and mutators for attributes (attributes)
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.16)
|
|
computational container.
(1)
container for a declared set of computational component types that has a management interface at which it can be requested to create a computational component of one of the types and add it to the container's content, delete a computational component from the container, list the computational components it currently contains, and list the computational factories it provides
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.17)
|
|
computational factory.
(1)
factory that returns an interface reference to the computational object it creates
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.15)
|
|
computational interface template.
(1)
interface template for either a signal interface, a stream interface, or an operation interface
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.10)
Note: A computational interface template comprises a signal, a stream or an operation interface signature as appropriate, a behavior specification and an environment contract specification.
|
|
computational object template.
(1)
object template which comprises a set of computational interface templates which the object template can instantiate, a behavior specification, and an environment contract specification
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.9)
|
|
computational viewpoint.
(1)
viewpoint on an ODP system and its environment which enables distribution through functional decomposition of the system into objects which interact at interfaces
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.1.1.3)
|
|
computer.
(1)
functional unit that can perform substantial computations, including numerous arithmetic operations and logic operations without human intervention
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: A computer can consist of a stand-alone unit or several interconnected units.
See Also: computing device
|
|
computer center.
(1)
facility that includes personnel, hardware, and software, organized to provide information processing services
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Syn: data processing center
|
|
computer crime.
(1)
crime committed through the use, modification, or destruction of hardware, software, or data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
computer generation.
(1)
category in a historical classification of computers based mainly on the technology used in their manufacture
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Example: first generation based on relays or vacuum tubes, the second on transistors, the third on integrated circuits
|
|
computer graphics.
(1)
methods and techniques for construction, manipulation, storage, and display of images by means of a computer
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
computer instruction.
(1)
statement in a programming language, specifying an operation to be performed by a computer and the addresses or values of the associated operands
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
loosely, any executable statement in a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: Move A to B
See Also: instruction format, instruction set
|
|
computer language.
(1)
language designed to enable humans to communicate with computers
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: design language, query language, programming language
|
|
computer network.
(1)
data processing nodes and their interconnections for the purpose of data communication
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
computer performance evaluation.
(1)
engineering discipline that measures the performance of computer systems and investigates methods by which that performance can be improved
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: system profile, throughput, utilization, workload model
|
|
computer program.
(1)
combination of computer instructions and data definitions that enable computer hardware to perform computational or control functions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
syntactic unit that conforms to the rules of a particular programming language and that is composed of declarations and statements or instructions needed for a certain function, task, or problem solution
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
See Also: software
|
|
computer program abstract.
(1)
brief description of a computer program that provides sufficient information for potential users to determine the appropriateness of the program to their needs and resources
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
computer resource.
(1)
element of a data processing system needed to perform required operations
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Example: storage devices, input-output units, one or more processing units, data, files, and programs
|
|
computer resource allocation.
(1)
assignment of computer resources to current and waiting jobs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: the assignment of main memory, input/output devices, and auxiliary storage to jobs executing concurrently in a computer system
See Also: dynamic resource allocation, storage allocation
|
|
computer resources.
(1)
computer equipment, programs, documentation, services, facilities, supplies, and personnel available for a given purpose
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: computer resource allocation
|
|
computer science.
(1)
branch of science and technology that is concerned with information processing by means of computers
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
computer software component (CSC).
(1)
functionally or logically distinct part of a computer software configuration item, typically an aggregate of two or more software units
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: computer software configuration item, software configuration item, software item
|
|
computer software configuration item (CSCI).
(1)
aggregation of software that is designated for configuration management and treated as a single entity in the configuration management process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: software configuration item (SWCI)
See Also: computer software component, hardware configuration item, configuration item, software configuration item, software item
|
|
computer system.
(1)
system containing one or more computers and associated software
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
system containing one or more components and elements such as computers (hardware), associated software, and data
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.3)
Syn: computing system
See Also: data processing system
|
|
computer-aided (CA).
(1)
pertaining to a technique or process in which a computer does part of the work
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
computer-aided design (CAD).
(1)
use of a computer to design a device or a system, display it on a computer monitor or printer, simulate its operation, and provide statistics on its performance
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.10)
|
|
computer-aided software engineering (CASE).
(1)
use of computers to aid in the software engineering process
(ISO/IEC 15940:2013 Systems and software engineering--Software Engineering Environment Services, 2.2)
Example: application of software tools to software design, requirements tracing, code production, testing, document generation, and other software engineering activities
Syn: computer aided software engineering
See Also: integrated development environment
|
|
computer-based software system (CBSS).
(1)
software system running on a computer
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.5)
Example: null
Note: A CBSS can be a data processing system as seen by human users at their terminals or at equivalent machine-user-interfaces. It includes hardware and all software (system software and application software) which is necessary for realizing data processing functions required by its users
|
|
computerization.
(1)
automation by means of computers
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
computerize.
(1)
to automate by means of computers
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
computing center.
(1)
facility designed to provide computer services to a variety of users through the operation of computers and auxiliary hardware and through services provided by the facility's staff
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: computing centre
|
|
computing device.
(1)
functional unit that can perform substantial computations, including numerous arithmetic operations and logic operations, with or without human intervention
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.6)
Note: A computing device can consist of a stand-alone unit, or several interconnected units. It can also be a device that provides a specific set of functions, such as a phone or a personal organizer, or more general functions such as a laptop or desktop computer.
See Also: computer
|
|
COMSEC.
(1)
communications security
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
concept analysis.
(1)
derivation of a system concept through the application of analysis
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: analysis
|
|
concept drift.
(1)
drift that occurs when the decision boundary changes
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: Concept drift appears as deviations to or from the desired system behavior, based on some agreed measure of objective fact, and is often observed in time series or streaming data.
|
|
concept of operations.
(1)
verbal and graphic statement, in broad outline, of an organizations assumptions or intent in regard to an operation or series of operations of new, modified, or existing organizational systems
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.15)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.9)
Note: It provides the basis for bounding the operating space, system capabilities, interfaces and operating environment. The concept of operations frequently is embodied in long-range strategic plans and annual operational plans. In the latter case, the concept of operations in the plan covers a series of connected operations to be carried out simultaneously or in succession. The concept is designed to give an overall picture of the organization's operations.
Syn: ConOps, CONOPS
See Also: operational concept
|
|
concept of operations (ConOps) document.
(1)
user-oriented document that describes a system's operational characteristics from the end user's viewpoint
(ISO/IEC/IEEE 24765e:2015)
See Also: operational concept description (OCD)
|
|
concept phase.
(1)
period of time in the system life cycle during which the user needs are identified and system concepts are described and evaluated
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: precedes the requirements phase
|
|
conceptual information.
(1)
explanations and descriptions which enable the audience to understand the product's operating principles in order to perform required tasks
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.12)
|
|
conceptual model.
(1)
model of the concepts relevant to some endeavor
(ISO/IEC/IEEE 24765n:2025, 3.1.39)
|
|
conceptual system design.
(1)
system design activity concerned with specifying the logical aspects of the system organization, its processes, and the flow of information through the system
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
concern.
(1)
matter of interest or importance to a stakeholder
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.16)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.10)
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.8)
(2)
interest in something relevant to one or more of its stakeholders
(ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.2)
(3)
matter of relevance or importance to a stakeholder
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.10)
Example: Affordability, agility, availability, dependability, flexibility, maintainability, reliability, resilience, usability and viability are examples of concerns. Survivability, depletion, degradation, loss, obsolescence are examples of concerns. The PESTEL mnemonic is a reminder of possible areas of concern: political, economic, social, technological, environmental, and legal.
Note: A concern pertains to any influence on a system in its environment.
|
|
conciseness.
(1)
software attributes that provide implementation of a function with a minimum amount of code
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
concurrency.
(1)
property of a system in which events can occur independently of each other, and hence are not ordered
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.6)
See Also: step
|
|
concurrent.
(1)
pertaining to the occurrence of two or more activities within the same interval of time, achieved either by interleaving the activities or by simultaneous execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
problem, process, system, or application in which many activities happen in parallel, the order of incoming events is not usually predictable, and events often overlap
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: A concurrent system or application has many threads of control.
See Also: parallel, simultaneous
|
|
concurrent communication diagram.
(1)
diagram depicting a network of concurrent tasks and their interfaces in the form of asynchronous and synchronous message communication, event synchronization, and access to passive information-hiding objects
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
concurrent elaboration.
(1)
life cycle process instances are enacted concurrently during the project, and the information items and artifacts produced by these process instances evolve concurrently
(ISO/IEC 30103:2015 Software and Systems Engineering - Lifecycle Processes - Framework for Product Quality Achievement, 3.1)
Note: This is referred to as concurrent elaboration of information items.
|
|
concurrent enabling (of transition modes).
(1)
state, for a multiset of transition modes, when all the involved input places contain enough tokens to satisfy the sum of all of the demands imposed on them by each input arc annotation evaluated for each transition mode in the multiset
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.5)
|
|
concurrent task architecture.
(1)
description of the concurrent tasks in a system or subsystem in terms of their interfaces and interconnections
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
condition.
(1)
measurable qualitative or quantitative attribute that is stipulated for a requirement and that indicates a circumstance or event under which a requirement applies
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.1.5)
(2)
description of a contingency to be considered in the representation of a problem, or a reference to other procedures to be considered as part of the condition
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.6)
(3)
Boolean expression containing no Boolean operators
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.13)
Example: "A < B is a condition, but A and B is not.
|
|
condition entry.
(1)
indication of the relevance of a condition to a particular rule
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.8)
|
|
condition stub.
(1)
list of all the conditions to be considered in the description of a problem
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.1)
|
|
conditional information.
(1)
information supplied with every product to which it is relevant
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
conditional jump.
(1)
jump that takes place only when specified conditions are met
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: unconditional jump
|
|
conditional task.
(1)
task that can be mandatory under some specified condition, can be optional under other specified conditions, and can be out of scope or not applicable under other specified conditions
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.28)
|
|
conditional text.
(1)
text that is marked to be excluded from one or more versions of a final content deliverable
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.8)
|
|
cone of uncertainty.
(1)
representation of how the uncertainties inherent in a project decrease over the duration of the project
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
confidentiality.
(1)
capability of a product to ensure that data are accessible only to those authorized to have access
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.6.1)
(2)
degree to which an IT service ensures that data are accessible only to those authorized to have access
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.3.1)
|
|
configurability.
(1)
degree of how well a variability mechanism supports the configuration of a member product
(ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.6)
|
|
configuration.
(1)
arrangement of a computer system or component as defined by the number, nature, and interconnections of its constituent parts
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
in configuration management, the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
arrangement of a system or network as defined by the nature, number, and chief characteristics of its functional units
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
requirements, design, and implementation that define a particular version of a system or system component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(5)
manner in which the hardware and software of an information processing system are organized and interconnected
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(6)
collection of objects able to interact at interfaces
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 10.2)
See Also: configuration item; form, fit, and function; version
|
|
configuration audit.
(1)
in configuration management, an independent examination of the configuration status to compare with the physical configuration
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
detailed review of processes, product definition information, documented verification of compliance with requirements, and an inspection of products to confirm that products have achieved their required attributes or conform to released product configuration definition information
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.1)
|
|
configuration baseline.
(1)
configuration information formally designated at a specific time during the life of a product, product component, service, or service component
(ISO/IEC/IEEE 24765c:2014)
Note: Configuration baselines, plus approved changes from those baselines, constitute the current configuration information.
|
|
configuration control.
(1)
an element of configuration management, consisting of the evaluation, coordination, approval or disapproval, and implementation of changes to configuration items after formal establishment of their configuration identification
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: change control, configuration identification, configuration status accounting
|
|
configuration control board (CCB).
(1)
group of people responsible for evaluating and approving or disapproving proposed changes to configuration items, and for ensuring implementation of approved changes
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(2)
qualified personnel who evaluate, for approval or disapproval, all proposed changes to the current developmental baseline
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
Note: This authority can approve a proposed change, thus converting it to an approved modification, or can disapprove a proposed change, or can defer a decision.
Syn: change authority
See Also: configuration control board
|
|
configuration identification.
(1)
element of configuration management, consisting of selecting the configuration items for a system and recording their functional and physical characteristics in technical documentation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
current approved technical documentation for a configuration item as set forth in specifications, drawings, associated lists, and documents referenced therein
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: configuration control, configuration status accounting
|
|
configuration index.
(1)
document used in configuration management, providing an accounting of the configuration items that make up a product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: configuration item development record, configuration status accounting
|
|
configuration item (CI).
(1)
item or aggregation of hardware, software, or both that is designated for configuration management and treated as a single entity in the configuration management process
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.11)
(2)
component of an infrastructure or an item which is or will be under control of configuration management
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.7)
(3)
aggregation of work products that is designated for configuration management and treated as a single entity in the configuration management process
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(4)
any system element or aggregation of system elements that satisfies an end use function and is designated by the acquirer for separate configuration control
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.1)
(5)
item or aggregation of software that is designed to be managed as a single entity and its underlying components, such as documentation, data structures, scripts
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.12)
(6)
system, system element, or artifact designated for configuration management
(INCOSE Systems Engineering Handbook, 5th ed.)
(7)
unit or aggregation of hardware, software, or both that is designated for configuration management and treated as a single entity in the configuration management process
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: Configuration items can vary widely in complexity, size and type, ranging from an entire system including all hardware, software and documentation, to a single module or a minor hardware component. CIs have four common characteristics: defined functionality; replaceable as an entity; unique specification; formal control of form, fit, and function. Information items can be considered as part of the software and managed as part of the configuration item, or can be managed using the information management process
See Also: hardware configuration item, computer software configuration item, configuration identification, critical item
|
|
configuration item development record.
(1)
document used in configuration management, describing the development status of a configuration item based on the results of configuration audits and design reviews
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: configuration index, configuration status accounting
|
|
configuration management (CM).
(1)
discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(2)
technical and organizational activities, comprising configuration identification, control, status accounting and auditing
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(3)
coordinated activities to direct and control the configuration
(ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.7)
See Also: baseline, change management, configuration identification, configuration control, configuration status accounting, configuration audit
|
|
configuration management authority.
(1)
person(s) or group designated to be responsible for assuring that configuration management activities are planned and carried out
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
|
|
configuration management database (CMDB).
(1)
specific type of repository for CM information, usually a data store, used to record attributes of configuration items, and the relationships between configuration items, throughout their lifecycle
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(2)
database containing all the relevant details of each configuration item and details of the important relationships between them
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.8)
(3)
database that is used by an organization to store information about the hardware and software in use
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.10)
See Also: configuration management system
|
|
configuration management system.
(1)
discipline of identifying the components of a continually evolving system to control changes to those components and maintaining integrity and traceability throughout the life cycle
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: configuration management database (CMDB)
|
|
configuration parameter.
(1)
parameter provided by variable components or interfaces, so that its value is selected when bindings occur
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.9)
|
|
configuration status accounting (CSA).
(1)
element of configuration management that consists of the recording and reporting of information needed to manage a configuration effectively
(ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.10)
Note: This information includes a listing of the approved configuration identification, the status of proposed changes to the configuration, and the implementation status of approved changes.
See Also: configuration control, configuration identification, configuration index, configuration item, development record.
|
|
confirmation bias.
(1)
type of cognitive bias that confirms preexisting beliefs or hypotheses
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
conflict.
(1)
change in one version of a file that cannot be reconciled with the version of the file to which it is applied
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Conflict can occur when versions from different branches are merged or when two committers work concurrently on the same file.
|
|
conformance.
(1)
fulfillment by a product, process or service of specified requirements
(2)
adherence to specified requirements
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
(3)
degree to which the results meet the set quality requirements
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: Conformance is used for fulfillment of the requirements of voluntary standards.
See Also: compliance
|
|
conformance point.
(1)
reference point at which behavior can be observed for the purposes of conformance testing
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 10.7)
|
|
conformity.
(1)
fulfillment of a requirement
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.12)
Note: In English the word "conformance" is synonymous but deprecated. In French the word "compliance" is synonymous but deprecated.
|
|
conformity assessment.
(1)
demonstration that specified requirements are fulfilled
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.30)
Note: Conformity assessment can have a negative outcome, i.e. demonstrating that the specified requirements are not fulfilled
|
|
conformity evaluation.
(1)
systematic examination of the extent to which a product, process, or device fulfills specified requirements
(ISO/IEC 25051:2014 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, 4.1.4)
|
|
conformity evaluation report.
(1)
document that describes the conduct and results of the evaluation carried out for a ready-to-use software product (RUSP)
(ISO/IEC 25051:2014 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, 4.1.4)
|
|
confusion matrix.
(1)
table used to describe the performance of a classifier on a set of test data for which the true and false values are known
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.24)
|
|
connectivity.
(1)
capability of a system or device to be attached to other systems or devices without modification
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
ConOps.
(1)
concept of operations
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.2)
Syn: CONOPS
|
|
consecutive.
(1)
pertaining to the occurrence of two sequential events or items without the intervention of any other event or item; that is, one immediately after the other
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
consent.
(1)
voluntary agreement with an action proposed by another
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
Note: Consent is an act of reason; the person giving consent is of sufficient mental capacity and in possession of essential information to give valid consent that includes personal identifiable information. The person giving consent (data subject) is also free from pressure (e.g., administered by the employer representative) to provide consent. Refusal of consent cannot be used to terminate or demote a data subject, but it can result in the need to reassign the data subject.
|
|
consequence.
(1)
outcome of an event affecting one or more stakeholders
(ISO/IEC/IEEE 16085:2021 Systems and software engineering--Life cycle processes--Risk management, 3.1)
(2)
outcome of an event affecting objectives
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.4.1)
(3)
outcome of an occurrence of a particular set of circumstances
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.5)
Note: An event can lead to a range of consequences. A consequence can be certain or uncertain and can have positive or negative effects on objectives. Consequences can be expressed qualitatively or quantitatively. Initial consequences can escalate through follow-on effects.
|
|
consistency.
(1)
degree of uniformity, standardization, and freedom from contradiction among the documents or parts of a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
software attributes that provide uniform design and implementation techniques and notations
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: traceability
|
|
consistent.
(1)
without internal conflicts
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.3)
|
|
consistent state.
(1)
point at which processing has been fully executed, the functional user requirement has been satisfied, and there is nothing more to be done
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.10)
Example: The functional user requirement is to print a check and mark the appropriate account as paid. If only part of the functional user requirement is completed (e.g., only printing the check or only marking it as paid), the application is not in a consistent state. The printing of a check without marking the account as paid causes an inconsistency in the application as does marking it as paid without printing it.
|
|
consolidation of an entitlement.
(1)
process of combining two or more entitlements into a single, unified entitlement
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.5)
Note: Entitlements can be consolidated to simplify understanding of the current position or as the result of a licensor negotiation. The entitlement schema enables the recording of entitlement consolidations.
|
|
constant.
(1)
quantity or data item whose value cannot change
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
instance whose identity is known at the time of writing
(ISO/IEC/IEEE 24765n:2025, 3.1.40)
(3)
specification that an attribute or participant property value, once assigned, is unchangeable, or that an operation always provides the same output argument values, given the same input argument values
(ISO/IEC/IEEE 24765n:2025, 3.1.40)
Example: the data item FIVE, with an unchanging value of 5
Note: The identity of a constant state class instance is represented by #K, where K is an integer or a name.
See Also: variable figurative constant, literal
|
|
constant dollar analysis.
(1)
addressing inflation and deflation by using cash flow amounts that represent money values which are referenced to a fixed time, typically, the beginning of a project
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: actual dollar analysis
|
|
constant-failure period.
(1)
period of time in the life cycle of a system or component during which hardware failures occur at an approximately uniform rate
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: early-failure period, wearout-failure period, bathtub curve
|
|
constituent configuration item.
(1)
individual item to be controlled that is a constituent part of a larger configuration item, such as a reference model, hardware prototype, or software build
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
|
|
constituent system.
(1)
independent system that forms part of a system of systems (SoS)
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.18)
(ISO/IEC/IEEE 21839:2019 Systems and software engineering-- System of systems (SoS) considerations in life cycle stages of a system, 3.1.1)
Note: Constituent systems can be part of one or more SoS. Each constituent system is a useful system by itself, having its own development, management, utilization, goals, and resources, but interacts within the SoS to provide the unique capability of the SoS.
Syn: CS
|
|
constraint.
(1)
limitation or implied requirement that constrains the design solution or implementation of the systems engineering process and is not changeable by the enterprise
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes)
(2)
externally imposed limitation on the system, its design, or implementation or on the process used to develop or modify a system
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.1.6)
(3)
a statement that expresses measurable bounds for an element or function of the system
(4)
limiting factor that affects the execution of a project, program, portfolio, or process
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(5)
a rule that specifies a valid condition of data
(6)
externally imposed limitation on system requirements, design, or implementation or on the process used to develop or modify a system
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.1.6)
(7)
restriction on the value of an attribute or the existence of any object based on the value or existence of one or more others
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
(8)
a responsibility that is a statement of facts that are required to be true in order for the constraint to be met
(9)
an externally imposed limitation on system requirements, design, or implementation or on the process used to develop or modify a system
|
|
constraints dependency.
(1)
relationship between variation points, between variants and between a variation point and a variant
(ISO/IEC 26558:2017 Software and systems engineering -- Methods and tools for variability modelling in software and systems product line, 3.5)
|
|
construct.
(1)
concept, such as the abstract idea, image, underlying theme, or subject matter, that one wishes to measure using process assessments
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.5)
Note: In process measurement frameworks, constructs (including latent constructs) are theoretical concepts such as the process quality characteristics and process attributes. The meaning that one assigns to a construct is its theoretical definition, which should describe its distinct dimensions (facets).
|
|
construction.
(1)
process of writing, assembling, or generating assets
(ISO/IEC/IEEE 24765j:2021)
(2)
activity in software development consisting of detailed design, coding, unit testing, and debugging
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: the collection of activities focused on creating source code
|
|
consumable.
(1)
any part or material that is necessary to be replaced or refilled for continuous use or maintenance of the product
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.6)
|
|
consumer.
(1)
individual member of the general public, purchasing or using products for private purposes
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.7)
Note: A consumer is assumed to be a nonskilled person.
See Also: event sink
|
|
consumer object.
(1)
object which is a sink of the information conveyed
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.4.4)
|
|
consumer product.
(1)
product available to, intended for or likely to be used by consumers
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.8)
|
|
consumer software package.
(1)
COTS software product designed and sold for end users to carry out identified functions; the software and its associated documentation are packaged for sale as a unit
(ISO/IEC/IEEE 24765a:2011)
|
|
container.
(1)
object that can act as a factory and can provide the necessary environment for subsequent management of the components created by it
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.27)
(2)
framework for integrating transactions, security, events and persistence into a component's behavior at runtime
(3)
isolated execution environment for running software that uses a virtualized operating system kernel
(ISO/IEC/IEEE 24765l:2024)
|
|
container interface.
(1)
interface of a data repository allowing access to data
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 14.1.1.2)
|
|
content.
(1)
interactive or non-interactive object containing information represented by text, image, video, sound, or other media
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.5)
|
|
content chunk.
(1)
unit of content that satisfies a requirement of a specific task for a specific user
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.2.8)
Example: A research report is divided into five content chunks that deal with background information, methodology, results, conclusions, and recommendations.
Note: A content chunk defines a subtopic that justifies separate consideration by the user.
|
|
content consistency.
(1)
semantic consistency among the contents of information items
(ISO/IEC 30103:2015 Software and Systems Engineering - Lifecycle Processes - Framework for Product Quality Achievement, 3.2)
|
|
content coupling.
(1)
type of coupling in which some or all of the contents of one software module are included in the contents of another module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: common-environment coupling, control coupling, data coupling, hybrid coupling, pathological coupling
|
|
content management.
(1)
control of units of information with their metadata, to allow selective reuse in documents or information products with variable structures and formats
(ISO/IEC/IEEE 24765h:2019)
Note: Content management for user documentation means management of help topics, explanations of
concepts, troubleshooting procedures, compliance statements, and variables such as the names and host platforms of
software products, with metadata tags that are applied to format output.
|
|
content management platform (CMP).
(1)
managed system that builds a unified, persistent database that is accessible to other systems
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
Note: A CMP acts as a fusion center and repository for data from various internal and external systems. A CMP provides the ability to accommodate different data types and formats that can have varying structures and naming conventions.
See Also: content management system
|
|
content management system.
(1)
system that makes components available for reuse and linking to build content objects and deconstructs large content objects into components that can be individually managed
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.5)
See Also: document management system
|
|
content object.
(1)
self-contained unit of content
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.6)
|
|
content type.
(1)
specific indicator of content
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.7)
|
|
content unit.
(1)
identifiable and manageable part of larger information objects
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.8)
Note: The individual content units available for management are typically defined by an XML schema or DTD.
|
|
context.
(1)
immediate environment in which a function (or set of functions in a diagram) operates
(ISO/IEC/IEEE 24765m:2024, 2.1.30)
|
|
context completeness.
(1)
degree to which a product or system can be used with the required levels of effectiveness, efficiency, freedom from risk and satisfaction in each of the specified contexts of use
(ISO/IEC 25022:2016, Systems and software engineering -- Systems and software quality requirements and evaluation (SQuaRE) -- Measurement of quality in use, 4.1)
Example: The extent to which software is usable using a small screen, with low network bandwidth, by a non-expert user, and in a fault-tolerant mode (e.g. no network connectivity).
Note: Context completeness can be specified or measured either as the degree to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency, freedom from risk and satisfaction in all the intended contexts of use, or by the presence of product properties that support use in all the intended contexts of use.
|
|
context-sensitive help.
(1)
type of onscreen information for users in which the material that is displayed depends upon the user's view of the software current status of the software and the progress of the users task
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.14)
See Also: embedded documentation, printed documentation
|
|
contextual factor.
(1)
condition that drives or affects the requirements for an organization or a system being developed
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
Note: Contextual factors are likely to change, and can be reviewed periodically where they have shaped requirements or controls.
|
|
contextual schema.
(1)
formal description of the boundary of the context of use where data models are applied
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.4)
Note: It is a high-level description of the business informational needs. It is more general than a conceptual model, as it includes a holistic vision of a (system) context of the architecture.
|
|
contiguous allocation.
(1)
storage allocation technique in which programs or data to be stored are allocated a block of storage of equal or greater size, so that logically contiguous programs and data are assigned physically contiguous storage locations
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: paging
|
|
contingency.
(1)
event or occurrence that can affect the execution of the project, which can be accounted for with a reserve
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
contingency plan.
(1)
plan for dealing with a risk factor, if it becomes a problem
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
contingency reserve.
(1)
time or money allocated in the schedule or cost baseline for known risks with active response strategies
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
contingent threshold.
(1)
threshold value in a dependability requirement that is desirable but optional owing to uncertainty about the trade-offs related to its achievement
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: A contingent threshold typically quantifies a capability level that is required only if it can be achieved without incurring excessive cost, unfavorable risk, or an unfavorable operational effect.
|
|
continual improvement.
(1)
recurring activity to enhance performance
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.13)
|
|
continual process improvement.
(1)
ongoing cycle of process improvement programs to strengthen and improve the processes supporting business and include one or several improvement projects or initiatives, which can be implemented in series or in parallel
(ISO/IEC TR 33014:2013 Information technology--Process assessment--Guide for process improvement, 3.1)
|
|
continuity.
(1)
degree to which the IT service is provided under all foreseeable circumstances, including mitigating the risks resulting from interruption to an acceptable level
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.4.1)
|
|
continuous delivery.
(1)
software engineering practices that allow for frequent releases of new systems (including software) to staging or various test environments through the use of automated tools
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
(2)
practice of delivering feature increments immediately to customers, often through the use of small batches of work and automation technology
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
continuous deployment.
(1)
automated process of deploying changes to production by verifying intended features and validations to reduce risk
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
Syn: CD
See Also: continuous delivery
|
|
continuous forms.
(1)
forms produced in continuous lengths during the manufacturing process and intended primarily for use with sprocket-hole transporting mechanisms
(ISO/IEC/IEEE 24765i:2020)
|
|
continuous improvement.
(1)
ongoing cycle of identification, implementation, and evaluation of changes to how practices are used that strengthen the ability of an organization or project to meet its objectives
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.12)
|
|
continuous integration.
(1)
technique that continually merges artifacts, including source code updates from all developers on a team, into a shared mainline to build and test the developed system
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
Syn: CI
|
|
continuous iteration.
(1)
loop that has no exit
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
continuous representation.
(1)
capability maturity model structure wherein capability levels provide a recommended order for approaching process improvement within each specified process area
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
continuous risk management.
(1)
process of analyzing the progress of a planned activity, project, or program on a periodic, ongoing basis and handling identified risk factors
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
continuous process, which may be automated, that identifies, applies, and monitors controls to treat risks for a planned activity, project, or program, to achieve a desired outcome
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
Example: null
Note: includes developing options and fallback positions to permit alternative solutions to reduce the impact if a risk factor becomes a problem.
|
|
contract.
(1)
mutually binding agreement that obligates the seller to provide the specified product, service, or result and obligates the buyer to pay for it
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
agreement governing part of the collective behavior of a set of objects
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.1)
(3)
relationship between acquirer and supplier, which in broad terms prescribes that one party will provide defined goods and services and the other party will pay a defined fee for them
(ISO/IEC/IEEE 26512:2018 Systems and software engineering--Requirements for acquirers and suppliers of information for users, 3.6)
Note: A contract is an agreement between two or more parties regarding a course of action. The formality of a contract can range from a simple informal oral description to a formal written instrument.
|
|
contract administration.
(1)
managing the contract and the relationship between the acquirer and supplier, including reviewing and documenting how the supplier is performing or has performed; establishing required corrective actions; and managing contract changes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
contract management plan.
(1)
document that describes how a specific agreement will be administered to monitor delivery of required documentation and performance of the statement of work, to evaluate performance, and to control changes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
contract work breakdown structure (CWBS).
(1)
portion of the overall work breakdown structure applicable to a contract, developed and maintained by the supplier
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
contractual context.
(1)
knowledge that a particular contract is in place, and thus that a particular behavior of a set of objects is required
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.2.3)
|
|
contractual requirement.
(1)
result of the analysis and refinement of customer requirements into a set of requirements suitable to be included in one or more solicitation packages, formal contracts, or supplier agreements between the acquirer and other appropriate organizations
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: acquirer, customer requirement
|
|
contravariance.
(1)
rule governing the overriding of a property and requiring that the set of values acceptable for an input argument in the overriding property is a superset (includes the same set) of the set of values acceptable for that input argument in the overridden property, and the set of values acceptable for an output argument in the overriding property is a subset (includes the same set) of the set of values acceptable for that output argument in the overridden property
(ISO/IEC/IEEE 24765n:2025, 3.1.42)
|
|
control.
(1)
in engineering, the monitoring of system output to compare with expected output and taking corrective action when the actual output does not match the expected output
(2)
monitoring of system output to compare with expected output and taking corrective action when the actual output does not match the expected output
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
(3)
process of comparing actual performance with planned performance, analyzing variances, assessing trends to effect process improvements, evaluating possible alternatives, and recommending appropriate corrective action as needed
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(4)
ability to determine the nature, sequence, or consequences of technical and operational settings, behavior, specific events, or experiences
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
(5)
measure that is modifying risk
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.12)
(6)
object, often analogous to physical controls, which allows a user to take some action which manipulates data, other objects or their attributes
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.2.5)
(7)
in an IDEF0 model, a condition or set of conditions required for a function to produce correct output
(ISO/IEC/IEEE 24765n:2025, 2.1.32)
Note: Control includes cognitive control (that is, being informed about activities), decisional control (having choices over actions), and behavioral control (receiving feedback from actions).
|
|
control chart.
(1)
graphic display of process data over time and against established control limits, which has a centerline that assists in detecting a trend of plotted values toward either control limit
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
control clustering.
(1)
task-structuring criterion by which a control object is combined into a task with the objects it controls
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
control coupling.
(1)
type of coupling in which one software module communicates information to another module for the explicit purpose of influencing the latter module's execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: common-environment coupling, content coupling, data coupling, hybrid coupling, pathological coupling
|
|
control data.
(1)
data that select an operating mode, direct the sequential flow of a program, or otherwise directly influence the operation of software
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a loop control variable
|
|
control field.
(1)
field comprising one or more input variables whose change in value, or lack of change, between successive logical records affects the flow of control through the main procedure
(ISO/IEC/IEEE 24765a:2011)
|
|
control flow.
(1)
sequence in which operations are performed during the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
sequence in which operations are performed during the execution of a test item
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.14)
Syn: flow of control
See Also: data flow
|
|
control flow diagram.
(1)
diagram that depicts the set of all possible sequences in which operations can be performed during the execution of a system or program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Types include box diagram, flowchart, input-process-output chart, state diagram.
See Also: data flow diagram, call graph, structure chart
|
|
control flow sub-path.
(1)
sequence of executable statements within a test item
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.15)
|
|
control Information.
(1)
data that influences an elementary process by specifying what, when or how data is to be processed
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.11)
|
|
control loopback.
(1)
loopback of output from one function to be the control for another function in the same diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.34)
Syn: feedback
|
|
control risks.
(1)
implementing risk response plans, tracking identified risks, monitoring residual risks, identifying new risks, and evaluating risk process effectiveness throughout the project
(ISO/IEC/IEEE 24765h:2019)
Syn: monitor and control risks
|
|
control statement.
(1)
program statement that selects among alternative sets of program statements or affects the order in which operations are performed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: if-then-else, case
See Also: assignment statement, declaration
|
|
control store.
(1)
in a microprogrammed computer, the computer memory in which microprograms reside
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: microword, nanostore
|
|
control task.
(1)
task that makes decisions to control other tasks' execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
controller.
(1)
device or computer chip that interfaces with a peripheral device
(ISO/IEC/IEEE 24765d:2015)
|
|
controller area network (CAN).
(1)
high-integrity bus system for networking intelligent devices within a system
(ISO/IEC/IEEE 24765d:2015)
Note: commonly used in embedded networks for vehicles or medical equipment
|
|
convention.
(1)
requirement employed to prescribe a disciplined, uniform approach to providing consistency in a software product, that is, a uniform pattern or form for arranging data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: practice, standard
|
|
conversational.
(1)
pertaining to an interactive system or mode of operation in which the interaction between the user and the system resembles a human dialog
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: batch, interactive, online, real time
|
|
conversion.
(1)
modification of existing software to enable it to operate with similar functional capability in a different environment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: converting a program from FORTRAN to Ada, converting a program that runs on one computer to run on another
|
|
conversion functionality.
(1)
transactional or data functions provided to convert data or provide other user-specified conversion requirements
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.12)
Note: Conversion functionality exists only during the development or enhancement of an application.
|
|
convertibility.
(1)
the ability to convert the results from applying two or more FSM methods in the measurement of a functional size of the same set of functional user requirements
(ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.3)
|
|
cookie.
(1)
small file that is stored in and retrieved from user web storage to maintain state information, including identification of users and transaction coherency
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.6)
Note: Web sites store and retrieve cookies from user client systems to maintain state information including identification of users and transaction coherency.
|
|
COOP.
(1)
continuity of operations plan
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 3.2)
|
|
copy.
(1)
to read data from a source, leaving the source data unchanged, and to write the same data elsewhere in a physical form that can differ from that of the source
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
result of a copy process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: to copy data from a magnetic disk onto a magnetic tape
See Also: move
|
|
copyright.
(1)
exclusive right granted to the owner of an original work of authorship, which is fixed in any tangible medium of expression, to reproduce, publish, perform, or sell the work
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
COQ.
(1)
cost of quality
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
Cor.
(1)
corrigenda
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
CORBA.
(1)
Common Object Request Broker Architecture
(ISO/IEC 14769:2001 Information technology -- Open Distributed Processing -- Type Repository Function, 4)
|
|
core.
(1)
processing unit in a computer or processor which manages instructions, data, and operations
(ISO/IEC/IEEE 24765c:2014)
|
|
core report.
(1)
document for providing descriptions of the process and outcomes of the benchmarking activity
(ISO/IEC 29155-3:2015 Systems and software engineering--Information technology project performance benchmarking framework--Part 3: Guidance for reporting)
Note: Two kinds of core reports (i.e. executive summary and detailed report) are often produced for reporting results of an instance of benchmarking activity.
|
|
core value.
(1)
A value that is identified as central in the context of a system of interest
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
Example: Transparency and privacy can be primary attributes (core values) of an information system.
Note: A core value is at the center of a value cluster of instrumental or related values and value demonstrators. A core value is a positive value. Typically, a system of interest (SoS) has several core values.
|
|
coroutine.
(1)
routine that begins execution at the point at which operation was last suspended, and that is not required to return control to the program or subprogram that called it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: subroutine
|
|
corporate board or equivalent body.
(1)
person or group of people who assumes legal responsibility for conducting or controlling an organization at the highest level
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.9)
|
|
corporate governance of IT.
(1)
at the level of top management, establishment of strategy and policy for the use of IT, and organizational control of the use of IT
(ISO/IEC/IEEE 24765c:2014)
Example: null
|
|
correctability.
(1)
degree of effort required to correct software defects and to cope with user complaints
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
correction.
(1)
change that addresses and implements problem resolutions to recover gaps and to make software operational enough to meet defined operational requirements
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.1.3)
Note: The term correction is mainly used as a maintenance type and to classify modification requests (MR).
See Also: enhancement
|
|
corrective action.
(1)
action to eliminate the cause of a nonconformity and to prevent recurrence
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.14)
See Also: preventive action
|
|
corrective maintenance.
(1)
modification of a software product performed after delivery to correct discovered problems
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.1.4)
(2)
maintenance performed to correct faults in hardware or software
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The modification repairs the software product to satisfy defined system requirements.
|
|
corrective support.
(1)
modification of an in-service system to remove faults causing failures or anomalies
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: Corrective support changes an in-service system so that it satisfies defined system requirements.
|
|
correctness.
(1)
degree to which a system or component is free from faults in its specification, design, and implementation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
degree to which software, documentation, or other items meet specified requirements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
degree to which software, documentation, or other items meet user needs and expectations, whether specified or not
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
degree to which an IT service uses the correct process and produces the correct results with accurate data
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.1.2)
|
|
correspondence.
(1)
identified or named relationship between two or more architecture description elements
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.11)
Note: Correspondences are used to express a wide range of relationships, such as equivalence, composition, refinement, consistency, traceability, dependency, constraint, satisfaction, and obligation. Correspondences can be identified or named relationships between architecture description elements in different architecture descriptions or between architecture description elements stated in different notations.
|
|
COSMIC.
(1)
Common Software Measurement International Consortium
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method)
|
|
cost avoidance.
(1)
revenue (positive cash flow) that results from decreasing expenses, rather than from increasing income
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
cost baseline.
(1)
approved version of the time-phased project budget, excluding any management reserves, which can be changed only through formal change control procedures and is used as a basis for comparison to actual results
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
cost basis.
(1)
entire cost to acquire an asset
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: includes the purchase price, delivery, installation, and any other costs to put the asset into service
Syn: acquisition cost
|
|
cost constraint.
(1)
limitation or restraint placed on the project budget, such as funds available over time
(ISO/IEC/IEEE 24765c:2014)
|
|
cost function.
(1)
objective function that characterizes the cost associated with different values of the decision variable
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: income function
|
|
cost management plan.
(1)
component of a project or program management plan that describes how costs will be planned, structured, and controlled
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
cost of quality (COQ).
(1)
all costs incurred over the life of the product by investment in preventing non-conformance to requirements, appraisal of the product or service for conformance to requirements, and failure to meet requirements
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: Prevention and appraisal costs (cost of conformance) include costs for quality planning, quality control (QC), and quality assurance to help ensure compliance to requirements (i.e., training, QC systems, etc.). Failure costs (cost of non-conformance) include costs to rework products, components, or processes that are non-compliant, costs of warranty work and waste, and loss of reputation.
|
|
cost performance baseline.
(1)
time-phased budget under change control, used to compare actual expenditures to planned expenditures
(ISO/IEC/IEEE 24765c:2014)
Note: used to determine if preventive or corrective action is needed to meet the project objectives
|
|
cost performance index (CPI).
(1)
measure of the cost efficiency of budgeted resources expressed as the ratio of earned value to actual cost
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
cost plus award fee contract (CPAF).
(1)
category of contract that involves payments to the seller for all legitimate actual costs incurred for completed work, plus an award fee representing seller profit
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
cost plus fixed fee contract (CPFF).
(1)
type of cost-reimbursable contract where the buyer reimburses the seller for the seller's allowable costs (allowable costs are defined by the contract) plus a fixed amount of profit (fee)
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: cost-plus-fixed-fee contract
|
|
cost plus incentive fee contract (CPIF).
(1)
type of cost-reimbursable contract where the buyer reimburses the seller for the seller's allowable costs (allowable costs are defined by the contract), and the seller earns its profit if it meets defined performance criteria
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: cost-plus-incentive-fee contract
|
|
cost variance (CV).
(1)
amount of budget deficit or surplus at a given point in time, expressed as the difference between the earned value and the actual cost
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
cost-benefit analysis.
(1)
financial analysis tool used to determine the benefits provided by a project against its costs
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
cost-plus-fee (CPF).
(1)
contract in which the acquirer reimburses the supplier's allowable costs for performing the contract work and also pays a fee
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: cost plus fee
|
|
cost-reimbursable contract.
(1)
type of contract involving payment to the seller for the seller's actual costs, plus a fee typically representing the seller's profit
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: cost reimbursable contract
|
|
COTS.
(1)
commercial-off-the-shelf
(ISO/IEC/IEEE 90003:2018 Software engineering -- Guidelines for the application of ISO 9001:2015 to computer software, 3.4)
(2)
component off-the-shelf
(ISO/IEC 26560:2019 Software and systems engineering -- Tools and methods for product line product management, 4)
|
|
countable failure.
(1)
anomalous behavior that does not satisfy one or more of a systems explicit or revealed capability requirements; meets or exceeds the severity criteria of its reliability class; and the tick at which it occurred is imputed or recorded
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
counter.
(1)
variable used to record the number of occurrences of a given event during the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a variable that records the number of times a loop is executed
|
|
counting rule.
(1)
conditions and procedures under which the measurement value is obtained
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
counting scope.
(1)
set of Functional User Requirements to be included in the function point count
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.14)
|
|
coupling.
(1)
manner and degree of interdependence between software modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
strength of the relationships between modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
measure of how closely connected two routines or modules are
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
in software design, a measure of the interdependence among modules in a computer program
(ISO/IEC TR 19759:2016 Software Engineering -- Guide to the Software Engineering Body of Knowledge (SWEBOK), 2.1.4)
Note: Types include common-environment coupling, content coupling, control coupling, data coupling, hybrid coupling, and pathological coupling.
See Also: cohesion
|
|
courtesy.
(1)
degree to which the IT service is provided in a polite, respectful and friendly way
(ISO/IEC TR 33014:2013 Information technology--Process assessment--Guide for process improvement, 3.2.2.6)
|
|
CPAF.
(1)
cost plus award fee
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
CPC.
(1)
computer program component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: computer software component
|
|
CPCI.
(1)
computer program configuration item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: computer software configuration
|
|
CPD.
(1)
continuing professional development
(ISO/IEC/IEEE 24765j:2021)
(2)
capability production document
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
CPF.
(1)
cost-plus-fee
(ISO/IEC/IEEE 24765c:2014)
|
|
CPFF.
(1)
cost plus fixed fee
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
CPG.
(1)
clock pulse generator
(ISO/IEC/IEEE 24765d:2015)
|
|
CPI.
(1)
cost performance index
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
critical program information
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
CPIF.
(1)
cost plus incentive fee
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
CPLD.
(1)
complex programmable logic device
(ISO/IEC/IEEE 24765d:2015)
|
|
CPM.
(1)
critical path method
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
critical path method
|
|
CPPC.
(1)
cost plus percentage of cost
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
CPU.
(1)
central processing unit
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
|
|
crash.
(1)
sudden and complete failure of a computer system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: hard failure
|
|
crashing.
(1)
method used to shorten the schedule duration for the least incremental cost by adding resources
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: fast tracking, schedule compression
|
|
CRC.
(1)
cyclic redundancy check
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
create WBS (work breakdown structure).
(1)
the process of subdividing project deliverables and project work into smaller, more manageable components
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
creation.
(1)
of an <X>, instantiating by an action of objects in the model
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.18)
See Also: introduction
|
|
crisis.
(1)
critical state of affairs in which a decisive, probably undesirable outcome is impending
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
crisis management.
(1)
steps to take when a contingency plan does not solve the associated problem
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
criteria.
(1)
standards, rules, or tests on which a judgment or decision can be based, or by which a product, service, result, or process can be evaluated
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
rules on which a judgment or decision can be based, or by which a product, service, result, or process can be evaluated
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 3.1.6)
|
|
critical asset.
(1)
asset having potential to significantly impact on the achievement of the organization's objectives
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.15)
Note: Assets can be safety-critical, environment-critical or performance-critical, and can relate to legal, regulatory or statutory requirements. Critical assets can refer to those assets necessary to provide services to critical customers. Asset systems can be distinguished as being critical in a similar manner to individual assets.
|
|
critical chain method.
(1)
schedule method that allows the project team to place buffers on any project schedule path to account for limited resources and project uncertainties
(ISO/IEC/IEEE 24765h:2019)
|
|
critical design review (CDR).
(1)
review conducted to verify that the detailed design of one or more configuration items satisfy specified requirements; to establish the compatibility among the configuration items and other items of equipment, facilities, software, and personnel; to assess risk areas for each configuration item; and, as applicable, to assess the results of producibility analyses, review preliminary hardware product specifications, evaluate preliminary test planning, and evaluate the adequacy of preliminary operation and support documents
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
critical information.
(1)
information describing the safe use of the software, the security of the information created with the software, or the protection of the sensitive personal information created by or stored with the software
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.6)
|
|
critical item.
(1)
in configuration management, an item within a configuration item that, because of special engineering or logistic considerations, requires an approved specification to establish technical or inventory control at the component level
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
critical path.
(1)
sequence of activities that represents the longest path through a project, which determines the shortest possible duration
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: critical path methodology
|
|
critical path method (CPM).
(1)
method used to estimate the minimum project duration and determine the amount of scheduling flexibility on the logical network paths within the schedule model
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
critical piece first.
(1)
system development approach in which the most critical aspects of a system are implemented first
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: The critical piece can be defined in terms of services provided, degree of risk, difficulty, or other criteria.
See Also: bottom-up, top-down
|
|
critical property.
(1)
property that is agreed by primary stakeholders as having serious consequence
(ISO/IEC/IEEE 15026-4:2021, Systems and software engineering Systems and software assurance Part 4: Assurance in the life cycle, 3.6)
|
|
critical range.
(1)
values used to classify software into the categories of acceptable, marginal, or unacceptable
(ISO/IEC/IEEE 24765j:2021)
|
|
critical section.
(1)
section of a task's internal logic that is executed mutually exclusively with other tasks
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
critical system.
(1)
system having the potential for serious impact on the users or environment, due to factors including safety, performance, and security
(ISO/IEC/IEEE 24765n:2025)
Example: safety critical items, fracture critical items, mission critical items, key characteristics
|
|
critical value.
(1)
value of a validated metric that is used to identify software that has unacceptable quality
(ISO/IEC/IEEE 24765j:2021)
|
|
criticality.
(1)
degree of impact that a requirement, module, error, fault, failure, or other item has on the development or operation of a system
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
|
|
cross-assembler.
(1)
assembler that executes on one computer but generates machine code for a different computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
cross-compiler.
(1)
compiler that executes on one computer but generates machine code for a different computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
cross-reference generator.
(1)
software tool that accepts as input the source code of a computer program and produces as output a listing that identifies each of the program's variables, labels, and other identifiers and indicates which statements in the program define, set, or use each one
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: cross-referencer
|
|
cross-reference list.
(1)
list that identifies each of the variables, labels, and other identifiers in a computer program and indicates which statements in the program define, set, or use each one
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
cross-reference tool.
(1)
software maintenance tool that lets the user determine where a variable is used or where a particular procedure is called on
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
CRS.
(1)
commonality and reuse strategy
(ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 4)
|
|
CRUD.
(1)
create, read, update, delete
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
cryptographic hash.
(1)
Method to verify the authenticity of a system element or software via the production of a checksum
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
|
|
CS.
(1)
constituent system
(ISO/IEC/IEEE 21840:2019 Systems and software engineering--Guidelines for the utilization of ISO/IEC/IEEE 15288 in the context of system of systems (SoS), 3.2)
|
|
CSA.
(1)
configuration status accounting
(ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.10)
|
|
CSAS.
(1)
containment spray actuation signal
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
CSC.
(1)
computer software component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
cloud service customer
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.3.3)
|
|
CSCI.
(1)
computer software configuration item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: SWCI
|
|
CSF.
(1)
critical success factor
(ISO/IEC TR 14471:2007 Information technology--Software engineering--Guidelines for the adoption of CASE tools, 2.2)
|
|
CSN.
(1)
cloud service partner
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 4)
See Also: CSP
|
|
CT.
(1)
communication technology
(ISO/IEC/IEEE 24765c:2014)
|
|
cumulative flow diagram (CFD).
(1)
chart indicating features completed over time, features in other states of development, and those features in the backlog
(Software Extension to the PMBOK(R) Guide Fifth Edition)
Note: may indicate features at some intermediate milestones, such as features designed but not yet constructed
|
|
curriculum standard.
(1)
standard that describes the characteristics of a course of study on a body of knowledge that is offered by an educational institution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
custom software.
(1)
software product developed for a specific application from a user requirements specification
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.3)
|
|
customer.
(1)
organization or person that receives a product or service
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.16)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.12)
(2)
an individual or organization who specifies the requirements for and formally accepts delivery of a new or modified hardware or software product and its documentation
(3)
organization or part of an organization that receives a service or services
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.3.3)
(4)
organization or part of an organization that receives a service or services or products of the application management organization
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.14)
(5)
the entity or entities for whom the requirements are to be satisfied in the system being defined and developed
(6)
person or organization that can or does receive a product or a service that is intended for or required by this person or organization
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.33)
(7)
relationship with the supplier of an organization or person that receives or uses a product or service
(ISO/IEC 25022:2016, Systems and software engineering -- Systems and software quality requirements and evaluation (SQuaRE) -- Measurement of quality in use, 4.3)
(8)
individual or organization that purchases or receives a product
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.9)
Example: consumer, client, end-user, retailer, receiver or product or service from an internal process, an organization within the same company as the developing organization (e.g., System Management), a company or entity external to the developing company, a higher-level project, or some combination of these
Note: The term "customer" includes but has a broader meaning than "consumer". A customer can be internal or external to the organization. Customers are a subset of stakeholders. An application management organization can have customers that are internal or external business information management organizations and other application management organizations.
A user or end user is a person that actually uses the application software, while a customer is a person or organization that decides about and acquires the products or services.
The customer or user organization, in its relationships with application management, can be represented by business information management.
See Also: acquirer, buyer, stakeholder, user
|
|
customer requirement.
(1)
result of eliciting, consolidating, and resolving conflicts among the needs, expectations, constraints, and interfaces of the product's relevant stakeholders in a way that is acceptable to the customer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
customer satisfaction.
(1)
state of fulfillment in which the needs of a customer are met or exceeded for the customer's expected experiences as assessed by the customer at the moment of evaluation
(ISO/IEC/IEEE 24765h:2019)
|
|
customizability.
(1)
degree to which the IT service can be customized at the request of users
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.7.1)
|
|
customization.
(1)
adaptation of a software or information product to the needs of a particular audience
(ISO/IEC/IEEE 26512:2018 Systems and software engineering--Requirements for acquirers and suppliers of information for users, 3.7)
(2)
modification of a document type definition to add new structures or change the document type definition in a way that is not compatible with a previous structure
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.9)
|
|
customize.
(1)
adapt a software or information product to the needs of a particular audience
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.15)
|
|
cut-off date.
(1)
date after which changes to the software are reflected in the next, rather than the current, software release or issue of the documentation
(ISO/IEC/IEEE 24765a:2011)
|
|
cutover.
(1)
transfer of functions of a system to its successor at a given moment
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
CV.
(1)
cost variance
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
coefficient of variation
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
CVE.
(1)
common vulnerabilities and exposures
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
CVSS.
(1)
Common Vulnerability Scoring System
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
CWBS.
(1)
contract work breakdown structure
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
cycle.
(1)
period of time during which a set of events is completed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
set of operations that is repeated regularly in the same sequence, possibly with variations in each repetition
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: software development cycle, software life cycle
|
|
cycle stealing.
(1)
suspending the operation of a central processing unit for one or more cycles to permit the occurrence of other operations, such as transferring data from main memory in response to an output request from an input/output controller
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
cycle time.
(1)
time associated with one complete operation of a repetitive process
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.10)
(2)
total elapsed time from the start of a particular activity or work item to its completion
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
cycle time chart.
(1)
diagram that shows the average cycle time of the work items completed over time
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
cyclic search.
(1)
storage allocation technique in which each search for a suitable block of storage begins with the block following the one last allocated
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
DAC.
(1)
digital-to-analogue converter
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
daily standup.
(1)
short, daily, time-boxed meeting used to discuss progress, plans, and any blocking issues with each member of an agile team
(ISO/IEC TR 24587:2021, Software and systems engineering--Agile development--Agile adoption considerations, 3.7)
(2)
brief daily collaboration meeting in which the team reviews progress from the previous day, declares intentions for the current day, and highlights any obstacles encountered or anticipated.
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: Duration typically does not exceed 15 minutes.
Syn: daily stand-up
|
|
danger.
(1)
hazardous situation, which if not avoided, can result in death or serious injury
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.8)
|
|
dangerous condition.
(1)
state of a system which, in combination with some states of the environment, will result in adverse consequence
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.4.11)
Note: A hazardous situation in ISO/IEC Guide 51 and IEC 61508-4 is an instance of a dangerous condition. A concept of dangerous conditions is introduced in order to cover not only hazardous situations in the safety context but also errors in the reliability, integrity, confidentiality, or dependability contexts and other states of a system which can lead to adverse consequences.
Occurrences of failures in the context of reliability often, but not always, lead to dangerous conditions. A dangerous condition therefore has attributes, at least, a) the associated adverse consequences, b) the trigger events that lead to the dangerous condition, and c) the trigger events that lead to the adverse consequences from the dangerous condition.
|
|
dark matter.
(1)
work missed in the original project plan that is required to complete the deliverable product
(Software Extension to the PMBOK(R) Guide Fifth Edition)
|
|
Darwin Information Typing Architecture (DITA).
(1)
XML-based architecture for authoring, producing, and delivering topic-oriented, information-typed content that can be reused and single-sourced in a variety of ways
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.13)
|
|
dashboard.
(1)
set of charts and graphs showing progress or performance against important measures of the project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
data.
(1)
representation of facts, concepts, or instructions in a manner suitable for communication, interpretation, or processing by humans or by automatic means
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
collection of values assigned to base measures, derived measures or indicators
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.4)
(3)
representations of information dealt with by information systems and users thereof
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 3.2.1)
(4)
reinterpretable representation of information in a formalized manner suitable for communication, interpretation, or processing
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.4)
(5)
facts about an object
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.16)
Note: Data can be a captured, measured, or recorded representation of information, before it is analyzed, interpreted, or processed. Data can relate to objects such as facts, events, things, processes, or ideas, including concepts that within a certain context have a particular meaning.
See Also: data type, information
|
|
data abstraction.
(1)
extracting the essential characteristics of data by defining data types and their associated functional characteristics and disregarding representation details
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
the result of the process in (1)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: encapsulation, information hiding
|
|
data action.
(1)
system operation on data elements
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
data analysis.
(1)
systematic investigation of the data and their flow in a real or planned system
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
data attribute.
(1)
smallest parcel of information, within an identified data group, carrying a meaning from the perspective of the software's functional user requirements
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 3.4)
|
|
data bank.
(1)
set of data related to a given subject and organized in such a way that it can be consulted by subscribers
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
data breakpoint.
(1)
breakpoint that is initiated when a specified data item is accessed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: storage breakpoint
See Also: code breakpoint, dynamic breakpoint, epilog breakpoint, programmable breakpoint, prolog breakpoint, static breakpoint
|
|
data buffer register (DBR).
(1)
region of a physical memory storage used to temporarily store data while it is being moved, e.g., from input to processing
(ISO/IEC/IEEE 24765d:2015)
|
|
data characteristic.
(1)
inherent, possibly accidental, trait, quality, or property of data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
Example: arrival rates, formats, value ranges, or relationships between field values
|
|
data communication.
(1)
transfer of data among functional units according to sets of rules governing data transmission and the coordination of the exchange
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
data configuration.
(1)
process of adding, changing or deleting reference data or code data information from the database or data storage with no change in software code or the database structure
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.5)
|
|
data corruption.
(1)
Incorrect and un-recovered alteration to a data item, including malicious encryption
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
data coupling.
(1)
type of coupling in which output from one software module serves as input to another module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: input-output coupling
See Also: common-environment coupling, content coupling, control coupling, hybrid coupling, pathological coupling
|
|
data declaration source statement.
(1)
source statement that reserves or initializes memory at compilation time
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
data definition.
(1)
statement where a variable is assigned a value
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.16)
Syn: variable definition
|
|
data definition c-use pair.
(1)
data definition and subsequent computation data use, where the data use uses the value defined in the data definition
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.17)
|
|
data definition p-use pair.
(1)
data definition and subsequent predicate data use, where the data use uses the value defined in the data definition
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.18)
|
|
data definition-use pair.
(1)
data definition and subsequent data use, where the data use uses the value defined in the data definition
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 4.12)
|
|
data dictionary.
(1)
collection of information about data such as name, description, creator, owner, provenance, translation in different languages, and usage
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.7)
|
|
data drift.
(1)
drift that occurs when data changes after the model is deployed
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: Data drift occurs when new data points arise from a region of the input space that was less populated by training data.
|
|
data element.
(1)
unique, user-recognizable, non-repeated field in a BFC
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, 3.3)
(2)
smallest unit of data of an IT project
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 3.11)
(3)
item of data that conveys or contains meaningful information
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
Note: A data element can be a character string, or a digital or graphical element in a BFC. When 'data elements' are indicated for a BFC, the number of data elements is always greater than 0.
See Also: data item
|
|
data element type (DET).
(1)
unique, user-recognizable, non-repeated attribute
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.15)
(2)
unique, user-recognizable, non-recursive item of information
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
Note: A data element type (DET) can be in business data, reference data, or code data. The number of different types of data elements of all tables is the number of DETs. Instances of control information are also counted as a DET,
such as the Enter key to facilitate an external input.
|
|
data erasure.
(1)
irrevocable loss of a data item
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
data exception.
(1)
exception that occurs when a program attempts to use or access data incorrectly
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: addressing exception, operation exception, overflow exception, protection exception, underflow exception
|
|
data exposure.
(1)
unpermitted access to a data item, without actual unpermitted usage or transfer
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
data failure (DF).
(1)
occurrence of data corruption, erasure, exposure, or leakage occurring during any IN-SERVICE or REMOVED mode of a system of interest instance
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
data file.
(1)
set of related data records treated as a unit
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.7)
|
|
data flow.
(1)
sequence in which data transfer, use, and transformation are performed during the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
movement of data through a system from one component to the next
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
See Also: control flow
|
data flow diagram (DFD).
(1)
diagram that depicts data sources, data sinks, data storage, and processes performed on data as nodes, and logical flow of data as links between the nodes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: data flowchart, data flow graph
See Also: control flow diagram, data structure diagram
 |
|
data flow testing.
(1)
class of structure-based test case design techniques based on exercising definition-use pairs
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.19)
|
|
data format.
(1)
specified arrangement and encoding for data to be communicated or stored and retrieved
(ISO/IEC/IEEE 24765d:2015)
(2)
arrangement of data for storage or display
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.8)
Note: Format can refer to data type and length of data item.
|
|
data function.
(1)
functionality provided to the user to meet internal or external data storage requirements
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.16)
Note: FPA assigns each data function a type and distinguishes between the following types: the internal logical file and the external interface file.
|
|
data gathering and analysis methods.
(1)
methods used to collect, assess, and evaluate data and information to gain a deeper understanding of a situation
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
data governance.
(1)
execution and enforcement of authority over the definition, production, and usage of data and data related assets
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
|
|
data group.
(1)
a distinct, non-empty, non-ordered and non-redundant set of data elements
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, A.5)
(2)
a distinct, non-empty, non-ordered and non-redundant set of data attributes where each included data attribute describes a complementary aspect of the same object of interest
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.5)
(ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts)
Note: Each included data element describes a complementary aspect of the same object of interest. A data group is characterized by its persistence.
Syn: data group type
See Also: object of interest
|
|
data input sheet.
(1)
user documentation that describes, in a worksheet format, the required and optional input data for a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: user manual
|
|
data inventory.
(1)
in an information processing system, all the data and their characteristics, including interdependencies
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
data item.
(1)
smallest identifiable unit of data within a certain context for which the definition, identification, permissible values, and other information is specified by means of a set of properties
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.9)
(2)
well-defined set of data elements that is associated with a single tag, which defines its meaning and layout
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.2.6)
Note: Data item is a physical object 'container' of data values.
Syn: field
See Also: data element
|
|
data leakage.
(1)
unpermitted usage or transfer of a data item
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
data management.
(1)
in a data processing system, the functions that provide access to data, perform or monitor the storage of data, and control input-output operations
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
disciplined process that plans for, acquires, and provides stewardship for business and technical data, consistent with data requirements, throughout the data lifecycle
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
|
|
data manipulation.
(1)
any processing of the data other than a movement of the data into or out of a functional process, or between a functional process and persistent storage
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.6)
|
|
data map.
(1)
visual representation of data processing within the system
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
data medium.
(1)
material in or on which data can be recorded and from which data can be retrieved. Plural: data media
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
data model.
(1)
graphical and textual representation of analysis that identifies the data needed by an organization to achieve its mission, functions, goals, objectives, and strategies and to manage and rate the organization
(ISO/IEC/IEEE 24765n:2025, 3.1.44)
(2)
model about data by which an interpretation of the data can be obtained in the modeling tool industry
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
(3)
graphical or lexical representation of data, specifying their properties, structures, and interrelationships
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.15)
Note: A data model can be encoded and manipulated by a computer. A data model identifies the entities, domains, attributes, and relationships (associations) with other data and provides the conceptual view of the data and the relationships among data [key style]. A distinction is made between a logical (or functional) and a technical data model. A logical data model is a representation of an organization's data, organized in terms of entities and relationships and is independent of any particular data management technology. In a technical data model, it is determined in what form data are recorded in the database and in which way the data are approached.
|
|
data movement (-type).
(1)
base functional component which moves a single data group
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 3.6)
Note: The COSMIC Functional Size Measurement Method has four types of data movements: Entry, Exit, Read and Write.
For measurement purposes, each data movement is considered to account for certain associated data manipulation
|
|
data privacy.
(1)
fair and legitimate processing of personal data
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
data processing (DP).
(1)
systematic performance of operations upon data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Example: arithmetic or logic operations upon data, merging or sorting of data, assembling or compiling of programs, or operations on text, such as editing, sorting, merging, storing, retrieving, displaying, or printing
Note: The term data processing is not a synonym for information processing.
Syn: automatic data processing (ADP)
|
|
data processing system.
(1)
one or more computers, peripheral equipment, and software that perform data processing
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Syn: computer system, computing system
|
|
data protection.
(1)
implementation of appropriate administrative, technical, or physical means to guard against unauthorized intentional or accidental disclosure, modification, or destruction of data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: includes static and dynamic data.
|
|
data protection impact assessment.
(1)
tool described in the General Data Protection Regulation (GDPR) to assess in advance the privacy risks of data processing and then to be able to implement controls to reduce the risks
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.14)
Syn: DPIA
|
|
data provider.
(1)
individual or organization that is a source of data
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.5)
|
|
data quality.
(1)
capability of the characteristics of data to satisfy stated and implied needs when used under specified conditions
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.1.6)
(2)
degree to which the characteristics of data satisfy stated and implied needs when used under specified conditions
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.5)
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 4.1)
|
|
data quality characteristic.
(1)
category of data quality attributes that bears on data quality
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.12)
|
|
data quality measure.
(1)
variable to which a value is assigned as the result of measurement of a data quality characteristic
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.13)
|
|
data quality model.
(1)
defined set of characteristics which provides a framework for specifying data quality requirements and evaluating data quality
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.14)
|
|
data record.
(1)
defined group of related data elements, in which all the necessary data elements are included to represent attributes of interest
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 3.12)
|
|
data repository.
(1)
object providing the storage function
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 14.1.1.1)
|
|
data sequencer.
(1)
component that replaces keyword parameters with data, if necessary, across several hierarchy levels
(ISO/IEC/IEEE 29119-5:2024 Software and systems engineering--Software testing--Part 5: Keyword-driven testing, 3.3)
|
|
data store.
(1)
organized and persistent collection of data and information that allows for its retrieval
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.6)
|
|
data structure.
(1)
physical or logical relationship among data elements, designed to support specific data manipulation functions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: The data structures are usually documented in technical and logical data models.
|
data structure diagram.
(1)
diagram that depicts a set of data elements, their attributes, and the logical relationships among them
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: data flow diagram, entity-relationship diagram
 |
|
data structure-centered design.
(1)
software design technique in which the architecture of a system is derived from analysis of the structure of the data sets with which the system deals
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: input-process-output, modular decomposition, object-oriented design, rapid prototyping, stepwise refinement, structure clash, structured design, transaction analysis, transform analysis
|
|
data subject.
(1)
natural person to whom personal data relates
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
(2)
identifiable natural person
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
(3)
person who provides personal data that is used by the system
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: To determine whether a data subject is identifiable involves identifying the means which can reasonably be used by the privacy stakeholder holding the data, or by any other party, to identify that natural person.
Syn: PII principal, personally identifiable information principal
|
|
data submitter.
(1)
person or organization that provides IT project data to be included into a benchmarking repository
(ISO/IEC 29155-2:2013 Systems and software engineering--Information technology project performance benchmarking framework--Part 2: Requirements for benchmarking, 3.1)
|
|
data system.
(1)
discrete set of resources organized for the collection, processing, maintenance, use, sharing, dissemination, or disposition of data
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
data transfer controller (DTC).
(1)
functional unit to control data communication without going through the central processing unit (CPU)
(ISO/IEC/IEEE 24765e:2015)
|
|
data type.
(1)
class of data, characterized by the members of the class and the operations that can be applied to them
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: integers, characters, alphanumeric, floating point, and Boolean (true-false)
|
|
data use.
(1)
executable statement where the value of a variable is accessed
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.20)
|
|
data value.
(1)
content of data item
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.17)
Note: Data quality refers to data itself, such as data domain values and possible restrictions.
|
|
data-driven.
(1)
informing an activity by evidence
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
|
|
data-sensitive fault.
(1)
fault that causes a failure in response to some particular pattern of data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: pattern-sensitive fault
See Also: program-sensitive fault
|
|
data-structure-oriented design.
(1)
design methodology used for business applications by basing the design on the logical data structures of the program specification
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: Jackson System Design and Warnier-Orr methods
|
|
database.
(1)
collection of interrelated data stored together in one or more computerized files
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
collection of data organized according to a conceptual structure describing the characteristics of the data and the relationships among their corresponding entities, supporting one or more application areas
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 3.1.8)
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(3)
collection of data describing a specific target area that is used and updated by one or more applications
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, A.4)
Syn: data base
|
|
database design specification.
(1)
document that describes the content and format of the permanent or semi-permanent data necessary for the software to carry out its functions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
database management system.
(1)
organized collection of structured data
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.18)
Note: In order to use database management systems (DBMS), it is necessary to represent data and the relative operations on it in terms of a data model, a data definition and manipulation language
|
|
database view.
(1)
result set of a stored query on the data, which the database users can query just as they would in a persistent database collection object
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.8)
Note: This stored command (pre-established query) is kept in the database dictionary. Unlike ordinary base tables in a relational database, it is a virtual table computed or collated dynamically from data in the database, when access to that view is requested. Changes applied to the data in a relevant underlying table are reflected in the data shown in subsequent invocations of the view.
|
|
datum.
(1)
singular of "data"
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: "Data" is commonly used for both singular and plural.
|
|
DBMS.
(1)
database management system
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 5)
|
|
DBR.
(1)
data buffer register
(ISO/IEC/IEEE 24765d:2015)
|
|
DCS.
(1)
digital computer system
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
DDOS.
(1)
distributed denial of service
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.22)
|
|
DDR.
(1)
detailed design review
(ISO/IEC/IEEE 24765d:2015)
(2)
double data rate
(ISO/IEC/IEEE 24765c:2014)
|
|
DDR2.
(1)
double data rate x 2 (twice as fast as DDR)
(ISO/IEC/IEEE 24765c:2014)
|
|
DDR2 SDRAM.
(1)
double data rate synchronous dynamic random access memory unit with higher performance than DDR SDRAM, because the device transfers data four times (four consecutive words) in one internal clock cycle.
(ISO/IEC/IEEE 24765c:2014)
|
|
DDR3.
(1)
double data rate 3, which transfers data 2 to the third power (8 times) faster than DDR
(ISO/IEC/IEEE 24765c:2014)
|
|
DDR3 SDRAM.
(1)
double data rate synchronous dynamic random access memory unit with higher performance because it transfers data 2 to the third power (8) times (8 consecutive words) in one internal clock cycle.
(ISO/IEC/IEEE 24765c:2014)
|
|
DDR4.
(1)
double data rate 4; data transfer is 2 to the 4th power = 16 times that of a SDRAM
(ISO/IEC/IEEE 24765c:2014)
|
|
DDR4 SDRAM.
(1)
double data rate synchronous dynamic random access memory unit with higher performance, because it transfers data at the rate of 2 to the 4th power (16) times (16 consecutive words) in one internal clock cycle
(ISO/IEC/IEEE 24765c:2014)
|
|
de-identification.
(1)
removal of personally identifiable data from a data set
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
deactivation.
(1)
checkpointing a cluster, followed by deletion of the cluster
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.23)
|
|
deadlock.
(1)
situation in which computer processing is suspended because two or more devices or processes are each awaiting resources assigned to the others
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
situation in which two or more tasks are suspended indefinitely because each task is waiting for a resource acquired by another task
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: lockout
|
|
deblock.
(1)
to separate the parts of a block
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: block (2)
|
|
debug.
(1)
to detect, locate, and correct faults in a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to detect, locate, and eliminate errors in programs
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: Techniques include use of breakpoints, desk checking, dumps, inspection, reversible execution, single-step operation, and traces.
|
|
decision.
(1)
types of statements in which a choice between two or more possible outcomes controls which set of actions will result
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.23)
Note: Typical decisions are simple selections (e.g. if-then-else), to decide when to exit loops (e.g. while-loop), and in case (switch) statements (e.g. case-1-2-3-..-N).
|
|
decision criteria.
(1)
thresholds, targets, or patterns used to determine the need for action or further investigation, or to describe the level of confidence in a given result
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.7)
|
|
decision gate.
(1)
approval event
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: often associated with a review meeting. Entry and exit criteria are established for each decision gate; continuation beyond the decision gate is contingent on the agreement of decision-makers
|
|
decision outcome.
(1)
result of a decision that determines the branch to be executed
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.21)
|
|
decision policy.
(1)
one or more rules used to determine whether a biometric comparison results in a positive or negative match
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.15)
Note: The decision policy often includes a threshold above which a comparison score is considered a match.
|
|
decision rule.
(1)
combination of conditions (also known as causes) and actions (also known as effects) that produce a specific outcome in decision table testing and cause-effect graphing
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.22)
|
|
decision table.
(1)
table of all contingencies that are to be considered in the description of a problem together with the action to be taken
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.1)
(2)
tabular representation of decision rules between causes (inputs described as Boolean conditions) and effects (outputs described as Boolean expressions)
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.23)
(3)
table of conditions that are to be considered in the analysis of a problem, together with the action to be taken for each condition
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(4)
table that specifies decision variables
(ISO/IEC 26557:2016 Software and systems engineering -- Methods and tools for variability mechanisms in software and systems product line, 3.8)
|
|
decision table testing.
(1)
specification-based test case design technique based on exercising decision rules in a decision table
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.24)
|
|
decision testing.
(1)
structure-based test case design technique based on exercising decision outcomes in the control flow of the test item
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.28)
|
|
decision tree.
(1)
supervised-learning model for which inference can be represented by traversing one or more tree-like structures
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.25)
|
|
decision tree analysis.
(1)
diagramming and calculation method for evaluating the implications of a chain of multiple options in the presence of uncertainty
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
decision variable.
(1)
representation of different values for a decision which the decision-maker can choose
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: for example, in an economic life calculation, the decision variable is how long to keep the asset
|
|
declaration.
(1)
action that establishes a state of affairs in the environment of the object making the declaration
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.5)
(2)
non-executable program statement that affects the assembler or compiler's interpretation of other statements in the program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
set of statements which define the sets, constants, parameter values, typed variables, and functions required for defining the annotations on a high-level Petri net
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.7)
Note: The essence of a declaration is that, by virtue of the act of declaration itself and the authority of the object or its principal, it causes a state of affairs to come into existence outside the object making the declaration.
|
|
declarative language.
(1)
nonprocedural language that permits the user to declare a set of facts and to express queries or problems that use these facts
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: interactive language, rule-based language
|
|
decompile.
(1)
to translate a compiled computer program from its machine language version into a form that resembles, but is not necessarily identical to, the original high-order language program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: compile
|
|
decompiler.
(1)
software tool that decompiles computer programs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
decomposer.
(1)
component that deconstructs the high-level keywords across all levels into a sequence of low-level keywords that eventually comprise it
(ISO/IEC/IEEE 29119-5:2024 Software and systems engineering--Software testing--Part 5: Keyword-driven testing, 3.4)
|
|
decomposition.
(1)
method used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
the partitioning of a modeled function into its component functions
(ISO/IEC/IEEE 24765m:2024, 2.1.35)
(3)
specification of a given object as a composition
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.3.a)
(4)
specification of a given behavior as a composition
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.3.b)
See Also: composition
|
|
decomposition diagram.
(1)
diagram that details its parent box
(ISO/IEC/IEEE 24765m:2024, 2.1.36)
|
|
decoupling.
(1)
making software modules more independent of one another to decrease the impact of changes to, and errors in, the individual modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: coupling
|
|
deep learning.
(1)
approach to creating rich hierarchical representations through the training of neural networks with one or more hidden layers
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.26)
Note: Deep learning uses multi-layered networks of simple computing units (or neurons). In these neural networks each unit combines a set of input values to produce an output value, which in turn is passed on to other neurons downstream.
|
|
deep neural net.
(1)
neural network with more than two layers
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.27)
Syn: deep neural network, DNN
|
|
defect.
(1)
imperfection or deficiency in a work product or characteristic that does not meet its requirements or specifications
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
(2)
fault or deviation from the intended level of performance of a system or software
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.4)
(3)
imperfection or deficiency in a work product where that work product does not meet its requirements or specifications and needs to be either repaired or replaced
(ISO/IEC 23531:2020, Systems and software engineering--Capabilities of issue management tools, 3.1)
Example: (1) omissions and imperfections found during early life cycle phases and (2) faults contained in software sufficiently mature for test or operation
See Also: fault
|
|
defect density.
(1)
number of defects per unit of product size
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: problem reports per thousand lines of code
|
|
defensive programming.
(1)
a general approach to programming that assumes that errors will occur during both initial development and maintenance and, as a result, creates code in such a way that the program still operates properly when errors occur
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
defined process.
(1)
implemented process that is managed and tailored from the organization's set of standard processes according to the organization's tailoring guidelines
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.2)
Example: null
Note: A defined process has a process description that is documented and maintained and contributes work products, measures, and other process improvement information to the organization's process assets. A project's defined process provides a basis for planning, performing, and improving the tasks and activities of the project.
|
|
definition-use pair.
(1)
data definition and subsequent predicate or computational data use, where the data use uses the value defined in the data definition
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.26)
Syn: data definition-use pair
|
|
definitive software library (DSL).
(1)
secure storage environment, formed of physical media or of one or more electronic software repositories, capable of control and protection of definitive authorized versions of all software configuration items and masters of all software controlled by SAM
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.11)
|
|
degree of influence (DI).
(1)
a numerical indicator of the impact of each of the 19 (or more) technical complexity adjustment factors, ranging from 0 (no influence) to 5 (strong influence, throughout)
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
Note: These indicators are used to compute the value adjustment factor.
|
|
delegation.
(1)
action that assigns something, such as authorization, responsibility or provision of a service, to another object
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.6)
Note: A delegation, once made, can later be withdrawn.
|
|
deleted source statement.
(1)
source statement that is removed or modified from an existing software product as a new product is constructed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
deletion.
(1)
of an <X>, the action of destroying an instantiated <X>
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.20)
|
|
delimiter.
(1)
character or set of characters used to denote the beginning or end of a group of related bits, characters, words, or statements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
deliver primitive.
(1)
service primitive for which the protocol object is the responding object of the corresponding communication
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.6)
|
|
deliverable.
(1)
any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
item to be provided to an acquirer or other designated recipient as specified in an agreement
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
Note: This item can be a document, hardware item, software item, service, or any type of work product.
See Also: acquirer, product, result
|
|
deliverable product.
(1)
unique and verifiable system or software product to perform a service, that is subject to approval by the project sponsor or customer
(ISO/IEC 25041: 2012 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Evaluation guide for developers, acquirers and independent evaluators, 4.1)
|
|
delivered source statement.
(1)
source statement that is incorporated into the product delivered to the customer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
delivery.
(1)
release of a system or component to its customer or intended user
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: software life cycle, system life cycle
|
|
delivery performance domain.
(1)
performance domain that addresses activities and functions associated with delivering the scope and quality that the project was undertaken to achieve
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
Delphi method.
(1)
information-gathering technique used as a way to reach consensus of experts on a subject
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.16)
Note: A facilitator uses a questionnaire to solicit ideas about the important project points related to the subject. The responses are summarized and are then recirculated to the experts for further comment. Consensus can be reached in a few rounds of this process.
|
|
delta.
(1)
difference between two versions
(ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.11)
|
|
demand paging.
(1)
storage allocation technique in which pages are transferred from auxiliary storage to main storage only when those pages are needed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: anticipatory paging
|
|
DEMIL.
(1)
demilitarization
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
demodularization.
(1)
in software design, combining related software modules, usually to optimize system performance
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: downward compression, lateral compression, upward compression
|
|
demonstration.
(1)
dynamic analysis technique that relies on observation of system or component behavior during execution, without need for post-execution analysis, to detect errors, violations of development standards, and other problems
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: testing
|
|
dependability.
(1)
extent to which measured values of reliability, availability, recoverability, and supportability meet or exceed their required thresholds during an in-service interval
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
(2)
of an item, ability to perform as and when required
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.1.7)
(3)
ability of a system to perform as and when required
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
Note: Dependability includes availability, reliability, resilience, maintainability, and in some cases, other characteristics such as durability, safety and security. Dependability is used as a collective term for the time-related quality characteristics of an item.
|
|
dependability measurement.
(1)
data collection and processing to produce values for reliability, availability, supportability, or recoverability of a system
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
dependability requirement.
(1)
requirement statement that specifies a bounded threshold for one or more parameters of reliability, availability, supportability, or recoverability for a system
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
See Also: capability requirement
|
|
dependency export.
(1)
operation in which a component and all of its dependencies are exported from the CCMS as a single process
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.10)
|
|
dependent entity.
(1)
entity for which the unique identification of an instance depends upon its relationship to another entity
(ISO/IEC/IEEE 24765n:2025, 3.1.46)
Note: Expressed in terms of the foreign key, an entity is said to be dependent if any foreign key is wholly contained in its primary key.
Syn: identifier-dependent entity
See Also: independent entity [key style]
|
|
dependent state class.
(1)
class whose instances are, by their very nature, intrinsically related to certain other state class instances
(ISO/IEC/IEEE 24765n:2025, 3.1.47)
Note: It would not be appropriate to have a dependent state class instance by itself and unrelated to an instance of another class, and furthermore, it makes no sense to change the instances to which it relates.
See Also: independent state class
|
|
deployment.
(1)
stage of a project in which a system is put into operation and transition issues are resolved
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
(2)
[of requirements] assignment of requirements along with the system decomposition
(ISO/IEC 25030:2019 Systems and software engineering--Systems and software quality requirements and evaluation (SQuaRE)--Quality requirements framework, 3.3)
See Also: release
|
|
deployment package.
(1)
set of artifacts developed to facilitate the implementation of a set of practices of the selected framework in a very small entity
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.35)
Syn: DP
|
|
derivation of requirements.
(1)
translation and elaboration of requirements from one type of requirements to another in the same system level
(ISO/IEC 25030:2019 Systems and software engineering--Systems and software quality requirements and evaluation (SQuaRE)--Quality requirements framework, 3.4)
Note: Types of requirements include quality in use requirements, product quality requirements, and data requirements.
|
|
derived class.
(1)
relation between a template class CA of instances of A, and template class CB of instances of B, where template A is an incremental modification of template B
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.24)
See Also: base class
|
|
derived data.
(1)
data created as a result of processing that involves steps other than or in addition to direct retrieval and validation of information from data functions
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.17)
|
|
derived measure.
(1)
measure that is defined as a function of two or more values of base measures
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.8)
Note: A transformation of a base measure using a mathematical function can also be considered as a derived measure.
|
|
derived property.
(1)
designation given to a property whose value is determined by computation
(ISO/IEC/IEEE 24765n:2025, 3.1.50)
Note: The typical case of a derived property is as a derived attribute although there is nothing to prohibit other kinds of derived property.
Syn: derived attribute, derived participant party
|
|
derived requirement.
(1)
requirement deduced or inferred from the collection and organization of requirements into a particular system configuration and solution
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.1.8)
(2)
a requirement deduced or inferred from the collection and organization of requirements into a particular system configuration and solution
Note: Derived requirements can arise during analysis and design of components of the product or service.
See Also: product requirement
|
|
derived type.
(1)
data type whose members and operations are taken from those of another data type according to some specified rule
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: subtype
|
|
descendent box.
(1)
box in a descendent diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.37)
|
|
descendent diagram.
(1)
decomposition diagram related to a specific box by a hierarchically consecutive sequence of one or more child/parent relationships
(ISO/IEC/IEEE 24765m:2024, 2.1.38)
|
|
description.
(1)
information item that represents a planned or actual concept, function, design, or object
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.8)
|
|
description standard.
(1)
standard that describes the characteristics of product information or procedures provided to help understand, test, install, operate, or maintain the product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
descriptive model.
(1)
model that shows an interconnected set of model elements which represent key system aspects including its structure, behavior, parameters, and requirements
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.6)
|
|
design.
(1)
specification of system elements and their relationships, that is sufficiently complete to support a compliant implementation of the architecture
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.20)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.13)
(2)
stage of information development that is concerned with determining what information for users is to be provided in a product and what is the nature of that information
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.17)
(3)
stage of documentation development that is concerned with determining what documentation will be provided in a product and what the nature of the documentation will be
(ISO/IEC/IEEE 26512:2018 Systems and software engineering--Requirements for acquirers and suppliers of information for users, 3.8)
Note: Design provides the detailed implementation-level physical structure, behavior, temporal relationships, and other attributes of system elements. It is information, including specification of system elements and their relationships, that is sufficiently complete to support a compliant implementation of the architecture.
See Also: architectural design, preliminary design, detailed design
|
|
design analyzer.
(1)
automated design tool that accepts information about a program's design and produces such outputs as module hierarchy diagrams, graphical representations of control and data structure, and lists of accessed data blocks
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
design attribute.
(1)
element of a design view that names a characteristic or property of a design entity, design relationship, or design constraint
(ISO/IEC/IEEE 24765j:2021)
See Also: design constraint, design entity, design relationship
|
|
design authority.
(1)
person or organization that is responsible for the design of the product
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.5.3)
|
|
design characteristic.
(1)
design attribute or distinguishing feature that pertains to a measurable description of a product or service
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.21)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.17)
|
|
design concept.
(1)
fundamental idea that can be applied to designing a system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: information hiding
|
|
design constraint.
(1)
explicit and direct restriction regarding the choice of design ideas
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
(2)
boundary condition, externally or internally imposed, for the system of interest, within which the organization remains when executing the processes during the concept and development stages
(INCOSE Systems Engineering Handbook, 5th ed.)
Example: physical requirements, performance requirements, software development standards, and software quality assurance (SQA) standards
Note: It either declares a design idea to be compulsory or to be excluded.
See Also: design attribute, design entity, design relationship
|
|
design description.
(1)
model or information item that specifies the design of a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Typical contents include system or component architecture, control logic, data structures, input/output formats, interface descriptions, and algorithms.
Syn: design document, design specification
See Also: product specification, requirements specification, software design description
|
|
design fault.
(1)
design (specification, coding) fault that results from a human error during system design and that can result in a design failure
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
design language.
(1)
specification language with special constructs and, sometimes, verification protocols, used to develop, analyze, and document a hardware or software design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
standardized notation, modeling technique, or other representation scheme and its usage conventions, shown to be effective in representing and communicating design information
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Types include hardware design language, program design language.
See Also: requirements specification language
|
|
design level.
(1)
design decomposition of the configuration item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: system, subsystem, program, or module
See Also: high-level design, low-level design
|
|
design methodology.
(1)
systematic approach to creating a design consisting of the ordered application of a specific collection of tools, techniques, and guidelines
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
design pattern.
(1)
description of the problem and the essence of its solution to enable the solution to be reused in different settings
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: not a detailed specification, but a description of accumulated wisdom and experience.
|
|
design phase.
(1)
period in the software life cycle during which definitions for architecture, software components, interfaces, and data are created, documented, and verified to satisfy requirements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: detailed design, preliminary design
|
|
design rationale.
(1)
information capturing the reasoning of the designer that led to the system as designed, including design options, trade-offs considered, decisions made, and the justifications of those decisions
(ISO/IEC/IEEE 24765j:2021)
|
|
design requirement.
(1)
requirement that specifies or constrains the design of a system or system component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: functional requirement, implementation requirement, interface requirement, performance requirement, physical requirement
|
|
design review.
(1)
formal, documented, comprehensive, and systematic examination of a design to determine if the design meets the applicable requirements, to identify problems, and to propose solutions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
process or meeting during which a system, hardware, or software design is presented to project personnel, managers, users, customers, or other interested parties for comment or approval
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Types include critical design review, preliminary design review, system design review.
See Also: code review, formal qualification review, requirements review, test readiness review
|
|
design standard.
(1)
standard that describes the characteristics of a design or a design description of data or program components
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
design strategy.
(1)
overall plan and direction for performing design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: functional decomposition
|
|
design thinking.
(1)
methodology for solving complex problems where these are defined from the human needs
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.17)
Note: Solutions are determined with brainstorming sessions, where prototypes are produced to test the intended solution in practice.
|
|
design unit.
(1)
logically related collection of design elements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
design view.
(1)
representation comprised of one or more design elements to address a set of design concerns from a specified design viewpoint
(ISO/IEC/IEEE 24765j:2021)
See Also: design concern, design element, design viewpoint
|
|
design viewpoint.
(1)
specification of the elements and conventions available for constructing and using a design view
(ISO/IEC/IEEE 24765j:2021)
See Also: design view
|
|
design-to-cost.
(1)
approach to managing a system or software project so as to hold the project to a predetermined cost
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Actual and projected costs are closely tracked, and actions such as deleting or postponing lower-priority requirements are taken if costs threaten to exceed targets.
Syn: cost as an independent variable (CAIV), design to cost
|
|
desirable consequence.
(1)
consequence associated with a benefit or gain or avoiding an adverse consequence
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.4.4)
Syn: positive consequence
|
|
desk checking.
(1)
manual simulation of program execution to detect faults through step-by-step examination of the source program for errors in function or syntax
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
static analysis technique in which code listings, test results, or other documentation are visually examined, usually by the person who generated them, to identify errors, violations of development standards, or other problems
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: inspection, walk-through
|
|
desktop publishing.
(1)
electronic publishing using a microcomputer
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
destination address.
(1)
address of the device or storage location to which data is to be transferred
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: source address
|
|
destructive read.
(1)
read operation that alters the data in the accessed location
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: nondestructive read
|
|
DET.
(1)
data element type
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 4)
(2)
detection error trade-off
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.16)
|
|
detailed design.
(1)
refinement and expansion of the preliminary design of a system or component to the extent that the design is sufficiently complete to be implemented
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: low-level design, preliminary design, software development process
|
|
detailed design description.
(1)
document that describes the exact detailed configuration of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: It identifies the input, output, control logic, algorithms, and data structure of each individual low-level component of the software product and is the primary product of the detailed design phase.
Syn: detailed design specification
|
|
detailed design phase.
(1)
software development lifecycle phase during which the detailed design process takes place, using the software system design and software architecture from the previous phase (architectural design) to produce the detailed logic for each unit such that it is ready for coding
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
detailed design review.
(1)
milestone review to determine the acceptability of the detailed software design (as depicted in the detailed design description) to satisfy the requirements of the software requirements document
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
detection error trade-off.
(1)
relationship between false-negative and false-positive errors of a binary classification system as the discrimination threshold varies
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.16)
Note: The DET may be represented as a DET table or a DET plot.
Syn: DET
|
|
deterministic system.
(1)
system which, given a particular set of inputs and starting state, will always produce the same set of outputs and final state
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.28)
|
|
developed source statement.
(1)
source statement that is newly created for, added to, or modified for a software product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
developer.
(1)
individual or organization that performs development activities (including requirements analysis, design, testing through acceptance) during the system or software life-cycle process
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.6)
(2)
an organization that develops software products
(3)
person who applies a methodology for some specific job, usually an endeavor
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.11)
(4)
entity responsible for development, deployment, or decommission of a system
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Example: original equipment manufacturers; programmers; analysts; quality control personnel; external contractors; third-party actors who deploy, modify, or license the system for commercial gain or non-profit support; third-party providers (including open-source providers) of sub-components
Note: Activities of the developer of custom software include set-up and analysis of functional and non-functional system and software requirements, design, programming. and testing.
See Also: implementer
|
|
development.
(1)
specification, construction, testing and delivery of a new application or of a discrete addition to an existing application
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
(2)
activity of preparing information for users after it has been designed
(ISO/IEC/IEEE 26512:2018 Systems and software engineering--Requirements for acquirers and suppliers of information for users, 3.9)
|
|
development approach.
(1)
method used to create and evolve the product, service, or result during the project life cycle, such as predictive, adaptive, or a hybrid method
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: life cycle model
|
|
development approach and life cycle performance domain.
(1)
performance domain that addresses activities and functions associated with the development approach, cadence, and life cycle phases of the project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
development branch.
(1)
branch where active product development takes place
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: A product build from the development branch will have the latest features, but will also likely be immature and unstable.
|
|
development environment.
(1)
hardware, software, platform and tools for designers and developers of computer solutions
(ISO/IEC/IEEE 24765c:2014)
(2)
workplace facility in which a system is developed and maintained
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: It has staffing, resources, interfaces, capabilities, and tooling not found in that systems target environments.
|
|
development pipeline.
(1)
set of tools aimed at the managed and controlled build of a package with which an application can be taken into use
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.19)
Syn: build pipeline
|
|
development plan.
(1)
plan for guiding, implementing, and controlling the design and development of one or more products or services
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: project plan
|
|
development project.
(1)
project to develop and deliver the first release of a software application
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.18)
Note: It entails the specification, construction, testing, and delivery of a new application. During actualization, this project can be split up into a number of sub-projects. If these are carried out more or less in parallel, each being responsible for effectuating a certain sub-system of the total application, then each sub-project can be considered as an individual development project, if the sub-system itself is an application. Re-building an existing application, otherwise known as re-engineering, is considered as development.
|
|
development project function point count (DFP).
(1)
a count that measures the functionality provided to the end users with the first installation of the software, developed when the project is complete
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
(2)
activity of applying ISO/IEC 20926:2009 to measure the functional size of a development project
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.20)
|
|
development project functional size.
(1)
measure of the functionality provided to the users with the first release of the software, as measured by the development project function point count
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.19)
Note: The functional size of a development project can include the size of conversion functionality.
|
|
development team.
(1)
team that develops or maintains software
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.20)
Note: The acquirer, product owner, and future maintainer can form part of the development team. Development teams can be broken down by function (e.g. a team of designers, a team of programmers, a team of testers) or be multidisciplinary (each team has, e.g., design, programming and test expertise).
|
|
development testing.
(1)
formal or informal testing conducted during the development of a system or component, usually in the development environment by the developer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
testing conducted to establish whether a new software product or software-based system (or components of it) satisfies its criteria
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The criteria will vary based on the level of test being performed.
See Also: acceptance testing, operational testing, qualification testing
|
|
development tool.
(1)
hardware and software for developing or modifying applications
(ISO/IEC/IEEE 24765c:2014)
|
|
developmental baseline.
(1)
specifications that are in effect at a given time for a system under development
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
developmental configuration.
(1)
in configuration management, the software and associated technical documentation that define the evolving configuration of a computer software configuration item during development
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The developmental configuration is under the developer's control, and therefore is not called a baseline.
See Also: allocated baseline, functional baseline, product baseline
|
|
deviation.
(1)
departure from a specified requirement
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
written authorization, granted prior to the manufacture of an item, to depart from a particular performance or design requirement for a specific number of units or a specific period of time
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
device.
(1)
mechanism or piece of equipment designed to serve a purpose or perform a function
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: platform
|
|
device interface task.
(1)
concurrent task that hides the characteristics of and interfaces to an external I/O device
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
DevOps.
(1)
set of principles and practices which enable better communication and collaboration between relevant stakeholders for the purpose of specifying, developing, and operating software and systems products and services, and continuous improvements in all aspects of the life cycle
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
(2)
collection of practices for creating a smooth flow of deliveries by improving collaboration between development and operations staff
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
DF.
(1)
data failure
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
DFD.
(1)
data flow diagram
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
diagnostic.
(1)
pertaining to the detection and isolation of faults or failures
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a diagnostic message, a diagnostic manual
|
|
diagnostic manual.
(1)
document that presents the information necessary to execute diagnostic procedures for a system or component, identify malfunctions, and remedy those malfunctions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Typically described are the diagnostic features of the system or component and the diagnostic tools available for its support.
See Also: installation manual, operator manual, programmer manual, support manual, user manual
|
|
diagonal microinstruction.
(1)
microinstruction capable of specifying a limited number of simultaneous operations needed to carry out a machine language instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Diagonal microinstructions fall, in size and functionality, between horizontal microinstructions and vertical microinstructions. The designation 'diagonal' refers to this compromise rather than to any physical characteristic of the microinstruction.
See Also: horizontal microinstruction, vertical microinstruction
|
|
diagram boundary.
(1)
edge of a diagram in a diagram page
(ISO/IEC/IEEE 24765m:2024, 2.1.40)
|
|
diagram feature.
(1)
element of a diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.41)
Note: Diagram features include boxes, arrow segments, arrow labels, ICOM codes, ICOM labels, model notes, and reader notes.
|
|
diagram number.
(1)
that part of a diagram reference that corresponds to a diagram's parent function's node number
(ISO/IEC/IEEE 24765m:2024, 2.1.43)
Note: The diagram number refers to the diagram that details or decomposes the function designated by the same node number.
|
|
diagram page.
(1)
model page that contains a context diagram or a decomposition diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.44)
|
|
diagram reference.
(1)
expression that unambiguously identifies a diagram and specifies the diagram's position in a specific model hierarchy
(ISO/IEC/IEEE 24765m:2024, 2.1.45)
Note: A diagram reference is composed of a model name, abbreviation and a diagram number.
|
|
diagram title.
(1)
verb or verb phrase that describes the overall function presented by a diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.46)
Note: The diagram title of a child diagram is the box name of its parent box.
|
|
dialog.
(1)
interaction between a user and an interactive system as a sequence of user actions (inputs) and system responses (outputs) in order to achieve a goal
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 2.4)
Syn: dialogue
|
|
DIB.
(1)
directory information base
(ISO/IEC 13235-3:1998 Information technology -- Open Distributed Processing -- Trading Function -- Part 3: Provision of Trading Function using OSI Directory service, 4)
|
|
differential cash flow.
(1)
representation of the difference between cash flows of two alternatives or proposals
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: often performed using internal rate of return (IRR) as the basis of comparison
See Also: incremental analysis
|
|
digit numeric character.
(1)
character that represents a nonnegative integer
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Example: one of the characters 0, 1, ..., F in the hexadecimal numeration system
Syn: numeric character
|
|
digital.
(1)
pertaining to data that consists of digits as well as to processes and functional units that use the data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
digital asset.
(1)
IT asset expressed electronically in a digital format
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.17)
Example: software assets and digital information content assets
|
|
digital computer.
(1)
computer that is controlled by internally stored programs and that is capable of using common storage for all or part of a program and also for all or part of the data necessary for the execution of the programs; executing user-written or user-designated programs; performing user-designated manipulation of digitally represented discrete data, including arithmetic operations and logic operations; and executing programs that modify themselves during their execution
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
digital information content asset.
(1)
digital asset with information content
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.18)
Example: Documents, audio, video, graphics, databases, free-standing dictionaries, collections of standards in digital form, media collections, and credit agency rating information
Note: Often licensed, but not considered to be software. IT asset management can include management of these assets for license compliance, but excludes management of the content.
|
|
digital product.
(1)
product or service that is delivered, used, and stored in an electronic format
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
digital signal processing (DSP).
(1)
modification of an information signal represented by a sequence of digits or symbols to affect the representation of discrete time, discrete frequency, or other attributes
(ISO/IEC/IEEE 24765d:2015)
|
|
digital signal processor (DSP).
(1)
microprocessor designed to perform digital signal processing
(ISO/IEC/IEEE 24765d:2015)
|
|
DIKW.
(1)
data, information, knowledge, wisdom
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
dimension.
(1)
distinct components that a multidimensional construct encompasses
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.6)
|
|
DIP.
(1)
dual inline package
(ISO/IEC/IEEE 24765c:2014)
|
|
direct address.
(1)
address that identifies the storage location of an operand
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: one-level address
See Also: immediate data, indirect address, n-level address, direct instruction
|
|
direct instruction.
(1)
computer instruction that contains the direct addresses of its operands
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: immediate instruction, indirect instruction, absolute instruction, effective instruction
|
|
direct labor.
(1)
personnel efforts that are directly related to the units of production
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: indirect labor
|
|
direct measure.
(1)
measure of an attribute that does not depend upon a measure of any other attribute
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
direct memory access (DMA).
(1)
technique in which a peripheral takes direct control of a central processing unit's memory bus to transfer data to or from memory
(ISO/IEC/IEEE 24765d:2015)
|
|
direct memory access controller (DMAC).
(1)
functional unit that performs direct memory access
(ISO/IEC/IEEE 24765d:2015)
|
|
direct metric.
(1)
metric that does not depend upon a measure of any other attribute
(ISO/IEC/IEEE 24765l:2024)
|
|
direct staff-hour.
(1)
amount of effort directly expended in creating a specific output product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
direct user.
(1)
person who directly interacts with the product
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.1.14)
(ISO/IEC 25002:2024, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model overview and usage, 3.1.8)
See Also: indirect user
|
directed graph.
(1)
a graph (sense 2) in which direction is implied in the internode connections
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: digraph
See Also: undirected graph
 |
|
directed system of systems.
(1)
system of systems (SoS) created and managed to fulfill specific purposes and the constituent systems are subordinated to the SoS
(ISO/IEC/IEEE 21841:2019 Systems and software engineering--Taxonomy of systems of systems, 3.2.3)
Note: Component systems maintain an ability to operate independently; however, their normal operational mode is subordinated to the central managed purpose.
Syn: directed SoS
|
|
directory.
(1)
list of data items and information about those data items
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
disassemble.
(1)
to translate an assembled computer program from its machine language version into a form that resembles, but is not necessarily identical to, the original assembly language program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assemble
|
|
disassembler.
(1)
software tool that disassembles computer programs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
disaster recovery.
(1)
in computer system operations, the return to normal operation after a hardware or software failure
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
ability of the information and communications technology elements of an organization to support its critical business functions to an acceptable level within a predetermined period following a disaster
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.11)
Syn: DR
|
|
discipline-specific model.
(1)
representation of a system or system elements from the perspective of a discipline addressing domain-specific concerns where the model elements come from a specific discipline
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.7)
|
|
disclaimer.
(1)
notice that renounces or repudiates a legal claim or right
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
discounted payback period.
(1)
time it will take to recover a project's initial investment including interest
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: An indication of exposure to risk. If a project is canceled before it reaches its payback period, the organization will have lost money.
|
|
discrete.
(1)
pertaining to data that consist of distinct elements, such as characters, or to physical quantities having a finite number of distinctly recognizable values, as well as to processes and functional units that use those data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
discrete data.
(1)
data that arrives at specific time intervals
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
discrete effort.
(1)
work effort that is separate, distinct, and related to the completion of specific work breakdown structure components and deliverables, and that can be directly planned and measured
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: One of three earned value management types of activities used to measure work performance
See Also: apportioned effort
|
|
discrete type.
(1)
data type whose members can assume any of a set of distinct values
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: A discrete type can be an enumeration type or an integer type.
|
|
discretionary dependency.
(1)
relationship that is based on best practices or project preferences
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: preferential logic, preferred logic, soft logic
|
|
discrimination (threshold).
(1)
largest change in a stimulus that produces no detectable change in the response of a measuring instrument, the change in the stimulus taking place slowly and monotonically
(ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.4)
Note: The discrimination threshold can depend on, for example, noise (internal or external) or friction. It can also depend on the value of the stimulus.
|
|
discriminator.
(1)
property of a superclass, associated with a cluster of that superclass, whose value identifies to which subclass a specific instance belongs
(ISO/IEC/IEEE 24765n:2025, 3.1.51)
(2)
attribute in the generic entity (or a generic ancestor entity) of a category cluster whose values indicate which category entity in the category cluster contains a specific instance of the generic entity
(ISO/IEC/IEEE 24765n:2025, 3.1.51)
Note: Since the value of the discriminator (when a discriminator has been declared) is equivalent to the identity of the subclass to which the instance belongs, there is no requirement for a discriminator in identity-style modeling.
Syn: category discriminator
|
|
disk.
(1)
data medium originally consisting of a flat circular plate that is rotated in order to read or write data on one or both sides
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
display.
(1)
information presented on a screen or in a window of a screen
(ISO/IEC/IEEE 24765g:2018)
|
|
disposal.
(1)
removal or archiving, but not deletion, of an artifact so it can be made available for traceability and auditability
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
|
|
disposition.
(1)
range of processes associated with implementing retention, destruction or transfer decisions which are documented in disposition or other instruments
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.12)
|
|
distributed computing.
(1)
spreading of computation and data across a number of computers connected by a network
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
distributed denial of service attack.
(1)
unauthorized access to a system resource or the delaying of system operations and functions in the way of compromising multiple systems to flood the bandwidth or resources of the targeted system, with resultant loss of availability to authorized users
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.22)
Syn: DDOS attack
|
|
distributed processing.
(1)
information processing in which discrete components can be located in different places, and where communication between components can suffer delay or can fail
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 3.2.2)
|
|
distribution transparency.
(1)
property of hiding from the user some specific aspects of the system's complexity needed to support distribution
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.1.1)
|
|
distributional shift.
(1)
in machine learning, the distance between the training data distribution and the desired data distribution
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.29)
Note: The effect of distributional shift often increases as the users interaction with the system (and thus the desired data distribution) changes over time.
Syn: dataset shift
|
|
disturbance.
(1)
operational fault or event or anything that can change the state of the system
(ISO/IEC 25045:2010 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Evaluation module for recoverability, 4.2)
Example: an abrupt shutdown of an OS process that brings down a system, a significant increase in users of the system
Note: Disturbances are limited to external faults or events, rather than introduced internal faults that would require modifying the application or OS code.
|
|
DIT.
(1)
directory information tree
(ISO/IEC 13235-3:1998 Information technology -- Open Distributed Processing -- Trading Function -- Part 3: Provision of Trading Function using OSI Directory service, 4)
|
|
DITA.
(1)
Darwin Information Typing Architecture
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.2)
|
|
diversity.
(1)
in fault tolerance, realization of the same function by different means
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: use of different processors, storage media, programming languages, algorithms, or development teams
See Also: software diversity
|
|
dividing action.
(1)
action which enables two or more chains
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.1.4)
|
|
DL.
(1)
Definition Language
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
DLC.
(1)
data-life-cycle
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 5)
|
|
DMA.
(1)
direct memory access
(ISO/IEC/IEEE 24765d:2015)
|
|
DMAC.
(1)
direct memory access controller
(ISO/IEC/IEEE 24765d:2015)
|
|
DMS.
(1)
document management system
(ISO/IEC/IEEE 24765h:2019)
(2)
data management system
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
DN.
(1)
distinguished name
(ISO/IEC 13235-3:1998 Information technology -- Open Distributed Processing -- Trading Function -- Part 3: Provision of Trading Function using OSI Directory service, 4)
|
|
DNN.
(1)
deep neural network
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.2)
|
|
DNS.
(1)
Domain Name Service
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
do nothing alternative.
(1)
in a decision analysis, the alternative of not investing in any of the proposed alternatives
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: doesn't really mean doing nothing at all. Instead, it means putting the money into readily available investments that give a predetermined rate of return (bonds, interest bearing accounts, put into a more profitable part of the organization)
|
|
document.
(1)
uniquely identified unit of information for human use
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 3.1.10)
(2)
to create a document as in (1)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
to add comments to a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
fixed and structured amount of information intended for human perception that can be managed and interchanged as a unit between users and systems
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.10)
(5)
medium, and the information recorded on it, that generally has permanence and can be read by a person or a machine
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
(6)
information and the medium on which it is contained
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.36)
Example: policies, plans, process descriptions, procedures, service level agreements, contracts. In software engineering: project plans, specifications, test plans, user manuals
Note: Documents include both paper and electronic documents. The documentation can be in any form or type of medium. Documents, except for records, state the intent to be achieved. A set of documents, for example specifications and records), is frequently called "documentation".
See Also: documentation
|
|
document control.
(1)
application of configuration management to the control of documents
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
document management system.
(1)
system that supports the storage, retrieval, versioning, and manipulation of whole documents, images, and other media
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 4.12)
(2)
system that supports the storage, retrieval, the production of a version, and the manipulation of whole documents, images, and other media
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.11)
See Also: content management system
|
|
document management system (DMS).
(1)
system that supports the storage, retrieval, versioning, and manipulation of whole documents, images, and other media
(ISO/IEC/IEEE 24765h:2019)
See Also: content management system
|
|
document set.
(1)
documentation that has been segmented into separately identified volumes or products for ease of distribution or use
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.20)
|
|
document type definition (DTD).
(1)
template for the structure, content, and semantics of documents
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.12)
|
|
documentation.
(1)
collection of documents related to a given subject
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.10)
(2)
information that explains how to use software, devices, applications, or services
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.10)
(3)
information that explains how to use a product
(ISO/IEC/IEEE 26512:2018 Systems and software engineering--Requirements for acquirers and suppliers of information for users, 3.11)
(4)
record (e.g., report, calculation, specification) or other similar product that provides an evidentiary basis of a single or series of activities, tasks, or events and their associated plans, results of outcomes that may support a larger product, process, or program
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3)
Example: printed manuals, on-screen information, standalone online help, user guides, reference manuals, tutorials, wikis, input forms, error messages, user interfaces
Note: can be provided as separate documentation or as embedded documentation or both
See Also: document, information for users
|
documentation tree.
(1)
diagram that depicts all the documents for a given system and shows their relationships to one another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: specification tree
 |
|
documented information.
(1)
information required to be controlled and maintained by an organization and the medium on which it is contained
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.19)
Note: Documented information can be in any format and media and from any source. Documented information can refer to information created in order for the organization to operate (documentation), or evidence of results achieved (e.g. records, key performance indicators).
|
|
DoDAF.
(1)
Department of Defense architecture framework
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
DOI.
(1)
digital object identifier
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
domain.
(1)
aspect or area of knowledge or activity characterized by a set of concepts and terminology understood by practitioners in that area
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.1)
(2)
problem space
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
(3)
distinct scope, within which common and variable characteristics are exhibited, common rules and binding mechanisms are observed, and over which a distribution transparency is preserved
(ISO/IEC 26560:2019 Software and systems engineering -- Tools and methods for product line product management, 3.3)
|
|
domain analysis.
(1)
analysis of systems within a domain to discover commonalities and differences among them
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
(2)
process by which information used in developing software systems is identified, captured, and organized so that it can be reused to create new systems, within a domain
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
|
|
domain architecture.
(1)
common architecture for a product line that can embrace variability of member products
(ISO/IEC 26552:2019 Software and systems engineering--Tools and methods for product line architecture design, 3.5)
(2)
core architecture that captures the high-level design of a software and systems product line including the architectural structure and texture (e.g. common rules and constraints) that constrains all member products within a software and systems product line
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.10)
|
|
domain asset.
(1)
output of domain engineering life cycle processes that can be reused in producing products during application engineering
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.11)
Example: domain features, domain models, domain requirements specification, domain architecture, domain components, domain test cases, domain process description, variability model, architectural design, software component, source or object code, plan, process description, or any other element useful for producing products and services
Note: Domain assets are not physical products available off-the-shelf and ready for commissioning. Domain assets have their own life cycles.
Syn: core asset, domain artifact
|
|
domain assets in requirements.
(1)
reusable artifacts produced during domain requirements engineering
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.10)
Example: asset proposals, domain requirements specifications, domain requirements models
|
|
domain component.
(1)
reusable component among member products within a product line
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.10)
|
|
domain engineering.
(1)
reuse-based approach to defining the scope (i.e., domain definition), specifying the structure (i.e., domain architecture), and building the assets for a class of systems, subsystems, or applications
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
(2)
life cycle consisting of a set of processes for specifying and managing the commonality and variability of a product line
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.12)
Note: For example, "assets" such as requirements, designs, software code, documentation. Domain engineering can include the following activities: domain definition, domain analysis, developing the domain architecture, and domain implementation.
|
|
domain engineering process.
(1)
processes for domain asset development
(ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.5)
|
|
domain interface.
(1)
reusable interface among the components of a member product within a product line
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.11)
|
|
domain layer.
(1)
highest level of abstraction for the test item
(ISO/IEC/IEEE 29119-5:2024 Software and systems engineering--Software testing--Part 5: Keyword-driven testing, 3.5)
Note: Keywords on this level are chosen in a way that is familiar to domain experts.
|
|
domain model.
(1)
product of domain analysis that provides a representation of the requirements of the domain
(ISO/IEC/IEEE 24765j:2021)
Note: The domain model identifies and describes the structure of data, flow of information, functions, constraints, and controls within the domain that are included in software systems in the domain. The domain model describes the commonalities and variabilities among requirements for software systems in the domain.
|
|
domain realization.
(1)
one of the domain engineering processes that include detailed design and implementation
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.12)
|
|
domain requirements analysis.
(1)
subprocess that models domain requirements so as to analyze and scrutinize commonality/variability of a product line in requirements
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.12)
|
|
domain requirements elicitation.
(1)
subprocess that identifies initial requirements from domain stakeholders for a product line
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3,11)
|
|
domain requirements management.
(1)
subprocess that manages traceability and changes with respect to domain requirements and their relevant domain/application artifacts
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.15)
|
|
domain requirements specification.
(1)
subprocess that documents domain requirements for a product line based on domain analysis results
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.13)
|
|
domain requirements verification and validation.
(1)
subprocess that confirms that domain requirements are correct, consistent, and complete
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.14)
|
|
domain scoping.
(1)
subprocess for identifying and bounding the functional domains that are important to an envisioned product line and provide sufficient reuse potential to justify the product line creation
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.13)
Note: Identifies and bounds the functional domains that are important to an envisioned product line and provide sufficient reuse potential to justify the product line creation.
|
|
domain supersets.
(1)
collection comprising the feature catalogue and shared asset supersets
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.3)
|
|
domain test asset.
(1)
domain test artifacts that will be reused in application testing
(ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.6)
Note: Domain test assets, e.g., test plans, artifacts of regression testing, can be reused in domain testing.
|
|
domain test requirement.
(1)
specific element of a domain artifact that should be covered by domain testing
(ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.7)
Note: Domain test requirements cover functional and non-functional commonality and variability, and they include both their normal and error conditions.
|
|
domain testing.
(1)
domain engineering phase whose role is to test domain artefacts
(ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.5)
Note: testing of artifacts related to a product line (domain) rather than to an individual product
|
|
domain variability model.
(1)
explicit definition of product line variability
(ISO/IEC 26558:2017 Software and systems engineering -- Methods and tools for variability modelling in software and systems product line, 3.4)
|
|
domain-based requirement.
(1)
requirement originated from its application domain
(ISO/IEC 25030:2019 Systems and software engineering--Systems and software quality requirements and evaluation (SQuaRE)--Quality requirements framework, 3.5)
|
|
dominance.
(1)
decision technique that looks for an alternative that is at least as good in every attribute and better in at least one attribute
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
See Also: lexicography, satisficing
|
|
done.
(1)
regarded by the agile team as complete and ready to use
(ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 3.5)
(2)
statement on the required quality attributes that work meets before the work completes a specified life cycle activity or task and is ready for use
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.13)
(3)
checklist of all the criteria required to be met so that a deliverable can be considered ready for customer use
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: definition of done
See Also: ready
|
|
dot notation.
(1)
technique for naming that joins the name of a parent class to the name of a dependent class with the period character
(ISO/IEC/IEEE 24765m:2024, 2.1.47)
Example: The diagram feature reference ABC/A31.3 uses dot notation to join the page reference of the parent diagram ABC/A31 to the feature reference for box 3 in that diagram.
|
|
double data rate (DDR) SDRAM.
(1)
synchronous dynamic random access memory unit with higher access speed and bandwidth, because it transfers two consecutive words in one internal clock cycle
(ISO/IEC/IEEE 24765c:2014)
|
|
down.
(1)
pertaining to a system or component that is not operational or has been taken out of service
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: up, busy, crash, idle
|
|
down time.
(1)
in-service interval during which a system has not performed or cannot perform its required capabilities
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: Downtime can result from planned or unplanned support activities, system failures, or failures originating in a systems runtime or operational environments.
Syn: downtime
See Also: up time, busy time, idle time, mean time to repair, set-up time
|
|
downgrade right.
(1)
right granted to receive, install, or use an installation of a previous version of software than the currently granted entitlement
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.7)
|
|
download.
(1)
to transfer programs or data from a computer to a connected computer with fewer resources
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: typically, from a server to a personal computer
|
|
downward compatible.
(1)
pertaining to hardware or software that is compatible with an earlier or less complex version of itself
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a program that handles files created by an earlier version of itself
See Also: upward compatible
|
|
downward compression.
(1)
in software design, a form of demodularization in which a superordinate module is copied into the body of a subordinate module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: lateral compression, upward compression
|
|
DP.
(1)
data processing
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
deployment package
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.35)
|
|
DPIA.
(1)
data protection impact assessment
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.2)
|
|
DR.
(1)
decision review
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
(2)
disaster recovery
(ISO/IEC/IEEE 24765n:2025)
|
|
DRAM.
(1)
dynamic random access memory
(ISO/IEC/IEEE 24765c:2014)
|
|
drift.
(1)
changes to machine learning model behavior that occur over time
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 6.1.30)
(2)
expression of deviations between training data and collected data inputs
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: These changes typically make predictions less accurate and can require the model to be re-trained with new data.
Syn: degradation, staleness
See Also: algorithmic drift, concept drift, data drift
|
|
driver.
(1)
external dynamic component or simulator that activates the performing of functions of an aggregate of system elements
(ISO/IEC/IEEE 24748-6:2023 Systems and software engineering Life cycle management Part 6: System and software integration, 3.1.2)
Syn: launcher
See Also: test driver
|
|
DRP.
(1)
disaster recovery plan
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
|
|
DSL.
(1)
definitive software library
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.11)
|
|
DSP.
(1)
digital signal processing
(ISO/IEC/IEEE 24765d:2015)
(2)
digital signal processor
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
DT.
(1)
development test
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
DT&E.
(1)
developmental test and evaluation
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
DTC.
(1)
data transfer controller
(ISO/IEC/IEEE 24765d:2015)
|
|
DTCF.
(1)
downtime cycle finish
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
DTCS.
(1)
downtime cycle start
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
DTD.
(1)
document type definition
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users)
Note: for XML or SGML specifications
|
|
DUA.
(1)
Directory User Agent
(ISO/IEC 13235-3:1998 Information technology -- Open Distributed Processing -- Trading Function -- Part 3: Provision of Trading Function using OSI Directory service, 4)
|
|
dual boot.
(1)
having more than one boot mode, to allow running two different operating systems on the same computer
(ISO/IEC/IEEE 24765e:2015)
See Also: single boot
|
|
dual inline package (DIP).
(1)
microcircuit unit with connectors (pins) arranged in two rows
(ISO/IEC/IEEE 24765c:2014)
|
|
dump.
(1)
display of some aspect of a computer program's execution state, usually the contents of internal storage or registers
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
display of the contents of a file or device
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
to copy the contents of internal storage to an external medium
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: change dump, dynamic dump, memory dump, postmortem dump, selective dump, snapshot dump, static dump
|
|
duration (DU or DUR).
(1)
total number of work periods required to complete an activity or work breakdown structure component, expressed in hours, days, or weeks
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
positive difference between any two ticks of the same type
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
See Also: effort
|
|
duty.
(1)
obligation or expectation to perform a specific action when certain circumstances occur
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
|
|
duty ethics.
(1)
ethical theory that identifies universal moral laws to bound the actions of all rational individuals
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
Syn: deontology
|
|
DVD.
(1)
digital versatile disc
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2)
(2)
digital video disc
(ISO/IEC/IEEE 24765c:2014)
|
|
dyadic selective construct.
(1)
if-then-else construct in which processing is specified for both outcomes of the branch
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: monadic selective construct
|
|
dynamic.
(1)
pertaining to an event or process that occurs during computer program execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: dynamic analysis, dynamic binding
See Also: static
|
|
dynamic analysis.
(1)
evaluating a system or component based on its behavior during execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: static analysis demonstration, testing
|
|
dynamic attribute.
(1)
element of a hardware identification (HWID) tag that can change over the life of the product or be defined after creation
(ISO/IEC 19770-6:2024, Information technology IT asset management Part 6: Hardware identification tag, 3.1.1)
|
|
dynamic binding.
(1)
binding performed during the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: static binding
|
|
dynamic breakpoint.
(1)
breakpoint whose predefined initiation event is a runtime characteristic of the program, such as the execution of any twenty source statements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: static breakpoint, code breakpoint, data breakpoint, epilog breakpoint, programmable breakpoint, prolog breakpoint
|
|
dynamic buffering.
(1)
buffering technique in which the buffer allocated to a computer program varies during program execution, based on current need
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: simple buffering
|
|
dynamic bus sizing.
(1)
capability to adjust the size of a bus on request during operations
(ISO/IEC/IEEE 24765d:2015)
Note: used during direct memory access
|
|
dynamic dump.
(1)
dump that is produced during the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: static dump, change dump, memory dump, postmortem dump, selective dump, snapshot dump
|
|
dynamic error.
(1)
error that is dependent on the time-varying nature of an input
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: static error
|
|
dynamic invocation.
(1)
constructing and issuing a request whose signature is possibly not known until run-time
(ISO/IEC/IEEE 24765l:2024)
|
|
dynamic model.
(1)
model that describes individual requests or patterns of requests among objects
(ISO/IEC/IEEE 24765n:2025, 3.1.53)
See Also: static model
|
|
dynamic product.
(1)
system or software product that is measurable during execution in a testing or an operational environment
(ISO/IEC 25041: 2012 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Evaluation guide for developers, acquirers and independent evaluators, 4.2)
|
|
dynamic program analysis.
(1)
process of evaluating a software system or component based on its behavior during execution
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.5)
Note: The software is compiled and run on a certain number of input data test cases. The physical response from the system is then examined and compared to expected results. Dynamic program analysis can be done manually or using an automated process.
|
|
dynamic random access memory (DRAM).
(1)
RAM with a frequent refresh process to retain data
(ISO/IEC/IEEE 24765c:2014)
Note: used with a circuit architecture in single stable state
|
|
dynamic relocation.
(1)
migration of a computer program during its execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
dynamic resource allocation.
(1)
computer resource allocation technique in which the resources assigned to a program vary during program execution, based on current need
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
dynamic restructuring.
(1)
reorganizing a database, data structure, computer program, or set of system components during program execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
dynamic schema.
(1)
specification of the allowable state changes of one or more information objects, subject to the constraints of any invariant schemata
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 6.1.3)
Example: null
Note: Behavior in an information system can be modeled as transitions from one static schema to another, i.e., reclassification of instances from one type to another. In the information language, a state change involving a set of objects can be regarded as an interaction between those objects. Not all of the objects involved in the interaction need change state; some of the objects can be involved in a read-only manner.
|
|
dynamic storage allocation.
(1)
storage allocation technique in which the storage assigned to a computer program varies during program execution, based on the current needs of the program and of other executing programs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
dynamic testing.
(1)
testing in which a test item is evaluated by executing it
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.3)
|
|
E-R diagram.
(1)
entity-relationship diagram
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
EA/IS.
(1)
empathetic autonomous and intelligent systems
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
|
|
EAC.
(1)
estimate at completion
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
early-failure period.
(1)
period of time in the life cycle of a system or component during which hardware failures occur at a decreasing rate as problems are detected and repaired
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: burn-in period
See Also: constant-failure period, wearout-failure period, bathtub curve
|
|
earned value (EV).
(1)
measure of work performed expressed in terms of the budget authorized for that work
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: budgeted cost of work performed (BCWP)
|
|
earned value analysis.
(1)
analysis method that uses a set of measures associated with scope, schedule, and cost to determine the cost and schedule performance of a project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
ECCS.
(1)
emergency core cooling systems
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
ECFS.
(1)
electronic contract filing system
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
echo.
(1)
to return a transmitted signal to its source, often with a delay to indicate that the signal is a reflection rather than the original
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
returned signal
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
ECMS.
(1)
Enterprise Content Management System
(ISO/IEC/IEEE 24765l:2024)
|
|
ECO.
(1)
engineering change order
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)
|
|
ECP.
(1)
engineering change proposal
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
ECR.
(1)
engineering change request
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
EDA.
(1)
electronic design automation
(ISO/IEC/IEEE 24765d:2015)
|
|
EDI.
(1)
electronic data interchange
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.2)
|
|
edit.
(1)
to modify the form or format of computer code, data, or documentation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: to insert, rearrange, or delete characters
|
|
EDRAP.
(1)
engineering data requirements agreement plan
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
EEF.
(1)
enterprise environmental factors
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
EEPROM.
(1)
electric erasable programmable read only memory
(ISO/IEC/IEEE 24765c:2014)
|
|
EF.
(1)
early finish date
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
effective address.
(1)
address that results from performing any required indexing, indirect addressing, or other address modification on a specified address
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: If the specified address requires no modification, it is also the effective address.
See Also: generated address, indirect address, relative address
|
|
effective instruction.
(1)
computer instruction that results from performing any required indexing, indirect addressing, or other modification on the addresses in a specified computer instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: If the specified instruction requires no modification, it is also the effective instruction.
See Also: absolute instruction, direct instruction, immediate instruction, indirect instruction
|
|
effective interest rate.
(1)
interest rate that has been adjusted for more or less frequent compounding
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
effectiveness.
(1)
accuracy and completeness with which users achieve specified goals
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.1.7)
(2)
extent to which planned activities are realized and planned results achieved
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.20)
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.1.3)
Example: For documentation, common measures include percentage of task completion, frequency of defects, frequency of assists,
frequency of accesses to help or documentation.
|
|
efferent.
(1)
pertaining to a flow of data or control from a superordinate module to a subordinate module in a software system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: afferent
|
|
efficiency.
(1)
relationship between the result achieved and the resources used
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.17)
(2)
resources used in relation to the results achieved
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.1.8)
Note: Time-on-task and Completion Rate/Mean Time-On-Task (defect rates vs. time to achieve task) are measures of efficiency. Efficiency in the context of usability is related to productivity, rather than to its meaning in the context of software efficiency. Efficiency is the degree to which an information system efficiently uses the technical infrastructure and thus becomes usable for the customer. The most important underlying topic here is the capacity of the platform in relation to the demand.
See Also: execution efficiency, storage efficiency
|
|
effort.
(1)
number of labor units required to complete a schedule activity or work breakdown structure component, often expressed in hours, days or weeks
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: duration
|
|
egoless programming.
(1)
software development technique based on the concept of team, rather than individual, responsibility for program development
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Its purpose is to prevent individual programmers from identifying so closely with their work that objective evaluation is impaired.
|
|
EI.
(1)
external input
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 4)
|
|
EIF.
(1)
external interface file
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 4)
|
|
EJB.
(1)
Enterprise Java Beans
(ISO/IEC/IEEE 24765m:2024)
|
|
elasticity.
(1)
for a service, degree to which a service adjusts rapidly to the amount of resources that are allocated to an instance of the service
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.1.5)
|
|
electric erasable programmable read only memory (EEPROM).
(1)
type of programmable ROM in which the memory can be erased using electrical current and rewritten
(ISO/IEC/IEEE 24765c:2014)
See Also: flash memory
|
|
electronic data interchange (EDI).
(1)
structured way of transmitting data held electronically from database to database, usually using telecommunications networks
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
electronic design automation (EDA).
(1)
software-driven design and development of electronic components such as microcomputer units and circuit boards
(ISO/IEC/IEEE 24765d:2015)
|
|
electronic publishing.
(1)
production of typeset-quality documents including text, graphics, and pictures with the assistance of a computer
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
element.
(1)
identifiable part of a system
(ISO/IEC/IEEE 24765e:2015)
(2)
component of an information structure that provides information related to the entity represented by the information structure
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.12)
(3)
one of the parts of a compound or complex whole
(ISO/IEC 19506:2012 Information technology -- Object Management Group Architecture-Driven Modernization (ADM) -- Knowledge Discovery Meta-Model (KDM), 4)
(4)
component of an XML document or part of the entitlement schema (Ent) that provides information related to the entitlement represented by the Ent
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.8)
(5)
smaller part of an architecture
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.19)
Example: documents, requirements specifications, test cases, source code, installation information, and read-me files
See Also: component, unit
|
|
element type.
(1)
category or class of elements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
elementary process.
(1)
smallest unit of activity that is meaningful to the user
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.21)
Syn: EP
|
|
ELSE-rule.
(1)
actions to be taken for all combinations of conditions not covered by the other rules in the table
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.5)
Note: The use of the ELSE-rule facility is optional.
|
|
email.
(1)
correspondence in the form of messages transmitted over a computer network
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Syn: electronic mail, e-mail
|
|
embedded computer system.
(1)
computer system that is part of a larger system and performs some of the requirements of that system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a computer system used in an aircraft or rapid transit system
Note: The hardware and software of an embedded system are usually minimized and optimized for specific functions. The embedded system includes at least one microcontroller, microprocessor or digital signal processor. The embedded system designed to optimize reliability, cost, size and power saving for applications.
Syn: embedded system
|
|
embedded documentation.
(1)
information that is delivered as an integral part of a piece of software
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.14)
Example: on-screen help provided with the software
See Also: separate documentation
|
|
embedded help system.
(1)
information for users that is delivered as an integral part of a piece of software
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.14)
|
|
embedded information for users.
(1)
information for users that is accessed as an integral part of software
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.22)
Example: Pop-up help and help text on a screen
See Also: onscreen information for users, printed information for users
|
|
embedded middleware.
(1)
software that communicates between an embedded operating system and an embedded application or firmware
(ISO/IEC/IEEE 24765e:2015)
|
|
embedded operating system.
(1)
operating system software for an embedded computer system
(ISO/IEC/IEEE 24765d:2015)
|
|
embedded software.
(1)
software that is part of a larger system and performs some of the requirements of that system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: software used in an aircraft or rapid transit system
|
|
EMC.
(1)
electromagnetic compatibility
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
EMD.
(1)
engineering and manufacturing development
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
emergence.
(1)
principle that entities exhibit properties which are meaningful only when attributed to the whole, not to its parts
(ISO/IEC/IEEE 21840:2019 Systems and software engineering--Guidelines for the utilization of ISO/IEC/IEEE 15288 in the context of system of systems (SoS), 3.1.3)
Note: These properties cannot be reduced or decomposed back down to the those of any individual constituent system.
|
|
emergency.
(1)
serious, unexpected, and often dangerous situation requiring immediate action
(ISO/IEC/IEEE 24748-9:2023, Systems and software engineering Life cycle management Part 9: Application of system and software life cycle processes in epidemic prevention and control systems, 3.1.2)
|
|
emergency maintenance.
(1)
unscheduled modification performed to temporarily keep a system operational pending corrective maintenance
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.1.5)
Note: Emergency maintenance can be performed to make a software system partially operational. It can include various modifications to the software or its parameters that limit operations, functionalities, inputs, outputs, interfaces, or usability, Emergency maintenance can be regarded as a type of corrective maintenance.
|
|
emergency support.
(1)
unscheduled in-service modification performed to temporarily keep a system operational, pending corrective support
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: Emergency support can be regarded as a corrective support type. Emergency support can include modifications to a system, its configuration, or runtime environment that alter operations, functionality, inputs, outputs, interfaces, storage, and other resources, or by establishing temporary usage alternatives (workarounds) to avoid triggering anomalies or failures.
|
|
EMI.
(1)
electromagnetic interference
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
emotional intelligence.
(1)
ability to identify, assess, and manage the personal emotions of oneself and other people, as well as the collective emotions of groups of people
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
empathetic autonomous and intelligent system (EA/IS).
(1)
affect-sensitive technologies employed to algorithmically infer, model, simulate, or stimulate understanding of emotions, feelings, moods, perspective, attention or intention
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: AI that uses processes such as sentiment analysis, biometrics, or natural language processing to analyze, infer, or simulate affect. Data insights or actions taken in response to automated inferences typically inform future interactions between a person, group, or another system and the EA/IS.
Syn: affective computing system, emotional AI, emotion-detecting AI
|
|
empathy.
(1)
share or understand another's feelings or experience
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: Empathy performed by a machine is considered to be an emulation of human empathy, rather than the same process.
|
|
employee.
(1)
person who works in a subordinate arrangement within or beyond the physical boundaries of an organization
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
|
|
emulated user.
(1)
imitation of a user, with regard to the tasks he submits and his time behavior, realized by a technical system
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.6)
|
|
emulation.
(1)
model that accepts the same inputs and produces the same outputs as a given system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
use of a data processing system to imitate another data processing system, so that the imitating system accepts the same data, executes the same programs, and achieves the same results as the imitated system
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
See Also: simulation
|
|
emulator.
(1)
device, computer program, or system that accepts the same inputs and produces the same outputs as a given system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: often used for testing or debugging
See Also: simulator
|
|
EMV.
(1)
expected monetary value
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
enabled behavior.
(1)
behavior characterizing a set of objects which becomes possible as a result of establishing behavior
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.2.2)
Syn: enabled behaviour
|
|
enabling (a transition).
(1)
state of a transition in a particular mode and net marking when the following conditions are met: the marking of each input place of the transition satisfies the demand imposed on it by its arc annotation evaluated for the particular transition mode; the demand is satisfied when the place?s marking contains (at least) the multiset of tokens indicated by the evaluated arc annotation; the determination of transition modes guarantees that the transition condition is satisfied
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.8)
Note: The determination of transition modes guarantees that the transition condition is satisfied.
|
|
enabling system.
(1)
system that supports a system-of-interest during its life cycle stages but does not necessarily contribute directly to its function during operation
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.23)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.15)
Note: For example, when a system-of-interest enters the production stage, an enabling production system is required. Each enabling system has a life cycle of its own.
See Also: software development environment
|
|
enactment.
(1)
establishment of something by law, ruling, or other authoritative acts
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
act of applying a methodology for some particular purpose, typically an endeavor
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.8)
|
|
encapsulation.
(1)
software development technique that consists of isolating a system function or a set of data and operations on those data within a module and providing precise specifications for the module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
concept that access to the names, meanings, and values of the responsibilities of a class is entirely separated from access to their realization
(ISO/IEC/IEEE 24765n:2025, 3.1.54)
(3)
idea that a module has an outside that is distinct from its inside, that it has an external interface and an internal implementation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: data abstraction, information hiding
|
|
encoding.
(1)
definition of how the elements of a syntax are represented using an identified character set
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: Details of representation of the various terminal symbols and data types in the syntax's grammar are provided.
|
|
ENCODING.1.
(1)
primary encoding defined within the CDIF family of standards
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: The CDIF family of standards supports multiple transfer formats, each composed of a syntax and an encoding.
|
|
end item.
(1)
entity that is ready for use
(ISO/IEC/IEEE 24765f:2016)
|
|
end of period convention.
(1)
representation of discrete cash-flow instances at the end of the period in which they occur (in contrast to showing them at the beginning)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The initial investment is shown at the end of period zero.
|
|
end user.
(1)
person who directly uses the system for its intended purpose
(ISO/IEC/IEEE 24765e:2015)
(2)
the person or persons who will ultimately be using the system for its intended purpose
(3)
individual person who ultimately benefits from the outcomes of the system or software
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.7)
(4)
any person that communicates or interacts with the software at any time
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, 3.5)
(5)
person or persons who will ultimately be using the system for its intended purpose
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.13)
(6)
individual person who ultimately benefits from the ready-to-use software product functionalities
(ISO/IEC 25051:2014 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, 4.1.7)
Note: An end user will generally be defined in terms of a specific software component of a system.
Syn: end-user
See Also: direct user, functional user, indirect user, operator, secondary user, user
|
|
endeavor.
(1)
IBD development effort aimed at the delivery of some product or service through the application of a methodology
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.5)
Example: projects, programs and infrastructural duties
Syn: endeavour
|
|
endeavor element.
(1)
simple component of an endeavor
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.7)
Example: Customer, Invoice (classes), Name, Age (attributes), High-Level Class Model number 17 (a model), System Requirements Description (a document), Coding Cycle number 2, Coding Cycle number 3 (tasks)
Note: During the execution of an endeavor, developers create a number of endeavor elements, such as tasks, models, classes, documents.
|
|
endurance testing.
(1)
type of performance efficiency testing conducted to evaluate whether a test item can sustain a required load continuously for a specified period of time
(ISO/IEC/IEEE 24765k:2022)
|
|
engineered system.
(1)
system designed or adapted to interact with an anticipated operational environment to achieve one or more intended purposes while complying with applicable constraints
(INCOSE Systems Engineering Handbook, 5th ed.)
|
|
engineering.
(1)
application of a systematic, disciplined, quantifiable approach to structures, machines, products, systems, or processes
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.24)
|
|
engineering change.
(1)
alteration in the configuration of a hardware/software configuration item or items, delivered, to be delivered, or under development, after formal establishment of their configuration identification
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
in configuration management, an alteration in the configuration of a configuration item or other designated item after formal establishment of its configuration identification
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: configuration control, engineering change proposal, deviation, waiver
|
|
engineering change proposal (ECP).
(1)
in configuration management, a proposed engineering change and the documentation by which the change is described and suggested
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: configuration control
|
|
engineering interface reference.
(1)
identifier, in the context of an engineering interface reference management domain, for an engineering object interface that is available for distributed binding
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.16)
Note: An engineering interface reference is necessary to establish distributed bindings, and is distinct from the binding endpoint identifiers used by a basic engineering object for the purposes of interaction.
|
|
engineering interface reference management domain.
(1)
set of nodes forming a naming domain for the purpose of assigning engineering interface references
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.17)
|
|
engineering interface reference management policy.
(1)
set of permissions and prohibitions that govern the federation of engineering interface reference management domains
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.18)
|
|
engineering viewpoint.
(1)
viewpoint on an ODP system and its environment that focuses on the mechanisms and functions required to support distributed interaction between objects in the system
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.1.1.4)
|
|
enhancement.
(1)
software change that addresses and implements a new requirement
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.1.7)
Note: The term "enhancement" is mainly used as a maintenance type and to classify modification requests. There are three types of software enhancements: adaptive, perfective. and additive. An enhancement is not a software correction. These activities usually also change the functional size as a result (e.g. change requests).
See Also: change, correction
|
|
enhancement project.
(1)
project to develop and deliver adaptive maintenance
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.22)
Note: In an enhancement project, functionality can be added to, changed in, or deleted from an existing application. An enhancement project can also develop and deliver corrective and perfective maintenance, but these do not contribute to the enhancement project functional size.
|
|
enhancement project function point count (EFP).
(1)
activity of applying ISO/IEC 20926:2009 to measure the functional size of an enhancement project
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.24)
|
|
ensure.
(1)
to make certain that things occur or events take place
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
Note: Standards do not ensure any potential results; the result depends on how the standard is applied. Insure is used only for insurance matters.
See Also: assure
|
|
Ent.
(1)
[software] entitlement schema
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.2)
|
|
Ent creator.
(1)
entity that initially creates an Ent
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.10)
Note: This entity can be part of the organization that created or published the software to which the Ent relates, in which case the Ent creator and software creator will be the same. The Ent creator can also be a separate organization which holds the licensing rights or even a third-party organization unrelated to
the software creator (such as in the case where Ents are created for legacy software by a consultant or tool developer).
Syn: entitlement schema creator
|
|
enterprise.
(1)
bold or complex endeavor
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.9)
(2)
purposeful combination of interdependent resources that interact with each other to achieve business and operational goals
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: One or more organizations can participate in an enterprise. In case of multi-organization enterprises, each of the organizations brings various resources forward for use in the enterprise and they participate to the extent that they benefit from their involvement. The purpose of the enterprise is to address some challenges that these participating organizations cannot readily address on their own. Within a single organization, an enterprise may refer to a subset of the organization which is typically addressing particularly challenging or complex issues, often over a defined duration, and may undertake this with certain relaxations, tightening or otherwise authorized modifications of its standard processes and practices.
|
|
enterprise environmental factors.
(1)
conditions, not under the immediate control of the team, that influence, constrain or direct the project, program or portfolio
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
enterprise viewpoint.
(1)
viewpoint on an ODP system and its environment that focuses on the purpose, scope, and policies for that system
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.1.1.1)
|
|
entitlement schema.
(1)
information structure containing a digital encapsulation of a licensing transaction and its associated entitlement information
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.11)
Note: A single transaction does not necessarily encapsulate a full (or effective) entitlement. An effective entitlement can be determined by an analysis of multiple licensing transactions, of a full license and then of upgrades and/or maintenance transactions assessed together with it.
Syn: software entitlement schema, Ent
|
|
entity.
(1)
a fundamental thing of relevance to the user, about which information is kept
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
(2)
individual, group, or organizational function that can be tasked with a given responsibility
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
(3)
the representation of a concept, or meaning, in the minds of the people of the enterprise
(4)
object (i.e., thing, event, or concept) that occurs in a model (i.e., transfer)
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
(5)
object that is to be characterized by measuring its attributes
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.9)
(6)
logical component of the data store, representing fundamental things of relevance to the user, and about which persistent information is stored
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, A.8)
(7)
concrete or abstract thing of interest
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 6.1)
(8)
object to be modeled
(ISO/IEC 15476-4:2005 Information technology--CDIF semantic metamodel--Part 4: Data models, 6.3)
Example: a data item, program statement, or subprogram
Note: While in general the word entity can be used to refer to anything, in the context of modeling it is reserved to refer to things in the universe of discourse being modeled.
|
|
entity dependent.
(1)
entity that is meaningless or insignificant to the business in and of itself without the presence of other entities, such that an occurrence of entity X must be linked to an occurrence of entity Y, and the deletion of an occurrence of entity Y results in the deletion of all related occurrences of entity X
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.25)
Syn: entity-dependent
|
|
entity independent.
(1)
〈entity〉 meaningful or significant to the business in and of itself without the presence of other entities
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.26)
Syn: entity-independent
|
|
entity instance.
(1)
one of a set of real or abstract things represented by an entity
(ISO/IEC/IEEE 24765n:2025, 3.1.56)
Note: Each instance of an entity can be specifically identified by the value of the attribute(s) participating in its primary key. [key style]
|
|
entity of interest (EoI).
(1)
subject of an architecture description
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.12)
Example: Enterprise, organization, solution, system (including software systems), subsystem, process, business, data (as a data item or data structure), application, information technology (as a collection), mission, product, service, software item, hardware item, product line, family of systems, system of systems, collection of systems, collection of applications.
Note: Entity of interest refers to the entity whose architecture is under consideration in the preparation of an architecture description. Interest in an entity is intended to encompass interest in that entitys environment, life cycle, architecture, requirements, design, implementation and operation. Such interests are captured via aspects, concerns and stakeholder perspectives.
Syn: entity-of-interest
See Also: system of interest
|
|
entity-relationship (E-R) diagram.
(1)
a diagram that depicts a set of real-world entities and the logical relationships among them
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: entity-relationship map
See Also: data structure diagram
|
|
entry (-type).
(1)
data movement that moves a data group from a functional user across the boundary into the functional process where it is required
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.8)
Note: an entry is considered to account for certain associated data manipulations (e.g., validation of the entered data)
Syn: entry type
|
|
entry criteria.
(1)
states of being that have to be present before an effort can begin successfully
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
artifacts and other review or audit elements that have to be completed before the review or audit can be conducted
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.1)
See Also: exit criteria
|
|
entry point.
(1)
point in a software module at which execution of the module can begin
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
point in a test item at which execution of the test item can begin
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.27)
Note: An entry point is an executable statement within a test item that can be selected by an external process as the starting point for one or more paths through the test item. It is most commonly the first executable statement within the test item.
Syn: entrance, entry
See Also: exit, reentry point
|
|
entry profile.
(1)
profile targeted at start-up very small entities (i.e., VSEs that started their operation fewer than three years ago) or at VSEs working on small projects (e.g., project size of fewer than six person-months)
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.40)
|
|
enumeration type.
(1)
discrete data type whose members can assume values that are explicitly defined by the programmer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a data type called COLORS with possible values RED, BLUE, and YELLOW
See Also: character type, integer type, logical type, real type
|
|
environment.
(1)
context determining the setting and circumstances of all influences upon a system
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.25)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.16)
(2)
context of surrounding things, conditions, or influences upon an entity
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.13)
(3)
of an object, the part of the model which is not part of that object
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.2)
(4)
context determining the setting and circumstances of influences upon an architecture entity or upon which the architecture entity can have an influence
(ISO/IEC/IEEE 42030:2019 Software, systems, and enterprise--Architecture evaluation framework, 3.7)
(5)
responsible organization, its systems, or processing activities it operates
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
(6)
surroundings (natural or human-made) in which the system of interest is utilized and supported or in which the system is being developed, produced, and retired
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: The environment of a system includes external entities that can have various influences, such as developmental, technological, business, operational, organizational, political, economic, legal, regulatory, ethical, ecological, and social influences. Environment can refer to external physical effects, such as electromagnetic radiation, charged particles, gravitational effects, and electric and magnetic fields.
|
|
environment contract.
(1)
contract between an object and its environment, including Quality of Service constraints, usage and management constraints
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.3)
|
|
EO.
(1)
external output
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 4)
|
|
EoI.
(1)
entity of interest
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.12)
(2)
event of interest
(IEEE 7009-2024, Fail-Safe Design of Autonomous and Semi-Autonomous Systems, 3.2)
Syn: EOI
|
|
EP.
(1)
elementary process
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.9)
|
|
epic.
(1)
high-level or complex user story to be refined into more detailed user stories
(Software Extension to the PMBOK(R) Guide Fifth Edition)
(2)
major collection of related feature sets broken down into individual features or user stories and implemented in parts over a longer period of time
(ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 3.6)
(3)
large, related body of work intended to hierarchically organize a set of requirements and deliver specific business outcomes
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
epilog breakpoint.
(1)
breakpoint that is initiated upon exit from a given program or routine
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: postamble breakpoint
See Also: prolog breakpoint, code breakpoint, data breakpoint, dynamic breakpoint, programmable breakpoint, static breakpoint
|
|
epistemic logic.
(1)
relating to knowledge or to the degree of its validation
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
|
|
epoch.
(1)
period of time for which an object displays a particular behavior
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 10.5)
|
|
EPROM.
(1)
erasable programmable read only memory
(ISO/IEC/IEEE 24765c:2014)
|
|
EQ.
(1)
external inquiry
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 4)
|
|
equipment.
(1)
associated assemblies intended to achieve a defined final objective
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.12)
|
|
equivalence class.
(1)
range on a classification axis which has a rule to judge whether a target system is to be mapped to the range or not
(ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.8)
|
|
equivalence partition.
(1)
class of inputs or outputs that are expected to be treated similarly by the test item
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.28)
Syn: equivalence class
|
|
equivalence partitioning.
(1)
test design technique in which test cases are designed to exercise equivalence partitions by using one or more representative members of each partition
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.31)
(2)
specification-based test case design technique based on exercising equivalence partitions
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.29)
|
|
equivalent faults.
(1)
two or more faults that result in the same failure mode
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
ERA.
(1)
Entity-Relationship-Attribute modeling
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 5.2)
|
|
erasable programming read only memory (EPROM).
(1)
type of programmable ROM which can be rewritten after erasing the existing data using ultraviolet (UV) rays
(ISO/IEC/IEEE 24765c:2014)
Note: The device can be rewritten many times.
|
|
ergonomics.
(1)
scientific discipline concerned with the understanding of the interactions among human and other elements of a system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
profession that applies theory, principles, data and methods to design in order to optimize human well-being and overall system performance
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
errata.
(1)
severe service-disrupting bugs for which there is no known workaround
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Fixes for such bugs can often be introduced on a frozen branch.
|
|
error.
(1)
discrepancy between a computed, observed, or measured value or condition and the true, specified, or theoretically correct value or condition
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.4.5)
Example: omission or misinterpretation of user requirements in a software specification, incorrect translation, or omission of a requirement in the design specification
See Also: failure, defect
|
|
error guessing.
(1)
test design technique in which test cases are derived on the basis of the tester's knowledge of past failures, or general knowledge of failure modes
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.32)
Note: The relevant knowledge can be gained from personal experience, or can be encapsulated in, for example, a defects database or a bug taxonomy.
|
|
error message.
(1)
message that the application gives when incorrect data is entered or when another processing error occurs
(ISO/IEC/IEEE 24765l:2024)
|
|
error model.
(1)
in software evaluation, a model used to estimate or predict the number of remaining faults, required test time, and similar characteristics of a system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: error prediction model
|
|
error prediction.
(1)
quantitative statement about the expected number or nature of faults in a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: error model, error seeding
|
|
error processing.
(1)
process of detecting and responding to a program's errors
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
error seeding.
(1)
process of intentionally adding known faults to those already in a computer program for the purpose of monitoring the rate of detection and removal, and estimating the number of faults remaining in the program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: bug seeding, fault seeding
See Also: indigenous error
|
|
error tolerance.
(1)
ability of a system or component to continue normal operation despite the presence of erroneous inputs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: fault tolerance, robustness
|
|
escaped.
(1)
preceding each occurrence of a pattern by the |
|
escrow.
(1)
source code and documentation that is kept in the custody of a third party until specified contractual conditions have been fulfilled
(ISO/IEC/IEEE 24765k:2022)
|
|
ESF.
(1)
engineered safety feature
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
ESOH.
(1)
environment, safety, and occupational health
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
establish and maintain.
(1)
to formulate, document, and use [a policy or procedure] throughout an organization
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: This phrase means more than a combination of its component terms; it includes documentation and usage.
See Also: maintain
|
|
established requirement.
(1)
requirement that the project has verified as satisfying project-specific criteria (such as clarity, suitability, and feasibility) and has validated to be an accurate representation of stakeholder needs, wants, and expectations
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
Note: Established requirements are accepted by the project to form the basis of product development.
|
|
establishing behavior.
(1)
behavior by which a given contract is put in place between given objects
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.2.1)
Syn: establishing behaviour
|
|
estimate.
(1)
quantitative assessment of the likely amount or outcome of a variable, such as project costs, resources, effort, or durations
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: usually preceded by a modifier (i.e., preliminary, conceptual, feasibility, order-of-magnitude, definitive) and including an indication of accuracy (e. g. , (+ or -) x percent).
See Also: budget, cost
|
|
estimate at completion (EAC).
(1)
expected total cost of completing all work expressed as the sum of the actual cost to date and the estimate to complete
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: earned value technique, estimate to complete
|
|
estimate to complete (ETC).
(1)
expected cost to finish all the remaining project work
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: estimate at completion
|
|
estimating methods.
(1)
methods used to develop an approximation of work, time, or cost on a project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
estimation.
(1)
process of developing a quantitative assessment of the likely amount or outcome
(ISO/IEC/IEEE 24748-5:2017 Systems and software engineering--Life cycle management--Part 5: Software development planning, 3.5)
|
|
ETC.
(1)
estimate to complete
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
ethical.
(1)
supporting the realization of positive values or the reduction of negative values
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
Note: A system can be ethical or unethical in the sense that it bears value dispositions to cater to positive value creation or negative value prohibition.
|
|
ethical policy statement.
(1)
high-level declaration endorsed by the top management to explain and demonstrate the organization's commitment to respect core values in the conduct of its activities
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
|
|
ethical principle.
(1)
shared proposition about ethical values that members of a community can pursue and uphold
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
|
|
ethical requirement.
(1)
requirement that is either an ethical value requirement (EVR) or a value-based system requirement
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
|
|
ethical risk.
(1)
risk to ethical values
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
|
|
ethical value.
(1)
value in the context of human culture that supports a judgment on what is right or wrong
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
Example: A virtue is an example of an ethical value.
|
|
ethical value requirement (EVR).
(1)
organizational or technical requirement catering to values that stakeholders and conceptual value analysis identified as relevant for the system of interest (SOI)
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
|
|
ethics.
(1)
branch of knowledge or theory that investigates the correct reasons for thinking that this or that is right
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
(2)
principles of conduct governing an individual or group
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
|
|
ETL.
(1)
extract, transform, load
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
|
|
ETSI.
(1)
European Telecommunications Standards Institute
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.2)
|
|
EV.
(1)
earned value
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
EVA.
(1)
earned value analysis
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
evaluation.
(1)
systematic determination of the extent to which an entity meets its specified criteria
(ISO/IEC 25001:2014 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE)--Planning and management, 4.1)
(2)
action that assesses the value of something
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.7)
Example: the action by which an ODP system assigns a relative status to something, according to estimation by the system
Note: Value can be considered in terms of usefulness, importance, preference, acceptability, etc.; the evaluated target can be, for example, a credit rating, a system state, a potential behavior.
|
|
evaluation activity.
(1)
assessment of systems or software product against targeted values of identified and applicable quality characteristics performed using applicable techniques or methods
(ISO/IEC 25001:2014 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE)--Planning and management, 4.1)
|
|
evaluation checklist.
(1)
list of questions, each of which is designed to check for conformity of a product, process or service to one or more provisions within a particular International Standard
(ISO/IEC 14143-2:2011 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1, 3.2)
|
|
evaluation group.
(1)
organization responsible for specifying the systems and software quality requirements as well as managing and implementing the quality evaluation activities through the provision of technology, tools, experiences, and management skills
(ISO/IEC 25001:2014 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE)--Planning and management, 4.3)
Note: Software quality requirements can be specified previously by the requestor of the evaluation, so that the evaluation group can verify the presence and value of the software quality requirements.
|
|
evaluation method.
(1)
procedure describing actions to be performed by the evaluator in order to obtain results for the specified measurement applied to the specified product components or on the product as a whole
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.8)
|
|
evaluation module.
(1)
package of evaluation technology for measuring software quality characteristics, subcharacteristics, or attributes
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.9)
Note: The package includes evaluation methods and techniques, input to be evaluated, data to be measured and collected, and supporting procedures and tools.
|
|
evaluation module (EVM).
(1)
microcomputer module used in application development, e.g., to benchmark software, prototype applications, and debug algorithms for computer systems
(ISO/IEC/IEEE 24765d:2015)
|
|
evaluation procedure.
(1)
series of tasks and steps that, when completed, enable the evaluation team to determine if the product, process or service being evaluated is conformant to a particular standard
(ISO/IEC 14143-2:2011 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1, 3.3)
|
|
evaluation report.
(1)
system follow-up report that describes how the system objectives have been met, identifies the remaining problems, and is intended to assist future development
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
document that presents evaluation results and other information relevant to an evaluation
(ISO/IEC/IEEE 24765j:2021)
|
|
evaluation sponsor.
(1)
person or organization that requires the evaluation to be performed and provides financial or other resources to carry it out
(ISO/IEC 14143-2:2011 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1, 3.4)
|
|
evaluation technology.
(1)
techniques, processes, tools, measures and relevant technical information used for evaluation
(ISO/IEC 25001:2014 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE)--Planning and management, 4.3)
Example: internal, external or quality in use measures or specific evaluation processes designed for developers, acquirers or independent evaluators
Syn: technology used for evaluation
|
|
evaluation tool.
(1)
instrument that can be used during evaluation to collect data, to perform interpretation of data or to automate part of the evaluation
(ISO/IEC/IEEE 24765j:2021)
Example: source code analyzers to compute code metrics, CASE tools to produce formalized models, test environments to run the executable programs, checklists to collect inspection data, or spreadsheets to produce syntheses of measures
|
|
evaluator.
(1)
individual or organization that performs an evaluation
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.18)
(2)
competent person engaged in the verification or validation of a system or software
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.7)
Example: a testing laboratory, the quality department of a software development organization, a government organization, or a user
|
|
event.
(1)
fact that an action has taken place
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.4)
(2)
system behavior, support action, or other condition that can result in a mode change
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
(3)
occurrence or change of a particular set of circumstances
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.23)
(IEEE 7009-2024, Fail-Safe Design of Autonomous and Semi-Autonomous Systems, 3.1)
Note: The event can be certain or uncertain. The event can be a single occurrence or a series of occurrences, and can have several causes. The probability associated with the event can be estimated for a given period of time. An event can be an external interrupt, a timer expiration, an internal signal, or an internal message.
|
|
event history.
(1)
object representing significant actions
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 13.1.1.1)
|
|
event record.
(1)
notional data type representing the attributes of an event
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
event sequence analysis.
(1)
performance analysis of the sequence of tasks that are executed to service a given external event
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
event sequence diagram.
(1)
diagram that identifies the sequence of tasks required to process an external event
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
event sink.
(1)
operation interface consuming announcements carrying notifications of typed events
(ISO/IEC/IEEE 24765l:2024)
See Also: event source
|
|
event source.
(1)
operation interface originating notifications of events to event consumers or an event channel
(ISO/IEC/IEEE 24765l:2024)
See Also: event sink
|
|
event synchronization.
(1)
control of task activation by means of signals
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Three types of event synchronization are possible: external interrupts, timer expiration, and internal signals from other tasks.
|
|
event trace.
(1)
time-ordered description of each external input and the time at which it occurred
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
event-sequencing logic.
(1)
description of how a task responds to each of its message or event inputs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: in particular, what output is generated as a result of each input.
|
|
EVM.
(1)
earned value management
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
(2)
evaluation module
(ISO/IEC/IEEE 24765d:2015)
|
|
EVR.
(1)
ethical value requirement
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
|
|
examination.
(1)
mechanism that is part of the assessment, which measures a candidate's competence by one or more means such as written, oral, practical and observational, as defined in the certification scheme
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.10)
|
|
exception.
(1)
event that causes suspension of normal program execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Types include addressing exception, data exception, operation exception, overflow exception, protection exception, and underflow exception.
|
|
exception handling.
(1)
programming language mechanism that passes error information by throwing and catching exceptions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
exclusive requirement.
(1)
requirement of a normative document that is fulfilled in order to comply with that document
(ISO/IEC 14143-2:2011 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1, 3.5)
Note: deprecated: mandatory requirement. [ISO/IEC Guide 2:2004]
|
|
executable requirements specification.
(1)
software requirement specification that is represented in an executable requirements language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
executable source statement.
(1)
source statement that directs the actions of the computer at run time
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
executable statement.
(1)
statement which, when compiled, is translated into object code, which will be executed procedurally when the test item is running and can perform an action on program data
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.30)
|
|
execute.
(1)
to carry out an instruction, process, or computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
executing process group.
(1)
those processes performed to complete the work defined in the project management plan to satisfy the project requirements
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
execution efficiency.
(1)
degree to which a system or component performs its designated functions with minimum consumption of time
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: execution time, storage efficiency
|
|
execution time.
(1)
time which elapses between task submission and completion
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.7)
(2)
amount of elapsed time or processor time used in executing a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Processor time is usually less than elapsed time because the processor can be idle (for example, awaiting needed computer resources) or employed on other tasks during the execution of a program.
See Also: run time
|
|
execution trace.
(1)
record of the sequence of instructions executed during the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: often takes the form of a list of code labels encountered as the program executes
Syn: code trace, control flow trace
See Also: retrospective trace, subroutine trace, symbolic trace, variable trace
|
|
executor.
(1)
software that manages the running of a program, job, or steps on a designated platform
(ISO/IEC/IEEE 24765l:2024)
|
|
exhaustive testing.
(1)
test approach in which all combinations of input values and preconditions are tested
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.34)
Note: In nearly all non-trivial situations, exhaustive testing is impossible, due to the large number of possible tests.
|
|
existence constraint.
(1)
constraint stating that an instance of one entity cannot exist unless an instance of another related entity also exists
(ISO/IEC/IEEE 24765n:2025, 3.1.59)
Note: [key style]
|
|
existence dependency.
(1)
constraint between two related entities indicating that no instance of one can exist without being related to an instance of the other
(ISO/IEC/IEEE 24765n:2025, 3.1.60)
Example: null
Note: The following association types represent existence dependencies: identifying relationships, categorization structures and mandatory nonidentifying relationships.
|
|
existing software.
(1)
software that is already developed and available; is usable either "as is" or with modifications; and which is provided by the supplier, acquirer, or a third party
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
exit.
(1)
point in a software module at which execution of the module can terminate
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
data movement that moves a data group from a functional process across the boundary to the functional user that requires it
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.9)
Note: An exit is considered to account for certain associated data manipulations (e.g. formatting and routing associated with the data to be exited).
Syn: exit type
See Also: entry point, return
|
|
exit criteria.
(1)
states of being that have to be present before an effort can end successfully
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
review or audit elements to be assessed, completed, and have action items closed before successful completion of the technical review or audit can be declared
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.1)
See Also: entry criteria
|
|
exit point.
(1)
last executable statement within a test item
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.31)
Note: An exit point is a terminal point of a path through a test item, being an executable statement within the test item which either terminates the test item, or returns control to an external process. This is most commonly the last executable statement within the test item.
|
|
exit routine.
(1)
routine that receives control when a specified event, such as an error, occurs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
expandability.
(1)
degree of effort required to improve or modify software functions' efficiency
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: extendability
|
|
expected monetary value (EMV).
(1)
estimated value of an outcome expressed in monetary terms
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
expected results.
(1)
observable predicted behavior of the test item under specified conditions based on its specification or another source
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.32)
Syn: expected result
|
|
expected value.
(1)
estimated outcome that is as likely to be exceeded as not
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: the mean of the probability distribution, the point where the cumulative probability function equals 0.5
Syn: 50-50 estimate
|
|
expected value of perfect information.
(1)
in decision-tree analysis, the difference between the expected value of the decision tree and the value of the decision tree if all random outcomes were known in advance
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: helps the decision maker determine whether it is justifiable to invest in activities that would reduce uncertainties
|
|
experience.
(1)
extent to which users or stakeholders accumulate knowledge or skill acquired over time, especially that gained in a particular profession
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.2.3.1)
Example: Data analyses or replaying, simulating, or detecting similar or different patterns based on recorded weather data can help weather monitoring users to improve their knowledge or skills for weather forecasting.
|
|
experience-based testing.
(1)
class of test case design techniques based on using the experience of testers to generate test cases
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.33)
Example: error guessing
Note: Experience based testing can include concepts such as test attacks, tours, and error taxonomies which target potential problems such as security, performance, and other quality areas.
|
|
expert system (ES).
(1)
computer system that provides for expertly solving problems in a given field or application area by drawing inferences from a knowledge base developed from human expertise
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: Some expert systems are able to improve their knowledge base and develop new inference rules based on their experience with previous problems.
|
|
explainability.
(1)
ability to describe how an autonomous intelligent system makes decisions
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: Explanations can reflect both the procedures followed by the autonomous/intelligent system (A/IS), i.e., its inputs, methods, models, and outputs, and also the specific decisions that the A/IS made.
|
|
explanatory report.
(1)
document attached to a product for providing complementary information in order to assist understanding and to avoid inappropriate usage of the product
(ISO/IEC 29155-3:2015 Systems and software engineering--Information technology project performance benchmarking framework--Part 3: Guidance for reporting)
Note: Examples of an explanatory report are data element definitions, data demographics, data source information which are attached to benchmarking repositories or benchmarks. Examples of the product are benchmarking repository, benchmark(s), or software tools to support benchmarking activities.
|
|
explicit knowledge.
(1)
knowledge that can be codified using symbols such as words, numbers, and pictures
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
explicit requirement.
(1)
requirement expressed in writing, often using natural language or a semi-formal notation
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
exploitable.
(1)
characteristic of a vulnerability that can be activated in practice
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.36)
|
|
exploratory testing.
(1)
type of unscripted experience-based testing in which the tester spontaneously designs and executes tests based on the tester's existing relevant knowledge, prior exploration of the test item (including the results of previous tests), and heuristic "rules of thumb" regarding common software behaviors and types of failure
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 4.9)
Note: Exploratory testing hunts for hidden properties (including hidden behaviors) that, while quite possibly benign by themselves, can interfere with other properties of the software under test, and so constitute a risk that the software will fail.
|
|
export process.
(1)
process of generating a transfer file from a source environment
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.1)
|
|
exporter.
(1)
agent of the export process
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.1)
|
|
extend.
(1)
in UML, a relationship from an extending use case to a base use case, specifying how the behavior defined for the extending use case can be optionally inserted into the behavior defined for the base use case
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
extended entry table.
(1)
decision table where the conditions and actions are generally described but are incomplete
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.15)
Note: The specifications are completed by the values specified in the rules
|
|
extended process set.
(1)
set of processes specific to a maturity level higher than the basic maturity level that help ensure the achievement of the relevant process profile
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.5)
|
|
extensible markup language (XML).
(1)
license-free and platform-independent markup language that carries rules for generating text formats that contain structured data
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.15)
(2)
formal language used to specify the structure of XML documents
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.15)
(3)
platform-independent markup language that carries rules for generating text formats that contain structured data
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.14)
Note: specified in the XML Schema Part 1.1 Structures Recommendation
Syn: eXtensible Markup Language
|
|
EXtensible Style Language Transformations (XSLT).
(1)
language for transforming XML documents into other document types, such as PDF or HTML
(ISO/IEC/IEEE 24765l:2024)
Syn: extensible style language transformations
|
|
extensional set.
(1)
set containing the currently existing instances of a class
(ISO/IEC/IEEE 24765n:2025, 3.1.61)
Note: The instances in the extensional set correspond to the database and data modeling notion of instance.
Syn: current extent
|
|
extensive logical operation.
(1)
logical operation containing either a minimum of four nesting levels or more than 38 data element types required to operate the logical operation, or both
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.11)
Note: The data element types do not necessarily have to cross the application boundary.
|
|
extensive mathematical operation.
(1)
mathematical operation that includes one or more series of mathematical equations and calculations executed in conjunction with, or according to, logical operators, to produce results identifiable to the user
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.10)
Example: A program evaluation review technique (PERT) to calculate the expected completion date of a project
|
|
external.
(1)
input information source or output information destination that is outside the scope of the project life cycle
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
See Also: invocation, iteration, mapping
|
|
external attribute.
(1)
measurable property of an entity which can only be derived with respect to how it relates to its environment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: External attributes are those that relate to requirements (external properties of the software). External attributes can only be derived from the operational behavior of the system of which it is a part.
|
|
external dependency.
(1)
relationship between project activities and non-project activities
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
external event.
(1)
event from an external object, typically an interrupt from an external I/O device
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
external I/O device.
(1)
hardware input and/or output device that is outside the software system and part of the external environment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
external input (EI).
(1)
elementary process that processes data or control information sent from outside the boundary
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.27)
Note: The primary intent of an EI is to maintain one or more ILFs and/or to alter the behavior of the system. An external input is a type of base functional component.
See Also: external inquiry, external output
|
|
external inquiry (EQ).
(1)
elementary process that sends data or control information outside the boundary
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.28)
Note: The primary intent of an external inquiry is to present information to a user through the retrieval of data or control information from an ILF or EIF. The processing logic contains no mathematical formulas or calculations, and creates no derived data. No ILF is maintained during the processing, nor is the behavior of the system altered. An external inquiry is a type of base functional component.
See Also: external input, external output
|
|
external interface file (EIF).
(1)
user-recognizable group of logically related data or control information, which is referenced by the application being measured, but which is maintained within the boundary of another application
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.29)
Note: The primary intent of an EIF is to hold data referenced through one or more elementary processes within the boundary of the application counted. This means an EIF counted for an application is necessarily in an ILF in another application. An external interface file is a type of base functional component.
See Also: internal logical file, external logical file
|
|
external interface requirement.
(1)
system requirement that specifies a hardware, software, or database element with which a system or component interfaces, or that sets forth constraints on formats, timing, or other factors caused by such an interface
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
external measure.
(1)
indirect measure of a product derived from measures of the behavior of the system of which it is a part
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The number of failures found during testing is an external measure of the number of faults in the program, because the number of failures is counted during the operation of a computer system running the program. External measures can be used to evaluate quality attributes closer to the ultimate objectives of the design.
|
|
external measure of system or software quality.
(1)
measure of the degree to which a system or software product enables the behavior to satisfy stated and implied needs for the system, including the software to be used under specified conditions
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.11)
Example: The number of failures found during testing is an external measure of software quality related to the number of faults present in the computer system. The two measures are not necessarily identical since testing does not find all faults, and a fault can give rise to apparently different failures in different circumstances.
Note: Attributes of the behavior can be verified or validated by executing the system or software product during testing and operation.
|
|
external output (EO).
(1)
elementary process that sends data or control information outside the application's boundary and includes additional processing logic beyond that of an external inquiry
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.30)
Note: The primary intent of an external output is to present information to a user through processing logic other than, or in addition to, the retrieval of data or control information. The processing logic contains at least one mathematical formula or calculation, or create derived data. An external output can also maintain one or more ILFs and/or alter the behavior of the system. An external output is a type of base functional component.
See Also: external input, external inquiry
|
|
external quality.
(1)
extent to which a product satisfies stated and implied needs when used under specified conditions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
external service provider.
(1)
person or organization providing services commercially to external customers
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.41)
|
|
external variability.
(1)
variability that is visible to customers
(ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.4)
|
|
extractive approach.
(1)
approach of developing the initial baseline of a product line from one or more existing products
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.13)
|
|
extranet.
(1)
intranet that is accessible to authorized external users for the retrieval or exchange of information
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.7)
|
|
extreme programming.
(1)
form of agile software development in which procedures for iterative planning and working are combined with technical procedures, such as test-driven design and pair programming
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.24)
Syn: XP
|
|
F-profile.
(1)
Format and presentation profile
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
F1 score.
(1)
performance metric used to evaluate a classifier, which provides a balance (the harmonic average) between recall and precision
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.33)
Syn: F1-score
|
|
facet.
(1)
operation interface in which a computational component plays a server role
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.16)
Note: the primary vehicle through which a component exposes its functional application behavior to clients during normal execution
|
|
faceted search.
(1)
progressive search that allows users to narrow the results by selecting values for one or more attributes
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.15)
|
|
facility.
(1)
physical means or equipment for facilitating the performance of an action
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.26)
Example: buildings, instruments, tools
|
|
factoring.
(1)
decomposing a system into a hierarchy of modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
removing a function from a module and placing it into a module of its own
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: modular decomposition
|
|
factory.
(1)
object that, in response to an interaction initiated by its environment, creates a new object and returns a reference to it to the environment
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.25)
|
|
fail safe.
(1)
capability of a product to automatically place itself in a safe operating mode, or to revert to a safe condition in the event of a failure
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.9.3)
Example: a traffic light that reverts to blinking red in all directions when normal operation fails
Syn: fail-safe, failsafe
See Also: fail soft, fault secure, fault tolerance
|
|
fail soft.
(1)
pertaining to a system or component that continues to provide partial operational capability in the event of certain failures
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a traffic light that continues to alternate between red and green if the yellow light fails
See Also: fail safe, fault secure, fault tolerance
|
|
failure.
(1)
termination of the ability of a system to perform a required function or its inability to perform within previously specified limits; an externally visible deviation from the system's specification
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.4.9)
(2)
event in which any part of a system or system element does not perform as required by its specification
(INCOSE Systems Engineering Handbook, 5th ed.)
(3)
violation of a contract
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.6.1)
(4)
departure of system behavior from system requirements
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: A failure can be produced when a fault is encountered. The failure can occur at a value in excess of the minimum required in the specification, that is, past design limits or beyond the margin of safety.
|
|
failure intensity.
(1)
quantitative characterization of in-service reliability as a ratio of the number of observed failures to the duration of an observed span
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
See Also: failure rate
|
|
failure intensity objective (FIO).
(1)
failure intensity level to be achieved during pre-release testing as part of a systems release criteria
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
failure mode.
(1)
physical or functional manifestation of a failure
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: A system in failure mode is characterized by slow operation, incorrect outputs, or complete termination of execution.
|
|
failure mode and effect analysis (FMEA).
(1)
analytical procedure in which each potential failure mode in every component of a product is analyzed to determine its effect on the reliability of that component and, by itself or in combination with other possible failure modes, on the reliability of the product or system and on the required function of the component; or the examination of a product (at the system or lower levels) for all ways that a failure may occur. For each potential failure, an estimate is made of its effect on the total system and of its impact. In addition, a review is undertaken of the action planned to minimize the probability of failure and to minimize its effects.
(ISO/IEC/IEEE 24765h:2019)
|
|
failure rate.
(1)
ratio of the number of failures of a given category to a given unit of measure
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
rate of change in the number of failures per unit of time according to a model and its parameters
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Example: failures per unit of time, failures per number of transactions, failures per number of computer runs
Syn: failure ratio
See Also: failure intensity
|
|
failure severity.
(1)
step on a scale ranking the detrimental effect of failures
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
failure to acquire.
(1)
failure to accept for subsequent comparison the biometric sample of the biometric characteristic of interest output from the biometric capture process
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.17)
Note: Acceptance of the output of a biometric capture process for subsequent comparison depends on policy. Possible causes of failure to acquire include failure to capture, failure to extract, poor biometric sample quality, algorithmic deficiencies, and biometric characteristics outside the range of the system.
Syn: FTA
|
|
failure to capture.
(1)
failure of the biometric capture process to produce a captured biometric sample of the biometric characteristic of interest
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.19)
Note: The decision as to whether a biometric sample has been captured depends on system policy. For example, one system can use a low-quality fingerprint whereas another can declare it a failure to capture.
Syn: FTC
|
|
failure to enroll.
(1)
failure to create and store a biometric enrollment data record for an eligible biometric capture subject in accordance with a biometric enrollment policy
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.20)
Note: Not enrolling someone ineligible to enroll is not a failure to enroll.
Syn: FTE
|
|
failure to enroll rate.
(1)
proportion of a specified set of biometric enrolment transactions that resulted in a failure to enroll
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.21)
Note: Basing the denominator on the number of biometric enrollment transactions can result in a higher value than basing it on the number of biometric capture subjects. If the FTER is to measure solely transactions that fail to complete due to quality of the submitted biometric data, the denominator should not include transactions that fail due to non-biometric reasons (i.e. lack of eligibility due to age or citizenship).
Syn: failure-to-enroll rate
FTER
|
|
failure transparency.
(1)
distribution transparency which masks, from an object, the failure and possible recovery of other objects (or itself), to enable fault tolerance
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.4.1.2)
|
|
failure-to-acquire rate.
(1)
proportion of a specified set of biometric acquisition processes that were failures to acquire
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.18)
Note: The proportion is the number of processes that failed divided by the total number of biometric acquisition processes within the specified set. The results of the biometric acquisition processes may be biometric probes or biometric references. The experimenter specifies which biometric probe (or biometric reference) acquisitions are in the set, as well as the criteria for deeming a biometric acquisition process to have failed.
Syn: failure to acquire rate, FTAR
|
|
fairness.
(1)
equanimity, balanced and unbiased processes or outcomes
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
|
|
false accept rate.
(1)
proportion of verification transactions with false biometric claims erroneously accepted
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.22)
Syn: FAR
|
|
false match.
(1)
comparison decision of a match for a biometric probe and a biometric reference that are from different biometric capture subjects
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.23)
|
|
false match rate.
(1)
proportion of the completed biometric non-mated comparison trials that result in a false match
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.24)
Note: The value computed for the false match rate depends on thresholds and other parameters of the comparison process, and the protocol defining the biometric non-mated comparison trials."Completed" refers to the computational processes required to make a comparison decision, i.e. failures to decide are excluded.
Syn: FMR
|
|
false negative.
(1)
true defect that has not been observed
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.8)
(2)
incorrect reporting of a failure when in reality it is a pass
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.34)
See Also: false positive, true negative
|
|
false negative identification rate.
(1)
proportion of a specified set of identification transactions by capture subjects enrolled in the system for which the subjects correct reference identifier is not among those returned
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.25)
Note: The false negative identification rate can be expressed as a function of N, the number of enrollees, and of parameters of the identification process where only candidates up to rank R, and with a candidate score greater than threshold T are returned to the candidate list.
Syn: FNIR, FNIR (N, R, T), false-negative identification rate
|
|
false non-match.
(1)
comparison decision of non-match for a biometric probe and a biometric reference that are from the same biometric capture subject and of the same biometric characteristic
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.26)
Note: The decision accounts for how much non-conformance to system policy on the part of the biometric capture subject is tolerated before the biometric probe and the biometric reference are deemed to be of different biometric characteristics.
|
|
false non-match rate.
(1)
proportion of the completed biometric mated comparison trials that result in a false non-match
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.27)
Note: The value computed for the false non-match rate depends on thresholds and other parameters of the comparison process, and the protocol defining the biometric mated comparison trials. Completed refers to the computational processes required to make a comparison decision, i.e. failures to decide are excluded.
Syn: FNMR
|
|
false positive.
(1)
observed defect which does not correspond to a true defect
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.9)
(2)
incorrect reporting of a pass when in reality it is a failure
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.35)
Note: False positives can appear during the analysis of an application due to lack of precision of the analysis rules.
See Also: false negative, true positive
|
|
false positive identification rate.
(1)
proportion of identification transactions by capture subjects not enrolled in the system, where an identifier is returned
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.28)
Note: The false positive identification rate can be expressed as a function of parameters of the identification process for returning matched reference identifiers, including comparison score threshold (T), and the number of enrollees in the system (N).
Syn: false-positive identification rate, FPIR, FPIR (N, T)
|
|
false reject rate.
(1)
proportion of verification transactions with true biometric claims erroneously rejected
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.29)
Syn: FRR
|
|
families of programs.
(1)
sets of programs that are related by sharing significant portions of requirements, design, and code
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: A program family can include one version of a program developed for an English-speaking audience, a second version of a program developed for a German-speaking audience, and a third version for a Japanese-speaking audience.
|
|
family of platforms.
(1)
software platforms that are serving the same purpose
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.16)
Example: operating systems, browsers
|
|
FAQ.
(1)
frequently asked question
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.2)
|
|
FAR.
(1)
false accept rate
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.22)
|
|
FAS.
(1)
failure at source
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
FAST.
(1)
function analysis system technique
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
fast tracking.
(1)
schedule compression method in which activities or phases normally done in sequence are performed in parallel for at least a portion of their duration
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: schedule compression, crashing
|
|
fatal error.
(1)
error that results in the complete inability of a system or component to function
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
fault.
(1)
manifestation of an error in software
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
defect in a system or a representation of a system that if executed or activated can result in an error
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.4.6)
(3)
situation that can cause errors to occur in an object
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.6.3)
(4)
defect in a hardware device or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: A fault, if encountered, can cause a failure. Faults can occur in specifications when they are not correct.
Syn: bug
|
|
fault dictionary.
(1)
a list of faults in a system or component, and the tests that have been designed to detect them
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
fault isolation.
(1)
ability of a subsystem to prevent a fault within the subsystem from causing consequential faults in other subsystems
(ISO/IEC/IEEE 24765c:2014)
|
|
fault masking.
(1)
condition in which one fault prevents the detection of another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
fault secure.
(1)
pertaining to a system or component in which no failures are produced from a prescribed set of faults
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: fault tolerance, fail-safe, fail soft
|
|
fault tolerance.
(1)
capability of a product to operate as intended despite the presence of hardware or software faults
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.5.3)
See Also: error tolerance, fail safe, fail soft, fault secure, robustness
|
|
fault-tolerant.
(1)
pertaining to a system or component that is able to continue normal operation despite the presence of faults
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: fault tolerant
|
|
faultlessness.
(1)
capability of a product to perform specified functions without fault under normal operation
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.5.1)
|
|
FCA.
(1)
functional configuration audit
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
|
|
FD.
(1)
full deployment
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
FDT.
(1)
formal description techniques
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
feasibility.
(1)
degree to which the requirements, design, or plans for a system or component can be implemented under existing constraints
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
feasibility study.
(1)
study to identify and analyze a problem and its potential solutions in order to determine their viability, costs, and benefits
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
feature.
(1)
functional or non-functional distinguishing characteristic of a system
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.9)
(2)
abstract functional characteristic of a system of interest that end-users and other stakeholders can understand
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.14)
(3)
characteristic of a member product in a product line that distinguishes it from other member products in the product line
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.4)
(4)
set of related requirements or functionalities that provides value to an organization
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: Features are considered to add value for the user. Features can a) express the customer-visible or end-user-visible variability among the member products in a product line, or b) distinguish implementation variability not directly visible to a customer or end user except through non-functional differences such as price, performance, noise, weight, energy and more. In feature-based product line engineering, features express differences among member products. A capability or other characteristic common to all member products in the product line is not modeled as a feature.
|
|
feature branch.
(1)
branch created for developing a particular set of features
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The branch is typically not released but is collapsed back at some point to its parent branch.
|
|
feature catalog.
(1)
model of the collection of all the feature options and feature constraints available across the entire product line
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.5)
Syn: feature catalogue
|
|
feature constraint.
(1)
formal relationship between two or more features that is necessarily satisfied for all member products
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.6)
|
|
feature engineering.
(1)
in machine learning, activity in which those attributes in the raw data that best represent the underlying relationships that should appear in the model are identified for use in the training data
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.36)
Syn: feature selection
|
|
feature freeze.
(1)
period during which no new features are added to a specific branch
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: allows the branch to stabilize for a release.
|
|
feature language.
(1)
syntax and semantics for the formal representation, structural taxonomy, and relationships among the concepts and constructs in the feature catalogue, bill-of-features portfolio, and shared asset superset variation points
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.7)
|
|
feature reference.
(1)
expression that unambiguously identifies a diagram feature in a diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.48)
|
|
FEP.
(1)
front-end processor
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
fetch.
(1)
to locate and load computer instructions or data from storage
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: move, store
|
|
FF.
(1)
finish-to-finish
(ISO/IEC/IEEE 24765n:2025)
(2)
file formatter
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
FFBD.
(1)
functional flow block diagram
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
FFP.
(1)
firm fixed price
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
FIDO.
(1)
fast identity online
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
field of application (of a specification).
(1)
properties of the environment of the ODP system that allow the specification of that system to be used
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.1.2)
|
|
field programmable gate array (FPGA).
(1)
logic device designed to be programmed after it is acquired
(ISO/IEC/IEEE 24765d:2015)
Note: often based on look-up table architecture
|
|
fieldbus.
(1)
industrial computer network protocol used for real-time distributed control
(ISO/IEC/IEEE 24765d:2015)
Note: a family of related standardized interfaces
|
|
FIF.
(1)
fusion information format
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
FIFO.
(1)
special kind of queue that is operated first in first out
(ISO/IEC 15909-3:2021. Systems and software engineering--High-level Petri nets--Part 3: Extensions and structuring mechanisms, 3.3)
|
|
fifth-generation language (5GL).
(1)
computer language that incorporates the concepts of knowledge-based systems, expert systems, inference engines, and natural language processing
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assembly language, fourth-generation language, high-order language, machine language
|
|
FIGS.
(1)
French, Italian, German, and Spanish
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)
|
|
figurative constant.
(1)
data name that is reserved for a specific constant in a programming language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: The data name THREE is reserved to represent the value 3.
See Also: literal
|
|
file.
(1)
set of related records treated as a unit
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
named set of records stored or processed as a unit
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Example: In stock control, a file can consist of a set of invoice records.
|
|
file type referenced (FTR).
(1)
data function read or maintained by a transactional function
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.31)
Note: A file type referenced (FTR) includes an internal logical file read or maintained by a transactional function, or an external interface file read by a transactional function. Code data is grouped into one additional FTR.
|
|
final transfer set.
(1)
collection of changed objects that are to be transferred integrally to one or more production environments, including implementation instructions
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.18)
|
|
financial independence.
(1)
of software quality assurance (SQA), situation in which control of the SQA budget is vested in an organization independent of the development organization
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
|
|
finish-to-finish (FF).
(1)
constraint in which one activity cannot finish unless another activity is finished
(ISO/IEC/IEEE 24765n:2025)
|
|
finish-to-start (FS).
(1)
constraint in which one activity cannot start unless another activity has finished
(ISO/IEC/IEEE 24765n:2025)
|
|
finite state machine.
(1)
computational model consisting of a finite number of states and transitions between those states, possibly with accompanying actions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
FIO.
(1)
failure intensity objective
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
FIPP.
(1)
fair information practice principles
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
firm-fixed-price (FFP) Contract.
(1)
type of fixed price contract where the buyer pays the seller a set amount (as defined by the contract), regardless of the seller's costs
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
firm-fixed-price contract (FFP).
(1)
type of fixed price contract where the buyer pays the seller a set amount (as defined by the contract), regardless of the seller's costs
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: firm fixed price contract
FFP contract
|
|
firmware.
(1)
ordered set of instructions and associated data stored in a way that is functionally independent of main storage, usually in read-only memory
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.27)
(2)
combination of a hardware device and computer instructions and data that reside as read-only software on that device
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
Note: The software cannot be readily modified under program control.
|
|
first input routine.
(1)
those activities required to obtain the logical record, if any, to be processed first
(ISO/IEC/IEEE 24765a:2011)
|
|
FiSMA.
(1)
Finnish Software Measurement Association
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, A.10)
Note: a network of Finnish companies, which share interest in developing software measurement and/or software processes.
|
|
fitness for purpose.
(1)
Assurance that a system, service or algorithm meets its agreed requirements, and performs reliably
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
|
|
fixed cost.
(1)
cost that is not dependent on the rate of production
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: such as facilities cost or loan interest
See Also: variable cost
|
|
fixed duration.
(1)
type of activity where the length of time required to complete the activity remains constant regardless of the number of people or resources assigned to the activity
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
fixed formula method.
(1)
earned value method for assigning a specified percentage of budget value of a work package to the start milestone of the work package with the remaining budget value percentage assigned when the work package is complete
(ISO/IEC/IEEE 24765h:2019)
|
|
fixed price with economic price adjustment contract (FP-EPA).
(1)
fixed-price contract, but with a special provision allowing for pre-defined final adjustments to the contract price due to changed conditions, such as inflation changes, or cost increases (or decreases) for specific commodities
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
fixed-cost analysis.
(1)
analysis that seeks to maximize the effectiveness that can be attained from a fixed, maximum investment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: fixed-effectiveness analysis
|
|
fixed-effectiveness analysis.
(1)
analysis that seeks to minimize the investment needed to attain a fixed, minimum degree of effectiveness
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: fixed-cost analysis
|
|
fixed-price contract.
(1)
agreement that sets the amount that will be paid for a defined scope of work regardless of the cost or effort to deliver it
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: fixed price contract, fixed-price contracts
|
|
fixed-price-incentive-fee (FPIF) contract.
(1)
type of contract where the buyer pays the seller a set amount (as defined by the contract), and the seller can earn an additional amount if the seller meets defined performance criteria
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: fixed price incentive fee contract
|
|
flag.
(1)
variable that is set to a prescribed state, often 'true' or 'false,' based on the results of a process or the occurrence of a specified condition
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: indicator, semaphore
|
|
flash memory.
(1)
larger and faster programmable ROM which allows data to be electrically erased from memory and rewritten many times
(ISO/IEC/IEEE 24765c:2014)
Syn: NVRAM, non-volatile random access memory
See Also: EEPROM
|
|
flexibility.
(1)
ability of a system to work in contexts outside its initial specification (i.e. change its behavior according to its actual situation to satisfy its objectives)
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.37)
(2)
capability of a product to be adapted to changes in its requirements, contexts of use, or system environment
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.8)
(3)
degree to which a product or system can be used with acceptable levels of effectiveness, efficiency, freedom from risk and satisfaction in contexts beyond those initially specified in the requirements
(ISO/IEC 25022:2016, Systems and software engineering -- Systems and software quality requirements and evaluation (SQuaRE) -- Measurement of quality in use, 4.7)
Note: Flexibility enables products to adapt to circumstances, opportunities and individual preferences that had not been anticipated in advance. Flexibility can refer to the technical environment (platform), the social environment, or the physical environment. If a product is not designed for flexibility, it can be unsafe to use the product in unintended contexts.
See Also: adaptability, maintainability
|
|
flip-flop.
(1)
electronic circuit with one or two stable states
(ISO/IEC/IEEE 24765c:2014)
Note: can be used to store 0 or 1 as digital data
Syn: latch
|
|
float.
(1)
amount of unscheduled time between sequential activities not on the critical path, which can be used to delay the completion of the earlier activity or advance the start of the later activity
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: slack
See Also: free float, total float
|
|
flow.
(1)
abstraction of a sequence of interactions, resulting in conveyance of information from a producer object to a consumer object
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.)
(2)
measure of how efficiently work moves through a given process or framework
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Example: multimedia data broadcast
Note: A flow can be used to abstract over, for example, the exact structure of a sequence of interactions, or over a continuous interaction including the special case of an analogue information flow.
|
flowchart.
(1)
graphical representation of a process or the step-by-step solution of a problem, using suitably annotated geometric figures connected by flowlines for the purpose of designing or documenting a process or program
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
graphical representation of the definition, analysis, or method of solution of a problem in which symbols are used to represent operations, data, flow, equipment, etc
(ISO 5807:1985 Information processing -- Documentation symbols and conventions for data, program and system flowcharts, program network charts and system resources charts, 3.3)
(3)
control flow diagram in which suitably annotated geometrical figures are used to represent operations, data, or equipment, and arrows are used to indicate the sequential flow from one to another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
the depiction in a diagram format of the inputs, process actions, and outputs of one or more processes within a system
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: flow chart, flow diagram
See Also: block diagram, box diagram, bubble chart, graph, input-process-output chart, structure chart
 |
|
flowcharter.
(1)
software tool that accepts as input a design or code representation of a program and produces as output a flowchart of the program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
FMEA.
(1)
failure mode and effect analysis
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
FMECA.
(1)
failure mode, effects, and criticality analysis
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
FMR.
(1)
false match rate
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.24)
|
|
FNIR.
(1)
false negative identification rate
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.25)
Syn: FNIR(N, R, T)
|
|
FNMR.
(1)
false non-match rate
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.27)
|
|
FNR.
(1)
false negative rate
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
FOAF.
(1)
friend of a friend
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.2)
|
|
FOC.
(1)
full operational capability
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
footer.
(1)
material repeated at the bottom of each page
(ISO/IEC/IEEE 24765a:2011)
Example: section title
|
|
For Exposition Only (FEO) page.
(1)
model page that contains pictorial and graphical information (in contrast to text) about a specific diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.51)
Note: Unlike a diagram, the contents of a For Exposition Only page (FEO page) need not comply with IDEF0 rules.
|
|
forecast.
(1)
estimate or prediction of conditions and events in the project's future based on information and knowledge available at the time of the forecast
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: The forecast is based on the project's past performance and expected future performance, and includes information that cam impact the project, such as estimate at completion and estimate to complete.
|
|
foreground.
(1)
in job scheduling, the computing environment in which high-priority processes or those requiring user interaction are executed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: background, foreground processing
|
|
foreground processing.
(1)
execution of a high-priority process while lower priority processes await the availability of computer resources, or the execution of processes that require user interaction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: background processing
|
|
foreign key.
(1)
attribute, or combination of attributes, of a child or category entity instance whose values match those in the primary key of a related parent or generic entity instance
(ISO/IEC/IEEE 24765n:2025, 3.1.62)
Note: A foreign key results from the migration of the parent or generic entity's primary key through a generalization structure or a relationship. [key style]
Syn: migrated key
|
|
forking action.
(1)
dividing action, where the enabled chains (subject to failure) eventually join each other, i.e., the enabled chains cannot join other chains and they cannot terminate separately
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.1.5)
|
|
form.
(1)
module or formulary to collect data
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.20)
Note: It can be paper-based (paper form) or digital.
|
|
form, fit, and function.
(1)
in configuration management, that configuration comprising the physical and functional characteristics of an item as an entity, but not including any characteristics of the elements making up the item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: configuration identification
|
|
formal design.
(1)
use of rigorous mathematical methods to specify a software design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
formal evaluation process.
(1)
structured approach to evaluating alternative solutions against established criteria to determine a recommended solution to address an issue
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
formal language.
(1)
language whose rules are explicitly established prior to its use
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Example: programming languages and mathematical languages
Syn: artificial language
See Also: natural language
|
|
formal parameter.
(1)
variable used in a software module to represent data or program elements that are to be passed to the module by a calling module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: argument
|
|
formal qualification review (FQR).
(1)
test, inspection, or analytical process by which a group of configuration items comprising a system is verified to have met specific contractual performance requirements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: code review, design review, requirements review, test readiness review
|
|
formal requirements language.
(1)
artificial language used to represent a software requirement
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The resulting formal requirements can be proven "correct" through proof-of-correctness methods.
Syn: verifiable requirements language
|
|
formal review.
(1)
form of review that follows a defined process with formal documented output
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.5)
|
|
formal specification.
(1)
specification that is used to prove mathematically the validity of an implementation or to derive mathematically the implementation
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
specification written in a formal notation, often for use in proof of correctness
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
specification written and approved in accordance with established standards
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
formal testing.
(1)
testing conducted in accordance with test plans and procedures that have been reviewed and approved by a customer, user, or designated level of management
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: informal testing
|
|
formal verification.
(1)
activity proving or disproving the correctness of intended applications with respect to a formal specification or a property, using formal methods of mathematics
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.10)
|
|
formalization.
(1)
precise description of the semantics of a language in terms of a formal language such as first order logic
(ISO/IEC/IEEE 24765n:2025, 3.1.63)
|
|
formative construct.
(1)
construct that is formed from its observed measures in the relationship between a construct and its measures
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.7)
Note: The construct is a consequence of its measures and each measure is a determinant of the construct.
|
|
formative evaluation.
(1)
evaluation designed and used to improve the object of evaluation, especially when it is still being developed
(ISO/IEC 25022:2016, Systems and software engineering -- Systems and software quality requirements and evaluation (SQuaRE) -- Measurement of quality in use, 4.8)
|
|
forward recovery.
(1)
reconstruction of a file to a given state by updating an earlier version, using data recorded in a chronological record of changes made to the file
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
type of recovery in which a system, program, database, or other system resource is restored to a new, not previously occupied state in which it can perform required functions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
FOSS.
(1)
free and open source software
(ISO/IEC/IEEE 41062:2024, Software engineering Life cycle processes Software acquisition, 3.2)
|
|
four-address instruction.
(1)
computer instruction that contains four address fields
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: an instruction to add the contents of locations A, B, and C, and place the result in location D
See Also: one-address instruction, two-address instruction, three-address instruction, zero-address instruction
|
|
four-plus-one address instruction.
(1)
computer instruction that contains five address fields, the fifth containing the address of the instruction to be executed next
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: an instruction to add the contents of locations A, B, and C, place the results in location D, then execute the instruction at location E
See Also: one-plus-one address instruction, two-plus-one address instruction, three-plus-one address instruction
|
|
fourth-generation language (4GL).
(1)
computer language designed to improve the productivity achieved by high-order (third-generation) languages and, often, to make computing power available to non-programmers
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: Features typically include an integrated database management system, query language, report generator, screen definition facility, graphics generator, decision support function, financial modeling, spreadsheet capability, and statistical analysis functions.
See Also: machine language, assembly language, high order language, fifth-generation language
|
|
FP.
(1)
function point
(ISO/IEC/IEEE 24765n:2025)
(2)
fixed price
(ISO/IEC/IEEE 24765n:2025)
|
|
FP-EPA.
(1)
fixed price with economic price adjustment
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: FPEPA
|
|
FPA.
(1)
function point analysis
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 4)
|
|
FPGA.
(1)
field programmable gate array
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
FPIF.
(1)
fixed price incentive fee
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
FPIR.
(1)
false positive identification rate
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.28)
Syn: FPIR(N, T)
|
|
FPR.
(1)
false positive rate
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
FQR.
(1)
formal qualification review
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
FRACAS.
(1)
failure reporting and corrective action system
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
frame.
(1)
element that divides a browser window into independent windows for displaying different content or different parts of the same content (document)
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.9)
|
|
frame a concern.
(1)
shape, compose, give expression to concerns
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.8)
Note: It is used to distinguish the stages of framing concerns by a viewpoint from addressing those concerns in a resulting view. This is analogous to the distinction between framing a problem and solving that problem.
|
|
framework.
(1)
reusable design (models or code) that can be refined (specialized) and extended to provide some portion of the overall functionality of many applications
(ISO/IEC/IEEE 24765n:2025, 3.1.64)
(2)
for a component content management system, essential data structures, operations, and rules that form the foundation from which all other features of the CCMS are built
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.16)
|
|
free float.
(1)
available slack between the scheduled completion date of a task and the scheduled start date of a successor task
(ISO/IEC/IEEE 24765n:2025)
See Also: total float
|
|
freedom from economic risk.
(1)
extent to which a product or system mitigates the potential risk to financial status, efficient operation, commercial property, reputation, or other aspects in the intended contexts of use
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.2.2)
|
|
freedom from environmental and societal risk.
(1)
extent to which a product or system mitigates the potential risk to the environment and society at large in the intended contexts of use
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.2.2.2)
|
|
freedom from health risk.
(1)
extent to which a product or system mitigates the potential risk to peoples health in the intended contexts of use
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.2.2.3)
|
|
freedom from human life risk.
(1)
extent to which a product or system mitigates the potential risk to peoples lives in the intended contexts of use
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.2.2.4)
|
|
freedom from risk.
(1)
extent to which a product or system mitigates the potential risk to economic status, human life, health, society, financial values, enterprise activities, or the environment
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.2.2)
(2)
degree to which the quality of a product or system mitigates or avoids the potential risk to economic status, human life, health, or the environment
(ISO/IEC 25022:2016, Systems and software engineering -- Systems and software quality requirements and evaluation (SQuaRE) -- Measurement of quality in use, 4.9)
Note: Freedom from risk includes reduction of potential risks to the user, organization or project.
See Also: risk
|
|
front matter.
(1)
material that comes at the front of a printed book or manual, such as the title page and table of contents
(ISO/IEC/IEEE 24765a:2011)
|
|
frozen branch.
(1)
branch where no development takes place, either in preparation for a release or because active development has ceased on it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
FRP.
(1)
full-rate production
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
FS.
(1)
finish-to-start
(ISO/IEC/IEEE 24765n:2025)
|
|
FSM method.
(1)
a specific implementation of FSM defined by a set of rules
(ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 3.4)
Syn: FSMM
|
|
FSMM.
(1)
functional size measurement method
(ISO/IEC 14143-6:2012 Information technology--Software measurement--Functional size measurement--Part 6: Guide for use of ISO/IEC 14143 series and related International Standards, 2)
|
|
FTAR.
(1)
failure to acquire rate
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.18)
|
|
FTC.
(1)
failure to capture
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.19)
|
|
FTE.
(1)
failure to enroll
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.20)
|
|
FTER.
(1)
failure-to-enroll rate
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.21)
|
|
FTP.
(1)
File Transfer Protocol
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
FTR.
(1)
file type referenced
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 4)
|
|
full duplex.
(1)
able to communicate data in both directions simultaneously
(ISO/IEC/IEEE 24765d:2015)
See Also: half duplex
|
|
function.
(1)
a task, action, or activity that must be accomplished to achieve a desired outcome.
(2)
defined objective or characteristic action of a system or component
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.23)
(3)
software module that performs a specific action, is invoked by the appearance of its name in an expression, receives input values, and returns a single value
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
transformation of inputs to outputs, by means of some mechanisms, and subject to certain controls, that is identified by a function name and modeled by a box
(ISO/IEC/IEEE 24765m:2024)
(5)
single-valued mapping
(ISO/IEC/IEEE 24765l:2024)
|
|
function name.
(1)
active verb or verb phrase that describes what is to be accomplished by a function
(ISO/IEC/IEEE 24765m:2024, 2.1.54)
Note: A box takes as its box name the function name of the function represented by the box.
|
|
function point (FP).
(1)
unit of measure for functional size
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.25)
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.18)
(2)
estimate of the amount of business functionality in an information system, used to calculate the functional size measurement of a software system
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
function point analysis (FPA).
(1)
method for measuring functional size
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.36)
(2)
a form of functional size measurement (FSM) that measures the functional size of software development, enhancement and maintenance activities associated with business applications, from the customer's point of view
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
|
|
function point count.
(1)
activity of applying rules to measure the functional size of an application or project
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.37)
Note: Three types of function point count are application, development project, and enhancement project.
|
|
function type.
(1)
type of base functional component identified in ISO/IEC 20926:2009
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.38)
Note: The five function types are External Input, External Output, External Inquiry, Internal Logical File and External Interface File or External Logical File.
|
|
function-oriented design.
(1)
partitioning of a design into subsystems and modules, with each one handling one or more functions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: object-oriented design, data-structure-oriented design
|
|
functional adaptability.
(1)
degree to which an AI system can accurately acquire information from data, or the result of previous actions, and use that information in future predictions
(ISO/IEC 25059:2023, Software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model for AI systems, 3.2.2)
|
|
functional analysis.
(1)
systematic investigation of the functions of a real or planned system
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
examination of a defined function to identify all the subfunctions necessary to accomplish that function, to identify functional relationships and interfaces (internal and external) and capture these in a functional architecture, to flow down upper-level performance requirements and to assign these requirements to lower-level subfunctions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
functional appropriateness.
(1)
capability of a product to provide functions that facilitate the accomplishment of specified tasks and objectives
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.1.3)
Example: A product provides the necessary and sufficient steps to complete a task, excluding any unnecessary steps.
Note: Functional appropriateness corresponds to suitability for the task.
|
|
functional architecture.
(1)
arrangement of functions and their subfunctions and interfaces (internal and external) that defines the execution sequencing, conditions for control or data flow, and the performance requirements to satisfy the requirements baseline
(ISO/IEC/IEEE 24765f:2016)
(2)
hierarchical arrangement of functions, their internal and external (external to the aggregation itself) functional interfaces and external physical interfaces, their respective functional and performance requirements, and their design constraints
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
functional baseline.
(1)
description of the system's performance (functional, interoperability, and interface characteristics) and the verification required to demonstrate the achievement of those specified characteristics
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.1)
See Also: allocated baseline, developmental configuration, product baseline
|
|
functional cohesion.
(1)
type of cohesion in which the tasks performed by a software module all contribute to the performance of a single function
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: coincidental cohesion, communicational cohesion, logical cohesion, procedural cohesion, sequential cohesion, temporal cohesion
|
|
functional completeness.
(1)
capability of a product to provide a set of functions that covers all the specified tasks and intended users objectives
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.1.1)
|
|
functional complexity.
(1)
specific complexity rating assigned to a function using defined rules
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.32)
|
|
functional configuration audit (FCA).
(1)
audit conducted to verify that the development of a configuration item has been completed satisfactorily, that the item has achieved the performance and functional characteristics specified in the functional or allocated configuration identification, and that its operational and support documents are complete and satisfactory
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(2)
evaluation to help ensure that the product meets baseline functional and performance capabilities
(INCOSE Systems Engineering Handbook, 5th ed.)
See Also: configuration management, physical configuration audit
|
|
functional configuration identification.
(1)
in configuration management, the current approved technical documentation for a configuration item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: It prescribes all necessary functional characteristics, the tests required to demonstrate achievement of specified functional characteristics, the necessary interface characteristics with associated configuration items, the configuration item's key functional characteristics and its key lower-level configuration items, if any, and design constraints.
See Also: allocated configuration identification, product configuration identification functional baseline
|
|
functional correctness.
(1)
capability of a product to provide accurate results when used by intended users
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.1.2)
Note: Precision is one of the attributes of correctness. AI systems, and particularly those using machine learning models, do not usually provide functional correctness in all observed circumstances.
|
|
functional decomposition.
(1)
type of modular decomposition in which a system is broken down into components that correspond to system functions and subfunctions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
in software engineering, the partitioning of higher-level system functions into smaller and smaller pieces to render them more manageable and understandable
See Also: hierarchical decomposition, stepwise refinement
|
|
functional design.
(1)
specification of the functions of the components of a system and of the working relationships among them
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
See Also: architectural design
|
|
functional domain.
(1)
class of software based on the characteristics of functional user requirements which are pertinent to FSM
(ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 3.5)
(2)
categorized functions that are generally used together
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.16)
|
|
functional domain categorization (FDC).
(1)
process for identifying functional domains
(ISO/IEC TR 14143-5:2004 Information technology -- Software measurement -- Functional size measurement -- Part 5: Determination of functional domains for use with functional size measurement, 3.2)
|
|
functional language.
(1)
programming language used to express programs as a sequence of functions and function calls
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: LISP
|
|
functional manager.
(1)
someone with management authority over an organizational unit within a functional organization, the manager of any group that actually makes a product or performs a service
(ISO/IEC/IEEE 24765h:2019)
Syn: line manager
|
|
functional process.
(1)
elementary component of a set of functional user requirements, comprising a unique, cohesive and independently executable set of data movements
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.10)
(2)
an elementary component of a set of Functional User Requirements, comprising a unique, cohesive and independently executable set of data or data movements (functional services)
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, A.11)
Note: It is triggered by a data movement (an Entry) from a functional user that informs the piece of software that the functional user has identified a triggering event, and is complete when it has executed all that is required to be done in response to the triggering event.
Syn: functional process type, transactional process
|
|
functional requirement.
(1)
statement that identifies what results a product or process produces
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
(2)
requirement that specifies a function that a system or system component performs
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
(3)
statement that identifies what results a system produces
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
See Also: nonfunctional requirement
|
|
functional service.
(1)
base functional component (BFC)
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, 3.6)
(2)
service that is implemented in the piece of software in order to fulfill functional user requirements
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, A.9)
|
|
functional size.
(1)
size of the software derived by quantifying the functional user requirements
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.33)
(ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 3.6)
Syn: FS, number of function points
|
|
functional size measurement (FSM).
(1)
process of measuring functional size
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.11)
(ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 3.7)
|
|
functional size measurement method.
(1)
specific implementation of FSM defined by a set of rules
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.12)
Syn: FSMM, FSM method
|
|
functional specification.
(1)
document that specifies the required actions, from the user's point of view, that a system or component performs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: often part of a requirements specification
|
|
functional suitability.
(1)
capability of a product to provide functions that meet stated and implied needs of intended users when it is used under specified conditions
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.1)
Note: Functional suitability is concerned with whether the functions meet not only stated and implied needs, but also the functional specification.
|
|
functional system design.
(1)
specification of the functions of the components of a software system and of the working relationships between them
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.19)
|
|
functional testing.
(1)
testing that ignores the internal mechanism of a system or component and focuses solely on the outputs generated in response to selected inputs and execution conditions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
testing conducted to evaluate the compliance of a system or component with specified functional requirements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: black-box testing
See Also: structural testing, specification-based testing
|
|
functional unit.
(1)
entity of hardware or software, or both, capable of accomplishing a specified purpose
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
functional user.
(1)
user that is a sender or an intended recipient of data in the Functional User Requirements of a piece of software
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.13)
|
|
functional user requirements (FUR).
(1)
subset of the user requirements describing what the software does in terms of tasks and services
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.14)
(ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 3.8)
Note: Functional User Requirements include but are not limited to data transfer (for example Input customer data, Send control signal); data transformation (for example Calculate bank interest, Derive average temperature); data storage (for example Store customer order, Record ambient temperature over time); data retrieval (for example List current employees, Retrieve aircraft position). User Requirements that are not Functional User Requirements include but are not limited to: quality constraints (for example usability, reliability, efficiency and portability); organizational constraints (for example locations for operation, target hardware and compliance to standards); environmental constraints (for example interoperability, security, privacy and safety); implementation constraints (for example development language, delivery schedule).
|
|
functionality.
(1)
set of capabilities, such as features, mechanisms, services, or procedures, allowable and actionable by the system
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
Note: This characteristic is concerned with what the software does to fulfill needs. The software quality characteristic functionality can be used to specify or evaluate the suitability, accuracy, interoperability, security, and compliance of a function.
|
|
FUR.
(1)
functional user requirement (s)
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.14)
(ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 4)
|
|
fuse ROM.
(1)
programmable ROM with written data based on a fuse connection state
(ISO/IEC/IEEE 24765c:2014)
Example: If the normal state of the fuse means logic "1", the breaking state is "0."
|
|
future worth.
(1)
representation of a cash flow as a single instance at the end of the planning horizon
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: annual equivalent, present worth
|
|
fuzz testing.
(1)
software testing approach in which high volumes of random (or near-random) data, called fuzz, are used to generate inputs to the test item
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.38)
|
|
GAN.
(1)
generative adversarial networks
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
Gantt chart.
(1)
bar chart of schedule information where activities are listed on the vertical axis, dates are shown on the horizontal axis, and activity durations are shown as horizontal bars placed according to start and finish dates
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
garbage collection.
(1)
in computer resource management, a synonym for memory compaction (1)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
GDPR.
(1)
General Data Protection Regulation
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.2)
|
|
gemba.
(1)
observation of work processes actually in use
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.15)
|
|
general artificial intelligence.
(1)
artificial intelligence that exhibits intelligent behavior comparable to a human across the full range of cognitive abilities
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.39)
Syn: general AI, strong artificial intelligence, strong AI
|
|
General Data Protection Regulation.
(1)
European regulation that standardizes the rules for processing personal data by private businesses and government bodies in the European Union
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.27)
Syn: GDPR
|
|
general purpose input/output port (GPIO).
(1)
generic pin (port) on a microcomputer whose function (whether it is an input or output pin) is not predefined and is user-controlled
(ISO/IEC/IEEE 24765d:2015)
Syn: general-purpose input output port
|
|
general register.
(1)
register that stores both addresses and data
(ISO/IEC/IEEE 24765e:2015)
|
|
general system characteristics (GSCs).
(1)
terminology for technical complexity adjustment factors
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
|
|
generality.
(1)
degree to which a system or component performs a broad range of functions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: reusability
|
|
generalization.
(1)
taxonomy in which instances of both entities represent the same real or abstract thing
(ISO/IEC/IEEE 24765n:2025, 3.1.66)
Note: One entity (the generic entity) represents the complete set of things and the other (category entity) represents a subtype or sub-classification of those things. The category entity can have one or more attributes, or relationships with instances of another entity, not shared by all generic entity instances. Each instance of the category entity is simultaneously an instance of the generic entity. [key style]
See Also: categorization
|
|
generalization structure.
(1)
connection between a superclass and one of its more specific, immediate subclasses
(ISO/IEC/IEEE 24765n:2025, 3.1.69)
|
|
generalization taxonomy.
(1)
set of generalization structures with a common generic ancestor
(ISO/IEC/IEEE 24765n:2025, 3.1.70)
Note: In a generalization taxonomy every instance is fully described by one or more of the classes in the taxonomy. The structuring of classes as a generalization taxonomy determines the inheritance of responsibilities among classes.
Syn: generalization hierarchy, generalization network
|
|
generalize.
(1)
saying that a subclass s generalizes to a superclass C means that every instance of class s is also an instance of class C
(ISO/IEC/IEEE 24765n:2025, 3.1.66)
Example: null
Note: Generalization is fundamentally different from a relationship, which can associate distinct instances.
|
|
generally accepted.
(1)
knowledge to be included in the study material of a software engineering licensing exam that a graduate would pass after completing four years of work experience
(ISO/IEC TR 19759:2016 Software Engineering -- Guide to the Software Engineering Body of Knowledge (SWEBOK))
|
|
generated address.
(1)
address that has been calculated during the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: synthetic address
See Also: absolute address, effective address, relative address, indirect address
|
|
generation.
(1)
act of defining and describing a methodology from a particular metamodel
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.8)
Note: Generating a methodology includes explaining the structural position and semantics of each methodology element using the selected metamodel. Thus, what methodology elements are possible, and how they relate to each other, are constrained by such a metamodel. Usually, method engineers perform generation, yielding a complete and usable methodology.
|
|
generic ancestor (of a class).
(1)
superclass that is either an immediate superclass of the class or a generic ancestor of one of the superclasses of the class
(ISO/IEC/IEEE 24765n:2025, 3.1.71)
See Also: reflexive ancestor
|
|
generic entity.
(1)
entity whose instances are classified into one or more subtypes or subclassifications (category entities)
(ISO/IEC/IEEE 24765n:2025, 3.1.72)
Note: [key style]
See Also: superclass, supertype
|
|
generic practice.
(1)
activity that, when consistently performed, contributes to the achievement of a specific process attribute
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.6)
|
|
generic profile group.
(1)
profile group applicable to very small entities (VSEs) that do not develop critical systems or software products
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.43)
See Also: specific profile group
|
|
generic program unit.
(1)
software module that is defined in a general manner and that requires substitution of specific data, instructions, or both, in order to be used in a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: instantiation
|
|
GFAR.
(1)
generalized false accept rate
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
GFE.
(1)
government-furnished equipment
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
GFI.
(1)
government-furnished information
(ISO/IEC/IEEE 24765j:2021)
|
|
GFRR.
(1)
generalized false reject rate
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
GIF.
(1)
General Interworking Framework
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 4)
(2)
Graphics Interchange Format
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
glass box.
(1)
system or component whose internal contents or implementation are known
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: white box, transparent box
See Also: black box
|
|
global attribute.
(1)
condition when the attributes that describe the foreign keys are the same attributes (and attribute values) as those describing the associated candidate key
(ISO/IEC 15476-4:2005 Information technology--CDIF semantic metamodel--Part 4: Data models, 6.10)
|
|
global compaction.
(1)
in microprogramming, compaction in which microoperations can be moved beyond the boundaries of the single-entry, single-exit sequential blocks in which they occur
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: local compaction
|
|
global data.
(1)
data that can be accessed by two or more non-nested modules of computer program without being explicitly passed as parameters between the modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: common data
See Also: local data
|
|
global label.
(1)
label associated with the net graph itself, rather than with an object of a net graph
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.4)
|
|
global navigation.
(1)
set of navigation links available on all pages of a website
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.11)
|
|
global variable.
(1)
variable that can be accessed by two or more non-nested modules of a computer program without being explicitly passed as a parameter between the modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: local variable
|
|
globally unique identifier (GUID).
(1)
16-byte string of characters that is generated in a manner that gives a high probability that the string is unique in any context
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.16)
Note: GUID as an all capitalized term refers specifically to the 16-byte version. If the term is in lowercase (guid), it refers to a general algorithm that can use either a URI or a 16-byte-based identifier.
|
|
glossary.
(1)
collection of the names and narrative descriptions of all terms that can be used for defined concepts within an environment
(ISO/IEC/IEEE 24765l:2024)
|
|
glossary page.
(1)
model page that contains definitions for the arrow labels and box names in a specific diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.56)
|
|
go to.
(1)
computer program statement that causes a jump
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: call, case, if-then-else branch
|
|
goal.
(1)
intended outcome
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.1.6)
Note: [SOURCE: ISO 9241-11]
|
|
GOTS.
(1)
government-off-the-shelf
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
governability.
(1)
degree to which the provision and use of a service is directed and controlled by a system, and to which the service complies with the regulations applied in the countries where the service is used
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.8.3)
|
|
governance.
(1)
human-based system comprising directing, overseeing, and accountability
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.44)
(2)
framework for directing and enabling an organization through its established policies, practices, and other relevant documentation
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(3)
process of establishing and enforcing strategic goals and objectives, organizational policies, and performance parameters
(ISO/IEC/IEEE 21840:2019 Systems and software engineering--Guidelines for the utilization of ISO/IEC/IEEE 15288 in the context of system of systems (SoS), 3.1.4)
|
|
governing authority.
(1)
entity responsible for establishing the rules, e.g., for specifying types and uses of sensitive data
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
|
|
Government-off-the-Shelf.
(1)
software supplied by the government for reuse in another project
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3)
Syn: GOTS, Government-Off-The-Shelf, Government off the Shelf, Government Off The Shelf
See Also: COTS
|
|
GPIO.
(1)
general-purpose input/output port
(ISO/IEC/IEEE 24765d:2015)
|
|
GPS.
(1)
global positioning system
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
GPU.
(1)
graphical processing unit
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.40)
|
|
grade.
(1)
category or rank used to distinguish items that have the same functional use, but do not share the same requirements for quality
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
granularity.
(1)
depth or level of detail at which data is collected
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
graph.
(1)
diagram that represents the variation of a variable in comparison with that of one or more other variables
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
diagram or other representation consisting of a finite set of nodes and internode connections called edges or arcs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: graph showing a bathtub curve
 |
|
graphical information.
(1)
information defining the graphical appearance of objects and labels of a net graph, which can be the position, size, line color, fill color, font, or line width
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.3)
|
|
graphical processing unit (GPU).
(1)
application-specific integrated circuit (ASIC) specialized for display functions such as rendering images
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.40)
Note: GPUs are designed for parallel data processing of images with a single function, and this parallel processing is also useful for executing artificial intelligence software, such as neural networks.
|
|
graphical symbol.
(1)
visually perceptible figure with a particular meaning used to transmit information independently of language
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.13)
|
|
greenfield system engineering.
(1)
development of a system for a new environment and set of user scenarios and requirements
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: A greenfield approach is rare, because it typically has no significant legacy constraints or dependencies within the system boundary or from external interfaces or enabling systems.
|
|
Grosch's law.
(1)
guideline formulated by H. R. J. Grosch, stating that the computing power of a computer increases proportionally to the square of the cost of the computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: computer performance evaluation
|
|
ground rules.
(1)
list of acceptable and unacceptable behaviors adopted by a project team to improve working relationships, effectiveness, and communication
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
ground truth.
(1)
data that is chosen to indicate the actual facts of the matter, e.g., for scientific analysis or for training machine-learning models
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
Note: For measuring human emotion, affect or empathy, ground truth is elusive and subjective.
|
|
group.
(1)
number of model elements regarded as a unit formed by traceability relationships to a single distinct element
(ISO/IEC/IEEE 24765l:2024)
|
|
GSiU.
(1)
grievance system in use
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
Syn: GSIU
|
|
GSN.
(1)
goal structuring notation
(ISO/IEC/IEEE 15026-2:2022, Systems and software engineering Systems and software assurance Part 2: Assurance case, 3.2)
|
|
GTE.
(1)
greater than or equal
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
GUI.
(1)
graphical user interface
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
GUID.
(1)
globally unique identifier
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.16)
|
|
guide.
(1)
document published by ISO or IEC giving rules, orientation, advice or recommendations relating to international standardization
(ISO/IEC/IEEE 24765l:2024)
See Also: standard, guideline
|
|
guideline.
(1)
official recommendation or advice that indicates policies, standards, or procedures for how something should be accomplished
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
See Also: guide, standard
|
|
gull wing lead.
(1)
connector from the thin side of an integrated circuit package which extends out, down, and then out horizontally to allow it to be connected within a device
(ISO/IEC/IEEE 24765c:2014)
Note: The bent shape is thought to resemble a bird wing.
|
|
hacker.
(1)
technically sophisticated computer enthusiast
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
technically sophisticated computer enthusiast who uses their knowledge and means to gain unauthorized access to protected resources
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
half duplex.
(1)
able to communicate data in both directions, but in only one direction at a time
(ISO/IEC/IEEE 24765d:2015)
See Also: full duplex
|
|
halt.
(1)
most commonly, a synonym for stop
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
less commonly, a synonym for pause
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
[HALT] highly accelerated life testing
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
HAM.
(1)
hardware asset management
(ISO/IEC 19770-6:2024, Information technology IT asset management Part 6: Hardware identification tag, 3.1.2)
|
|
hard copy.
(1)
permanent copy of a display image generated on an output unit such as a printer or a plotter, and which can be carried away
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
hard failure.
(1)
failure that results in complete shutdown of a system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: soft failure
|
|
hardware.
(1)
physical equipment used to process, store, or transmit computer programs or data
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.21)
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.29)
(2)
all or part of the physical components of an information system
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Syn: HW
See Also: software
|
|
hardware asset management (HAM).
(1)
coordinated activity of an organization to realize value from hardware assets
(ISO/IEC 19770-6:2024, Information technology IT asset management Part 6: Hardware identification tag, 3.1.2)
Note: specialization of IT asset management
|
|
hardware configuration item (HCI).
(1)
aggregation of hardware that is designated for configuration management and treated as a single entity in the configuration management process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: An HCI exists where functional allocations have been made that clearly distinguish equipment functions from software functions and where the hardware has been established as a configuration item.
See Also: software configuration item
|
|
hardware description language (HDL).
(1)
software programming language used to design and model hardware, especially digital logic circuits
(ISO/IEC/IEEE 24765d:2015)
Example: VHDL (IEEE 1076), Verilog (IEEE 1364)
Syn: hardware design language
|
|
hardware engineering.
(1)
application of a systematic, disciplined, and quantifiable approach to design, implement, and maintain a tangible product by transforming a set of requirements that represent the collection of stakeholder needs, expectations, and constraints; using documented techniques and technology
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: software engineering, systems engineering
|
|
hardware identification creator.
(1)
entity that initially creates a HWID record
(ISO/IEC 19770-6:2024, Information technology IT asset management Part 6: Hardware identification tag, 3.1.3)
Note: This entity can be part of the organization that manufactured the component to which the record relates, in which case the HWID creator and component manufacturer are the same. The HWID creator can also be a separate organization or third party unrelated to the manufacturer (such as in the case where HWID records are created for existing hardware components by an operating system or a tool deployed by the device owner).
Syn: HWID creator
|
|
hardware identification schema.
(1)
information structure containing a digital description of a hardware component and its associated information
(ISO/IEC 19770-6:2024, Information technology IT asset management Part 6: Hardware identification tag, 3.1.4)
Syn: HWID schema
|
|
hardware monitor.
(1)
device that measures or records specified events or characteristics of a computer system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
software tool that records or analyzes hardware events during the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a device that counts the occurrences of various electrical events or measures the time between such events
|
|
harm.
(1)
injury or damage to the health of people, or damage to property or the environment
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.14)
(IEEE 7009-2024, Fail-Safe Design of Autonomous and Semi-Autonomous Systems, 3.1)
(2)
negative event or negative social development entailing value damage or loss to people
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
Note: Harm entails acting with negative value effects for self or others, within a respective organization or beyond.
|
|
harm from use.
(1)
negative consequences regarding health, safety, finances or the environment that result from use of the system
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.1.15)
Note: The negative consequences can be for the user or for any other stakeholder.
|
|
Harvard architecture.
(1)
computer architecture with physically separate communication paths for instructions and data
(ISO/IEC/IEEE 24765d:2015)
|
|
hazard identification.
(1)
process of recognizing that a hazard exists and defining its characteristics
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1.12)
|
|
hazard warning.
(1)
capability of a product to provide warnings of unacceptable risks to operations or internal controls so that users can react in sufficient time to sustain safe operations
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.9.4)
Example: A traffic light gives a signal to pedestrians, showing the remaining seconds before changing from green to yellow or red
|
|
hazardous event.
(1)
event that can cause harm
(IEEE 7009-2024, Fail-Safe Design of Autonomous and Semi-Autonomous Systems, 3.1)
|
|
hazardous situation.
(1)
circumstance in which people, property or the environment is/are exposed to one or more hazards
(IEEE 7009-2024, Fail-Safe Design of Autonomous and Semi-Autonomous Systems, 3.1)
|
|
HAZOPS.
(1)
hazards and operability studies
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
HCI.
(1)
human computer interface
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
(2)
hardware configuration item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: HWCI
|
|
HDD.
(1)
hardware design description
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
HDL.
(1)
hardware description language
(ISO/IEC/IEEE 24765d:2015)
(2)
hardware design language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: design language
|
|
HDTV.
(1)
high-definition television
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
head.
(1)
forefront of a branch, which contains the evolving versions of the source tree
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: A release coming out of head will have the newest features but will also likely be unstable.
|
|
head action.
(1)
in a given activity, an action that has no predecessor
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.1.7)
|
|
header.
(1)
block of comments placed at the beginning of a computer program or routine
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
identification or control information placed at the beginning of a file or message
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
material repeated at the top of each page
(ISO/IEC/IEEE 24765a:2011)
|
|
heading.
(1)
text that identifies the topic that will be covered in the following text
(ISO/IEC/IEEE 24765a:2011)
|
|
heavyweight process.
(1)
process with its own memory and multiple threads of control
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
help system.
(1)
ancillary part of a program, or sometimes a separate program, that allows the user to view parts of the online documentation or help text on request
(ISO/IEC/IEEE 24765a:2011)
See Also: online documentation system
|
|
heuristic evaluation.
(1)
assessment by one or more experts who judge conformance to a recognized set of principles
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.18)
|
|
HFE.
(1)
human factors engineering
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
hidden.
(1)
both private and protected
(ISO/IEC/IEEE 24765n:2025, 3.1.74)
See Also: public, private, protected
|
|
hierarchical decomposition.
(1)
type of modular decomposition in which a system is broken down into a hierarchy of components through a series of top-down refinements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: functional decomposition, stepwise refinement
|
|
hierarchical modeling.
(1)
technique used in computer performance evaluation, in which a computer system is represented as a hierarchy of subsystems, the subsystems are analyzed to determine their performance characteristics, and the results are used to evaluate the performance of the overall system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
hierarchically consecutive.
(1)
an unbroken unidirectional traversal of all nodes between two specified nodes in a tree
(ISO/IEC/IEEE 24765m:2024, 2.1.57)
|
|
hierarchy.
(1)
a structure in which components are ranked into levels of subordination; each component has zero, one, or more subordinates; and no component has more than one superordinate component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: hierarchical decomposition, hierarchical modeling
|
|
hierarchy chart.
(1)
chart that begins with high-level information that is progressively decomposed into lower levels of detail
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
high level.
(1)
general; abstract
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
high-level design.
(1)
defining the more significant concepts, characteristics, and functions that guide detailed design and implementation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: High-level design typically involves organizing a system into subprograms and specifying the interfaces between them.
See Also: architecture
|
|
high-level keyword.
(1)
keyword that covers complex activities that may be composed from other keywords and is used by domain experts to assemble keyword test cases
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 4.2)
|
|
high-order language (HOL).
(1)
programming language that requires little knowledge of the computer on which a program will run, can be translated into several different machine languages, allows symbolic naming of operations and addresses, provides features designed to facilitate expression of data structures and program logic, and usually results in several machine instructions for each program statement
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: Ada, COBOL, FORTRAN, ALGOL, PASCAL
Syn: high-level language, high order language, higher order language, third-generation language
See Also: assembly language, fifth-generation language, fourth-generation language, machine language
|
|
higher-level management.
(1)
person or persons who provide the policy and overall guidance for the process, but do not provide the direct day-to-day monitoring and controlling of the process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Such persons belong to a level of management in the organization above the immediate level responsible for the process.
|
|
HILS.
(1)
hardware in the loop simulation
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
histogram.
(1)
a special form of bar chart used to describe the central tendency, dispersion, and shape of a statistical distribution
(ISO/IEC/IEEE 24765h:2019)
(2)
bar chart that shows the graphical representation of numerical data
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
history file.
(1)
notional data type consisting of a collection of event records that can be processed to obtain durations, counts, and statistics for support actions, events, and modes over a span of interest
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
HLL.
(1)
high-level language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: high-order language
|
|
HMI.
(1)
human-machine interface
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: user interface
|
|
HOL.
(1)
high-order language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
home page.
(1)
web page through which users typically enter the website, and whose URL is typically published or linked as the main web address of the site or organization
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.12)
Syn: center page, front page, index page, main page, start page, top page
|
|
homogeneous redundancy.
(1)
in fault tolerance, realization of the same function with identical means
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: use of two identical processors
See Also: diversity
|
|
horizontal microinstruction.
(1)
microinstruction that specifies a set of simultaneous operations needed to carry out a given machine language instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Horizontal microinstructions are relatively long, often 64 bits or more, and are called 'horizontal' because the set of simultaneous operations that they specify are written on a single line, rather than being listed sequentially down the page.
See Also: diagonal microinstruction, vertical microinstruction
|
|
host machine.
(1)
the computer on which a program or file is installed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
in a computer network, a computer that provides processing capabilities to users of the network
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
computer used to develop software intended for another computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
computer used to emulate another computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
hostile backout.
(1)
backout done without prior arrangement by a committer other than the one who introduced the original change
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: This is usually the opening shot in a commit war.
|
|
housekeeping operation.
(1)
computer operation that establishes or reestablishes a set of initial conditions to facilitate the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: initializing storage areas, clearing flags, rewinding tapes, opening and closing files
Syn: overhead operation
|
|
HR.
(1)
human resources
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.2)
|
|
HREF.
(1)
HTML reference designator
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
HRS.
(1)
hardware requirements specification
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
|
|
HSI.
(1)
human systems integration
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.2)
|
|
HTER.
(1)
half total error rate
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
HTML.
(1)
hypertext markup language
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
HTTP.
(1)
hypertext transfer protocol
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
HTTPS.
(1)
hypertext transfer protocol secure
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.2)
|
|
human factors.
(1)
systematic application of relevant information about human abilities, characteristics, behavior, motivation, and performance
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: It includes principles and applications in the areas of human‐related engineering, anthropometrics, ergonomics, job performance skills and aids, and human performance evaluation.
|
|
human resource planning.
(1)
identification and documentation of project roles, responsibilities and reporting relationships, as well as estimation of required staff by time period and creation of a staffing management plan
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
human rights.
(1)
rights to which every person is entitled
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
|
|
human systems engineering.
(1)
activities involved throughout the system life cycle that address the human element of system design (including usability, measures of effectiveness, measures of performance, and total ownership cost)
(ISO/IEC/IEEE 24765f:2016)
Note: These activities include the definition and synthesis of manpower, personnel, training, human engineering, health hazards, and safety issues.
|
|
human systems integration (HSI).
(1)
interdisciplinary technical and management process for integrating human considerations with and across all system elements
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 3.1.13)
|
|
human-centered design.
(1)
approach to system design and development that aims to make interactive systems more usable by focusing on the use of the system; applying human factors, ergonomics and usability knowledge and techniques
(ISO/IEC 25063:2014 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) Common Industry Format (CIF) for usability: Context of use description, 3.6)
Note: The term "human-centered design" is used rather than "user-centered design" to emphasize that design impacts a number of stakeholders, not just those typically considered as users. However, in practice, these terms are often used synonymously. Usable systems can provide a number of benefits, including improved productivity, enhanced user well-being, avoidance of stress, increased accessibility, and reduced risk of harm.
Syn: human-centred design, user-centered design, user-centred design
|
|
human-centered quality.
(1)
extent to which requirements relating to usability, accessibility, user experience, and avoidance of harm from use are met
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.1.13)
Note: collective term for the intended outcomes of interaction of the user with the system
Syn: human-centred quality, human centered quality
|
|
Hurwicz criterion.
(1)
in decision making under uncertainty, a method which gives each decision a value which is a weighted sum of its worst and best possible outcomes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: allows the decision maker to account for optimistic and pessimistic views
See Also: maximax rule, maximin rule, minimax regret rule
|
|
HW.
(1)
hardware
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
HWCI.
(1)
hardware configuration item
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
HWID.
(1)
hardware identification
(ISO/IEC 19770-6:2024, Information technology IT asset management Part 6: Hardware identification tag, 3.2)
|
|
hybrid approach.
(1)
combination of two or more agile and nonagile elements, having a non-agile end result
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
hybrid computer.
(1)
computer that integrates analog computer components and digital computer components by interconnection of digital-to-analog converters and analog-to-digital converters
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: A hybrid computer can use or produce analog data and discrete data.
|
|
hybrid coupling.
(1)
type of coupling in which different subsets of the range of values that a data item can assume are used for different and unrelated purposes in different software modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: common-environment coupling, content coupling, control coupling, data coupling, pathological coupling
|
|
hyperparameter.
(1)
variable used to define the structure of a neural network and how it is trained
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.41)
Note: Typically, hyperparameters are set by the developer of the model and may also be referred to as a tuning parameter.
|
|
hypertext markup language (HTML).
(1)
language for creating web pages
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.17)
|
|
HyperText Transfer Protocol (HTTP).
(1)
application-level protocol for distributed, collaborative, hypermedia information systems
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.18)
|
|
I&C.
(1)
instrumentation and control
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
Syn: I & C
|
|
I/O.
(1)
input/output
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
I/O task-structuring criteria.
(1)
category of the task-structuring criteria addressing how device interface objects are mapped to I/O tasks and when an I/O task is activated
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
I2C.
(1)
inter-integrated circuit bus
(ISO/IEC/IEEE 24765d:2015)
Syn: IIC
|
|
IaaS.
(1)
infrastructure as a service
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
See Also: PaaS
|
|
IaC.
(1)
infrastructure as code
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
|
|
IAEA.
(1)
International Atomic Energy Agency
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
IAP.
(1)
in-application programming
(ISO/IEC/IEEE 24765d:2015)
|
|
IBa.
(1)
issue benchmarks activity
(ISO/IEC 29155-2:2013 Systems and software engineering--Information technology project performance benchmarking framework--Part 2: Requirements for benchmarking, 4)
|
|
IBD.
(1)
information-based domain
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 4.2)
|
|
IBDR.
(1)
input biometric data record
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
IC.
(1)
interface controller
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
ICAO.
(1)
International Civil Aviation Organization
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
ICD.
(1)
initial capabilities document
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
(2)
interface control document
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
ICE.
(1)
in-circuit emulator
(ISO/IEC/IEEE 24765d:2015)
|
|
ICOM.
(1)
input, control, output, and mechanism
(ISO/IEC/IEEE 24765m:2024, 2.2)
|
|
ICOM code.
(1)
expression in one diagram that unambiguously identifies an arrow segment in another diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.58)
Note: An ICOM code is used to associate a boundary arrow of a child diagram with an arrow attached to an ancestral box.
Syn: arrow reference
|
|
ICOM label.
(1)
arrow label attached without a squiggle directly to the arrowhead of an output boundary arrow or to the arrowtail of an input, control, or mechanism boundary arrow
(ISO/IEC/IEEE 24765m:2024, 2.1.59)
Note: An ICOM label associates a boundary arrow of a child diagram with an arrow label of an arrow attached to an ancestral box.
|
|
icon.
(1)
graphic displayed on the screen that represents a function
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.24)
|
|
ICS.
(1)
Implementation Conformance Statement
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
ICT.
(1)
information and communications technology
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
ICT product.
(1)
product which uses information and communication technologies (ICTs) and can be a part of an information system
(ISO/IEC 25030:2019 Systems and software engineering--Systems and software quality requirements and evaluation (SQuaRE)--Quality requirements framework, 3.8)
Syn: information and communication technology product
|
|
ICT requirement.
(1)
requirement resulting from adoption of some information and communication technology (ICT) as a technical solution in the design process
(ISO/IEC 25030:2019 Systems and software engineering--Systems and software quality requirements and evaluation (SQuaRE)--Quality requirements framework, 3.7)
Note: ICT technical solutions include web-based technologies and cloud servers.
Syn: information and communication technology requirement
|
|
ICWG.
(1)
Interface Control Working Group
(ISO/IEC/IEEE 16326:2019 Systems and software engineering -- Life cycle processes -- Project management, 5)
Note: Depending on the size and complexity of a project, can be a group of people, a single person or a function
|
|
IDD.
(1)
interface design document
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
IDE.
(1)
integrated development environment
(ISO/IEC/IEEE 24765d:2015)
|
|
idea/mind mapping.
(1)
technique used to consolidate ideas created through individual brainstorming sessions into a single map to reflect commonality and differences in understanding, and to generate new ideas
(ISO/IEC/IEEE 24765h:2019)
(2)
technique of graphically connecting ideas and concepts around a central idea to show their relationships
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: used to generate new ideas and to obtain consensus on the relationships among concepts
Syn: idea mapping
See Also: entity-relationship (E-R) diagram
|
|
ideal time.
(1)
a best-case estimate of the time needed for a developer or team to complete a task or deliver a feature
(Software Extension to the PMBOK(R) Guide Fifth Edition)
|
|
IDEF.
(1)
integration definition for functional modeling
(ISO/IEC/IEEE 24765l:2024)
|
|
identification transaction.
(1)
sequence of one or more capture attempts and biometric searches to find and return the biometric reference identifiers attributable to a single individual
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.30)
|
|
identifier.
(1)
unambiguous name, in a given naming context
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 12.2)
(2)
name, address, label, or distinguishing index of an object in a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
identifying relationship.
(1)
specific (not many-to-many) relationship in which every attribute in the primary key of the parent entity is contained in the primary key of the child entity
(ISO/IEC/IEEE 24765n:2025, 3.1.79)
See Also: nonidentifying relationship [key style]
|
|
identity.
(1)
inherent property of an instance that distinguishes it from all other instances
(ISO/IEC/IEEE 24765n:2025, 3.1.80)
Note: Identity is intrinsic to the instance and independent of the instance's property values or the classes to which the instance belongs.
|
|
IDIQ.
(1)
indefinite delivery indefinite quantity
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
IDL.
(1)
Interface Definition Language
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
idle.
(1)
pertaining to a system or component that is operational and in service, but not in use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
See Also: busy, down, up
|
|
idle time.
(1)
period of time during which a system or component is operational and in service, but not in use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: standby time
See Also: busy time, down time, set-up time, up time
|
|
IEC.
(1)
International Electrotechnical Commission
(IEEE 1228-1994 (R2002) IEEE Standard for Software Safety Plans, 3.2)
|
|
IEEE.
(1)
Institute of Electrical and Electronics Engineers
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
IETF.
(1)
Internet Engineering Task Force
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
if-then-else.
(1)
single-entry, single-exit two-way branch that defines a condition, specifies the processing to be performed if the condition is met and, optionally, if it is not, and returns control in both instances to the statement immediately following the overall construct
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: case, jump, go to, dyadic selective construct, monadic selective construct
 |
|
IFB.
(1)
invitation for bid
(ISO/IEC/IEEE 24765n:2025)
|
|
iff.
(1)
if and only if
(ISO/IEC/IEEE 24765i:2020)
|
|
IFPUG.
(1)
International Function Point Users Group
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009)
Note: membership governed, non-profit organization committed to promoting and supporting function point analysis and other software measurement techniques. The IFPUG maintains the definition of the direct descendent of the Albrecht 1984 FPA method
|
|
IIOP-IOR.
(1)
Internet Inter-ORB Protocol -- Interoperable Object Reference
(ISO/IEC 14753:1999 Information technology -- Open Distributed Processing -- Interface references and binding, 4)
|
|
ILF.
(1)
internal logical file
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 4)
|
|
illustration.
(1)
graphic element set apart from the main body of text and normally cited within the main text
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.25)
(2)
visually perceptible figure, artificially created to transmit specific information, excluding safety signs and graphical symbols
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.16)
Note: used as the generic term for tables, figures, exhibits, screen captures, flow charts, diagrams, drawings, icons, and other types of graphics
|
|
ILS.
(1)
integrated logistics support
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
image processing.
(1)
use of a data processing system to create, scan, analyze, enhance, interpret, or display images
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
immediate data.
(1)
data contained in the address field of a computer instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: direct address, indirect address, n-level address, immediate instruction
|
|
immediate instruction.
(1)
computer instruction whose address fields contain the values of the operands rather than the operands' addresses
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: direct instruction, indirect instruction, absolute instruction, effective instruction, immediate data
|
|
immunity provision.
(1)
exemption granted by statute or government authorities from a legal duty, penalty, or prosecution
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
|
|
immutable class.
(1)
class for which the set of instances is fixed; its instances do not come and go over time
(ISO/IEC/IEEE 24765n:2025, 3.1.82)
See Also: mutable class, value class
|
|
impact analysis.
(1)
identification of all system and software products that a change request affects and development of an estimate of the resources needed to accomplish the change
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: This includes determining the scope of the changes to plan and implement work, accurately estimating the resources needed to perform the work, and analyzing the requested changes' cost and benefits.
|
|
impact mapping.
(1)
strategic planning method that serves as a visual roadmap for the organization during product development
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
impairment.
(1)
non-terminal system failure or change in a runtime environment resource or operating condition that degrades system capabilities, but does not result in an immediate terminal failure
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: An impairment can be a result of a system fault, an as-designed system response, or an environment condition. It can trigger other impairments or failures. Each impairment has a duration and can result in lossage.
|
|
impediment.
(1)
obstacle that prevents the team from achieving its objectives
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: blocker
|
|
imperative construct.
(1)
sequence of one or more steps not involving branching or iteration
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
implementable standard.
(1)
template for a technology object
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 9.1.1)
|
|
implementation.
(1)
process of translating a design into hardware components, software components, or both
(ISO/IEC/IEEE 90003:2018 Software engineering -- Guidelines for the application of ISO 9001:2015 to computer software, 3.4)
(2)
process of instantiation whose validity can be subject to test
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 9.1.2)
(3)
construction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
system development phase at the end of which the hardware, software and procedures of the system become operational
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
See Also: coding
|
|
implementation phase.
(1)
period of time in the software life cycle during which a software product is created from design documentation and debugged
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
|
|
implementation rating module.
(1)
quality rating module that can be directly applied to a target entity
(ISO/IEC 25040:2024 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Quality evaluation framework, 3.2)
|
|
implementation requirement.
(1)
requirement that specifies or constrains the coding or construction of a system or system component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: design requirement, functional requirement, interface requirement, performance requirement, physical requirement
|
|
implied addressing.
(1)
method of addressing in which the operation field of a computer instruction implies the address of the operands
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: If a computer has only one accumulator, an instruction that refers to the accumulator needs no address information describing it.
See Also: direct address, indirect address, one-ahead addressing, relative address, repetitive addressing
|
|
implied need.
(1)
need that has not been stated but is an actual need
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.12)
Note: Implied needs include needs not stated but implied by other stated needs, and needs not stated because they are considered to be evident or obvious. Some implied needs only become evident when the software product is used in particular conditions (context of use)
|
|
import process.
(1)
process of incorporating the content of a transfer file into a target environment
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.1)
|
|
importer.
(1)
agent of the import process
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.1)
|
|
impossible zone.
(1)
in a range of estimates, the region that is impossible under any circumstances to achieve
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: It is impossible to drive a car 500 miles in less than one hour, so the one-hour outcome for a 500-mile car trip is in the impossible zone for the estimate of how long it will take to drive 500 miles.
|
|
improvability.
(1)
inherent ability of an organization to support continual process improvement
(ISO/IEC TR 33014:2013 Information technology--Process assessment--Guide for process improvement, 3.3)
|
|
improvement backlog.
(1)
intentional, emergent, ordered list of items describing how to make improvements
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.16)
|
|
in-application programming (IAP).
(1)
capability of a microcontroller unit to fetch new program code and reprogram itself while the system is operating
(ISO/IEC/IEEE 24765d:2015)
See Also: in-system programming
|
|
in-circuit emulator (ICE).
(1)
hardware device used to debug the software of an embedded system
(ISO/IEC/IEEE 24765d:2015)
|
|
in-service.
(1)
portion of a systems life cycle that includes support actions to establish, sustain, and deactivate an SOI instance, and the active use of an instance for its intended purpose
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: IN-SERVICE mode is comprised of modes SUPPORTING, BLOCKED, READY, RUNNING, and INOPERABLE. It may be concurrent with DEVELOPMENT/MAINTENANCE. It is typically concluded with uninstallation, resulting in the REMOVED mode.
|
|
in-service period.
(1)
time span starting with the first installation of a system and ending with the first of 1) its replacement by a materially different version of that system, 2) its uninstallation, abandonment, or 3) the demise of its runtime or operational environment
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
in-service reference model (ISRM).
(1)
model of support actions, events, and modes of an in-service software system that supports classification of SOI behavior and subsetting of in-service time spans necessary for dependability measurements
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
in-system programming (ISP).
(1)
capability of a microcontroller unit to allow the user to download new code (reprogram the unit), activated by restarting the unit
(ISO/IEC/IEEE 24765d:2015)
See Also: in-application programming
|
|
INC.
(1)
incremental
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
incident.
(1)
anomalous or unexpected event, set of events, condition, or situation at any time during the life cycle of a project, product, service, or system
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.17)
(2)
unplanned interruption to a service, a reduction in the quality of a service or an event that has not yet impacted the service to the customer or user
(ISO/IEC 29110-5-1-2:2025 Systems and software engineering Life cycle profiles for very small entities (VSEs) Part 5-1-2: Software engineering guidelines for the generic Basic profile, 3.15)
(3)
unplanned event or occurrence resulting in damage or other loss
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.22)
Note: An incident is elevated and treated as a problem when the cause of the incident is analysed and corrected to prevent recurrence, or to avoid or minimise loss of life, or damage to property or natural resources. Some incidents do not involve further analysis, as they result from known errors where workarounds or solutions are already known.
See Also: software test incident
|
|
incident report.
(1)
documentation of the occurrence, nature, and status of an incident
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.7)
Example: anomaly reports, bug reports, defect reports, error reports, issues, problem reports and trouble reports
See Also: test incident report
|
|
incipient failure.
(1)
failure that is about to occur
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
include.
(1)
in UML, a relationship from a base use case to an included use case specifying how the behavior defined for the included use case can be inserted into the behavior defined for the base use case
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
[information] has either the information or a reference to the information
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 3.1.12)
|
|
inclusivity.
(1)
capability of a product to be utilized by people of various backgrounds
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.4.6)
Example: People of various ages, abilities, cultures, ethnicities, languages, genders, economic situations, education, geographical locations, and life situations.
|
|
income function.
(1)
objective function that characterizes the income generated by different values of the decision variable
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: cost function
|
|
incomplete process.
(1)
process that is not performed or is performed only partially
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: One or more of the specific goals of the process are not satisfied.
|
|
inconsistency ratio.
(1)
in analytic hierarchy process (AHP), a function that measures how consistently the decision analyst assigned the values to the pair-wise comparisons
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
increment.
(1)
tested, deliverable version of a software product that provides new or modified capabilities
(Software Extension to the PMBOK(R) Guide Fifth Edition)
|
|
incremental analysis.
(1)
consideration of the relative differences between alternatives
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: If the incremental benefit of a second alternative over the first is more than the incremental investment between them, the second alternative is a better investment than the first.
|
|
incremental approach.
(1)
adaptive development approach in which the deliverable is produced successively, adding functionality until the deliverable contains the necessary and sufficient capability to be considered complete
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
incremental benefit.
(1)
additional income from one alternative compared to another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: If Alternative A generates $10,000 and Alternative B generates $12,000, the incremental benefit between A and B is $2000.
|
|
incremental compiler.
(1)
compiler that completes as much of the translation of each source statement as possible during the input or scanning of the source statement
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Typically used for online computer program development and checkout.
Syn: conversational compiler, interactive compiler, online compiler
|
|
incremental development.
(1)
software development technique in which requirements definition, design, implementation, and testing occur in an overlapping, iterative (rather than sequential) manner, resulting in incremental completion of the overall software product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: waterfall model, data structure-centered design, input-process-output, modular decomposition, object-oriented design
|
|
incremental investment.
(1)
avoidable additional investment between one alternative and another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: If Alternative A costs $10,000 and Alternative B costs $12,000, the incremental investment between A and B is $2000.
|
|
incremental productivity.
(1)
productivity computed periodically during development
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
indefinite delivery indefinite quantity (IDIQ).
(1)
contract that provides for an indefinite quantity of goods or services, with a stated lower and upper limit, within a fixed time period
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
independence.
(1)
of software quality assurance (SQA), situation in which SQA is free from technical, managerial, and financial influences, intentional or unintentional
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
|
|
independent.
(1)
performed by an organization free from control by the supplier, developer, operator, or maintainer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
independent entity.
(1)
entity for which each instance can be uniquely identified without determining its relationship to another entity
(ISO/IEC/IEEE 24765n:2025, 3.1.84)
Syn: identifier-independent entity
See Also: dependent entity [key style]
|
|
independent state class.
(1)
state class that is not a dependent state class
(ISO/IEC/IEEE 24765n:2025, 3.1.85)
See Also: dependent state class
|
|
independent verification and validation (IV&V).
(1)
verification and validation performed by an organization that is technically, managerially, and financially independent of the development organization
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
|
|
index.
(1)
composite set of measures that reflect a concept
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.1)
|
|
indexed address.
(1)
address that is added to the contents of an index register to obtain the address of the storage location to be accessed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: offset, relative address, self-relative address
|
|
indicator.
(1)
measure that provides an estimate or evaluation of specified attributes derived from a model with respect to defined information needs
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.13)
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.10)
(2)
device or variable that can be set to a prescribed state based on the results of a process or the occurrence of a specified condition
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
measure of a discrete element of a domain
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.1)
Example: a flag or semaphore
|
|
indicator value.
(1)
numerical or categorical result assigned to an indicator
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.11)
|
|
indigenous error.
(1)
computer program error that has not been purposely inserted as part of an error-seeding process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
indirect address.
(1)
address that identifies the storage location of another address
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The designated storage location can contain the address of the desired operand or another indirect address; the chain of addresses eventually leads to the operand.
Syn: multilevel address
See Also: direct address, immediate data, indirect instruction, n-level address
|
|
indirect instruction.
(1)
computer instruction that contains indirect addresses for its operands
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: direct instruction, immediate instruction, absolute instruction, effective instruction
|
|
indirect labor.
(1)
human effort that is not directly associated with the units being produced
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: direct labor
|
|
indirect measure.
(1)
measure of an attribute that is derived from measures of one or more other attributes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: An external measure of an attribute of a computing system (such as the response time to user input) is an indirect measure of attributes of the software as the measure will be influenced by attributes of the computing environment as well as attributes of the software.
|
|
indirect user.
(1)
person who receives output from a system, but does not interact with the system
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.3.4)
(ISO/IEC 25002:2024, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model overview and usage, 3.9)
See Also: direct user, secondary user
|
|
individual interface.
(1)
physical implementation of one or more user interface elements and content chunks that is presented at a point in time
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.2.9)
|
|
inductive assertion method.
(1)
a proof of correctness technique in which assertions are written describing program inputs, outputs, and intermediate conditions, a set of theorems is developed relating satisfaction of the input assertions to satisfaction of the output assertions, and the theorems are proved or disproved using proof by induction
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual)
|
|
infant mortality.
(1)
set of failures that occur during the early-failure period of a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
inference.
(1)
reasoning step that derives a claim from a list of claims (premises) under a specified context
(ISO/IEC/IEEE 15026-2:2022, Systems and software engineering Systems and software assurance Part 2: Assurance case, 3.1.4)
Note: The claim derived by inference is the conclusion, and the supported claims from which the inference derives the conclusion are the premises. There are special inferences, called obvious inferences.
|
|
influence diagram.
(1)
graphical representation of situations showing causal influences, time ordering of events, and other relationships among variables and outcomes
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
influencer.
(1)
persons or groups that are not directly related to the acquisition or use of the product, but who can affect the course of the project, positively or negatively, due to their position in the customer organization
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: stakeholder
|
|
informal group review.
(1)
informal review performed by three or more persons
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.7)
|
|
informal review.
(1)
form of review that does not follow a defined process and has no formal documented output
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.6)
|
|
informal testing.
(1)
testing conducted in accordance with test plans and procedures that have not been reviewed and approved by a customer, user, or designated level of management
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: formal testing
|
|
information.
(1)
knowledge that is exchangeable amongst users, about things, facts, concepts, and so on, in a universe of discourse
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 3.2.6)
(2)
In information processing, knowledge concerning objects, such as facts, events, things, processes, or ideas, including concepts, that within a certain context has a particular meaning
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(3)
meaningful data
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.23)
Note: Although information will necessarily have a representation form to make it communicable, it is the interpretation of this representation (the meaning) that is relevant in the first place.
See Also: data
|
|
information analysis.
(1)
systematic investigation of information and its flow in a real or planned system
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
information architect.
(1)
person who develops the structure of an information space and the semantics for accessing required task objects, system objects, and other information
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.20)
|
|
information architecture.
(1)
human-centered structure of an information space and the semantics for accessing required task objects, system objects and other information
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 2.8)
(2)
structure of an information space and the semantics for accessing required task objects, system objects and other information
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.16)
(3)
structure of an information space and the semantics for accessing information on tasks, system functions and features, and other information
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.27)
Note: The appropriate combination of organization, labeling, navigation schemes and retrieval mechanisms within an information space facilitates task completion and efficient access to content.
|
|
information content.
(1)
set of metamodel and model instances found in a CDIF transfer
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
information developer.
(1)
person who prepares the content and visuals for product documentation
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.22)
(2)
person who prepares the content and visuals for information for users
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.17)
(3)
person who prepares content for information for users
(ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 3.8)
|
|
information development.
(1)
process of development concerned with determining what content and visuals are provided in product documentation and what the nature of the information is
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.21)
|
|
information development lead.
(1)
person who leads the activities of preparing documentation
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.23)
(2)
person who leads the activities of preparing information for users
(ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 3.9)
|
|
information for use.
(1)
information provided by the supplier that provides the target audience with concepts, procedures and reference material for the safe, effective, and efficient use of a supported product during its life cycle
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.17)
Example: Step-by-step instructions, troubleshooting information, service information, operation and maintenance instructions, and assembly instructions
Note: Excludes supplementary information, which s outside the scope of information for use
Syn: instructions for use
See Also: information for users, documentation
|
|
information for users.
(1)
information provided by the supplier that provides the target audience with concepts, procedures, and reference material for the safe, effective, and efficient use of a supported product during its life cycle
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.29)
Example: Printed manuals, onscreen information, and stand-alone online help
Note: can be provided separately or embedded in the product
See Also: information for use, documentation
|
|
information hiding.
(1)
software development technique in which each module's interfaces reveal as little as possible about the module's inner workings and other modules are prevented from using information about the module that is not in the module's interface specification
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
containment of a design or implementation decision in a single module so that the decision is hidden from other modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: encapsulation
|
|
information item.
(1)
separately identifiable body of information that is produced, stored, and delivered for human use
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.31)
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.11)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.18)
(2)
separately identifiable body of information that is produced and stored for human use during a system or software life cycle
(ISO/IEC 25063:2014 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) Common Industry Format (CIF) for usability: Context of use description)
Note: Information product is often considered a synonym. An information item can be produced in several versions during a system, software, or service life cycle.
See Also: document, information product
|
|
information item content.
(1)
information included in an information item, associated with a system, product or service, to satisfy a requirement or need
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.13)
|
|
information item type.
(1)
group of information items consistent with a pre-arranged set of generic criteria
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.14)
Example: A 'plan' is the information item type for all plans and 'report' is the information item type for all reports.
Syn: generic document type
|
|
information management.
(1)
in an information processing system, the functions of controlling the acquisition, analysis, retention, retrieval, and distribution of information
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
information model.
(1)
representation of concepts, relationships and rules for a body of information
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.18)
|
|
information need.
(1)
insight necessary to manage objectives, goals, risks, and problems
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.14)
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.12)
|
|
information part.
(1)
separately identifiable body of information that is produced, stored, and delivered for human and machine use
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.14)
See Also: information item
|
|
information processing.
(1)
systematic performance of operations upon information, which includes data processing and can include operations such as data communication and office automation
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: The term information processing is not a synonym for data processing
|
|
information processing requirements.
(1)
the set of functions required by the commissioning user of the application software product (excluding any technical and quality requirements)
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 1.1)
See Also: software
|
|
information processing system.
(1)
one or more data processing systems and devices, such as office and communication equipment, that perform information processing
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
information product.
(1)
one or more indicators and their associated interpretations that address an information need
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.13)
Example: a comparison of a measured defect rate to planned defect rate along with an assessment of whether or not the difference indicates a problem
Note: Often used as a synonym of information item.
See Also: information item
|
|
information provisioning.
(1)
collection of all the infrastructure tools, software applications, non-automated elements, data sets, user documentation, and organizational structures which serve to supply information to the business
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.20)
|
|
information quality.
(1)
degree to which an information product satisfies the stated and implied needs when used under specified conditions
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.20)
|
|
information radiator.
(1)
visible, physical display that provides information to the rest of the organization, enabling timely knowledge sharing
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Example: burndown charts, cumulative flow diagrams, parking lot diagrams
|
|
information retrieval (IR).
(1)
actions, methods, and procedures for obtaining information on a given subject from stored data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
information security.
(1)
preservation of confidentiality, integrity and accessibility of information
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
Note: In addition, other properties such as authenticity, accountability, non-repudiation and reliability can also be involved.
|
|
information security incident.
(1)
single or a series of unwanted or unexpected information security events that have a significant probability of compromising business operations and threatening information security
(ISO/IEC/IEEE 24765c:2014)
Note: [ISO/IEC 27000:2018, 3.31]
|
|
information security policy.
(1)
document that states, in writing, how an organization plans to protect its physical and information technology assets
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.47)
|
|
information structure.
(1)
structure that provides information about an IT asset in order to facilitate its management
(ISO/IEC 19770-4:2017 Information technology -- IT asset management -- Part 4: Resource utilization measurement, 3.13)
Syn: info struct
|
|
information structure creator.
(1)
entity that initially creates an information structure
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.19)
Example: part of the organization that created the software, a third-party organization that creates information structures for legacy software
Syn: info struct creator
|
|
information structure id.
(1)
globally unique value for every information structure created
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.20)
Syn: info struct ID
|
|
information system.
(1)
information processing system, together with associated organizational resources such as human, technical, and financial resources, which provides and distributes information
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(2)
all of the functions (input, output, transport, processing, and storage) of an application, databases, technical facilities, and manual procedures which support business processes
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.21)
(3)
one or more computer systems and communication systems together with associated organizational resources such as human, technical, and financial resources that provide and distribute information
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.24)
(4)
system that is comprised of software, hardware, communication facility, data, and the people who use it in a given environment to satisfy their information processing needs
(ISO/IEC 25030:2019 Systems and software engineering--Systems and software quality requirements and evaluation (SQuaRE)--Quality requirements framework, 3.10)
(5)
system which is designated to collect, organize, store, communicate, and process data
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
(6)
system that comprises ICT products, ICT environment, and the people who use them or are impacted by them, which become a combination of interacting elements organized to achieve one or more stated purposes
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.1.9)
See Also: application
|
|
information technology.
(1)
resources required to acquire, process, store and disseminate information
(ISO/IEC/IEEE 24765c:2014)
(2)
development, maintenance, and use of technology to acquire, process, store and distribute digital information
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.24)
Note: includes Communication Technology (CT) and the composite term Information and Communication Technology (ICT)
Syn: IT
|
|
information technology project.
(1)
temporary endeavor undertaken to create or change a unique information technology product, system, or service
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.7)
Syn: IT project, information technology (IT) project
|
|
information technology service.
(1)
service that makes use of IT systems as tools to provide value to an individual user or a business by facilitating results the user or business wants to achieve
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.3.2)
Syn: IT service
|
|
information type.
(1)
class of topics that addresses a particular user question
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.20)
(2)
category of topics, such as concepts, tasks, or reference
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.18)
Example: An information type that answers the question, "How do I ?" is called a task information type.
|
|
information viewpoint.
(1)
viewpoint on an ODP system and its environment that focuses on the semantics of information and information processing
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.1.1.2)
|
|
information-based domain.
(1)
realm of activity for which information is the most valuable asset
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.1)
Note: Information creation, manipulation, and dissemination are the most important activities within information-based domains. Typical information-based domains are software and systems engineering, business process reengineering, and knowledge management.
Syn: IBD
|
|
informed consent.
(1)
permission granted in the knowledge of the possible consequences
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
Note: Informed consent is a process for getting permission before performing an action involving personally identifiable information. Acceptance of informed consent can be used as a condition for extending an offer of employment.
|
|
infrastructure.
(1)
hardware and software environment to support computer system and software design, development, and modification
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.32)
(2)
facilities such as power, cooling, and physical security of the data center, networking, hardware, and software needed to support the systems life cycle and maintain information technology (IT) services
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
Note: Does not include the associated people or processes. In DevOps, software-defined infrastructure enables elasticity.
Syn: ecosystem
See Also: IT infrastructure, software engineering environment
|
|
infrastructure as code (IaC).
(1)
definition, management, and provision of infrastructure components using software
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
Note: In DevOps, infrastructure as code facilitates the automation of the systems life cycle, enabling consistency, performance, and security across the system and resources
|
|
inheritance.
(1)
a semantic notion by which the responsibilities (properties and constraints) of a subclass are considered to include the responsibilities of a superclass, in addition to its own, specifically declared responsibilities
(ISO/IEC/IEEE 24765n:2025, 3.1.86)
|
|
inherited attribute.
(1)
attribute that is a characteristic of a class by virtue of being an attribute of a generic ancestor
(ISO/IEC/IEEE 24765n:2025, 3.1.87)
(2)
attribute that is a characteristic of a category entity by virtue of being an attribute in its generic entity or a generic ancestor entity
(ISO/IEC/IEEE 24765n:2025, 3.1.87)
|
|
inherited error.
(1)
error carried forward from a previous step in a sequential process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
inhibitor arc.
(1)
special kind of arc that reverses the logic of an input place
(ISO/IEC 15909-3:2021. Systems and software engineering--High-level Petri nets--Part 3: Extensions and structuring mechanisms, 3.4)
Note: Instead of testing the presence of some tokens in the related place, it tests the lack of these.
|
|
initial Ent.
(1)
Ent that is referenced by later Ents
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.14)
Note: The initial Ent is typically a record of the first transaction between software licensor and end customer. An initial Ent is a type of primary Ent.
Syn: initial entitlement schema
|
|
initial investment.
(1)
investment required just to start an activity
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: first cost
|
|
initial marking (of the net).
(1)
set of initial place markings given with the high-level net definition
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.10)
|
|
initial marking of a place.
(1)
special marking of a place, defined with the net
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.11)
Syn: initial marking of place
|
|
initial program loader.
(1)
bootstrap loader used to load that part of an operating system needed to load the remainder of the operating system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
initial risk.
(1)
estimated risk before applying risk reduction measures
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.3.3)
|
|
initialization section.
(1)
optional list of unconditional actions to be executed sequentially before the first condition is examined
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.13)
Example: null
Note: It can be written in the row which follows that of the table heading.
|
|
initialize.
(1)
to set a variable, register, or other storage location to a starting value
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: clear, reset
|
|
initiating object.
(1)
object causing a communication
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.4.1)
|
|
initiating process group.
(1)
those processes performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
initiative.
(1)
degree to which the IT service recognizes users? goals and service suggests changes to meet users? needs
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.7.2)
|
|
initiator.
(1)
person or organization that has both the ability and authority to start a project
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
injection slot.
(1)
point where the recoverability of the system under test (SUT) is tested by injecting a disturbance while a workload is being run
(ISO/IEC 25045:2010 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Evaluation module for recoverability, 4.3)
|
|
inline code.
(1)
sequence of computer instructions that is physically contiguous with the instructions that logically precede and follow it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
inner cardinality.
(1)
number of allowed instances of the relationship from the viewpoint of a single instance of the data object planning a role
(ISO/IEC 15476-4:2005 Information technology--CDIF semantic metamodel--Part 4: Data models, 6.6.2)
See Also: outer cardinality
|
|
input.
(1)
data received from an external source
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
process of entering data into an information-processing system or any of its parts for storage or processing
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(3)
data entered into an information processing system or any of its parts for storage or processing
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
input arc (of a transition).
(1)
arc directed from a place to the transition
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.12)
|
|
input argument.
(1)
designation given to an operation argument that will always have a value at the invocation of the operation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: output argument
|
|
input assertion.
(1)
logical expression specifying one or more conditions that program inputs satisfy in order to be valid
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: loop assertion, output assertion, inductive assertion, method
|
|
input loopback.
(1)
loopback of output from one function to be input for another function in the same diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.64)
|
|
input place (of a transition).
(1)
place connected to the transition by an input arc
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.13)
|
|
input primitive.
(1)
the effort to develop software products, expressed in units of staff-hours
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
input routine.
(1)
those activities required to obtain the logical record to be processed next
(ISO/IEC/IEEE 24765a:2011)
Note: If there are no more logical records to be processed, the end-of-input condition becomes true.
|
input-process-output.
(1)
software design technique that consists of identifying the steps involved in each process to be performed and identifying the inputs to and outputs from each step
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: A refinement called hierarchical input-process-output identifies the steps, inputs, and outputs at both general and detailed levels of detail.
See Also: data structure-centered design, input-process-output chart, modular decomposition, object-oriented design, rapid prototyping
 |
|
input-process-output (IPO) chart.
(1)
diagram of a software system or module, consisting of a rectangle on the left listing inputs, a rectangle in the center listing processing steps, a rectangle on the right listing outputs, and arrows connecting inputs to processing steps and processing steps to outputs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: summarizes the process activities and their inputs and outputs from/to external actors; some inputs are categorized as controls and enablers.
Syn: IPO diagram
See Also: block diagram, box diagram, bubble chart, flowchart, graph, structure chart
|
|
inspection.
(1)
static analysis technique that relies on visual examination of development products to detect errors, violations of development standards, and other problems
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
formal review of a work product to identify issues, which uses defined team roles and measurement to improve the review process
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.8)
(3)
examining or measuring to verify whether an activity, component, product, result, or service conforms to specified requirements
(ISO/IEC/IEEE 24765h:2019)
Note: Inspections are peer examinations led by impartial facilitators who are trained in inspection techniques. Determination of remedial or investigative action for an anomaly is a mandatory element of a software inspection, although the solution can be determined outside the inspection meeting. Types include code inspection and design inspection.
See Also: static testing
|
|
inspection-based evaluation.
(1)
evaluation based on the judgment of one or more evaluators who examine or use a system to identify potential usability problems, including deviations from established criteria
(ISO/IEC 25066:2016, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Common Industry Format (CIF) for Usability--Evaluation Report, 3.10)
Example: heuristic evaluation, cognitive walkthrough, standards inspection, pluralistic walkthrough, consistency inspection
Note: The evaluators making the inspections typically are usability specialists, but can also include end users and members of the design team. Inspection-based evaluation can be conducted by machines in some cases, e.g., when consistency with required terminology is being evaluated. Established criteria typically include user requirements, usability guidelines in standards, design conventions contained in manufacturer guidelines and style guides, task models to be supported, as well as standardized principles.
|
|
installability.
(1)
capability of a product to be effectively and efficiently installed successfully or uninstalled in a specified environment
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.8.3)
|
|
installation and checkout phase.
(1)
period of time in the software life cycle during which a software product is integrated into its operational environment and tested in this environment to help ensure that it performs as required
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
installation manual.
(1)
document that provides the information necessary to install a system or component, set initial parameters, and prepare the system or component for operational use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: diagnostic manual, operator manual, programmer manual, support manual, user manual
|
|
installed function point count.
(1)
an application function point count related to a set of installed systems
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
|
|
instance.
(1)
discrete, bounded thing with an intrinsic, immutable, and unique identity
(ISO/IEC/IEEE 24765n:2025, 3.1.89)
(2)
individual occurrence of a type
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
(3)
mapping of an activity that processes all of its input information and generates all of its output information
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
(4)
of a type, an <X> that satisfies the type
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.21)
|
|
instance of benchmarking.
(1)
set of operations, described specifically, used in the execution of a particular benchmarking according to a given method
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.6)
|
|
instance-level attribute.
(1)
mapping from the instances of a class to the instances of a value class
(ISO/IEC/IEEE 24765n:2025, 3.1.90)
|
|
instance-level operation.
(1)
mapping from the (cross product of the) instances of the class and the instances of the input argument types to the (cross product of the) instances of the other (output) argument types
(ISO/IEC/IEEE 24765n:2025, 3.1.91)
|
|
instance-level responsibility.
(1)
responsibility that applies to each instance of the class individually
(ISO/IEC/IEEE 24765n:2025, 3.1.92)
See Also: class-level responsibility
|
|
instantiated trace link.
(1)
trace link derived by applying binding in a member product
(ISO/IEC 26559:2017 Software and systems engineering -- Methods and tools for variability traceability in software and systems product line, 3.2)
|
|
instantiation.
(1)
substituting specific data, instructions, or both into a generic program unit to make it usable in a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
of an <X> template, an <X> produced from a given <X> template and other necessary information
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.16)
(3)
identification, for each instance of a life cycle process, of the success criteria, artifact-specific activities and tasks needed to achieve the process outcomes, and the competencies needed to perform these tasks, based on the characteristics and requirements of the target system element
(ISO/IEC 30103:2015 Software and Systems Engineering - Lifecycle Processes - Framework for Product Quality Achievement, 3.5)
|
|
institutional knowledge.
(1)
knowledge from accepted sources, including standards, academic sources, domain and industry bodies of knowledge and organizational knowledge
(ISO/IEC 30103:2015 Software and Systems Engineering - Lifecycle Processes - Framework for Product Quality Achievement, 3.4)
|
|
institutionalization.
(1)
ingrained way of doing business that an organization follows routinely as part of its corporate culture
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
instruction counter.
(1)
register that indicates the location of the next computer instruction to be executed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: program counter
|
|
instruction cycle.
(1)
process of fetching a computer instruction from memory and executing it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: instruction time
|
|
instruction format.
(1)
number and arrangement of fields in a computer instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: address field, address format, operation field
|
|
instruction length.
(1)
number of words, bytes, or bits needed to store a computer instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: instruction format
|
|
instruction modifier.
(1)
word or part of a word used to alter a computer instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
instruction set.
(1)
complete set of instructions recognized by a given computer or provided by a given programming language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: instruction repertoire
|
|
instruction time.
(1)
time it takes a computer to fetch an instruction from memory and execute it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: instruction cycle
|
|
instructional information.
(1)
information that explains how to use a product, system, or service to perform tasks
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.30)
|
|
instrument.
(1)
in software and system testing, to install or insert devices or instructions into hardware or software to monitor the operation of a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
instrumentation.
(1)
devices or instructions installed or inserted into hardware or software to monitor the operation of a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
integer type.
(1)
data type whose members can assume only integer values and can be operated on only by integer arithmetic operations, such as addition, subtraction, and multiplication
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: character type, enumeration type, logical type, real type
|
|
integrate.
(1)
to combine software components, hardware components, or both into an overall system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to pull in the changes from one child branch into its parent
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
integrated circuit (IC).
(1)
small piece of semiconductive material that contains interconnected electronic elements
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Syn: chip, microchip
|
|
integrated development environment (IDE).
(1)
set of software tools or applications to provide comprehensive facilities for software development
(ISO/IEC/IEEE 24765d:2015)
|
|
integrated repository.
(1)
planned and controlled storage of information pertinent to the systems engineering effort
(ISO/IEC/IEEE 24748-4:2016 Systems and software engineering-Life cycle management-Part 4: Systems engineering planning, 4.6)
Note: The integrated repository typically includes key data, e.g., schema, models, tools, technical management decisions, process analysis information, requirement changes, process and product metrics, trade-offs and other analyses.
|
|
integrated team.
(1)
group of people with complementary skills and expertise who are committed to delivering specified work products in timely collaboration
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Integrated team members provide skills and advocacy appropriate to all phases of the work products' life and are collectively responsible for delivering work products as specified. An integrated team includes empowered representatives from organizations, disciplines, and functions that have a stake in the success of the work products.
|
|
integration.
(1)
process of combining software components, hardware components, or both into an overall system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
process of planning for and aggregating a progressively more complete set of physical, logical, or both, system elements and activating their interfaces to synthesize a system or part of a system whose properties can be verified and possibly validated
(ISO/IEC/IEEE 24748-6:2023 Systems and software engineering Life cycle management Part 6: System and software integration, 3.1.4)
Note: Integration can apply to the implemented system elements which compose a system and the necessary life-cycle related activities.
|
|
integration test.
(1)
progressive linking and testing of programs or modules to help ensure their proper functioning in the complete system
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
See Also: integration testing
|
|
integration testing.
(1)
testing in which software components, hardware components, or both are combined and tested to evaluate the interaction among them
(ISO/IEC 29110-5-1-2:2025 Systems and software engineering Life cycle profiles for very small entities (VSEs) Part 5-1-2: Software engineering guidelines for the generic Basic profile, 3.16)
(2)
testing in which software components, hardware components, or both are combined and tested to evaluate the interaction between them
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.28)
|
|
integrity.
(1)
capability of a product to ensure that the state of its system and data are protected from unauthorized modification or deletion either by malicious action or computer error
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.6.2)
(2)
degree to which an IT service prevents unauthorized access to or modification of data, whether accidentally or intentionally
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.3.2)
See Also: immunity
|
|
integrity assurance authority.
(1)
independent person or organization responsible for certifying compliance with the integrity-level requirements
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.5.4)
|
|
integrity level.
(1)
value representing project-unique characteristic, such as complexity, criticality, risk, safety level, security level, desired performance, and reliability, that define the importance of the system, software, or hardware to the user
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1.15)
(2)
claim of a system, product, or element that includes limitations on a property's values, the claim's scope of applicability, and the allowable uncertainty regarding the claim's achievement
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.3.1)
(3)
degree of confidence that the system-of-interest meets the associated integrity level claim
(ISO/IEC/IEEE 15026-3:2023, Systems and software engineering--Systems and software assurance--Part 3: System integrity levels, 3.1)
Note: Generally, the intention is that maintaining limitations on a property's values related to the relevant items results in maintaining system risks within limits. The words 'integrity level' form an indivisible label and do not depend on a concept of integrity by itself. An integrity level is different from the likelihood that the integrity level claim is met but they are closely related. The word 'confidence' implies that the definition of integrity levels can be a subjective concept. integrity levels are defined in terms of risk and hence, cover safety, security, financial and any other dimension of risk that is relevant to the system-of-interest.
|
|
integrity level assurance authority.
(1)
independent person or organization responsible for certifying compliance with the integrity level requirements
(ISO/IEC/IEEE 15026-3:2023, Systems and software engineering--Systems and software assurance--Part 3: System integrity levels, 3.2)
|
|
integrity level claim.
(1)
proposition representing a requirement on a risk reduction measure identified in the risk treatment process of the system-of-interest
(ISO/IEC/IEEE 15026-3:2023, Systems and software engineering--Systems and software assurance--Part 3: System integrity levels, 3.4)
|
|
integrity level definition authority.
(1)
person or organization responsible for defining integrity levels and integrity level requirements
(ISO/IEC/IEEE 15026-3:2023, Systems and software engineering--Systems and software assurance--Part 3: System integrity levels, 3.3)
|
|
integrity level requirement.
(1)
set of requirements that, when met, will provide a level of confidence in the associated integrity level claim commensurate with the associated integrity level
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.3.2)
(2)
set of requirements (3.2.5) that, when met, will provide a level of confidence in the associated integritylevel claim (3.3.4) commensurate with the associated integrity level
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.3.2)
|
|
integrity level requirements.
(1)
set of specified requirements imposed on aspects related to a system, product, or element and associated activities in order to show the achievement of the assigned integrity level (that is, meeting its claim) within the required limitations on uncertainty; this includes the evidence to be obtained
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.3.2)
|
|
integrity level scheme.
(1)
set of system characteristics (such as complexity, risk, safety level, security level, desired performance, reliability, or cost) selected as important to stakeholders, and arranged into discrete levels of performance or compliance (integrity levels), to help define the level of quality control to be applied in developing or delivering the software
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
intellectual property.
(1)
output of creative human thought process that has some intellectual or informational value
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.19)
Example: microcomputer design or computer program
Note: Intellectual property can be protected by patents, copyrights, trademarks, or trade secrets.
|
|
intended use.
(1)
exhaustive range of functions or foreseen applications defined and designed by the supplier of the product
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.21)
Note: Functions or applications not listed by the supplier are excluded from the intended use of the product. Additional or modified functions or applications resulting from modifications not sanctioned by the supplier of the product are excluded from the intended use.
|
|
inter-integrated circuit bus (I2C).
(1)
bi-directional two-wire serial bus that provides a communication link between integrated circuits
(ISO/IEC/IEEE 24765d:2015)
|
|
interaction.
(1)
action that takes place with the participation of the environment of the object
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.3)
Note: The identity is expressed in relevant phenomenological terms. Generally, an interaction identity can be categorized as energy transfer, matter transfer, or information transfer.
|
|
interaction capability.
(1)
capability of a product to be interacted with by specified users to exchange information between a user and a system via the user interface to complete the intended task
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.4)
Note: Interaction capability is a prerequisite for usability. Interaction capability enables interaction by users to complete specific tasks in a variety of contexts of use. On the other hand, usability focuses on outcomes of use to determine whether tasks are achieved by users with effectiveness, efficiency and satisfaction in a specific context of use.
|
|
interaction group.
(1)
subset of the objects participating in a binding managed by the group function
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 13.4.1.1)
|
|
interaction point.
(1)
location at which there exists a set of interfaces
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.12)
|
|
interaction sequence.
(1)
exchange of information between a user and an interactive system via the user interface to complete an intended task or to navigate through the interactive system
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.2.3)
|
|
interactive.
(1)
pertaining to a system or mode of operation in which each user entry causes a response from or action by the system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
when the user communicates with the computer in a conversational-type manner
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
See Also: batch, conversational, online, real-time
|
|
interactive language.
(1)
nonprocedural language in which a program is created as a result of interactive dialog between the user and the computer system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The system provides questions, forms, and so on, to aid the user in expressing the results to be achieved.
See Also: declarative language, rule-based language
|
|
interactive system.
(1)
combination of hardware, software and/or services that receives input from and communicates output to users
(ISO/IEC 25063:2014 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) Common Industry Format (CIF) for usability: Context of use description)
(2)
combination of hardware or software or services or people that users interact with to achieve specific goals
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.1.2)
Note: This includes, where appropriate, packaging, user documentation, online and human help, support and training.
|
|
interchange reference point.
(1)
reference point at which an external physical storage medium can be introduced into the system
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 15.3.4)
|
|
interface.
(1)
point at which two or more logical, physical, or both, system elements or software system elements meet and act on or communicate with each other
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.33)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.20)
(2)
shared boundary between two functional units, defined by various characteristics pertaining to the functions, physical signal exchanges, and other characteristics
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(3)
abstraction of the behavior of an object that consists of a subset of the interactions of that object together with a set of constraints on when they can occur
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.5)
(4)
shared boundary between two systems or system elements, defined by functional characteristics, common physical interconnection characteristics, signal characteristics, or other characteristics
(INCOSE Systems Engineering Handbook, 5th ed.)
|
|
interface control.
(1)
in configuration management, the administrative and technical procedures and documentation necessary to identify functional and physical characteristics between and within configuration items provided by different developers, and to resolve problems concerning the specified interfaces
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
in configuration management, identifying the functional and physical characteristics relevant to the interfacing of configuration items and confirming that proposed changes to these characteristics are evaluated and approved prior to implementation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Interface control can involve one or multiple organizations.
See Also: configuration control
|
|
interface design document (IDD).
(1)
documentation that describes the architecture and design interfaces between system and components
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1.16)
(2)
description of the architecture and design of interfaces between system and components
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: These descriptions include control algorithms, protocols, data contents and formats, and performance.
See Also: interface requirements specification (IRS)
|
|
interface requirement.
(1)
requirement that specifies an external item with which a system or system component nteracts, or that sets forth constraints on formats, timing, or other factors caused by such an interaction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: design requirement, functional requirement, implementation requirement, performance requirement, physical requirement
|
|
interface requirements specification (IRS).
(1)
documentation that specifies requirements for interfaces between or among systems and components
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1.17)
Note: These requirements include constraints on formats and timing.
See Also: interface specification, interface design document
|
|
interface role.
(1)
role of a community, identifying behavior which takes place with the participation of objects that are not members of that community
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.3.5)
|
|
interface signature.
(1)
set of action signatures associated with the interactions of an interface
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.15)
|
|
interface specification.
(1)
description of essential functional, performance, and design requirements and constraints at a common boundary between two or more system elements
(ISO/IEC/IEEE 24765f:2016)
(2)
document that specifies the interface characteristics of an existing or planned system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: This includes interfaces between humans and hardware or software, as well as interfaces between humans themselves.
See Also: interface requirements specification
|
|
interface task.
(1)
task that is part of the application, which interfaces to the external environment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
interface testing.
(1)
testing conducted to evaluate whether systems or components pass data and control correctly to one another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: component testing, integration testing, system testing, unit test
|
|
interleave.
(1)
to alternate the elements of one sequence with the elements of one or more other sequences so that each sequence retains its identity
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: to alternately perform the steps of two different tasks in order to achieve concurrent operation of the tasks
|
|
intermediate product.
(1)
system or software product of the development process that is used as input to another stage of the development process
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.15)
Example: static and dynamic models, other documents, source code
Syn: intermediate software product, intermediate system product
|
|
intermediate profile.
(1)
profile targeted at very small entities (VSEs) involved in the development of more than one project in parallel with more than one work team
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.48)
|
|
intermediate software product needs.
(1)
needs that can be specified as quality requirements by internal measures
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
intermittent fault.
(1)
temporary or unpredictable fault in a component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: random failure, transient error
|
|
internal action.
(1)
action which takes place without the participation of the environment of the object
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.3)
|
|
internal arrow.
(1)
arrow connected at both ends (source and use) to a box in a diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.65)
See Also: boundary arrow
|
|
internal attribute.
(1)
measurable property of an entity which can be derived purely in terms of the entity itself
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Internal attributes are those that relate to the internal organization of the software and its development.
|
|
internal dependency.
(1)
relationship between two or more project activities
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
internal event.
(1)
means of synchronization between two tasks
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
internal logical file (ILF).
(1)
user-recognizable group of logically related data or control information maintained within the boundary of the application being measured
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.39)
Note: The primary intent of an ILF is to hold data maintained through one or more elementary processes of the application being counted. An internal logical file is a type of base functional component.
See Also: external interface file
|
|
internal measure.
(1)
measure of the product itself, either direct or indirect
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The number of lines of code, complexity measures, the number of faults found in a walk through and the Fog Index are all internal measures made on the product itself.
|
|
internal measure of software quality.
(1)
measure of the degree to which a set of static attributes of a software product satisfies stated and implied needs for the software product to be used under specified conditions
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.16)
Example: Complexity measures and the number, severity, and failure frequency of faults found in a walkthrough are internal software quality measures made on the product itself.
Note: Static attributes include those that relate to the software architecture, structure and its components. Static attributes can be verified by review, inspection, simulation, or automated tools.
See Also: external measure of software quality
|
|
internal quality.
(1)
totality of attributes of a product that determine its ability to satisfy stated and implied needs when used under specified conditions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
internal service provider.
(1)
person or organization providing services internal to the very small entity (VSE)
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.49)
|
|
internal task-structuring criteria.
(1)
category of the task-structuring criteria addressing how internal objects are mapped to internal tasks and when an internal task is activated
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
internal variability.
(1)
variability defined from an engineer's perspective and not visible to customers
(ISO/IEC 26555:2015 Software and systems engineering--Tools and methods for product line technical management, 3.6)
|
|
internationalization.
(1)
process of developing information so that it is suitable for an international audience
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.31)
See Also: localization
|
|
Internet.
(1)
worldwide interlinked computer systems and networks connected by gateways that enable the transfer of data between them
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.13)
|
|
interoperability.
(1)
capability of a product to exchange information with other products and mutually use the information that has been exchanged
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.3.2)
(2)
capability of objects to collaborate, that is, the capability mutually to communicate information in order to exchange events, proposals, requests, results, commitments and flows
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.5)
(3)
capability to communicate, execute programs, and transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: Interoperability is used in place of compatibility in order to avoid possible ambiguity with replaceability.
See Also: compatibility
|
|
interoperability testing.
(1)
testing conducted to help ensure that a modified system retains the capability of exchanging information with systems of different types, and of using that information
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
interoperating system.
(1)
system that exchanges information with the system-of-interest and uses the information that has been exchanged
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.34)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.20)
|
|
interpersonal and team skills.
(1)
skills used to effectively lead and interact with team members and other stakeholders
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
interpersonal skills.
(1)
skills used to establish and maintain relationships with other people
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
interpret.
(1)
to translate and execute each statement or construct of a computer program before translating and executing the next
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assemble, compile
|
|
interpretability.
(1)
level of understanding how the underlying technology works
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.42)
|
|
interpreter.
(1)
computer program that translates and executes each statement or construct of a computer program before translating and executing the next
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assembler, compiler
|
|
interpretive code.
(1)
computer instructions and data definitions expressed in a form that can be recognized and processed by an interpreter
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assembly code, compiler code, machine code
|
|
interrogation.
(1)
interaction consisting of one interaction, the invocation, initiated by a client object, resulting in the conveyance of information from that client object to a server object, and requesting a function to be performed by the server object, followed by a second interaction, the termination, initiated by the server object, resulting in the conveyance of information from the server object to the client object in response to the invocation
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.4)
Example: request/response exchange
Note: In interrogations, invocations and terminations are always paired. Announcements do not have terminations. Thus, there is no possibility of an operation consisting of an invocation followed by a sequence of associated terminations.
|
|
interrupt.
(1)
suspension of a process to handle an event external to the process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to cause the suspension of a process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
loosely, an interrupt request
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: interruption
See Also: interrupt latency, interrupt mask, interrupt priority, interrupt service routine, priority interrupt
|
|
interrupt controller.
(1)
functional unit (integrated circuit) that determines the source and priority of interrupt requests and manages their execution
(ISO/IEC/IEEE 24765d:2015)
|
|
interrupt latency.
(1)
delay between a computer system's receipt of an interrupt request and its handling of the request
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: interrupt priority
|
|
interrupt mask.
(1)
mask used to enable or disable interrupts by retaining or suppressing bits that represent interrupt requests
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
interrupt priority.
(1)
importance assigned to a given interrupt request
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: This importance determines whether the request will cause suspension of the current process and, if there are several outstanding interrupt requests, which will be handled first.
|
|
interrupt request.
(1)
signal or other input requesting that the currently executing process be suspended to permit performance of another process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
interrupt service routine.
(1)
routine that responds to interrupt requests by storing the contents of critical registers, performing the processing required by the interrupt request, restoring the register contents, and restarting the interrupted process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: ISR
|
|
interval scale.
(1)
scale in which the measurement values have equal distances corresponding to equal quantities of the attribute
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: Cyclomatic complexity has the minimum value of one, but each increment represents an additional path. The value of zero is not possible.
See Also: ordinal scale, nominal scale, ratio scale
|
|
intervenability.
(1)
degree to which an operator can intervene in an AI systems functioning in a timely manner to prevent harm or hazard
(ISO/IEC 25059:2023, Software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model for AI systems, 3.2.4)
|
|
interworking reference point.
(1)
reference point at which an interface can be established to allow communication between two or more systems
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 15.3.3)
|
|
Intranet.
(1)
managed network operating within an organization with controlled and limited access
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.14)
Note: More than one connected or isolated intranet can exist within an organization.
Syn: intranet
|
|
intrinsic.
(1)
specification that a property is total (i.e., mandatory), single-valued, and constant
(ISO/IEC/IEEE 24765n:2025, 3.1.94)
|
|
intrinsic relationship.
(1)
relationship that is total, single-valued, and constant from the perspective of (at least) one of the participating classes, referred to as a dependent class
(ISO/IEC/IEEE 24765n:2025, 3.1.95)
Example: A transaction has an intrinsic relationship to its related account, because it makes no sense for an instance of a transaction to "switch" to a different account, since that would change the very nature of the transaction.
Note: Such a relationship is considered to be an integral part of the essence of the dependent class.
See Also: nonintrinsic relationship
|
|
introduction.
(1)
of an <X>, instantiating not achieved by an action of objects in the model
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.19)
See Also: creation
|
|
invariant.
(1)
assertion that is always be true for a specified segment or at a specified point of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
predicate that a specification requires to be true for the entire life time of a set of objects
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.28)
|
|
invariant schema.
(1)
set of predicates on one or more information objects which are always true
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 6.1.1)
Note: The predicates constrain the possible states and state changes of the objects to which they apply. Thus, an invariant schema is the specification of the types of one or more information objects that will always be satisfied by whatever behavior the objects exhibit.
|
|
invitation for bid (IFB).
(1)
request for prices from suppliers where the deliverable is a specified commodity and price is the only discriminator
(ISO/IEC/IEEE 24765n:2025)
|
|
invocation.
(1)
mapping of a parallel initiation of activities of an integral activity group that perform a distinct function and return to the initiating activity
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
See Also: instance, iteration, mapping
|
|
invocation deliver.
(1)
signal in the implicitly defined signal interface of a server computational object which has the same name and parameters as the invocation of an interrogation or announcement in the original operation interface
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.8)
|
|
invocation submit.
(1)
signal in the implicitly defined signal interface of a client computational object which has the same name and parameters as the invocation of an interrogation or announcement in the original operation interface
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.7)
See Also: termination submit
|
|
IOC.
(1)
initial operational capability
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
IoT.
(1)
internet of things
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.2)
|
|
IOT&E.
(1)
initial operational test and evaluation
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
IP.
(1)
Internet Protocol
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
IPO chart.
(1)
input-process-output chart
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
IPR.
(1)
intellectual property rights
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
IPSE.
(1)
integrated programming support environment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: programming support environment
|
|
IPT.
(1)
integrated product team
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
IRR.
(1)
integration readiness review
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
irreducible.
(1)
decision attribute (criterion) that cannot be expressed in terms of money
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
IRS.
(1)
interface requirements specification
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
IS.
(1)
international standard
(ISO/IEC/IEEE 24765a:2011)
|
|
ISBN.
(1)
international standard book number
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
ISC.
(1)
integration services components
(ISO/IEC/IEEE 24748-6:2023 Systems and software engineering Life cycle management Part 6: System and software integration, 3.2)
|
|
ISO.
(1)
International Organization for Standardization
(ISO/IEC/IEEE 24765i:2020)
|
|
ISO file.
(1)
file image of an entire CD or DVD that is encoded according to ISO 9660
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
|
|
isochronicity.
(1)
relation between adjacent pairs of actions in a sequence, in which every adjacent pair of actions occupies unique, equally-sized, adjacent intervals in time
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.3.2)
|
|
isolation.
(1)
for a cloud service, degree to which computations and data are isolated from and inaccessible by other customers, in the situation that physical and virtual resources are shared
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.5.3)
|
|
ISP.
(1)
in-system programming
(ISO/IEC/IEEE 24765d:2015)
(2)
in-service period
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
ISR.
(1)
interrupt service routine
(ISO/IEC/IEEE 24765d:2015)
|
|
ISRM.
(1)
in-service reference model
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
issue.
(1)
observation that deviates from expectations
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.9)
(2)
point or matter in question or in dispute, or a point or matter that is not settled and is under discussion or over which there are opposing views or disagreements
(ISO/IEC/IEEE 24765h:2019)
(3)
current condition or situation that may have an impact on the project objectives
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Example: potential defect, improvement, or point needing clarification
Note: The record of an issue includes its identifier and brief description, and often identifies the environment associated with it, its status, severity, priority, and resolution, as well as dependencies, details on replicating or solving a problem, the persons associated with it, attachments, and its change history.
See Also: problem report
|
|
issue log.
(1)
project document used to monitor elements under discussion or in dispute between project stakeholders
(ISO/IEC/IEEE 24765h:2019)
(2)
project document where information about issues is recorded and monitored
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
IT.
(1)
information technology
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
IT asset.
(1)
item, thing, or entity that can be used to acquire, process, store and distribute digital information and has potential or actual value to an organization
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.25)
Example: software, media (physical and digital); IT equipment (physical and virtual); licenses (including proof of license); contracts; and IT asset management systems, tools, and the metadata needed to manage all IT assets; services to meet IT asset management requirements, such as software as a service, hardware maintenance, software support, and training.
Note: Information per se, independent of IT hardware and software assets, can be considered an asset, but it is not considered an IT asset. The collective set of IT assets is also referred to as the IT infrastructure.
Syn: information technology asset
See Also: digital asset
|
|
IT asset management (ITAM).
(1)
coordinated activity of an organization to realize value from IT assets
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.26)
Syn: information technology asset management
|
|
IT asset management plan.
(1)
documented information that specifies the activities, resources and timescales required for an individual information technology (IT) asset, or a grouping of IT assets, to achieve the organization's IT asset management objectives
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.27)
Syn: information technology asset management plan
|
|
IT asset management system (ITAMS).
(1)
management system for information technology (IT) asset management, whose function is to establish the IT asset management policy and IT asset management objectives
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.28)
Syn: information technology asset management system
|
|
IT asset portfolio.
(1)
IT assets that are within the scope of the IT asset management system
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.29)
Note: A portfolio is typically established and assigned for managerial control purposes. Portfolios for IT hardware can be defined by category (e.g. servers, PCs, mobile devices). Software portfolios can be defined by software publisher, or by platform (e.g. PC, server, mainframe). An IT asset management system can encompass multiple IT asset portfolios.
Syn: information technology asset portfolio
See Also: asset portfolio
|
|
IT infrastructure.
(1)
all the technical components, system software, databases and data files and deployed application software, technical procedures, and technical documentation used to make the information available
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.22)
(2)
combined set of IT assets for developing, maintaining, and using IT services
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.30)
Syn: information technology infrastructure
|
|
IT infrastructure management.
(1)
domain responsible for all of the tasks and activities aimed at managing, maintaining, and renewing the IT infrastructure of the information system, including the operation of the information system
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.23)
Note: IT infrastructure management includes all of the tasks, responsibilities and activities that aim for a correct technical operation of the information system, consisting of hardware, (system) software, and data sets.
The IT infrastructure management organization is responsible for running the application software in the production environment.
Syn: information technology infrastructure management
|
|
IT project dataset.
(1)
classified group of data records, into which collected data records are selected by pre-defined criteria
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 3.17)
Syn: information technology project dataset
|
|
IT service.
(1)
service that makes use of information technology (IT) systems as tools to provide value to an individual user or a business by facilitating results the user or business wants to achieve
(ISO/IEC 25002:2024, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model overview and usage, 3.11)
Note: Users include customers and service providers.
Syn: information technology service
|
|
IT service adaptability.
(1)
degree to which an IT service can configure itself or be modified to meet new needs
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.7)
Syn: information technology service adaptability
See Also: adaptability
|
|
IT service function.
(1)
collection of related steps performed as a part of an IT service, or features provided by an IT system
(ISO/IEC TS 25025:2021, Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Measurement of IT service quality, 3.4)
Example: service status monitoring or data backup of an internet banking service
Syn: information technology service function
|
|
IT service interface appearance.
(1)
degree to which the interface of the service has an appearance or other physical properties that are pleasing and satisfying for the user
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.5.3)
Syn: information technology service interface appearance
|
|
IT service maintainability.
(1)
degree of effectiveness and efficiency with which the IT service can be modified by the service provider
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.8)
Syn: information technology service maintainability
|
|
IT service quality.
(1)
capability of an IT service to satisfy stated and implied quality needs when delivered under specified conditions
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.3.5)
(ISO/IEC 25002:2024, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model overview and usage, 3.13)
(2)
degree to which an IT service satisfies stated and implied needs when used under specified conditions
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.3.10)
Syn: information technology service quality
|
|
IT service recoverability.
(1)
degree to which, in the event of an interruption or a failure or disaster, the original IT service and its functions and data can be re-established and made accessible
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.4.2)
Syn: information technology service recoverability
See Also: recoverability
|
|
IT service reliability.
(1)
degree to which an IT service provides consistent and stable IT service outcomes
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.4)
Syn: information technology service reliability
See Also: reliability, software reliability
|
|
IT service system.
(1)
system that is comprised of an IT service and the people who use it (users) in a given (user) environment to satisfy their service needs
(ISO/IEC 25002:2024, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model overview and usage, 3.12)
Syn: information technology service system
|
|
IT system.
(1)
system which uses information technologies
(ISO/IEC TR 12182:2015 Systems and software engineering--Framework for categorization of IT systems and software, and guide for applying it, 3.3)
(2)
set of one or more computers, associated software, peripherals, terminals, human operations, physical processes, information transfer means, that form an autonomous whole, capable of performing information processing and/or information transfer
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.3.5)
|
|
ITAM.
(1)
information technology asset management
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.26)
Syn: IT asset management
|
|
ITAMS.
(1)
information technology asset management system
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.28)
Syn: IT asset management system
|
|
iteration.
(1)
repeating the application of the same process or set of processes on the same level of the system structure
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.28)
(2)
short time frame in which a set of software features is developed, leading to a working product that can be demonstrated to stakeholders
(ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 3.10)
(3)
timeboxed cycle of development on a product or deliverable in which all of the work that is needed to deliver value is performed
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: In agile, a typical iteration length is two to four weeks.
See Also: instance, invocation, mapping, sprint
|
|
iteration backlog.
(1)
subset of a backlog chosen for inclusion in the current iteration
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.19)
|
|
iteration plan.
(1)
detailed plan for the current iteration
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
iteration planning.
(1)
meeting to clarify the details of the backlog items, acceptance criteria, and work effort required to meet an upcoming iteration commitment
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
iteration review.
(1)
meeting held at the end of an iteration to demonstrate the work that was accomplished during the iteration
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
iterative approach.
(1)
development approach that focuses on an initial, simplified implementation, then progressively elaborates, adding to the feature set until the final deliverable is complete
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
iterative development.
(1)
repeated use of concurrent planning, developing, and testing activities
(ISO/IEC/IEEE 26515: 2018 Systems and software engineering: Developing information for users in an agile environment, 3.11)
|
|
iterative process.
(1)
repeated process in which the output is evaluated and used as input for the next cycle
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
ITT.
(1)
invitation to tender
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 3.2)
|
|
IV&V.
(1)
independent verification and validation
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
(2)
integration, verification, and validation
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
Syn: IV & V, IVV, IV and V
|
|
IXIT.
(1)
Implementation Extra Information for Testing
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
Example: null
Syn: Implementation extra Information for Test
|
|
JCIDS.
(1)
joint capabilities integration and development system
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
JCL.
(1)
job control language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
JDK.
(1)
Java development kit
(ISO/IEC/IEEE 24765m:2024)
|
|
JFC.
(1)
Java Foundation Class
(ISO/IEC/IEEE 24765l:2024)
|
|
JNDI.
(1)
Java naming and directory interface
(ISO/IEC/IEEE 24765l:2024)
|
|
job.
(1)
user-defined unit of work that is to be accomplished by a computer
(ISO/IEC 25023:2016, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Measurement of system and software product quality, 4.3)
Example: the compilation, loading, and execution of a computer program
See Also: job control language, job step, job stream
|
|
job control language (JCL).
(1)
language used to identify a sequence of jobs, describe their requirements to an operating system, and control their execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
job function.
(1)
group of engineering processes that is identified as a unit for the purposes of work organization, assignment, or evaluation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: design, testing, or configuration management
|
|
job step.
(1)
user-defined portion of a job, explicitly identified by a job control statement
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: A job consists of one or more job steps.
|
|
job stream.
(1)
sequence of programs or jobs set up so that a computer can proceed from one to the next without the need for operator intervention
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: run stream
|
|
join.
(1)
junction at which an arrow segment (going from source to use) merges with one or more other arrow segments to form a root arrow segment
(ISO/IEC/IEEE 24765m:2024, 2.1.66)
Example: null
Note: can denote bundling of arrows, meaning the inclusion of multiple object types within an object type set
|
|
joining action.
(1)
action shared between two or more chains resulting in a single chain
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.1.3)
|
|
JPEG.
(1)
Joint Photographic Experts Group
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
Note: image format
|
|
JPG.
(1)
Joint Photographic Group
(ISO/IEC/IEEE 24765l:2024)
Note: image format
|
|
JSOn.
(1)
JavaScript Object Notation
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.2)
|
|
JTA.
(1)
Java Transaction API
(ISO/IEC/IEEE 24765l:2024)
|
|
jump.
(1)
to depart from the implicit or declared order in which computer program statements are being executed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
program statement that causes a departure from consecutive execution of program statements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: transfer
|
|
junction.
(1)
point at which either a root arrow segment divides into branching arrow segments or arrow segments join into a root arrow segment
(ISO/IEC/IEEE 24765m:2024, 2.1.67)
|
|
JWT.
(1)
JSON (JavaScript Object Notation) web token
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.2)
|
|
KA.
(1)
knowledge area
(ISO/IEC 24773-4:2023 Software and systems engineering Certification of software and systems engineering professionals Part 4: Software engineering, 3.1)
|
|
Kanban board.
(1)
visualization tool that shows work in progress to help identify bottlenecks and overcommitments, thereby allowing the team to optimize the workflow
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
visual representation of an agile team's progress within an iteration
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary)
(3)
in software development, a visual representation of work for developers who pull tasks from the task backlog; used for on-demand or resource-bound scheduling
(Software Extension to the PMBOK(R) Guide Fifth Edition)
Syn: scrum board, task board, workflow board
|
|
kernel.
(1)
that portion of an operating system that is kept in main memory at all times
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
a software module that encapsulates an elementary function or functions of a system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: resident control program
See Also: nucleus, supervisory program
|
|
kernel entity.
(1)
a classification used for a meta-entity whose instances can exist without the occurrences of other meta-entities
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Example: An instance of the meta-entity called Attribute, having a name, full description and brief description, is significant without the knowledge of the DataObject it describes.
|
|
key migration.
(1)
in data modeling, placing the primary key of a parent or generic entity in its child or category entity as a foreign key
(ISO/IEC/IEEE 24765n:2025, 3.1.96)
Note: [key style]
|
|
key-style view.
(1)
view that represents the structure and semantics of data within an enterprise
(ISO/IEC/IEEE 24765n:2025, 3.1.97)
Note: That is, data (information) models.
|
|
keyword.
(1)
one or more words used as a reference to a specific set of actions intended to be performed during the execution of one or more test cases
(ISO/IEC/IEEE 29119-5:2024 Software and systems engineering--Software testing--Part 5: Keyword-driven testing, 3.5)
Note: The actions include interactions with the user interface during the test, verification, and specific actions to set up a test scenario. Keywords are named using at least one verb. Keywords often have parameters so they can be used with different data.
|
|
keyword dictionary.
(1)
repository containing a set of keywords reflecting the language and level of abstraction used to write test cases
(ISO/IEC/IEEE 29119-5:2024 Software and systems engineering--Software testing--Part 5: Keyword-driven testing, 3.9)
Syn: keyword library
|
|
keyword execution code.
(1)
implementation of a keyword that is intended to be executed by a test execution engine
(ISO/IEC/IEEE 29119-5:2024 Software and systems engineering--Software testing--Part 5: Keyword-driven testing, 3.12)
|
|
keyword test case.
(1)
sequence of keywords and the required values for their associated parameters (as applicable) that are composed to describe the actions of a test case
(ISO/IEC/IEEE 29119-5:2024 Software and systems engineering--Software testing--Part 5: Keyword-driven testing, 3.13)
|
|
keyword-driven testing.
(1)
testing using test cases composed from keywords
(ISO/IEC/IEEE 29119-5:2024 Software and systems engineering--Software testing--Part 5: Keyword-driven testing, 3.10)
|
|
keyword-driven testing framework.
(1)
test framework covering the functional capabilities of a keyword-driven editor, decomposer, data sequencer, keyword library, data repository, test environment, and including organizational processes that define their interaction and use
(ISO/IEC/IEEE 29119-5:2024 Software and systems engineering--Software testing--Part 5: Keyword-driven testing, 3.11)
|
|
kickoff meeting.
(1)
gathering of team members and other key stakeholders at the outset of a project to formally set expectations, gain a common understanding, and commence work
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
kNN.
(1)
k-nearest neighbors
(ISO/IEC/IEEE 24765j:2021)
|
|
knowledge.
(1)
aspect of an instance's specification that is determined by the values of its attributes, participant properties, and constant, read-only operations
(ISO/IEC/IEEE 24765n:2025, 3.1.98)
(2)
mixture of experience, values and beliefs, contextual information, intuition, and insight that people use to make sense of new experiences and information
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
knowledge area (KA).
(1)
identified group of knowledge
(ISO/IEC 24773-4:2023 Software and systems engineering Certification of software and systems engineering professionals Part 4: Software engineering, 3.1)
(2)
sub-area or grouping of related topics within a body of knowledge (BOK)
(ISO/IEC 24773-2:2024, Software and systems engineering Certification of software and systems engineering professionals Part 2: Guidance regarding description of knowledge, skills, and competencies contained in schemes, 3.1)
|
|
knowledge base (K-base).
(1)
database that contains inference rules and information about human experience and expertise in a domain
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: In self-improving systems, the knowledge base additionally contains information resulting from the solution of previously encountered problems
|
|
knowledge management.
(1)
multi-disciplinary process of obtaining, preserving, sharing, using, and refreshing knowledge
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
Note: In DevOps, knowledge management guides and facilitates the automation of system operations, system problem identification and remediation, and reporting system health.
|
|
known error.
(1)
result of a problem with an identified root cause or an identified workaround that reduces or eliminates its impact
(ISO/IEC/IEEE 24765c:2014)
|
|
KOPS.
(1)
kilo-operations per second; that is, thousands of operations per second
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: a measure of computer processing speed
See Also: MFLOPS, MIPS
|
|
KPI.
(1)
key performance indicator
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
|
|
KPP.
(1)
key performance parameter
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
KSA.
(1)
key system attribute
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
(2)
knowledge, skills and abilities
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
label.
(1)
a name or identifier assigned to a computer program statement to enable other statements to refer to that statement
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
one or more characters, within or attached to a set of data, that identify or describe the data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
a word or phrase that is attached to, or part of, a model graphic
(ISO/IEC/IEEE 24765n:2025, 3.1.99)
(4)
information associated with the net graph or one of its objects
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.5)
(5)
item, attached to a product (if practicable) or its packaging, which displays information related to one or more characteristics of the product
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.22)
|
|
lag.
(1)
amount of time whereby a successor activity is required to be delayed with respect to a predecessor activity
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
language.
(1)
systematic means of communicating ideas by the use of conventionalized signs, sounds, gestures, or marks and rules for the formation of admissible expressions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
means of communication, with syntax and semantics, consisting of a set of representations, conventions, and associated rules used to convey information
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
language binding.
(1)
wrapper for a programming language to allow access to a library written in another programming language
(ISO/IEC/IEEE 24765l:2024)
Syn: language mapping
|
|
language processor.
(1)
computer program that translates, interprets, or performs other tasks required to process statements expressed in a given language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assembler, compiler, interpreter, translator
|
|
language standard.
(1)
standard that describes the characteristics of a language used to describe a requirements specification, a design, or test data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
last responsible moment.
(1)
concept of deferring a decision to allow the team to consider multiple options until the cost of further delay would exceed the benefit
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
late binding.
(1)
the assignment of tasks to specific resources when the resources are available to start work, rather than when the project is planned
(Software Extension to the PMBOK(R) Guide Fifth Edition)
|
|
latency.
(1)
time interval between the instant at which an instruction control unit issues a call for data and the instant at which the transfer of data is started
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
latent variable.
(1)
variable representing a unidimensional construct
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.8)
|
|
lateral compression.
(1)
in software design, a form of demodularization in which two or more modules that execute one after the other are combined into a single module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: downward compression, upward compression
|
|
layer.
(1)
partition resulting from the functional division of a software system, where layers are organized in a hierarchy; there is only one layer at each level in the hierarchy; there is a superior/subordinate hierarchical dependency between the functional services provided by software in any two layers in the software system that exchange data directly; and the software in any two layers in the software system that exchange data interpret only part of that data identically
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.15)
|
|
layout.
(1)
physical organization of source code including the use of white space, grouping, blank lines, alignment, indentation, and parentheses
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
LCA.
(1)
life cycle assessment
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
LCC.
(1)
life-cycle cost
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
LCCE.
(1)
life-cycle cost estimate
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
LCL.
(1)
local coincidence logic
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
LCMS.
(1)
Learning Content Management System
(ISO/IEC/IEEE 24765l:2024)
|
|
LCSP.
(1)
life cycle sustainment plan
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
lead.
(1)
amount of time whereby a successor activity can be advanced with respect to a predecessor activity
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: lag
|
|
lead startup canvas.
(1)
one-page template designed to communicate a business plan with key stakeholders in an efficient and effective manner
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
lead time.
(1)
time between a customer request and the actual delivery
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
lead time chart.
(1)
diagram showing the trend over time of the average lead time of the items completed in work
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
leadframe.
(1)
framework of a semiconductor device, made of plated metal
(ISO/IEC/IEEE 24765e:2015)
Syn: lead frame
|
|
leading decision.
(1)
loop control that is executed before the loop body
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: trailing decision, WHILE
|
|
leaf diagram.
(1)
diagram that has no descendent diagrams
(ISO/IEC/IEEE 24765m:2024, 2.1.68)
Note: That is, a diagram that does not contain any function that has been decomposed.
|
|
leaf node.
(1)
function that is not decomposed
(ISO/IEC/IEEE 24765m:2024, 2.1.69)
Note: A box that represents a leaf node does not have a box detail reference.
|
|
learnability.
(1)
capability of a product to have specified users learn to use specified product functions within a specified amount of time
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.4.2)
(2)
degree to which an IT service can be learned by users to achieve a specified level of effectiveness, efficiency, freedom from risk and satisfaction within a specified amount of time and context of use
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.2.2)
|
|
left-shift.
(1)
prioritizing the involvement of relevant stakeholders in applying quality activities, security, privacy, performance, verification, and validation earlier in the life cycle
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
|
|
legacy hardware.
(1)
hardware originally created without native information structures
(ISO/IEC 19770-6:2024, Information technology IT asset management Part 6: Hardware identification tag, 3.1.5)
|
|
legacy software.
(1)
software originally created without information structures
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.17)
|
|
legal feasibility.
(1)
determination that the system of interest is consistent with applicable laws and regulations
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
|
|
legend.
(1)
in the context of an architecture description, an informal documentation of conventions
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.19)
|
|
lessons learned.
(1)
knowledge gained during a project which shows how project events were addressed or should be addressed in the future with the purpose of improving future performance
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
lessons learned register.
(1)
project document used to record knowledge gained during a project so that it can be used in the current project and entered into the lessons learned repository
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
level.
(1)
designation of the coverage and detail of a view
(ISO/IEC/IEEE 24765n:2025, 3.1.100)
Note: There are multiple levels of view; each is intended to be distinct, specified in terms of the modeling constructs to be used.
|
|
level of abstraction.
(1)
view of an object at a specific level of detail
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.1.12)
|
|
level of effort (LOE).
(1)
support activity which does not produce definitive end products, generally characterized by a uniform rate of work performance over a period of time determined by the activities supported
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: customer liaison, project cost accounting, project management
Note: One of three EVM types of activities used to measure work performance
|
|
level of risk.
(1)
magnitude of a risk or combination of risks, expressed in terms of the combination of consequences and their likelihood
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.3.5)
|
|
level of service.
(1)
parameters, or combination of parameters, which reflect social, political, environmental and economic outcomes that the organization delivers
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.31)
|
|
Levenshtein distance.
(1)
measure of the difference between two character sequences based on the minimum number of single character edits (insertion, deletion, or substitution) needed to convert one word to the other
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.21)
|
|
lexicography.
(1)
decision technique that prioritizes the decision attributes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: dominance, satisficing
|
|
LFT&E.
(1)
live fire test and evaluation
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
liaison.
(1)
relationship between a set of objects which results from the performance of some establishing behavior
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.2.4)
(2)
state of having a contractual context in common
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.2.4)
|
|
library.
(1)
place containing collections of work products and useful information items for people to read, borrow or refer to, and for machines to access and retrieve data from
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.10)
Note: In a repository, work products and other items are preserved for future retrieval when needed, whereas in a library, working data is temporarily stored and retrieved as necessary.
|
|
license.
(1)
legal agreement between two parties, the licensor and the licensee, as to the terms and conditions for the use or transfer of an intellectual property right from the licensor to the licensee
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
license compliance audit.
(1)
audit that reconciles license-related information from multiple information sources, such as entitlement consumption against entitlement rights
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
license model.
(1)
class of licenses with common characteristics
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: site license, OEM license, per computer license
|
|
licensing standard.
(1)
standard that describes the characteristics of an authorization given by an official or a legal authority to an individual or organization to do or own a specific thing
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
life cycle.
(1)
evolution of a system, product, service, project or other human-made entity from conception through retirement
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.26)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.21)
(2)
stages involved in the management of an asset
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.32)
(3)
<entity> set of distinguishable phases or stages that an entity goes through from its conceptualization until it ceases to exist
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.11)
(4)
<architecture> set of distinguishable phases or stages that an architecture goes through
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.12)
Note: In DevOps, the systems life cycle is supported by automated elements that produce meaningful and actionable audit logs.
Syn: lifecycle, life-cycle
|
|
life cycle assessment (LCA).
(1)
tool used to evaluate the total environmental impact of a product, process, or system
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
life cycle cost.
(1)
total cost of a system over its entire life
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: It includes all costs associated with the system and its use in the concept, development, production, utilization, support, and retirement stages.
Syn: life-cycle cost, LCC
|
|
life cycle model.
(1)
framework of processes and activities concerned with the life cycle that can be organized into stages, acting as a common reference for communication and understanding
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.37)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.22)
(2)
framework containing the processes, activities, and tasks involved in the development, operation, and maintenance of a software product, spanning the life of the system from the definition of its requirements to the termination of its use
(ISO/IEC 15940:2013 Systems and software engineering--Software Engineering Environment Services, 2.1)
Syn: life-cycle model
|
|
life cycle processes.
(1)
set of interrelated or interacting activities that result in the development or assessment of system, software, or hardware products
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
Note: Each activity consists of tasks. The life cycle processes can overlap one another. For V&V purposes, no process is concluded until its development products are verified and validated according to the defined tasks in the validation and verification plan.
Syn: life-cycle processes
|
|
lightweight process.
(1)
process with a single thread of control; a task
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
likelihood.
(1)
probability of something happening
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.3.6)
(2)
chance of something happening
(ISO/IEC/IEEE 16085:2021 Systems and software engineering--Life cycle processes--Risk management, 3.2)
Note: Refers to the chance of something happening, whether defined, measured, or determined objectively or subjectively, qualitatively or quantitatively, and described using general terms or mathematically (such as a probability or a frequency over a given time period).
|
|
limit.
(1)
restriction on rights or privileges granted by a software entitlement
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.16)
|
|
limited entry table.
(1)
decision table where all the conditions and actions are completely described without reference to the rules
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.14)
|
|
line of code.
(1)
programming-language statement; a non-comment, nonblank deliverable source statement
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
linear interpolation.
(1)
approximation of the value of a function at a given point, based on values on a straight line between two known points
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
link.
(1)
reference from some part of one document to some part of another document or another part of the same document
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.15)
(2)
part of a computer program, often a single instruction or address, which passes control and parameters between separate modules of the program
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.22)
Syn: hyperlink
See Also: linkage editor
|
|
linkage editor.
(1)
computer program that creates a single load module from two or more independently translated object modules or load modules by resolving cross-references among the modules and, possibly, by relocating elements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: can be part of a loader
Syn: linker
See Also: linking loader
|
|
linking loader.
(1)
computer program that reads one or more object modules into main memory in preparation for execution, creates a single load module by resolving cross-references among the separate modules, and, in some cases, adjusts the addresses to reflect the storage locations into which the code has been loaded
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: absolute loader, relocating loader, linkage editor
|
|
list.
(1)
set of data items, each of which has the same data definition
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to print or otherwise display a set of data items
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
collection class that contains no duplicates and whose members are ordered
(ISO/IEC/IEEE 24765n:2025, 3.1.101)
|
|
list processing language.
(1)
programming language designed to facilitate the manipulation of data expressed in the form of lists
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: LISP, IPL
See Also: algebraic language, algorithmic language, logic programming language
|
|
listing.
(1)
ordered display or printout of data items, program statements, or other information
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
literal.
(1)
in a source program, an explicit representation of the value of an item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
denotation of a specific instance of a value class
(ISO/IEC/IEEE 24765n:2025, 3.1.102)
(3)
number or string that is used by a program directly rather than being embedded in a named constant or variable
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
LITSR.
(1)
level interim test status report
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
load.
(1)
to read machine code into main memory in preparation for execution and, in some cases, to perform address adjustment and linking of modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to copy computer instructions or data from external storage to internal storage or from internal storage to registers
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: loader
|
|
load map.
(1)
computer-generated list that identifies the location or size of all or selected parts of memory-resident code or data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
load module.
(1)
computer program or subprogram in a form suitable for loading into main storage for execution by a computer; usually the output of a linkage editor
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: object module
|
|
load testing.
(1)
type of performance efficiency testing conducted to evaluate the behavior of a test item under anticipated conditions of varying load, usually between anticipated conditions of low, typical, and peak usage
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.43)
|
|
load-and-go.
(1)
operating technique in which there are no stops between the loading and execution phases of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
loaded origin.
(1)
address of the initial storage location of a computer program at the time the program is loaded into main memory
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assembled origin, offset, starting address
|
|
loader.
(1)
computer program that reads machine code into main memory in preparation for execution and, in some cases, adjusts the addresses and links the modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
any program that reads programs or data into main memory
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Types include absolute loader, linking loader, relocating loader.
See Also: bootstrap, linkage editor
|
|
LOC.
(1)
lines of code
(ISO/IEC/IEEE 24748-5:2017 Systems and software engineering--Life cycle management--Part 5: Software development planning, 4)
|
|
LOCA.
(1)
loss of coolant accident
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
local area network (LAN).
(1)
computer network located on a user's premises within a limited geographical area
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: Communication within a local area network is not subject to external regulations; however, communication across the LAN boundary can be subject to some form of regulation.
|
|
local compaction.
(1)
in microprogramming, compaction in which microoperations are not moved beyond the boundaries of the single-entry, single-exit sequential blocks in which they occur
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: global compaction
|
|
local customization.
(1)
FSM method that has been modified for local use, such that it can produce different functional sizes from those obtained prior to modification
(ISO/IEC 14143-1:2007 Information technology--Software measurement--Functional size measurement; Part 1: Definition of concepts, 3.9)
|
|
local data.
(1)
data that can be accessed by only one module or set of nested modules in a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
data that can be accessed only within the routine in which it is declared
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: global data
|
|
local SAM owner.
(1)
individual at a level of the organization below that of the SAM owner who is identified as being responsible for SAM for a defined part of the organization
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.21)
|
|
local variable.
(1)
variable that can be accessed by only one module or set of nested modules in a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: global variable
|
|
locality of quality responsibility.
(1)
assignment of responsibility for specific quality-related requirements or decompositions thereof to a particular process instance
(ISO/IEC 30103:2015 Software and Systems Engineering - Lifecycle Processes - Framework for Product Quality Achievement, 3.6)
(2)
responsibility for achievement of a quality requirement or decomposition thereof
(ISO/IEC 30103:2015 Software and Systems Engineering - Lifecycle Processes - Framework for Product Quality Achievement, 3.8)
|
|
location facility.
(1)
set of service primitives that allow a client-side binder object to ask a server-side if it will accept requests carrying invocations to a particular (computational) server object
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 3.3.9)
Note: The server-side can confirm or reject the proposal or suggest an alternative server-side that is capable of handling requests.
|
|
location in space.
(1)
interval of arbitrary size in space at which an action can occur
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.10)
|
|
location in time.
(1)
interval of arbitrary size in time at which an action can occur
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.11)
|
|
location reference.
(1)
indicator following a heading or subheading in an index or table of contents, showing to which part of the document the heading or subheading refers
(ISO/IEC/IEEE 24765a:2011)
|
|
location transparency.
(1)
distribution transparency which masks the use of information about location in space when identifying and binding to interfaces
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.4.1.3)
|
|
lock.
(1)
exclusive permission to edit a file
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
lockout.
(1)
computer resource allocation technique in which shared resources (especially data) are protected by permitting access by only one device or process at a time
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: deadlock, semaphore
|
|
LOE.
(1)
level of effort
(ISO/IEC/IEEE 24765n:2025)
|
|
log.
(1)
document used to record and describe or denote selected items identified during execution of a process or activity. Usually used with a modifier, such as issue, change, or assumption
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
log off.
(1)
to end a session
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Syn: log out
|
|
log on.
(1)
to initiate a session
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Syn: log in
|
|
logic programming language.
(1)
a programming language used to express programs in terms of control constructs and a restricted predicate calculus
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: PROLOG
See Also: algebraic language, algorithmic language, list processing language
|
|
logical cohesion.
(1)
type of cohesion in which the tasks performed by a software module perform logically similar functions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: processing of different types of input data
See Also: coincidental cohesion, communicational cohesion, functional cohesion, procedural cohesion, sequential cohesion, temporal cohesion
|
|
logical file.
(1)
logical group of data as seen by the user
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.22)
|
|
logical interface.
(1)
input-output flow between two or more system elements or software system elements and the function that determines it
(ISO/IEC/IEEE 24748-6:2023 Systems and software engineering Life cycle management Part 6: System and software integration, 3.1.5)
|
|
logical record.
(1)
set of data which is processed in a single iteration of the main procedure
(ISO/IEC/IEEE 24765a:2011)
Example: a row in a database table
Note: It can be part or the whole of a single physical record or of a number of records.
|
|
logical source statement (LSS).
(1)
software instruction, independent of the physical format (lines of code) in which it appears
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: physical source statement
|
|
logical trace.
(1)
execution trace that records only branch or jump instructions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: execution trace, retrospective trace, subroutine trace, symbolic trace, variable trace
|
|
logical transaction.
(1)
the basic functional component of Mk II FPA
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
Example: null
Note: The smallest complete unit of information processing that is meaningful to the end user in the business. It is triggered by an event in the real world of interest to the user, or by a request for information. It comprises an input, process and output component. It is self-contained and leaves the application being counted in a consistent state.
|
|
logical type.
(1)
data type whose members can assume only logical values (usually TRUE and FALSE) and can be operated on only by logical operators, such as and, OR, and NOT
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: character type, enumeration type, integer type, real type
|
|
loop.
(1)
sequence of computer program statements that is executed repeatedly until a given condition is met or while a given condition is true
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to execute a sequence of computer program statements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: iterative construct
See Also: loop body, loop control, UNTIL, WHILE
|
|
loop assertion.
(1)
logical expression specifying one or more conditions that are met each time a particular point in a program loop is executed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: loop invariant
See Also: input assertion, output assertion, inductive assertion method
|
|
loop body.
(1)
part of a loop that accomplishes the loop's primary purpose
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: loop control
|
|
loop control.
(1)
part of a loop that determines whether to exit from the loop
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: loop body, leading decision, trailing decision
|
|
loop-control variable.
(1)
program variable used to determine whether to exit from a loop
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
loopback.
(1)
an internal arrow that is the output of a box whose box number is greater than the box number of the box that uses that arrow as input, control, or mechanism
(ISO/IEC/IEEE 24765m:2024, 2.1.70)
Note: These uses are referred to as input loopback, control loopback, and mechanism loopback, respectively.
|
|
loopback testing.
(1)
testing in which signals or data from a test device are input to a system or component, and results are returned to the test device for measurement or comparison
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
lossage.
(1)
detrimental effect on stored data of a failure or an impairment
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
LOU.
(1)
letter of understanding
(ISO/IEC/IEEE 41062:2024, Software engineering Life cycle processes Software acquisition, 3.2)
|
|
low level.
(1)
specific; detailed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
low-level design.
(1)
design at the individual-routine or, sometimes, class level under the guidance of a more general design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: detailed design
|
|
low-level keyword.
(1)
keyword that covers only one or very few simple actions and is not composed from other keywords
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 4.9)
|
|
low-profile quad flat package (LQFP).
(1)
semiconductor device based on a leadframe with gull wing-shaped leads on all four sides
(ISO/IEC/IEEE 24765e:2015)
Note: The LQFP package can be encapsulated in plastic.
|
|
lowclass.
(1)
if an instance is in a class S and not in any subclass of S, then S is the lowclass for the instance
(ISO/IEC/IEEE 24765n:2025, 3.1.103)
|
|
LQFP.
(1)
low-profile quad flat package
(ISO/IEC/IEEE 24765d:2015)
|
|
LRIP.
(1)
low-rate initial production
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
LT.
(1)
less than
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
LTC.
(1)
level test case
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
LTD.
(1)
level test design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
LTE.
(1)
less than or equal
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
LTL.
(1)
level test log
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
LTP.
(1)
level test plan
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
See Also: LTPr
|
|
LTPr.
(1)
level test procedure
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
See Also: LTP
|
|
LTR.
(1)
level test report
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
M&S.
(1)
modeling and simulation
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
MAC.
(1)
Media Access Control
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
machine code.
(1)
computer instructions and data definitions expressed in a form that can be recognized by the processing unit of a computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assembly code, compiler code, interpretive code
|
|
machine language.
(1)
language that can be recognized by the processing unit of a computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Such a language usually consists of patterns of 1s and 0s, with no symbolic naming of operations or addresses.
Syn: first-generation language, machine-oriented language
See Also: assembly language, fifth-generation language, fourth-generation language, high-order language, symbolic language
|
|
machine learning (ML).
(1)
process using computational techniques to enable systems to learn from data or experience
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.43)
(2)
process of optimizing model parameters through computational techniques, such that the model's behavior reflects the data or experience
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
|
|
machine-dependent.
(1)
pertaining to software that relies on features unique to a particular type of computer and therefore executes only on computers of that type
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: machine-independent
|
|
machine-independent.
(1)
pertaining to software that does not rely on features unique to a particular type of computer, and therefore executes on computers of more than one type
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: machine-dependent, portability
|
|
machine-readable.
(1)
pertaining to data in a form that can be automatically generated by and input to a computer
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
Example: data encoded on a diskette
Syn: machine readable
|
|
macro.
(1)
in software engineering, a predefined sequence of computer instructions that is inserted into a program, usually during assembly or compilation, at each place that its corresponding macroinstruction appears in the program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: macro definition
See Also: macroinstruction, macrogenerator, open subroutine
|
|
macro library.
(1)
collection of macros available for use by a macrogenerator
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: system library
|
|
macroassembler.
(1)
assembler that includes, or performs the functions of, a macrogenerator
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
macrogenerator.
(1)
routine, often part of an assembler or compiler, that replaces each macroinstruction in a source program with the predefined sequence of instructions that the macroinstruction represents
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: macro-generating program
|
|
macroinstruction.
(1)
source code instruction that is replaced by a predefined sequence of source instructions, usually in the same language as the rest of the program and usually during assembly or compilation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: macro, macrogenerator
|
|
macroprocessor.
(1)
routine or set of routines provided in some assemblers and compilers to support the definition and use of macros
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
macroprogramming.
(1)
computer programming using macros and macroinstructions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
magic number.
(1)
literal value that is used by a program directly rather than being embedded in a named constant or variable
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: magic string
See Also: literal
|
|
magnetic core memory.
(1)
volatile memory that uses magnetic rings as the storage element
(ISO/IEC/IEEE 24765c:2014)
|
|
main library.
(1)
software library containing controlled versions of software and documentation from which working copies can be made for distribution and use
(ISO/IEC/IEEE 24765k:2022)
Note: replaces the deprecated term master library
|
|
main probe.
(1)
phase to perform repetitive cycle for gathering and analyzing data for finding strengths and challenges of an organization
(ISO/IEC 26561:2019 Software systems engineering--Methods and tools for product line technical probe, 3.2)
|
|
main procedure.
(1)
all those activities subsequent to the general initiation routine and prior to the general termination routine within the complete procedure
(ISO/IEC/IEEE 24765a:2011)
|
|
main program.
(1)
software component that is called by the operating system of a computer and that usually calls other software components
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: routine, subprogram
|
|
main schedule.
(1)
high-level schedule that includes the major milestones, deliverables, and work breakdown structure elements (activities)
(ISO/IEC/IEEE 24765n:2025)
Syn: top-level schedule, summary schedule
|
|
mainframe.
(1)
computer intended to run in a computer center, with extensive capabilities and resources to which other computers can be connected so that they can share facilities
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
maintain.
(1)
add, change or delete data through an elementary process
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.40)
|
|
maintainability.
(1)
degree of effectiveness and efficiency with which a product or system can be modified
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.1.6)
(2)
capability of a product to be modified by the intended maintainers with effectiveness and efficiency
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.7)
Note: Maintainability includes installation of updates and upgrades. Modifications can include corrections, improvements, or adaptation of the software to changes in environment, and in requirements and functional specifications. Modifications include those carried out by specialized support staff, and those carried out by business or operational staff, or end users. Maintainability can be interpreted as either an inherent capability of the product or system to facilitate maintenance activities, or the quality in use experienced by the maintainers for the goal of maintaining the product or system.
See Also: flexibility
|
|
maintainability plan.
(1)
document setting out the specific maintainability practices, resources and sequence of activities relevant to software
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The developer prepares the Maintainability Plan.
|
|
maintainability testing.
(1)
test type conducted to evaluate the degree of effectiveness and efficiency with which a test item can be modified
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.45)
|
|
maintainer.
(1)
individual or organization that performs maintenance activities
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.31)
|
|
maintenance.
(1)
process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment
(ISO/IEC 25051:2014 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, 4.1.9)
(2)
process of retaining a hardware system or component in, or restoring it to, a state in which it can perform its required functions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
actions intended to retain a product in, or restore it to, a useful and safe condition, in which it can perform the intended use
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.23)
Note: In the context of dependability, maintenance is a combination of all technical and management actions intended to retain an item in, or restore it to, a state in which it can perform as required.
See Also: adaptive maintenance, corrective maintenance, perfective maintenance, software maintenance
|
|
maintenance branch.
(1)
branch where most development concerns bug fixes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
maintenance compliance and versioning.
(1)
degree to which a service provides maintenance according to the service level agreement (SLA), and a new version is assigned and published after maintenance
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.6.1)
|
|
maintenance manual (MM).
(1)
software engineering project-deliverable document that enables a system's maintenance personnel (rather than users) to maintain the system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: operator manual, user manual
|
|
maintenance personnel.
(1)
software engineers who maintain software systems
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
maintenance plan.
(1)
document setting out the specific maintenance practices, resources, and sequence of activities relevant to maintaining a software product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
maintenance program.
(1)
organizational structure, responsibilities, procedures, processes, and resources used for implementing the maintenance plan
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: maintenance infrastructure
|
|
maintenance project.
(1)
software development project described as maintenance to correct errors in an original requirements specification, to adapt a system to a new environment, or to enhance a system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
make or buy analysis.
(1)
process of gathering and organizing data about product requirements and analyzing them against available alternatives including the purchase or internal manufacture of the product
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: make-or-buy analysis
|
|
malfunction.
(1)
behavior of a system or component that deviates from the specifications
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.11)
|
|
manage.
(1)
[requirements] provide storing and editing capabilities, tracking history of edition, versioning, author identification, change management, time stamping, user notification for content changes, security rights control
(ISO/IEC TR 24766:2009 Information technology--Systems and software engineering--Guide for requirements engineering tool capabilities, 3.2)
|
|
manageability.
(1)
degree to which IT infrastructure management can attain and keep an application in its operational state
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.24)
Note: Manageability involves the transparency and manageability of applications from an infrastructure point of view.
|
|
managed network.
(1)
network or set of networks established and controlled by one or more organizations to meet specific organizational or business needs
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.16)
|
|
managed process.
(1)
performed process that is planned and executed in accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: performed process
|
|
managed role.
(1)
view of the management interface of an object which is being managed within an ODP system
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 14.4)
|
|
managed website.
(1)
site created and maintained based on organizational guidelines
(ISO/IEC/IEEE 24765l:2024)
Syn: managed web site
|
|
management.
(1)
coordinated activities to direct and control an organization
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.52)
(2)
system of controls and processes required to achieve the strategic objectives set by the organization's governing body
(ISO/IEC/IEEE 21840:2019 Systems and software engineering--Guidelines for the utilization of ISO/IEC/IEEE 15288 in the context of system of systems (SoS), 3.1.5)
Note: Management is subject to the policy guidance and monitoring set through corporate governance. Management can include establishing policies and objectives, and processes to achieve these objectives. Management is a set of activities performed by managers.
See Also: top management
|
|
management information.
(1)
knowledge concerning objects which are of relevance to management
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 14.3)
|
|
management notification.
(1)
event notification initiated by an object operating in a managed role
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 14.6)
|
|
management process.
(1)
activities that are undertaken to help ensure that the software engineering processes are performed in a manner consistent with the organization's policies, goals, and standards
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
management reserve.
(1)
amount of the project budget or project schedule held outside the performance measurement baseline for management control purposes that is reserved for unforeseen work that is within the project scope
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: These are budgets reserved for unforeseen work that is within scope of the project. The management reserve is not included in the performance measurement baseline.
|
|
management review.
(1)
systematic evaluation of a software acquisition, supply, development, operation, or maintenance process performed by or on behalf of management that monitors progress, determines the status of plans and schedules, confirms requirements and their system allocation, or evaluates the effectiveness of management approaches used to achieve fitness for purpose
(ISO/IEC/IEEE 24765i:2020)
|
|
management skills.
(1)
ability to plan, organize, direct, and control individuals or groups of people to achieve specific goals
(ISO/IEC/IEEE 24765h:2019)
|
|
management system.
(1)
set of interrelated or interacting elements to establish policy and objectives and to achieve those objectives
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.33)
Note: A management system can address a single discipline or several disciplines. The system elements include the organization's structure, roles and responsibilities, planning, and operation. The scope of a management system may include the whole of the organization, specific and identified functions of the organization, specific and identified sections of the organization, or one or more functions across a group of organizations.
|
|
managerial independence.
(1)
of software quality assurance (SQA), situation in which the responsibility of the SQA effort is vested in an organization separate from the development and project management organizations
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
|
|
managing role.
(1)
view of an object which is performing managing actions
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 14.5)
|
|
mandatory.
(1)
syntax keyword used to specify a total mapping
(ISO/IEC/IEEE 24765n:2025, 3.1.104)
Note: Mandatory requirements are expressed using "shall".
Syn: MAN
See Also: optional, total
|
|
mandatory dependency.
(1)
relationship that is contractually required or inherent in the nature of the work
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: hard logic
|
|
mandatory nonidentifying relationship.
(1)
nonidentifying relationship in which an instance of the child entity is related to an instance of the parent entity
(ISO/IEC/IEEE 24765n:2025, 3.1.105)
See Also: optional nonidentifying relationship, nonidentifying relationship [key style]
|
|
manual testing.
(1)
humans performing tests by entering information into a test item and verifying the results
(ISO/IEC/IEEE 29119-5:2024 Software and systems engineering--Software testing--Part 5: Keyword-driven testing, 3.15)
Note: Manual testing does not use tools, robots, or other test execution engines.
|
|
manufacture.
(1)
in software engineering, to copy software to disks, chips, or other devices for distribution to customers or users
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
manufacturing phase.
(1)
stage in the software life cycle during which the basic version of a software product is adapted to a specified set of operational environments and is distributed to a customer base
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
many-sorted algebra.
(1)
mathematical structure comprising a set of sets and a set of functions taking these sets as domains and co-domains
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.14)
|
|
many-to-many relationship.
(1)
relationship between two state classes (not necessarily distinct) in which each instance of one class can be associated with any number of instances of a second class (possibly none), and each instance of the second class can be related to any number of instances of the first class (possibly none)
(ISO/IEC/IEEE 24765n:2025, 3.1.106)
|
|
MAO.
(1)
mean operational availability
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
map program.
(1)
software tool, often part of a compiler or assembler, that generates a load map
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
mapping.
(1)
assigned correspondence between two things that is represented as a set of ordered pairs
(ISO/IEC/IEEE 24765n:2025, 3.1.107)
(2)
establishing a sequence of activities according to a selected software life cycle model (SLCM)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
See Also: instance, invocation, iteration, software life cycle model (SLCM)
|
|
mapping completeness.
(1)
a designation of whether a mapping is complete (totally mapped) or incomplete (partial)
(ISO/IEC/IEEE 24765n:2025, 3.1.108)
See Also: partial, total
|
|
mapping document.
(1)
document that relates a standard and an existing industry practice
(ISO/IEC 19770-8:2020, Information technology IT asset management Part 8: Guidelines for mapping of industry practices to/from the ISO/IEC 19770 family of standards, 3.1)
|
|
marking.
(1)
symbols, pictograms, warnings, logos or inscriptions on the product, label, or packaging to identify its type, which can also include short textual messages
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.24)
|
|
marking (of a net).
(1)
the set of the place markings for all places of the net
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.15)
|
|
marking of a place.
(1)
a multiset of tokens associated with ('residing in') the place
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.16)
|
|
markup language.
(1)
method of defining and describing the structure of different types of electronic documents
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.20)
|
|
MARR.
(1)
minimum attractive rate of return
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
mask.
(1)
a pattern of bits or characters designed to be logically combined with an unknown data item to retain or suppress portions of the data item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: The bit string '00000011' when logically ANDed with an eight-bit data item, gives a result that retains the last two bits of the data item and has zero in all the other bit positions.
See Also: interrupt mask
|
|
mask ROM.
(1)
read-only memory unit whose circuits are programmed during the manufacturing process
(ISO/IEC/IEEE 24765c:2014)
|
|
material.
(1)
aggregate of things used by an organization in an undertaking
(ISO/IEC/IEEE 24765h:2019)
Example: equipment, apparatus, tools, machinery, gear, and supplies
Syn: materiel
|
|
maturity level.
(1)
point on an ordinal scale of organizational process maturity that characterizes the maturity of the organizational unit assessed in the scope of the maturity model used
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.1)
(2)
degree of achievement to which all goals have been attained
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.9)
|
|
maturity model.
(1)
model derived from one or more specified process assessment model(s) that identifies the process sets associated with the levels in a specified scale of organizational process maturity
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.7)
|
|
maximax rule.
(1)
in decision making under uncertainty, assuming that the best state of nature will happen, selection of the alternative that has the best payoff from all of the best payoffs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: Hurwicz criterion, maximin rule, minimax regret rule
|
|
maximin rule.
(1)
in decision making under uncertainty, assuming that the worst state of nature will happen, selection of the alternative that has the best payoff from all of the worst payoffs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: the most pessimistic of the uncertainty techniques
See Also: Hurwicz criterion, maximax rule, minimax regret rule
|
|
MBLa.
(1)
manage benchmarking business level activity
(ISO/IEC 29155-2:2013 Systems and software engineering--Information technology project performance benchmarking framework--Part 2: Requirements for benchmarking, 4)
|
|
MBSA.
(1)
model-based safety assessment
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
MBSE.
(1)
model-based systems engineering
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.2)
|
|
MBSSE.
(1)
model-based systems and software engineering
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.16)
|
|
MCDC.
(1)
modified condition/decision coverage
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.36)
|
|
MCDM.
(1)
multiple-criteria decision making
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.9)
(2)
multiple condition decision method
(ISO/IEC 26561:2019 Software systems engineering--Methods and tools for product line technical probe, 4)
|
|
MCI.
(1)
model configuration item
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.18)
Note: An MCI can be defined in different granularities, from a set of model elements, to the entire model.
|
|
MCU.
(1)
microcontroller unit
(ISO/IEC/IEEE 24765c:2014)
|
|
MD5.
(1)
message digest 5
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.22)
|
|
MDD.
(1)
model driven development
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 3.2)
(2)
model-driven design
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
MDT.
(1)
mean downtime
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
mean.
(1)
arithmetic average of a collection of numbers
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: For n observations 𝑥1,𝑥2⋯ 𝑥𝑛 the arithmetic mean 𝑥 =(𝑥1+ 𝑥2+⋯ +𝑥𝑛)/n
|
|
mean execution time.
(1)
the mean value of all execution times of tasks of the j-the task type which were submitted within the rating interval
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.8)
|
|
mean execution time rating value.
(1)
the quotient (corresponding to the j-th task type) of the mean execution time reference value and the measured mean execution time
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.9)
|
|
mean execution time reference value.
(1)
the mean execution time maximally accepted by the emulated user
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.1)
|
|
mean time between failures (MTBF).
(1)
the expected or observed time between consecutive failures in a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: up time
|
|
mean time to repair (MTTR).
(1)
expected or observed duration required to return a malfunctioning system or component to normal operations
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
the mean time the maintenance team requires to implement a change and restore the system to working order
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: down time
|
|
meaningful.
(1)
user-recognizable and satisfies a functional user requirement
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.41)
|
|
measurable concept.
(1)
abstract relationship between attributes of entities and information needs
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.14)
|
|
measurand.
(1)
particular quantity subject to measurement
(ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.5)
Example: vapor pressure of a given sample of water at 20 C
Note: The specification of a measurand involves statements about quantities such as time, temperature and pressure.
|
|
measure.
(1)
variable to which a value is assigned as the result of measurement
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.18)
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.15)
(2)
make a measurement
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.19)
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.16)
|
|
measure of effectiveness (MOE).
(1)
operational measure of success that is closely related to the achievement of the operational objective being evaluated in the intended operational environment under a specified set of conditions
(ISO/IEC/IEEE 24748-4:2016 Systems and software engineering-Life cycle management-Part 4: Systems engineering planning, 4.7)
(2)
criterion used to assess change in system behavior, capability, or operational environment that is tied to measuring the attainment of an end state, achievement of an objective or creation of an effect
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
(3)
measure that defines the acquirers key indicators of achieving the mission needs for performance, suitability, and affordability across the life cycle
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: Defines the information needs of the decision makers with respect to system effectiveness to meet operational expectations.
See Also: measure of performance
|
|
measure of performance (MOP).
(1)
engineering parameter that provides critical performance requirements to satisfy a measure of effectiveness (MOE)
(ISO/IEC/IEEE 24748-4:2016 Systems and software engineering-Life cycle management-Part 4: Systems engineering planning, 4.8)
(2)
measure to assess whether the system meets design or performance requirements and has the capability to achieve operational objectives
(INCOSE Systems Engineering Handbook, 5th ed.)
(3)
measure that characterizes physical or functional attributes relating to system operation
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: MoP
See Also: measure of effectiveness
|
|
measurement analyst.
(1)
individual or organization that is responsible for the planning, performance, evaluation, and improvement of measurement
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.18)
|
|
measurement experience base.
(1)
data store that contains the evaluation of the information products and the measurement process as well as any lessons learned during the measurement process
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.19)
|
|
measurement function.
(1)
algorithm or calculation performed to combine two or more base measures
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.20)
(2)
algorithm or calculation performed to combine two or more quality measure elements
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 4.7)
|
|
measurement librarian.
(1)
individual or organization that is responsible for managing measurement data stores
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
measurement method.
(1)
logical sequence of operations, described generically, used in quantifying an attribute with respect to a specified scale
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.21)
(2)
logical organization of operations, described generically, used in measurement
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 4.8)
(3)
logical sequence of operations, described generically, used in the performance of measurements
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.16)
Note: The type of measurement method depends on the nature of the operations used to quantify an attribute. Two types are distinguished: subjective - quantification involving human judgment; objective - quantification based on numerical rules.
|
|
measurement model.
(1)
implicit or explicit relationship between a latent variable and its (multi-item) measures
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.10)
|
|
measurement performance domain.
(1)
performance domain that addresses activities and functions associated with assessing project performance and taking appropriate actions to maintain acceptable performance
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
measurement procedure.
(1)
set of operations, described specifically, used in the performance of a particular measurement according to a given method
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.22)
(2)
logical organization of operations, applied specifically, used in the performance of particular measurements according to a given measurement method
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 4.9)
Note: A measurement procedure is usually recorded in a document that is sometimes itself called a "measurement procedure" and is usually in sufficient detail to enable an operator to carry out a measurement without additional information.
|
|
measurement process.
(1)
process for establishing, planning, performing and evaluating software measurement within an overall project or organizational measurement structure
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.23)
(2)
process of establishing, planning, performing and evaluating software measurement within an overall project or organizational measurement structure
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.18)
(3)
process for establishing, planning, performing and evaluating systems and software measurement within an overall project or organizational measurement structure
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.21)
|
|
measurement process owner.
(1)
individual or organization responsible for the measurement process
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.24)
|
|
measurement source.
(1)
set of artifacts used for quality measures when performing a quality evaluation
(ISO/IEC 25040:2024 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Quality evaluation framework, 3.5)
|
|
measurement sponsor.
(1)
individual or organization that authorizes and supports the establishment of the measurement process
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.25)
|
|
measurement standard.
(1)
standard that describes the characteristics of evaluating a process or product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
measurement user.
(1)
individual or organization that uses the information products
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.26)
|
|
measuring instrument.
(1)
device intended to be used to make measurements, alone or in conjunction with supplementary devices
(ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.6)
|
|
mechanism loopback.
(1)
loopback of output from one function to be mechanism for another function in the same diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.73)
|
|
member product.
(1)
product belonging to the product line
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.15)
See Also: application
|
|
memory.
(1)
addressable storage space in a processing unit and all other internal storage that is used to execute instructions
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
memory capacity.
(1)
maximum number of items that can be held in a given computer memory; usually measured in words or bytes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: channel capacity, storage capacity
|
|
memory compaction.
(1)
storage allocation technique in which the contents of all allocated storage areas are moved to the beginning of the storage space and the remaining storage blocks are combined into a single block
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
storage allocation technique in which contiguous blocks of non-allocated storage are combined to form single blocks
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: garbage collection
|
|
memory dump.
(1)
display of the contents of all or part of a computer's internal storage, usually in binary, octal, or hexadecimal form
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: change dump, dynamic dump, postmortem dump, selective dump, snapshot dump, static dump
|
|
memory map.
(1)
diagram that shows where programs and data are stored in a computer's memory
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
menu.
(1)
list displayed on a screen showing available functions from which the user can select an action to be initiated
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.33)
(2)
list of options displayed by a data processing system, from which the user can select an action to be initiated
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
menu by-pass.
(1)
in a menu-driven system, a feature that permits advanced users to perform functions in a command-driven mode without selecting options from the menus
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
menu-driven.
(1)
pertaining to a system or mode of operation in which the user directs the system through menu selections
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: menu by-pass, command-driven
|
|
merge.
(1)
to combine different changes to the same file
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Many systems follow the optimistic strategy of combining all lines that do not conflict.
|
|
merge from current.
(1)
to merge changes from the current branch into the stable branches
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: To avoid disruptive changes in a stable branch, code changes are typically first introduced into the current (development) branch, tested, and then merged back.
|
|
message.
(1)
communication sent from one object to another
(ISO/IEC/IEEE 24765n:2025, 3.1.110)
Note: Message encompasses requests to meet responsibilities as well as simple informative communications.
See Also: request
|
|
meta-.
(1)
prefix to a concept to imply definition information about the concept
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: Specifically, used to designate the location of an object in the three model layers.
|
|
meta-attribute.
(1)
definition of a characteristic of a meta-entity or meta-relationship
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: Instances of a meta-attribute occur in a model as data values.
|
|
meta-entity.
(1)
definition of a type of data object that occurs in CDIF models
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: Specifically, a meta-entity represents a set of zero or more meta-attributes, stored together to represent a thing, event or concept that has instances in a model.
|
|
meta-meta-attribute.
(1)
definition of a characteristic of a meta-meta-entity or meta-meta-relationship
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: Instances of a meta-meta-attribute occur in a metamodel as meta-data values.
|
|
meta-meta-entity.
(1)
a definition of the behavior and structure of meta-entities, meta-relationships, meta-attributes, or subject areas
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: i.e., a definition of the meta-object definitions used to describe information in models
|
|
meta-meta-relationship.
(1)
definition of a type of data object that occurs in CDIF metamodels
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: Specifically, a meta-meta-relationship represents the definition of a relationship between instances of meta-meta-entities.
|
|
meta-object.
(1)
generic term for meta-entities, meta-relationships and meta-attributes
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
meta-object facility.
(1)
specification of the object management group for repositories of type information for arbitrary type systems
(ISO/IEC 14769:2001 Information technology -- Open Distributed Processing -- Type Repository Function, 3.3.1)
Syn: MOF
|
|
meta-relationship.
(1)
definition of a type of data object that occurs in CDIF models
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Example: null
Note: Specifically, a meta-relationship represents the definition of a relationship between meta-entities that has instances in a model. A meta-relationship can also define a set of zero or more meta-attributes, stored together to represent characteristics of a relationship between meta-entities.
|
|
metadata.
(1)
data that describe other data
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.29)
|
|
metalanguage.
(1)
language used to specify some or all aspects of a language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: Backus-Naur form
See Also: stratified language, unstratified language
|
|
metamodel.
(1)
special kind of model that specifies the abstract syntax of a modeling language
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.12)
(2)
specification of the concepts, relationships and rules that are used to define a methodology
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.4)
(3)
model containing detailed definitions of the meta-entities, meta-relationships and meta-attributes whose instances appear in the model section of a CDIF transfer
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: The typical role of a metamodel is to define the semantics for how model elements in a model get instantiated. Model elements are created by instantiating elements from a meta-model.
Syn: meta-model, meta model
|
|
metamodel element.
(1)
element of a meta-model from which model elements are instantiated
(ISO/IEC/IEEE 24765l:2024)
|
|
metamorphic relation.
(1)
description of how a change in the test inputs from the source test case to the follow-up test case affects a change (or not) in the expected outputs from the source test case to the follow-up test case
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.44)
(2)
description of how changes to the test inputs for a test case affect the expected outputs based on the required behavior of a test item
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.34)
Syn: MR
|
|
metamorphic testing.
(1)
testing where the expected results are not based on the specification but are instead extrapolated from previous actual results
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.45)
(2)
specification-based test case design technique based on generating test cases on the basis of existing test cases and metamorphic relations
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.35)
|
|
method.
(1)
code that is executed to perform a service
(ISO/IEC/IEEE 24765l:2024)
(2)
means for achieving an outcome, output, result, or project deliverable
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
method engineer.
(1)
person who designs, builds, extends and maintains methodologies
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.10)
Note: Method engineers create methodologies from metamodels via generation.
|
|
method standard.
(1)
standard that describes the characteristics of the orderly process or procedure used in the engineering of a product or performing a service
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
methodology.
(1)
system of practices, techniques, procedures, and rules used by those who work in a discipline
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
specification of the process to follow together with the work products to be used and generated, plus the consideration of the people and tools involved, during an IBD development effort
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.2)
|
|
methodology element.
(1)
simple component of a methodology
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.6)
Note: Usually, methodology elements include the specification of what tasks, activities, techniques, models, documents, languages or notations can be used when applying the methodology. Methodology elements are related to each other, comprising a network of abstract concepts. Typical methodology elements are Capture Requirements, Write Code for Methods (kinds of tasks), Requirements Engineering, High-Level Modeling (kinds of activities), Pseudo-code, Dependency Graphs (notations), Class, Attribute (kinds of model building blocks), Class Model, Class Diagram, Requirements Specification (kind of work products).
|
|
metric.
(1)
measure or unit of measure that is designed to facilitate decision-making and improve performance and accountability through collection, analysis, and reporting of relevant data
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
(2)
defined measurement method and the measurement scale
(ISO/IEC 14102:2008 Information Technology - Guideline for the evaluation and selection of CASE tools)
(3)
description of a project or product attribute and how to measure it
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: software quality metric
|
|
MFA.
(1)
multi-factor authentication
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
MFLOPS.
(1)
millions of floating-point operations per second
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
megaflops, a unit of measure of processing performance equal to one million floating-point operations per second
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: a measure of computer processing speed
See Also: KOPS, MIPS
|
|
micro code assembler.
(1)
computer program that translates microprograms from symbolic form to binary form
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
microarchitecture.
(1)
microword definition, data flow, timing constraints, and precedence constraints that characterize a given microprogrammed computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
|
|
microcode.
(1)
collection of microinstructions, comprising part of, or all of, a set of microprograms
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
Syn: micro code
|
|
microcomputer.
(1)
digital computer whose processing unit consists of one or more microprocessors, and includes storage and input-output facilities
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
See Also: microprogrammable computer
|
|
microcontroller (unit) (MCU).
(1)
unit with application control function on a single chip
(ISO/IEC/IEEE 24765c:2014)
Note: It contains a processor, RAM, ROM, clock, register, and I/O control unit.
Syn: single chip microcomputer
|
|
microinstruction.
(1)
in microprogramming, an instruction that specifies one or more of the basic operations needed to carry out a machine language instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Types include diagonal microinstruction, horizontal microinstruction, vertical microinstruction.
See Also: micro code, microoperation, microprogram
|
|
microoperation.
(1)
in microprogramming, one of the basic operations needed to carry out a machine language instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: microinstruction
|
|
microprocessor.
(1)
processor whose elements have been miniaturized into one or a few integrated circuits
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
microprogram.
(1)
sequence of instructions, called microinstructions, specifying the basic operations needed to carry out a machine language instruction
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation)
|
|
microprogrammable computer.
(1)
microprogrammed computer in which microprograms can be created or altered by the user
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
microprogrammed computer.
(1)
computer in which machine language instructions are implemented by microprograms rather than by hard-wired logic
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
See Also: microarchitecture, microcomputer, microprogrammable computer
|
|
microprogramming.
(1)
designing and implementing the control logic of a computer by identifying the basic operations needed to carry out each machine language instruction and representing these operations as sequences of instructions in a special memory called control store
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: This method is an alternative to hard-wiring the control signals necessary to carry out each machine language instruction. Techniques include bit steering, compaction, residual control, single-level encoding, two-level encoding.
See Also: micro code, microinstruction, microprogram
|
|
microword.
(1)
addressable element in the control store of a microprogrammed computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
middleware.
(1)
software layer between an operating system and the software applications
(ISO/IEC/IEEE 24765d:2015)
|
|
migratability.
(1)
ability to change the configuration, substituting one reference point of an object for another while the object is being used
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 15.4.2)
See Also: portability
|
|
migrated attribute.
(1)
foreign key attribute of a child entity
(ISO/IEC/IEEE 24765n:2025, 3.1.113)
Note: [key style]
|
|
migration.
(1)
moving a cluster to a different capsule
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.27)
|
|
migration transparency.
(1)
distribution transparency which masks from an object, the ability of a system to change the location of that object
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.4.1.4)
Note: Migration is often used to achieve load balancing and reduce latency.
|
|
MIL.
(1)
mean impairment lossage
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
milestone.
(1)
significant point or event in a project, program, or portfolio
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
scheduled event used to measure progress
(ISO/IEC/IEEE 24765e:2015)
Example: Major milestones for software projects can include an acquirer or managerial sign-off, baselining of a specification, completion of system integration, and product delivery. Minor milestones can include baselining of a software module or completion of a chapter of the user manual.
|
|
milestone review.
(1)
formal review of a work product and supporting evidence used to determine its acceptability for use in the next stage of development or for delivery
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.10)
Note: The requirement for this form of review is normally specified in the project plan.
|
|
milestone schedule.
(1)
type of schedule that presents milestones with planned dates
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
MIM.
(1)
Management Information Model
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
minicomputer.
(1)
digital computer that is functionally intermediate between a microcomputer and a mainframe
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: Servers and network devices have generally replaced minicomputers
|
|
minimalism.
(1)
principle for the selection of information for users that supports task performance, troubleshooting, and problem resolution
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.22)
(2)
principle that information for use includes critical information and the least amount of other information needed to be complete
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.25)
|
|
minimax regret rule.
(1)
in decision making under uncertainty, selection of the alternative that minimizes the regret that one would have, if one chose the wrong alternative under each state of nature; that is, the alternative that has the smallest maximum regret
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
See Also: Hurwicz criterion, maximax rule, maximin rule
|
|
minimum attractive rate of return (MARR).
(1)
lowest rate of return at which an organization will consider investing; the interest rate used in business decision analysis
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: reflects a rate of return that the organization is confident it can achieve through typical activities
See Also: opportunity cost
|
|
minimum delay programming.
(1)
programming technique in which storage locations for computer instructions and data are chosen so that access time is minimized
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
minimum tasks.
(1)
those verification and validation tasks required for the integrity level assigned to the system, software, or hardware to be verified and validated
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
|
|
minimum viable product.
(1)
version of a work product with just enough features and requirements to satisfy early customers and provide feedback for future development
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
Syn: MVP
|
|
MIPS.
(1)
million instructions per second
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: a measure of computer processing speed
See Also: KOPS, MFLOPS
|
|
mirror site.
(1)
duplicate copy of a main site maintained on a different host typically to provide redundancy, higher performance, or local access
(ISO/IEC/IEEE 24765l:2024)
|
|
MIS.
(1)
management information system
(ISO/IEC/IEEE 24765b:2013)
|
|
mission.
(1)
important operational job or duty assigned to a resource or a group of resources or certain groups of people
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.13)
|
|
mistake.
(1)
human action that produces an incorrect result
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: The fault tolerance discipline distinguishes between a human action (a mistake), its manifestation (a hardware or software faul or defectt), the result of the fault (a failure), and the amount by which the result is incorrect (the error).
|
|
mixed entry table.
(1)
decision table whose stub consists of rows in which limited and extended entries are written
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.16)
|
|
mixed mode.
(1)
pertaining to an expression that contains two or more different data types
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: Y = X + N, where X and Y are floating point variables and N is an integer variable
Syn: mixed type
|
|
ML.
(1)
machine learning
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.43)
|
|
MLDT.
(1)
mean logistic downtime
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
MMC(S).
(1)
Multimedia Conferencing (System)
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
MMI.
(1)
man-machine interface
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: user interface
|
|
MO.
(1)
member of
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
mobile device.
(1)
portable computing device, typically having a wireless internet connection and a display screen with touch, pen, or keyboard input, and possibly auditory input and output features
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.26)
Note: Design of mobile devices is constrained by special usability needs, due to their size and available features for input and output.
|
|
mobility schema.
(1)
specification putting constraints on the mobility of an object
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 16.4.1.1)
|
|
mock object.
(1)
temporary dummy objects created to aid testing until the real objects become available
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
mock-up.
(1)
throw-away product
(ISO/IEC/IEEE 24765i:2020)
Note: It can be retained for verification or training, and as a record.
|
|
mode.
(1)
definition of the expected behavior of the system, its actors, or its components in situations foreseen at design time
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.14)
(2)
category of device or data used in a system
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
(3)
generic operational activity or system status whose duration is a variable for reliability, availability, supportability, or recoverability
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Example: on-line, off-line, and maintenance modes; sensor type, sensor data, or affective features.
Note: A mode is mainly characterized by the expected functional content of the system in this mode. A mode can reflect various concepts, such as phases of a mission, specific required functioning of the system under certain conditions, or specific conditions where the system is used.
|
|
model.
(1)
representation of a real-world process, device, or concept
(IEEE 7014-2024, IEEE Standard for Ethical Considerations in Emulated Empathy in Autonomous and Intelligent Systems, 3.1)
(2)
representation of something that suppresses certain aspects of the modeled subject
(ISO/IEC/IEEE 24765l:2024)
(3)
abstract representation of an entity or collection of entities that provides the ability to portray, understand or predict the properties or characteristics of the entity or collection under conditions or situations of interest
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.13)
(4)
related collection of instances of meta-objects, representing (describing or prescribing) an information system, or parts thereof, such as a software product
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
(5)
output of a machine learning algorithm trained with a training dataset that generates predictions using patterns in the input data
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.46)
(6)
system of postulates, value declarations and inference rules presented as a description of a state of affairs (universe of discourse)
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 7.3)
(7)
representation of a system of interest, from the perspective of a related set of concerns
(ISO/IEC/IEEE 24765l:2024)
(8)
algorithm or calculation combining one or more base or derived measures with associated decision criteria
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.27)
Note: The representation of the concepts or properties of an entity and governing principles is captured in architecture models.
|
|
model baseline.
(1)
immutable set of model configuration items with their associated versions and variants
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.17)
|
|
model configuration item (MCI).
(1)
logical part of the model that is maintained in a controlled fashion, having a trackable revision history
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.18)
|
|
model element.
(1)
instance of a meta-model element
(ISO/IEC 19506:2012 Information technology -- Object Management Group Architecture-Driven Modernization (ADM) -- Knowledge Discovery Meta-Model (KDM), 4)
(2)
atomic (elementary) item that represents an individual component, action, state, message, property, relationship, or another item that describes the composition, characteristics, or behavior of a system
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.19)
|
|
model element library.
(1)
set or catalogue of non-modifiable model elements usable within any project, packaged in a single artifact
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.20)
|
|
model glossary.
(1)
collection of the names and definitions of all defined concepts that appear within the views of a model
(ISO/IEC/IEEE 24765n:2025, 3.1.116)
|
|
model kind.
(1)
category of model distinguished by its key characteristics and modelling conventions
(ISO/IEC/IEEE 42010:2022, Software, systems and enterprise Architecture description, 3.15)
Example: functional models, activity models, structural models, use case models, geopolitical models, analytic models. economic models
|
|
model layers.
(1)
different layers of definition (or abstraction) used in defining the CDIF family of standards
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Example: null
Note: The four model layers in CDIF are user data, model, metamodel, meta-metamodel. Any given model layer provides an accurate and complete definition of all the instances that occur one layer below the given layer. For example, the meta-metamodel provides a set of definitions that are used to construct and understand the metamodel; the metamodel provides a set of definitions that are used to construct and understand a model.
|
|
model name abbreviation.
(1)
unique short form of a model name that is used to construct diagram references
(ISO/IEC/IEEE 24765m:2024, 2.1.76)
|
|
model note.
(1)
textual or graphical component of a diagram that records a fact not otherwise depicted by a diagram's boxes and arrows
(ISO/IEC/IEEE 24765m:2024, 2.1.77)
|
|
model note number.
(1)
integer number, placed inside a small square, that unambiguously identifies a model note in a specific diagram
(ISO/IEC/IEEE 24765m:2024, 2.1.78)
|
|
model pattern.
(1)
general, reusable model or model part that can be used as a solution to a commonly occurring problem within a given context in system or software design
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.21)
|
|
model repository.
(1)
means to store different models at different levels of abstraction and to facilitate understanding and cooperation between stakeholders and practitioners at different levels
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.22)
|
|
model-based systems and software engineering (MBSSE).
(1)
formalized applications of modelling to support systems and software engineering
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.16)
|
|
modeling.
(1)
activity of representing some elements of a process, device, or concept
(Software Extension to the PMBOK(R) Guide Fifth Edition)
(2)
creating simplified representations of systems, solutions, or deliverables, such as prototypes, diagrams, or storyboards
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
modeling tool.
(1)
tool that provides support for modeling, i.e., representing, a software product or an information system
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
modifiability.
(1)
ease with which a system can be changed without introducing defects
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
degree to which an IT service can be effectively and efficiently modified without introducing defects or degrading existing IT service quality
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.8.2)
(3)
capability of a product to be effectively and efficiently modified without introducing defects or degrading existing product quality
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.7.4)
Note: Modifiability is a combination of changeability and stability.
See Also: analyzability, maintainability, modularity
|
|
modifiable.
(1)
structured and has a style such that changes can be made completely, consistently, and correctly while retaining the structure
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.15)
|
|
modification request (MR).
(1)
information item that identifies and describes proposed changes(s) to a product or service
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.1.8)
Note: The MR can be classified as a correction or enhancement and identified as corrective, preventive, adaptive, additive, or perfective maintenance. MR can be based on stakeholder's requests, incidents, events, complaints, and failure or problem reports, as well as root cause analyses. MR can also be classified as scheduled, unscheduled, and emergency types.
See Also: change request, request for change
|
|
modified condition/decision coverage testing.
(1)
structure-based test case design technique based on demonstrating that a single Boolean condition within a decision can independently affect the outcome of the decision
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.36)
Syn: MCDC testing, MC/DC testing
|
|
modified source statement.
(1)
source statement that has been changed from the original source
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
modified-off-the-shelf (MOTS).
(1)
software product that is already developed and available, usable either as is or with modification, and provided by the supplier, acquirer, or a third party
(ISO/IEC/IEEE 24765l:2024)
|
|
MODL.
(1)
Meta-Object Definition Language
(ISO/IEC 14769:2001 Information technology -- Open Distributed Processing -- Type Repository Function, 4)
|
|
modular.
(1)
composed of discrete parts
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: modular decomposition, modular programming
|
|
modular decomposition.
(1)
breaking a system into components to facilitate design and development; an element of modular programming
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: modularization
See Also: cohesion, coupling, demodularization, factoring, functional decomposition, hierarchical decomposition, packaging
|
|
modular programming.
(1)
software development technique in which software is developed as a collection of modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: data structure-centered design, input-process-output, modular decomposition, object-oriented design, rapid prototyping, stepwise refinement, structured design, transaction analysis, transform analysis
|
|
modularity.
(1)
capability of a product to limit changes to one component from affecting other components
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.7.1)
(2)
software attributes that provide a structure of highly independent components
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Modularity implies that the product is composed of discrete modules or components with cohesive content and minimal coupling to other modules or components.
See Also: cohesion, coupling, modifiability
|
|
module.
(1)
program unit that is discrete and identifiable with respect to compiling, combining with other units, and loading
(ISO/IEC/IEEE 24765l:2024)
(2)
logically separable part of a program
(ISO/IEC 19506:2012 Information technology -- Object Management Group Architecture-Driven Modernization (ADM) -- Knowledge Discovery Meta-Model (KDM), 4)
(3)
independent information unit
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.24)
Note: The terms 'module', 'component,' and 'unit' are often used interchangeably or defined to be subelements of one another in different ways depending upon the context. The relationship of these terms is not yet standardized.
|
|
module data.
(1)
data that can be accessed by any routine within the module in which it is declared but not by routines in other modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: instance data, class data
|
|
MOE.
(1)
measure of effectiveness
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
Syn: MoE
|
|
MOF.
(1)
meta-object facility
(ISO/IEC 14769:2001 Information technology -- Open Distributed Processing -- Type Repository Function, 4)
(ISO/IEC 19793:2015 Information technology -- Open Distributed Processing -- Use of UML for ODP system specifications, 4)
Syn: Meta-Object Facility
|
|
monadic selective construct.
(1)
if-then-else construct in which processing is specified for only one outcome of the branch, the other outcome resulting in skipping this processing
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: dyadic selective construct
|
|
monitor.
(1)
software tool or hardware device that operates concurrently with a system or component and supervises, records, analyzes, or verifies the operation of the system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
collect project performance data, produce performance measures, and report and disseminate performance information
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: execution monitor
See Also: hardware monitor, software monitor
|
|
monitorability.
(1)
degree to which a service provides monitoring parameters and tools to monitor the performance of the service
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.6.3)
|
|
monitoring.
(1)
determining the status of a system, a process, or an activity
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.35)
|
|
monitoring and controlling process group.
(1)
those processes required to track, review, and regulate the progress and performance of the project; identify any areas in which changes to the plan are required; and initiate the corresponding changes
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
monolithic executor.
(1)
executor consisting of a single artifact
(ISO/IEC/IEEE 24765l:2024)
|
|
Monte Carlo simulation.
(1)
method of identifying the potential impacts of risk and uncertainty using multiple iterations of a computer model to develop a probability distribution of a range of outcomes that could result from a decision or course of action
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
mood chart.
(1)
visualization chart for tracking moods or reactions to identify areas for improvement
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
MOP.
(1)
measure of performance
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.2)
|
|
MOPS.
(1)
million operations per second
(ISO/IEC/IEEE 24765c:2014)
|
|
MOS.
(1)
measure of suitability
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
MOTS.
(1)
modified-off-the-shelf
(ISO/IEC/IEEE 24765l:2024)
|
|
MOU.
(1)
memorandum of understanding
(ISO/IEC/IEEE 41062:2024, Software engineering Life cycle processes Software acquisition, 3.2)
|
|
move.
(1)
to read data from a source, altering the contents of the source location, and to write the same data elsewhere in a physical form that can differ from that of the source
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: to move data from one file to another
See Also: copy
|
|
MP3.
(1)
MPEG Audio Layer 3
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.2)
|
|
MP4.
(1)
MPED-V AVC (Advanced Video Coding)
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.2)
|
|
MPa.
(1)
measure IT project activity
(ISO/IEC 29155-2:2013 Systems and software engineering--Information technology project performance benchmarking framework--Part 2: Requirements for benchmarking, 4)
|
|
MPEG.
(1)
Moving Picture Experts Group
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.2)
Example: MP3, MP4
|
|
MPLa.
(1)
manage benchmarking program level activity
(ISO/IEC 29155-2:2013 Systems and software engineering--Information technology project performance benchmarking framework--Part 2: Requirements for benchmarking, 4)
|
|
MR.
(1)
metamorphic relation
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
MRa.
(1)
maintain repository activity
(ISO/IEC 29155-2:2013 Systems and software engineering--Information technology project performance benchmarking framework--Part 2: Requirements for benchmarking, 4)
|
|
MRP.
(1)
machine-readable passport
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
MSP.
(1)
managed service provider
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
MSS.
(1)
management system standard
(ISO/IEC/IEEE 24765l:2024)
|
|
MT.
(1)
machine translation
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)
|
|
MTBF.
(1)
mean time between failures
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
MTBS.
(1)
mean time between support
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
MTBSF.
(1)
mean time between software failures
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
MTIR.
(1)
mean time to impairment recovery
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
MTTD.
(1)
mean time to detection
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
|
|
MTTF.
(1)
mean time to failure
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
MTTR.
(1)
mean time to repair
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
(2)
mean time to recovery
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
(3)
mean time to respond
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
MTX.
(1)
mean time to x
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
multi-attribute decision.
(1)
decision that considers more than just one criterion
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a decision based on price, delivery date, and quality all at the same time
Syn: multiple-attribute decision
|
|
multi-component system.
(1)
measured system consisting of more than one piece of software
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, A.13)
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, A.10)
|
|
multi-core.
(1)
chip with two or more microprocessor units
(ISO/IEC/IEEE 24765e:2015)
|
|
multi-core processor.
(1)
single integrated circuit chip with more than one processing unit
(ISO/IEC/IEEE 24765c:2014)
|
|
multi-level cache.
(1)
layered cache with progressively larger size and slower access
(ISO/IEC/IEEE 24765c:2014)
Note: denoted by L1 (level 1) to L4 (level 4) cache, where the first level is the fastest and smallest memory size for immediate access, and the highest level is slowest, but the largest memory size
|
|
multi-modal biometric system.
(1)
biometric system based on multiple biometric characteristics
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.1.31)
|
|
multi-valued.
(1)
a mapping that is not a function
(ISO/IEC/IEEE 24765n:2025, 3.1.117)
See Also: function
|
|
multi-valued property.
(1)
a property with a multi-valued mapping
(ISO/IEC/IEEE 24765n:2025, 3.1.118)
See Also: single-valued property
|
|
multiaddress instruction.
(1)
computer instruction that contains more than one address field
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: multiple-address instruction
See Also: one-address instruction
|
|
multidimensional construct.
(1)
construct that consists of a number of unidimensional constructs
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.11)
|
|
multiple inclusive selective construct.
(1)
special instance of the case construct in which two or more different values of the control expression result in the same processing
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: values 1 and 2 cause one branch, 3 and 4 cause another, and so on
|
|
multiple inheritance.
(1)
ability of a subclass to inherit responsibilities from more than one superclass
(ISO/IEC/IEEE 24765n:2025, 3.1.119)
(2)
situation when the subtype inherits all of the meta-attributes and meta-relationships of all of its supertypes (and their supertypes)
(ISO/IEC 15474-2:2002 Information technology -- CDIF framework -- Part 2: Modelling and extensibility, 6.2.6)
|
|
multiple instance approach.
(1)
case where each method of delivery of the same functionality is counted separately
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.23)
See Also: single instance approach
|
|
multiple readers and writers.
(1)
algorithm that lets multiple readers access a shared data repository concurrently; however, writers have mutually exclusive access to update the repository
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
multiple-criteria decision making (MCDM).
(1)
making preference decisions (e.g., evaluation, prioritization, and selection) of available alternatives characterized by multiple criteria
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.9)
Note: An MCDM with one alternative is the same as the development of a composite measure.
Syn: multi-attribute decision making
|
|
multiple-hit decision table.
(1)
decision table where at least one set of conditions will be satisfied by more than one rule
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.3)
|
|
multiplex receptacle.
(1)
specialization of a receptacle that allows multiple simultaneous connections
(ISO/IEC/IEEE 24765l:2024)
|
|
multiplicity.
(1)
natural number (i.e., non-negative integer) which describes the number of repetitions of an item in a multiset
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.18)
|
|
multipoint estimating.
(1)
method used to estimate cost or duration by applying an average or weighted average of optimistic, pessimistic, and most likely estimates when there is uncertainty with the individual activity estimates
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
multiprocessing.
(1)
mode of operation in which two or more processes are executed concurrently by separate processing units that have access (usually) to a common main storage
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: multiprogramming, multitasking, time sharing
|
|
multiprogramming.
(1)
mode of operation in which two or more computer programs are executed in an interleaved manner by a single processing unit
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: multiprocessing, multitasking, time sharing
|
|
multiset.
(1)
collection of items where repetition of items is allowed
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.17)
Syn: bag
|
|
multiset cardinality.
(1)
sum of the multiplicities of each of the members of the multiset
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.19)
Syn: cardinality of a multiset
|
|
multitasking.
(1)
mode of operation in which two or more tasks are executed in an interleaved manner
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: multiprocessing, multiprogramming, time sharing
|
|
mutable class.
(1)
class for which the set of instances is not fixed; its instances come and go over time
(ISO/IEC/IEEE 24765n:2025, 3.1.120)
See Also: immutable class, state class
|
|
mutation testing.
(1)
testing methodology in which two or more program mutations are executed using the same test cases to evaluate the ability of the test cases to detect differences in the mutations
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
mutual exclusion.
(1)
giving access to shared data only to one task at a time
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: can be enforced by means of binary semaphores or by using monitors.
|
|
mutually exclusive.
(1)
alternatives from which at most one is selected
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.9)
See Also: mutually inclusive
|
|
mutually exclusive clustering.
(1)
task structuring criterion in which a group of objects are combined into one task because only one object can be executed at any one time
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
mutually inclusive.
(1)
alternatives from which zero or more are selected
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.10)
See Also: mutually exclusive
|
|
MVP.
(1)
minimum viable product
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.29)
|
|
N 2 diagram.
(1)
system engineering or software engineering tool for tabulating, defining, analyzing, and describing functional interfaces and interactions among system components
(ISO/IEC/IEEE 24765e:2015)
Note: The N 2 diagram is a matrix structure that graphically displays the bidirectional interrelationships between functions and components in a given system or structure.
Syn: N2 diagram
|
|
n-address instruction.
(1)
computer instruction that contains n address fields, where n is any non-negative integer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: one-address instruction, two-address instruction, n-plus-one address instruction
|
|
N-ary relationship.
(1)
relationship with arity (degree) n > 2
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
Note: A relationship that has more than two participating entities. A single entity can participate several times in a single relationship.
|
|
n-level address.
(1)
indirect address that specifies the first of a chain of n storage locations, the first n-1 of which contains the address of the next location in the chain and the last of which contains the desired operand
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a two-level address
See Also: direct address, immediate data
|
|
n-plus-one address instruction.
(1)
computer instruction that contains n+1 address fields, the last containing the address of the instruction to be executed next
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: one-plus-one address instruction, two-plus-one address instruction, n-address instruction
|
|
N/A.
(1)
not applicable
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
(2)
not available
(ISO/IEC/IEEE 24765c:2014)
|
|
N/R.
(1)
not required
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
N2 diagram.
(1)
graphical representation used to define the internal operational relationships or external interfaces of the system of interest
(INCOSE Systems Engineering Handbook, 5th ed.)
Syn: N-squared diagram
|
|
name.
(1)
word or phrase that designates some model construct
(ISO/IEC/IEEE 24765n:2025, 3.1.121)
(2)
term which, in a given naming context, refers to an entity
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 12.1)
|
|
name resolution.
(1)
process by which, given an initial name and an initial naming context, an association between a name and the entity designated by the initial name can be found
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 12.8)
|
|
name space.
(1)
set of terms usable as names
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 12.3)
|
|
named constant.
(1)
identifier that refers to a numeric or string value that does not change during program execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
named constraint.
(1)
constraint that is specific to a particular model, rather than being inherent in some modeling construct
(ISO/IEC/IEEE 24765n:2025, 3.1.122)
Note: Such as a cardinality constraint. A named constraint is explicitly named, its meaning is stated in natural language, and its realization is written in the specification language.
|
|
naming action.
(1)
action that associates a term from a name space with a given entity
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 12.5)
|
|
naming context.
(1)
relation between a set of names and a set of entities
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 12.4)
|
|
naming domain.
(1)
subset of a naming context such that all naming actions are performed by the controlling object of the domain (the name authority object)
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 12.6)
|
|
naming graph.
(1)
directed graph where each vertex denotes a naming context, and where each edge denotes an association between a name appearing in the source naming context and the target naming context
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 12.7)
|
|
nano code.
(1)
collection of nanoinstructions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
nanoinstruction.
(1)
in a two-level implementation of microprogramming, an instruction that specifies one or more of the basic operations needed to carry out a microinstruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
nanostore.
(1)
in a two-level implementation of microprogramming, a secondary control store in which nanoinstructions reside
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
narrow artificial intelligence.
(1)
artificial intelligence focused on a single well-defined task to address a specific problem
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.47)
Syn: narrow AI, weak artificial intelligence, weak AI
|
|
natural language.
(1)
language whose rules are based on usage rather than being pre-established prior to the language's use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
language whose rules are based on current usage without being specifically prescribed
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Example: German and English
See Also: formal language
|
|
natural unit.
(1)
application-specific alternative to absolute or relative time to quantify the usage frequency of a software-based product
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Example: sensor interrupts, runs, user selection of menu items, pages of output, transactions, telephone calls, SMS messages, jobs, queries, or API calls
|
|
navigation.
(1)
process of accessing on-screen information by moving between different locations in a website or electronic document
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.17)
(2)
process of accessing on-screen documentation and moving between different items of information
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.27)
(3)
act of accessing documentation and viewing different topics
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.35)
|
|
navigational aids.
(1)
features of software that help the user to navigate around a computer application
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
Example: shortcut keys to move through a dialogue faster
|
|
NDA.
(1)
non-disclosure agreement
(ISO/IEC/IEEE 41062:2024, Software engineering Life cycle processes Software acquisition, 3.2)
|
|
NDI.
(1)
non-developmental item
(ISO/IEC/IEEE 24748-6:2023 Systems and software engineering Life cycle management Part 6: System and software integration, 3.2)
|
|
need statement.
(1)
result of a formal transformation of one or more life cycle concepts into an agreed-to expectation for an entity to perform some function or possess some quality
(INCOSE Systems Engineering Handbook, 5th ed.)
|
|
negotiation.
(1)
resolution of disputes through consultations between involved parties
(ISO/IEC/IEEE 24765h:2019)
|
|
NEQ.
(1)
not equal
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
nest.
(1)
to incorporate a computer program construct into another construct of the same kind
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: to nest one subroutine, block, or loop within another; to nest one data structure within another
|
|
nesting.
(1)
embedding one construct inside another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: to embed a WHILE loop within another WHILE loop or to embed an IF test within a WHILE loop
|
|
network.
(1)
arrangement of nodes and interconnecting branches
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
network chart.
(1)
directed graph used for describing and scheduling events, activities, and their relationships in project control
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
network open end.
(1)
schedule activity without any predecessor activities or successor activities, causing a break in a schedule network path
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Network open ends are usually caused by missing logical relationships
|
|
network path.
(1)
sequence of activities connected by logical relationships in a project schedule network diagram
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
network planning.
(1)
technique that uses network charts for planning, scheduling. and controlling a project
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
networking.
(1)
developing relationships with persons who can assist in the achievement of objectives and responsibilities
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
neural network.
(1)
network of primitive processing elements connected by weighted links with adjustable weights, in which each element produces a value by applying a nonlinear function to its input values, and transmits it to other elements or presents it as an output value
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.48)
Example: threshold function, sigmoid function, polynomial function
Note: Whereas some neural networks are intended to simulate the functioning of neurons in the nervous system, most neural networks are used in artificial intelligence as realizations of the connectionist model.
Syn: artificial neural network
|
|
neuron coverage.
(1)
proportion of activated neurons divided by the total number of neurons in the neural network (normally expressed as a percentage) for a set of tests
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.49)
Note: A neuron is considered to be activated if its activation value exceeds zero.
|
|
new source statements.
(1)
sum of the added and modified source statements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
NFR.
(1)
non-functional requirement
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.25)
|
|
NFSM.
(1)
non-functional size measurement
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.2)
|
|
no-op.
(1)
no-operation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
no-operation.
(1)
computer operation whose execution has no effect except to advance the instruction counter to the next instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: used to reserve space in a program or, if executed repeatedly, to wait for a given event
Syn: do-nothing operation
|
|
node.
(1)
vertex of a net graph, i.e. either a place or a transition
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.20)
(2)
configuration of engineering objects forming a single unit for the purpose of location in space, and which embodies a set of processing, storage, and communication functions
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.7)
Note: A node can have internal structure which is not of concern in an engineering specification.
See Also: graph
|
|
node letter.
(1)
letter that is the first character of a node number
(ISO/IEC/IEEE 24765m:2024, 2.1.82)
|
|
node number.
(1)
expression that unambiguously identifies a function's position in a model hierarchy
(ISO/IEC/IEEE 24765m:2024, 2.1.83)
Note: A node number is constructed by concatenating a node letter, the diagram number of the diagram that contains the box that represents the function, and the box number of that box.
|
|
nomenclature standard.
(1)
standard that describes the characteristics of a system or set of names, or designations, or symbols
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
nominal scale.
(1)
scale in which the measurement values are categorical
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: For example, the classification of defects by their type does not imply order among the categories.
See Also: ordinal scale, interval scale, ratio scale
|
|
non-compensatory model.
(1)
multiple-criteria decision-making model that does not allow criteria to compensate for each other in proportion to their weights
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.12)
Note: Strongly positive or negative terms influence the overall composite value disproportionately,
although the weight stays the same. There are various non-compensatory models depending on the evaluation policy, the purpose of the composite measure, or the measurement scale.
|
|
non-deliverable item.
(1)
hardware or software product that is not required to be delivered under the contract, but may be employed in the development of a product
(ISO/IEC/IEEE 24765g:2018)
Syn: nondeliverable item
|
|
non-deterministic system.
(1)
system which, given a particular set of inputs and starting state, will not always produce the same set of outputs and final state
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.50)
Syn: nondeterministic system
|
|
non-functional requirement (NFR).
(1)
requirement for a software-intensive system or for a software product, including how it should be developed and maintained, and how it should perform in operation, except any functional user requirement for the software
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.25)
|
|
non-functional requirements for software.
(1)
portion of the non-functional requirements (NFR) that are realized by the software
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.26)
Syn: NFR for software
|
|
non-functional size.
(1)
size of the software derived by quantifying the non-functional requirements (NFR), defined by a set of rules
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.24)
Syn: nonfunctional size
|
|
non-primary entity.
(1)
a data entity-type arrived at by Third Normal Form analysis which is not one of the main entity-types for which the application in question has been built
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
Note: Non-primary entities have only very few attributes, e.g. code, description
See Also: system entity
|
|
non-repudiation.
(1)
capability of a product to prove that actions or events have taken place, so that the events or actions cannot be repudiated later
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.6.3)
|
|
non-terminal symbol.
(1)
part of the hierarchical definition of a syntax that is further decomposed in the hierarchy
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
|
|
non-time-critical computationally intensive task.
(1)
low-priority compute-bound task that consumes spare CPU cycles
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
non-volatile memory.
(1)
unit that stores data whether power is on or off
(ISO/IEC/IEEE 24765c:2014)
|
|
noncompensatory decision technique.
(1)
a multi-attribute decision technique that weighs all attributes equally, without allowing lower performance in one attribute to be traded off against better performance in another attribute
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: compensatory decision technique
|
|
nonconformity.
(1)
non-fulfillment of a requirement
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.36)
Syn: non-conformity
|
|
nondelivered source statement.
(1)
source statement that is developed in support of the final product, but not delivered to the customer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: non-delivered source statement
|
|
nondestructive read.
(1)
read operation that does not erase the data in the accessed location
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: non-destructive read
See Also: destructive read
|
|
nondeveloped source statement.
(1)
existing source statement that is reused or deleted
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: non-developed source statement
|
|
nondevelopmental.
(1)
developed prior to its current use in an acquisition or development process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: Such an item can require minor modifications to meet the requirements of its current intended use.
|
|
nondimensional scaling.
(1)
decision technique in which attribute values are converted into a common scale where they can be added together to make a composite score for each alternative
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: additive weighting, analytic hierarchy process, compensatory decision technique
|
|
nonfunctional requirement.
(1)
software requirement that describes not what the software will do but how the software will do it
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
(2)
specification of how a system shall be developed and maintained, or how it performs in operation
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
Example: software performance requirements, software external interface requirements, software design constraints, and software quality attributes.
See Also: functional requirement, quality requirement
|
|
nonidentifying relationship.
(1)
a specific (not many-to-many) relationship in which some or all of the attributes contained in the primary key of the parent entity do not participate in the primary key of the child entity
(ISO/IEC/IEEE 24765n:2025, 3.1.123)
Syn: non-identifying relationship
See Also: identifying relationship, mandatory nonidentifying relationship, optional nonidentifying relationship [key style]
|
|
nonintrinsic relationship.
(1)
relationship that is partial, is multi-valued, or changeable.
(ISO/IEC/IEEE 24765n:2025, 3.1.125)
Syn: non-intrinsic relationship
See Also: intrinsic relationship
|
|
nonkey attribute.
(1)
attribute that is not the primary or a part of a composite primary key of an entity
(ISO/IEC/IEEE 24765n:2025, 3.1.125)
Note: [key style]
Syn: non-key attribute
|
|
nonprocedural language.
(1)
language in which the user states what is to be achieved without having to state specific instructions that the computer executes in a given sequence
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: procedural language, declarative language, interactive language, rule-based language
|
|
nonprocedural programming language.
(1)
computer programming language used to express the parameters of a problem rather than the steps in a solution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
Example: report writer or sort specification languages
Syn: non-procedural programming language
See Also: procedural programming language
|
|
nonprogrammable terminal.
(1)
user terminal that has no independent data processing capability
(ISO/IEC/IEEE 24765n:2025)
Syn: non-programmable terminal
|
|
nontechnical requirement.
(1)
requirement affecting product and service acquisition or development that is not a property of the product or service
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: numbers of products or services to be delivered, data rights for delivered COTS nondevelopmental items, delivery dates, milestones with exit criteria, work constraints associated with training, site provisions, and deployment schedules.
|
|
NOR.
(1)
notice of revision
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
norm.
(1)
something that is usual, typical, or standard
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
|
|
normalization.
(1)
process by which a data structure can be transformed by a database designer into a set of relations that have no repeating groups
(ISO/IEC/IEEE 24765a:2011)
|
|
not printable.
(1)
not a |
|
notation.
(1)
means of concrete representation for a particular type of a model, expressed as a grammar and suitable glyphs for its terminal symbols
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 7.5)
|
|
notation standard.
(1)
standard that describes the characteristics of formal interfaces within a profession
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
note.
(1)
helpful hint or other information that assists the user by emphasizing or supplementing important points of the main text
(ISO/IEC/IEEE 24765g:2018)
(2)
body of free text that describes some general comment or specific constraint about a portion of a model
(ISO/IEC/IEEE 24765n:2025, 3.1.126)
See Also: caution, danger, warning
|
|
notebook computer.
(1)
battery-powered portable computer small and light enough to be operated anywhere
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Syn: laptop computer
|
|
notice of revision (NOR).
(1)
form used in configuration management to propose revisions to a drawing or list, and, after approval, to notify users that the drawing or list has been, or will be, revised accordingly
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: configuration control, engineering change, specification change notice
|
|
NRR.
(1)
normal run response
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
NRT.
(1)
normal run termination
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
NSBGM.
(1)
non-state-based grievance mechanism
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
NSR.
(1)
normal support response
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
NTF.
(1)
non-terminal failure
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
nth of a kind.
(1)
re-manufacturing or re-installation of a previously verified and validated hardware or software design
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
Note: The nth of a kind component or system is equivalent to the first
application in all relevant aspects, including functional and performance requirements, design documentation, environment, and regulatory constraints.
|
|
nucleus.
(1)
engineering object which coordinates processing, storage and communications functions for use by other engineering objects within the node to which it belongs
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.6)
Example: an operating system
See Also: kernel
|
|
number of data element types.
(1)
sum of all data element types (DETs) that are part of the input/output/query of the elementary process(EP), plus the data elements which are read or maintained internally to the boundary
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.27)
Syn: number of DETs
|
|
numeric.
(1)
pertaining to data that consists of numerals as well as functional units that use the data
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
NVR.
(1)
network video recorder
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
O&S.
(1)
operations and support
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
Syn: O & S
|
|
OASIS.
(1)
Organization for the Advancement of Structured Information Standards
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)
|
|
OAUTH.
(1)
open authentication
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
object.
(1)
encapsulation of data and services that manipulate that data
(ISO/IEC/IEEE 24765l:2024)
(2)
encapsulation of content units in a component content management system
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.23)
(3)
arc, node, reference node, or page of a net graph
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.7)
(4)
model of an entity
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.1)
Note: An object represents something in the observable world that is distinguished from other instances of its object type and can be uniquely identified.
See Also: object code, object module, object program
|
|
object code.
(1)
computer instructions and data definitions in a form output by an assembler or compiler
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: An object program is made up of object code.
See Also: source code
|
|
object identifier.
(1)
some concrete representation for the identity of an object (instance)
(ISO/IEC/IEEE 24765n:2025, 3.1.128)
Note: The object identifier (OID) is used to show examples of instances with identity, to formalize the notion of identity, and to support the notion in programming languages or database systems.
Syn: OID
|
|
object implementation.
(1)
definition that provides the information needed to create an object and to allow the object to participate in providing an appropriate set of services
(ISO/IEC/IEEE 24765l:2024)
|
|
Object Management Group (OMG).
(1)
international standards organization that owns and maintains CORBA(R) and UML(R) standards
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
object module.
(1)
computer program or subprogram that is the output of an assembler or compiler
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: load module, object program
|
|
object of interest (-type).
(1)
anything that is identified from the point of view of the functional user requirements about which the software is required to process or store data
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.19)
Note: An object of interest can be any physical thing, as well as any conceptual object or part of a conceptual object
in the world of the functional user.
Syn: object of interest type
|
|
object program.
(1)
computer program that is the output of an assembler or compiler
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: target program
See Also: source program object module
|
|
object reference.
(1)
value that unambiguously stores a reference for accessing an object
(ISO/IEC/IEEE 24765l:2024)
Example: null
|
|
object set.
(1)
subset of instantiations from the set of all possible instantiations of all object types within an object type set
(ISO/IEC/IEEE 24765m:2024, 2.1.86)
Note: An object set is a subset of the union of the members of an object type set; the set of object sets includes the empty set and the set of the union of the members of the object type set itself. An object set is modeled by an arrow segment.
|
|
object type set.
(1)
named set of one or more object types
(ISO/IEC/IEEE 24765m:2024, 2.1.88)
Example: null
Note: An object type set can include object types that are themselves grouped as object type sets. An object type set is designated by an arrow label.
|
|
object-oriented design.
(1)
software development technique in which a system or component is expressed in terms of objects and connections between those objects
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: data structure-centered design, input-process-output, modular decomposition, rapid prototyping, stepwise refinement, structured design, transaction analysis, transform analysis
|
|
object-oriented language.
(1)
programming language that allows the user to express a program in terms of objects and messages between those objects
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: Smalltalk, LOGO
|
|
objective.
(1)
something toward which work is to be directed, a strategic position to be attained, a purpose to be achieved, a result to be obtained, a product to be produced, or a service to be performed
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
practical advantage or intended effect, expressed as preferences about future states
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.2.1)
(3)
result to be achieved
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.37)
(ISO/IEC/IEEE 16085:2021 Systems and software engineering--Life cycle processes--Risk management, 3.3)
(4)
predetermined result to be achieved
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.30)
Note: An objective can relate to different disciplines (such as financial, health and safety, and environmental goals) and can apply at different levels (such as strategic, organization-wide, project, product, and process). An objective can be expressed in other ways, e.g. as an intended outcome, a purpose, an operational criterion, an objective related to risk management, or by the use of other words with similar meaning (e.g. aim, goal, or target). Objectives related to risk management are set by the organization, consistent with the risk policy, to achieve specific results. Some objectives are ongoing; some are achieved once met.
Syn: purpose
|
|
objective evidence.
(1)
data supporting the existence or verity of something
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.13)
Note: Objective evidence can be obtained through observation, measurement, test, or other means. [ISO 9000:2015]
|
|
objective function.
(1)
formula that relates a decision variable to either the cost or the revenue of an alternative
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: cost function, income function
|
|
obligation.
(1)
prescription that a particular behavior is required
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.4)
|
|
OBS.
(1)
organizational breakdown structure
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
observation.
(1)
instance of applying a measurement procedure to produce a value for a base measure
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.28)
|
|
observation period.
(1)
time interval, where the measurement procedure is observed for collecting (logging) measurement results for rating or validation, consisting of the rating interval and the supplementary run
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.11)
|
|
occupational title standard.
(1)
standard that describes the characteristics of the general areas of work or profession
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
OCD.
(1)
operational concept document
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
See Also: concept of operations (ConOps) document
|
|
octet.
(1)
byte that consists of eight bits
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Syn: 8-bit byte
|
|
ODP.
(1)
Open Distributed Processing
(ISO/IEC 19793:2015 Information technology -- Open Distributed Processing -- Use of UML for ODP system specifications, 4)
Example: null
|
|
ODP function.
(1)
function required to support Open Distributed Processing
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.3.1)
|
|
ODP IDL.
(1)
Open Distributed Processing Interface Definition Language
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 4)
|
|
ODP standard.
(1)
standard that complies with the ODP Reference Model, directly or indirectly
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 3.2.3)
|
|
ODP system.
(1)
system which conforms to the requirements of ODP standards
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 3.2.5)
|
|
ODP-RM.
(1)
Open Distributed Processing: Reference Model
(ISO/IEC 14769:2001 Information technology -- Open Distributed Processing -- Type Repository Function, 4)
Syn: RM-ODP
|
|
OEM.
(1)
original equipment manufacturer
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.2)
|
|
OF.
(1)
operational failure
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
off-the-shelf.
(1)
product or system already developed and available
(ISO/IEC/IEEE 41062:2024, Software engineering Life cycle processes Software acquisition, 3.1.12)
Syn: OTS, off the shelf
|
|
office automation (OA).
(1)
integration of office activities by means of an information processing system
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: This term includes in particular the processing and communication of text, images, and voice.
|
|
offline.
(1)
pertaining to a device or process that is not under the direct control of the central processing unit of a computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
pertaining to the operation of a functional unit that takes place either independently of, or in parallel with, the main operation of a computer
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
See Also: online
|
|
offset.
(1)
difference between the loaded origin and the assembled origin of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
number that is added to a relative address to determine the address of the storage location to be accessed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: relocation factor
|
|
OID.
(1)
object identifier
(ISO/IEC 13235-3:1998 Information technology -- Open Distributed Processing -- Trading Function -- Part 3: Provision of Trading Function using OSI Directory service, 4)
|
|
OJT.
(1)
on-the-job-training
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.2)
|
|
OLA.
(1)
operations level agreement
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
|
|
OLGM.
(1)
operational level grievance mechanism
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
OMT.
(1)
Object Modeling Technique
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
on-chip oscillator.
(1)
electronic circuit on a microcomputer that produces a periodic electronic signal, often used for a device clock
(ISO/IEC/IEEE 24765d:2015)
|
|
on-demand scheduling.
(1)
scheduling approach in which work is pulled from a backlog according to the perceived value to customers and is assigned as resources become available
(Software Extension to the PMBOK(R) Guide Fifth Edition)
See Also: late binding
|
|
on-screen documentation.
(1)
information that is intended to be read on the screen by the user while using the software
(ISO/IEC/IEEE 26512:2018 Systems and software engineering--Requirements for acquirers and suppliers of information for users, 3.15)
Example: pop-up help and help text on a screen
Syn: on-screen information
See Also: printed documentation, embedded documentation
|
|
one-address instruction.
(1)
computer instruction that contains one address field
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: an instruction to load the contents of location A
Syn: single-address instruction, single-operand instruction
See Also: multiaddress instruction, two-address instruction, three-address instruction, four-address instruction, zero-address instruction
|
|
one-ahead addressing.
(1)
method of implied addressing in which the operands for a computer instruction are understood to be in the storage locations following the locations of the operands used for the last instruction executed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: repetitive addressing
|
|
one-plus-one address instruction.
(1)
computer instruction that contains two address fields, the second containing the address of the instruction to be executed next
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: an instruction to load the contents of location A, then execute the instruction at location B
See Also: two-plus-one address instruction, three-plus-one address instruction, four-plus-one address instruction
|
|
one-time programming (OTP).
(1)
method of recording data in ROM which can only be written once
(ISO/IEC/IEEE 24765c:2014)
|
|
one-to-many relationship.
(1)
relationship between two state classes in which each instance of one class, referred to as the child class, is specifically constrained to relate to no more than one instance of a second class, referred to as the parent class
(ISO/IEC/IEEE 24765n:2025, 3.1.131)
|
|
online.
(1)
pertaining to a system or mode of operation in which input data enter the computer directly from the point of origin or output data are transmitted directly to the point where they are used
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
pertaining to a device or process that is under the direct control of the central processing unit of a computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
pertaining to the operation of a functional unit when under the control of a computer
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Example: an airline reservation system
See Also: batch, conversational, real time
|
|
online documentation.
(1)
information accessed by the user through the use of software
(ISO/IEC/IEEE 24765a:2011)
Note: can be context-sensitive
|
|
online help.
(1)
information about the software that is intended to be read on the screen by the user while using the software
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.28)
Note: Online help can be displayed in a variety of forms (contextual help, screen tips, and examples).
|
|
onscreen information for users.
(1)
information for users that is intended to be read on the screen by the user while using the software
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.36)
Example: Pop-up help and help text on a screen
See Also: embedded information for users, printed information for users
|
|
ontology.
(1)
logical structure of the terms used to describe a domain of knowledge, including both the definitions of the applicable terms and their relationships
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.23)
|
|
OOD.
(1)
object-oriented design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
OOSEM.
(1)
object-oriented systems engineering method
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
OPA.
(1)
organizational process asset
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
open distributed processing.
(1)
distributed processing designed to conform to ODP standards
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 3.2.4)
Syn: ODP
|
|
open subroutine.
(1)
subroutine that is copied into a computer program at each place that it is called
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: direct insert subroutine
See Also: closed subroutine, inline code, macro
|
|
operability.
(1)
capability of a product to have functions and attributes that make it easy to operate and control
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.4.3)
(2)
degree to which an IT service has attributes that make it easy to operate and control
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.2.3)
Note: Operability is related to controllability, user error robustness, and conformity with user expectations. It is also related to the effectiveness and efficiency of physical interface devices (e.g. mouse, touch pen).
|
|
operable.
(1)
state of being able to perform the intended function
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
operand.
(1)
variable, constant, or function upon which an operation is to be performed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: In the expression A = B + 3, B and 3 are the operands.
|
|
operating environment (software).
(1)
set of software operating concurrently on a specified computer system
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.20)
Syn: operating environment software
|
|
operating mode.
(1)
type of operation for a system
(ISO/IEC/IEEE 24765d:2015)
Example: high-speed mode, low power mode
|
|
operating system.
(1)
collection of software, firmware, and hardware elements that controls the execution of computer programs and provides such services as computer resource allocation, job control, input/output control, and file management in a computer system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: OS
|
|
operation.
(1)
in computer mathematics, the action specified by an operator on one or more operands
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
in programming, a defined action that can be performed by a computer system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
running a computer system in its intended environment to perform its intended functions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
interaction between a client object and a server object which is either an interrogation or an announcement
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.2)
(5)
arithmetic or logical operation performed in an algorithmic and manipulation BFC
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, 3.7)
(6)
action needed to perform an activity
(ISO/IEC 15940:2013 Systems and software engineering--Software Engineering Environment Services, 2.11)
Example: In the expression A = B + 3, adding B to 3 to obtain A.
Note: An operation can consist of other operations.
|
|
operation and maintenance costs.
(1)
costs associated with using an asset as well as costs of keeping it in a usable condition
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
operation and maintenance phase.
(1)
period of time in the software life cycle during which a software product is employed in its operational environment, monitored for satisfactory performance, and modified as necessary to correct problems or to respond to changing requirements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
operation code.
(1)
character or set of characters that specifies a computer operation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: the code BNZ to designate the operation 'branch if not zero'.
Syn: op code
|
|
operation exception.
(1)
exception that occurs when a program encounters an invalid operation code
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: addressing exception, data exception, overflow exception, protection exception, underflow exception
|
|
operation field.
(1)
field of a computer instruction that specifies the operation to be performed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: function field, operation part
See Also: address field
|
|
operation interface.
(1)
interface in which all the interactions are operations
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.7)
|
|
operation interface signature.
(1)
interface signature for an operation interface
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.12)
Note: An operation interface signature comprises a set of announcements and interrogation signatures as appropriate, one for each operation type in the interface, together with an indication of causality (client or server, but not both) for the interface as a whole, with respect to the object which instantiates the template.
|
|
operational.
(1)
pertaining to a system or component that is ready for use in its intended environment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
(2)
pertaining to a system or component that is installed in its intended environment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
(3)
pertaining to the environment in which a system or component is intended to be used
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
operational concept (OpsCon).
(1)
verbal and graphic statement of an organizations assumptions or intent in regard to an operation or series of operations of a specific system or a related set of specific new, existing or modified systems
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.39)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.23)
Note: The operational concept is designed to give an overall picture of the operations using one or more specific systems, or set of related systems, in the organization's operational environment from the users' and operators' perspective.
See Also: concept of operations
|
|
operational constraint.
(1)
capability of a product to constrain its operation to within safe parameters or states when encountering an operational hazard
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.9.1)
|
|
operational environment.
(1)
physical context, setting, and circumstances used to support the in-service operation of a system
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: includes direct factors (developmental, technological, business, operational, organizational) and in some cases indirect factors (political, ethical, economic, legal, regulatory, ecological, and social) that may have a material effect on the dependability of a system
|
|
operational scenario.
(1)
description of an imagined sequence of events that includes the interaction of the product or service with its environment and users, as well as interaction among its product or service components
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.1.15)
Note: Operational scenarios are used to evaluate the requirements and design of the system and to verify and validate the system.
|
|
operational testing.
(1)
testing conducted to evaluate a system or component in its operational environment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
See Also: development testing, acceptance testing, qualification testing
|
|
operations.
(1)
ongoing execution of activities that produce the same product or provide a repetitive service
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: production, manufacturing, accounting
|
|
operator.
(1)
entity that performs the operation of a system
(2)
individual or organization that performs the operations of a system
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.40)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.24)
(3)
entity that performs the operations of a system
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.29)
(4)
mathematical or logical symbol that represents an action to be performed in an operation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(5)
individual or organization that operates the system
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.4)
(6)
symbol representing the name of a function
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.21)
(7)
individual or organization that performs the operations of a product, service or system
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
Note: The role of operator and the role of user can be vested, simultaneously or sequentially, in the same individual or organization. An individual operator combined with knowledge, skills and procedures can be considered as an element of the system. An operator can perform operations on a system that is operated, or of a system that is operated, depending on whether or not operating instructions are placed within the system boundary.
See Also: secondary user
|
|
operator manual.
(1)
document that provides the information necessary to initiate and operate a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Typically described are procedures for preparation, operation, monitoring, and recovery. An operator manual is distinguished from a user manual when a distinction is made between those who operate a computer system and those who use the system for its intended purpose.
Syn: operator's manual, operations manual
See Also: diagnostic manual, installation manual, programmer manual, support manual, user manual
|
|
OPM.
(1)
object-process methodology
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
Note: See ISO 19450
|
|
opportunity.
(1)
risk that would have a positive effect on one or more project objectives
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
condition or state with a potential to lead to a benefit or gain
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
See Also: threat
|
|
opportunity cost.
(1)
implicit cost associated with investing money in a certain activity, so that it is no longer available for investing elsewhere
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Making an investment means that the same money cannot be invested elsewhere, where it can be earning the minimum attractive rate of return (MARR).
See Also: minimum attractive rate of return (MARR)
|
|
opportunity study.
(1)
study to examine a problem and determine whether or not it requires being solved during the time period under consideration
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
OpsCon.
(1)
operational concept
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.2)
Syn: OPSCON
|
|
optical disc (OD).
(1)
disk which stores binary data in the form of pits which interrupt the reflection of light from a laser
(ISO/IEC/IEEE 24765c:2014)
|
|
optimistic duration.
(1)
estimate of the shortest activity duration that takes into account the known variables that can affect performance
(ISO/IEC/IEEE 24765h:2019)
|
|
optimization analysis.
(1)
balance of competing components to achieve the best performance under the situation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: For example, an algorithm that runs faster will typically use more memory. Optimization balances the value of a faster run time against the cost of additional memory.
|
|
optimizing process.
(1)
quantitatively managed process that is improved based on an understanding of the common causes of variation inherent in the process.
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The focus of an optimizing process is on continually improving the range of process performance through both incremental and innovative improvements.
|
|
optional.
(1)
syntax keyword used to specify a partial mapping
(ISO/IEC/IEEE 24765n:2025, 3.1.133)
Note: Optional recommendations are expressed using "should".
Syn: O
See Also: mandatory, partial
|
|
optional attribute.
(1)
attribute that can have no value for an instance
(ISO/IEC/IEEE 24765n:2025, 3.1.134)
|
|
optional nonidentifying relationship.
(1)
nonidentifying relationship in which an instance of the child entity can exist without being related to an instance of the parent entity
(ISO/IEC/IEEE 24765n:2025, 3.1.135)
See Also: mandatory nonidentifying relationship. nonidentifying relationship [key style]
|
|
optional requirement.
(1)
requirement of a normative document that is fulfilled in order to comply with a particular option permitted by that document
(ISO/IEC 14143-2:2011 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1, 3.6)
Note: An optional requirement is either: a) one of two or more alternative requirements, or b) an additional requirement that is fulfilled only if applicable and can otherwise be disregarded.
|
|
optional task.
(1)
verification and validation (V&V) task that can be added to the minimum V&V tasks to address specific application requirements
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
(2)
task that can be added to the minimum testing tasks to address specific requirements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
optional tasks.
(1)
verification and validation tasks that can be added to the minimum required verification and validation tasks to address specific application requirements
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
|
|
order clash.
(1)
in software design, a type of structure clash in which a program deal with two or more data sets that have been sorted in different orders
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: data structure-centered design
|
|
ordinal scale.
(1)
scale in which the measurement values are rankings
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: For example, the assignment of defects to a severity level is a ranking
See Also: interval scale, nominal scale, ratio scale
|
|
organization.
(1)
person or group of people that has its own functions with responsibilities, authorities, and relationships to achieve its objectives
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.41)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.25)
(2)
group of people and facilities with an arrangement of responsibilities, authorities and relationships
(ISO/IEC 15940:2013 Systems and software engineering--Software Engineering Environment Services, 2.4)
(3)
person or a group of people and facilities with an arrangement of responsibilities, authorities, and relationships
(INCOSE Systems Engineering Handbook, 5th ed.)
Example: company, corporation, firm, enterprise, institution, manufacturer, charity, sole trader, association, or parts or combination thereof, whether incorporated or not, public or private
Note: An identified part of an organization (even as small as a single individual) or an identified group of organizations can be regarded as an organization if it has responsibilities, authorities and relationships. A body of persons organized for some specific purpose, such as a club, union, corporation, or society, is an organization. An organization can be public or private. The arrangement is generally orderly.
Syn: organisation
|
|
organization chain.
(1)
constellation of organizations that have business relationships with one another
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.25)
Note: The following are two types of chains identified:
- supply chains of the IT organizations that are involved in the management and operation of the application (application manager, computer center, workspace manager, network manager, business information manager, suppliers, etc.);
- business chains in which the user organization using the application participates (the business process supported by the application forms part of a chain across several organizations; for example, the chain of criminal justice, the healthcare chain).
|
|
organization chart.
(1)
graphical depiction of hierarchies and interrelationships among persons working together
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
organization level.
(1)
management level or levels responsible for managing one or more data processing or information systems organizations
(ISO/IEC/IEEE 24765a:2011)
|
|
organizational breakdown structure (OBS).
(1)
hierarchical representation of the project organization, which illustrates the relationship between project activities and the organizational units that will perform those activities
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
organizational management profile.
(1)
profile targeted at very small entities (VSE) to provide additional organizational management guidance
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.55)
|
|
organizational maturity.
(1)
extent to which an organization has explicitly and consistently deployed processes that are documented, managed, measured, controlled, and continually improved.
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: Organizational maturity can be measured via appraisals.
|
|
organizational objective.
(1)
overarching objective that sets the context and direction for an organization's activities
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.39)
Note: Organizational objectives are established through the strategic level planning activities of the organization.
|
|
organizational plan.
(1)
documented information that specifies the programs to achieve the organizational objectives
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.40)
|
|
organizational policy.
(1)
guiding principle typically established by senior management that is adopted by an organization to influence and determine decisions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
organizational privacy framework.
(1)
set of principles, policies, and processes that describe what an organization may or may not do with personal data
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
organizational privacy requirements.
(1)
statements that reference key privacy objectives and specify capabilities and functions that a system performs
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
Example: Fair Information Practice Principles, or FIPPs
|
|
organizational process assets.
(1)
plans, processes, policies, procedures and knowledge bases, specific to and used by the performing organization
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
artifacts that relate to describing, implementing, and improving processes, such as policies, measurements, process descriptions, and process implementation support tools
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The term 'process assets' is used to indicate that these artifacts are developed or acquired to meet the business objectives of the organization and that they represent investments by the organization that are expected to provide current and future business value.
See Also: process asset library
|
|
organizational process maturity.
(1)
extent to which an organizational unit consistently implements processes within a defined scope that contributes to the achievement of its business needs (current or projected)
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.2)
Syn: organizational maturity
|
|
organizational risk.
(1)
risks that inhibit the achievement of business values and product line objectives
(ISO/IEC 26556:2018 Information technology--Software and systems engineering--Tools and methods for product line organizational management, 3.1)
|
|
organizational test practice.
(1)
documentation that expresses the recommended approaches or methods for the testing to be performed within an organization, providing detail on how the testing is to be performed
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.8)
Note: The organizational test practice is aligned with the organizational test policy. An organization can have more than one organizational test practices document to cover markedly different contexts, such one for mobile apps and one for safety critical systems. The organizational test practice can incorporate the context of the test policy where no separate test policy is available.
Syn: organizational test practices
|
|
organizational test process.
(1)
test process for developing and managing organizational test specifications
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.9)
|
|
organizational test specification.
(1)
document that provides information about testing for an organization, i.e. information that is not project-specific
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.10)
Example: organizational test policy and the organizational test practices
|
|
organizational unit.
(1)
part of an organization that is the subject of measurement
(ISO/IEC/IEEE 15939:2017 Systems and software engineering--Measurement process, 3.30)
(2)
identified part of an organization that deploys one or more processes that operate within a coherent set of business goals and which forms the basis for the scope of an assessment
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.14)
Note: An organizational unit is typically part of a larger organization, although in a small organization the organizational unit can be the whole organization.
|
|
origin.
(1)
address of the initial storage location assigned to a computer program in main memory
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assembled origin, loaded origin, starting address
|
|
origin attribute.
(1)
classification of software as either developed or nondeveloped
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
original equipment manufacturer license.
(1)
license for products or components that are created or manufactured by one company and licensed by another company
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.17)
Syn: OEM license
|
|
original source statement.
(1)
source statement that is obtained from an external product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
orphan page.
(1)
page on a website with no link from any other page on the website
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.18)
|
|
OS.
(1)
operating system
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
OSE.
(1)
Open System Environment
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
OSF.
(1)
Open Software Foundation
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
OSI.
(1)
Open Systems Interconnection
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
osmotic communication.
(1)
means of receiving information without direct communication by overhearing and through nonverbal cues
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
OSS.
(1)
open source software
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.2)
See Also: FOSS
|
|
OT.
(1)
operational test
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
OTE.
(1)
operational test and evaluation
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
Syn: OT&E, OT & E
|
|
OTP.
(1)
one-time password
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
OTRR.
(1)
operational test readiness review
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
OTS.
(1)
off the shelf
(ISO/IEC/IEEE 41062:2024, Software engineering Life cycle processes Software acquisition, 3.1.12)
|
|
outcome.
(1)
significant change of state or the meeting of specified constraints. e.g., requirements or goals.
(ISO/IEC/IEEE 24765l:2024)
(2)
end result or consequence of a process or project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
outer cardinality.
(1)
number of allowed instances of a participating data object from the viewpoint of the other participants in the relationship
(ISO/IEC 15476-4:2005 Information technology--CDIF semantic metamodel--Part 4: Data models, 6.6.1)
See Also: inner cardinality
|
|
output.
(1)
product, result, or service generated by a process
(ISO/IEC/IEEE 24774:2021, Systems and software engineering--Life cycle management--Specification for process description, 3.6)
(2)
process by which an information processing system, or any of its parts, transfers data outside of that system or part
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
See Also: process outcome
|
|
output arc (of a transition).
(1)
arc directed from the transition to a place
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.22)
|
|
output argument.
(1)
an argument that has not been specified as an input argument
(ISO/IEC/IEEE 24765n:2025, 3.1.136)
Note: It is possible for an output argument to have no value at the time a request is made.
See Also: input argument
|
|
output assertion.
(1)
logical expression specifying one or more conditions that program outputs satisfy in order for the program to be correct
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: input assertion, loop assertion, inductive assertion method
|
|
output place (of a transition).
(1)
place connected to the transition by an output arc
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.23)
|
|
output primitive.
(1)
primitive that includes source statements, function points, and documents
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
outsider's viewpoint.
(1)
perspective of a potential acquirer who does not own either an existing system nor its proposed replacement, and who evaluates the alternatives of buying the existing system at its salvage value or buying a replacement candidate system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: allows sunk cost and salvage values to be properly accounted for in a decision to replace a system
|
|
outsource.
(1)
make an arrangement in which an external organization performs part of an organization's function or process
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.41)
|
|
overfitting.
(1)
generation of a machine learning model that corresponds too closely to the training data, resulting in a model that finds it difficult to generalize to new data
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.51)
|
|
overflow exception.
(1)
exception that occurs when the result of an arithmetic operation exceeds the size of the storage location designated to receive it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: addressing exception, data exception, operation exception, protection exception, underflow exception
|
|
overhead time.
(1)
amount of time a computer system spends performing tasks that do not contribute directly to the progress of any user task
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: time spent tabulating computer resource usage for billing purposes
|
|
overlay.
(1)
storage allocation technique in which computer program segments are loaded from auxiliary storage to main storage when needed, overwriting other segments not currently in use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
computer program segment that is maintained in auxiliary storage and loaded into main storage when needed, overwriting other segments not currently in use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
to load a computer program segment from auxiliary storage to main storage in such a way that other segments of the program are overwritten
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
overlay supervisor.
(1)
routine that controls the sequencing and positioning of overlays
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
overload.
(1)
to assign an operator, identifier, or literal more than one meaning, depending upon the data types associated with it at any given time during program execution
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
override.
(1)
the ability of a property in a subclass to respecify the realization of an inherited property of the same name while retaining the same meaning
(ISO/IEC/IEEE 24765n:2025, 3.1.137)
|
|
overriding property.
(1)
property in a subclass that has the same meaning and signature as a similarly named property in one of its superclasses, but has a different realization
(ISO/IEC/IEEE 24765n:2025, 3.1.138)
|
|
OVM.
(1)
orthogonal variability model
(ISO/IEC 26559:2017 Software and systems engineering -- Methods and tools for variability traceability in software and systems product line, 4)
|
|
owned attribute.
(1)
attribute of an entity that has not migrated into the entity
(ISO/IEC/IEEE 24765n:2025, 3.1.139)
Note: [key style]
|
|
owner.
(1)
person or organization that owns the copyright for the Candidate FSM method
(ISO/IEC 14143-2:2011 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1, 3.7)
|
|
owner of the FSM method.
(1)
the person or organization that owns the intellectual property rights for the FSM method
(ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.7)
|
|
P&D.
(1)
production and deployment
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
Syn: P & D
|
|
P&P.
(1)
policies and procedures
(ISO/IEC/IEEE 24765k:2022)
Syn: P & P
|
|
P/T net.
(1)
Place/Transition net
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.2.4)
|
|
PaaS.
(1)
platform as a service
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
See Also: SaaS
|
|
pack.
(1)
to store data in a compact form in a storage medium, using known characteristics of the data and medium in such a way as to permit recovery of the data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: unpack
|
|
package.
(1)
separately compilable software component consisting of related data types, data objects, and subprograms
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to combine related components into a single, deployable item
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
(3)
namespace for the grouped elements
(ISO/IEC 30130:2016 Software engineering --Capabilities of software testing tools)
Example: a software package having a set of files that can be used to install software on a computing device and can be distributed via CD or electronic means
See Also: data abstraction, encapsulation, information hiding
|
|
packaging.
(1)
in software development, the assignment of modules to segments to be handled as distinct physical units for execution by a computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
padding.
(1)
technique of filling out a fixed-length block of data with dummy characters, words, or records
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
dummy characters, words, or records used to fill out a fixed-length block of data
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
page.
(1)
fixed-length segment of data or of a computer program treated as a unit in storage allocation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
in a virtual storage system, a fixed-length segment of data or of a computer program that has a virtual address and is transferred as a unit between main and auxiliary storage
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
screenful of information on a video display terminal
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
structuring mechanism used to split a large net graph into smaller parts, which are also the units of the net to be printed
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.8)
See Also: paging
|
|
page breakage.
(1)
portion of main storage that is unused when the last page of data or of a computer program does not fill the entire block of storage allocated to it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: paging
|
|
page frame.
(1)
block of main storage having the size of, and used to hold, a page
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: paging
|
|
page reference.
(1)
expression that unambiguously identifies a model page
(ISO/IEC/IEEE 24765m:2024, 2.1.91)
Note: The page reference incorporates a diagram reference to the associated diagram, the type of page, and any sequencing data needed to distinguish different pages of the same type that are associated with the same diagram.
|
|
page swapping.
(1)
exchange of pages between main storage and auxiliary storage
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: paging
|
|
page table.
(1)
table that identifies the location of pages in storage and gives significant attributes of those pages
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: paging
|
|
page type letter.
(1)
uppercase letter in a page reference that denotes a specific type of model page
(ISO/IEC/IEEE 24765m:2024, 2.1.92)
|
|
page zero.
(1)
in the paging method of storage allocation, the first page in a series of pages
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
page-by-page reviewing.
(1)
technique in which reviewers review a work product in a sequential order
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.11)
|
|
pager.
(1)
routine that initiates and controls the transfer of pages between main and auxiliary storage
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: paging
|
|
paging.
(1)
storage allocation technique in which programs or data are divided into fixed-length blocks called pages, main storage is divided into blocks of the same length called page frames, and pages are stored in page frames, not necessarily contiguously or in logical order
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
storage allocation technique in which programs or data are divided into fixed-length blocks called pages, main storage is divided into blocks of the same length called page frames, and pages are transferred between main and auxiliary storage as needed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: block allocation
See Also: contiguous allocation, page, page breakage, page frame, page swapping, page table, page zero, pager, working set
|
|
pair programming.
(1)
practice that typically involves one developer writing source code or configuring a system while a second developer observes their work to look for errors and to determine whether the completed work is accurate and meets its requirements
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.56)
Note: Pairs alternate roles periodically so a different developer writes code while the other developer observes.
|
|
pair review.
(1)
informal review of a work product performed by two suitably qualified people other than the author working together
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.12)
|
|
pairwise testing.
(1)
black-box test design technique in which test cases are designed to execute all possible discrete combinations of each pair of input parameters
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.52)
Note: Pairwise testing is the most popular form of combinatorial testing.
|
|
PAM.
(1)
process assessment model
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.62)
|
|
parallel.
(1)
pertaining to the simultaneous transfer, occurrence, or processing of the individual parts of a whole, such as the bits of a character, using separate facilities for the various parts
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: serial (1), concurrent
|
|
parallel classes.
(1)
pair of classes that are distinct, are not mutually exclusive and have a common generic ancestor class and for which neither is a generic ancestor of the other
(ISO/IEC/IEEE 24765n:2025, 3.1.140)
|
|
parallel construct.
(1)
program construct consisting of two or more procedures that can occur simultaneously
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
parallel run operation.
(1)
operation of two information processing systems, a given one and its intended replacement, with the same application and source data, for comparison and confidence
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
parameter.
(1)
variable that is given a constant value for a specified application
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
constant, variable, or expression that is used to pass values between software modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
symbol that can take a range of values defined by a set
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.24)
(4)
parts of the model that are learned from applying the training data to the algorithm
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.53)
Example: learned weights in a neural network
See Also: adaptation
|
|
parameter-value pair.
(1)
combination of a test item parameter with a value assigned to that parameter, used as a test coverage item in combinatorial test design techniques
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.38)
Syn: P-V pair
|
|
parameterized collection class.
(1)
collection class restricted to hold only instances of a specified type (class)
(ISO/IEC/IEEE 24765n:2025, 3.1.141)
|
|
parametric estimating.
(1)
estimating technique in which an algorithm is used to calculate cost or duration based on historical data and project parameters
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
parent box.
(1)
ancestral box related to its child diagram by exactly one parent/child relationship
(ISO/IEC/IEEE 24765m:2024, 2.1.93)
Note: That is, a box detailed by a child diagram. The existence of this child diagram is indicated by a box detail reference.
|
|
parent diagram.
(1)
diagram that contains a parent box
(ISO/IEC/IEEE 24765m:2024, 2.1.94)
|
|
parent entity.
(1)
entity in a specific relationship whose instances can be related to a number of instances of another entity (child entity)
(ISO/IEC/IEEE 24765n:2025, 3.1.142)
Note: [key style]
|
|
parent function.
(1)
function modeled by a parent box
(ISO/IEC/IEEE 24765m:2024, 2.1.95)
|
|
Pareto diagram.
(1)
histogram, ordered by frequency of occurrence, that shows how many results were generated by each identified cause
(ISO/IEC/IEEE 24765h:2019)
Syn: Pareto chart
|
|
parking lot.
(1)
register of deferred, unresolved issues or concerns
(ISO/IEC/IEEE 24765n:2025)
|
|
parking lot diagram.
(1)
displayed listing of incomplete tasks or user stories not yet being worked or completed
(Software Extension to the PMBOK(R) Guide Fifth Edition)
Note: This listing can be grouped by function, with the estimated priority and expected date to start, finish, or dispose of the items.
|
|
parse.
(1)
to determine the syntactic structure of a language unit by decomposing it into more elementary subunits and establishing the relationships among the subunits
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: to decompose blocks into statements, statements into expressions, expressions into operators and operands
|
|
parser.
(1)
software tool that parses computer programs or other text, often as the first step of assembly, compilation, interpretation, or analysis
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
partial.
(1)
incomplete mapping
(ISO/IEC/IEEE 24765n:2025, 3.1.143)
Example: null
Note: That is, some instances map to no related instance. An attribute can be declared partial, meaning it has no value. A participant property is declared optional as part of the relationship syntax. An operation is declared partial when it has no meaning for some instances, i.e., it does not give an answer or produce a response.
See Also: total, mapping completeness, optional
|
|
partial cluster.
(1)
subclass cluster in which an instance of the superclass exists without also being an instance of any of the subclasses
(ISO/IEC/IEEE 24765n:2025, 3.1.144)
Syn: incomplete cluster
See Also: total cluster, superclass
|
|
partial correctness.
(1)
in proof of correctness, a designation indicating that a program's output assertions follow logically from its input assertions and processing steps
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: total correctness
|
|
participant property.
(1)
property of a state class that reflects that class' knowledge of a relationship in which instances of the class participate
(ISO/IEC/IEEE 24765n:2025, 3.1.145)
Note: When a relationship exists between two state classes, each class contains a participant property for that relationship. A participant property is a mapping from a state class to a related (not necessarily distinct) state class. The name of each participant property is the name of the role that the other class plays in the relationship, or it is simply the name of the class at the other end of the relationship (as long as using the class name does not cause ambiguity). A value of a participant property is the identity of a related instance.
|
|
participatory design.
(1)
system design process that aims at investigating, understanding, reflecting upon, establishing, developing, and supporting mutual learning between multiple system stakeholders and system developers in collective reflection-in-action
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
Note: The participants in a participatory design practice typically undertake the two principal roles of users and designers, where the designers strive to learn the realities of the users situation and requirements, while the users strive to articulate their desired aims and identify appropriate technological means to obtain them.
|
|
partition.
(1)
set of software functions within an application boundary that share homogeneous criteria and values
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.28)
Example: Partitions can be used to improve maintainability by dividing the application into two modules (within a boundary), each needing different expertise. Integrating the modules requires additional effort, which is not reflected when sizing the functional aspect of the project or product, using function point analysis.
Note: Setting partitions is not based on technical or physical considerations. Partitions do not overlap.
|
|
partitioning.
(1)
decomposition; the separation of the whole into its parts
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
party.
(1)
organization entering into an agreement
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.42)
(2)
enterprise object modeling a natural person or any other entity considered to have some of the rights, powers and duties of a natural person
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.1)
Example: enterprise objects representing natural persons, legal entities, governments and their parts, and other associations or groups of natural persons
Note: Parties are responsible for their actions and the actions of their agents. Parties to an agreement are called the acquirer and the supplier.
|
|
pass.
(1)
single cycle in the processing of a set of data, usually performing part of an overall process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a pass of an assembler through a source program, a pass of a sort program through a set of data
|
|
pass/fail criteria.
(1)
decision rules used to determine whether a software item or a software feature passes or fails a test
(ISO/IEC 25051:2014 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, 4.1.10)
Syn: pass-fail criteria
|
|
passive I/O device.
(1)
device that does not generate an interrupt on completion of an input or output operation
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The input from a passive input device is read either on a polled basis or on demand.
|
|
passive I/O device interface task.
(1)
task that interfaces to a passive I/O device and either reads from it or writes to it on demand
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
passive object.
(1)
object with no thread of control
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: an object with operations that concurrent objects (that is, tasks) invoke directly or indirectly
|
|
patch.
(1)
modification made directly to an object program without reassembling or recompiling from the source program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
software component that, when installed, directly modifies files or device settings related to a different software component without changing the version number or release details for the related software component
(ISO/IEC 19770-2:2015 (corr 2017), Information technology -- Software asset management -- Part 2: Software identification tag, 3.1.1)
(3)
modification to a source or object program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
to perform a modification as in (1), (2), or (3)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
path.
(1)
in software engineering, a sequence of instructions that are performed in the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
in file access, a hierarchical sequence of directory and subdirectory names specifying the storage location of a file
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
sequence of executable statements of a test item
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.39)
|
|
path analysis.
(1)
analysis of a computer program to identify all possible paths through the program, to detect incomplete paths, or to discover portions of the program that are not on any path
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
path condition.
(1)
set of conditions required for a particular program path to be executed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
path expression.
(1)
logical expression indicating the input conditions that are required for a particular program path to be executed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
path testing.
(1)
testing designed to execute all or selected paths through a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: branch testing, statement testing
|
|
pathological coupling.
(1)
type of coupling in which one software module affects or depends upon the internal implementation of another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: common-environment coupling, content coupling, control coupling, data coupling, hybrid coupling
|
|
pause.
(1)
to suspend the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: halt, stop
|
|
payoff matrix.
(1)
in decisions under uncertainty, a table relating the desirability of a set of alternatives to a set of future states
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
PBS.
(1)
product breakdown structure
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.32)
|
|
PCA.
(1)
physical configuration audit
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
programmable counter array
(ISO/IEC/IEEE 24765d:2015)
|
|
PCB.
(1)
printed circuit board
(ISO/IEC/IEEE 24765d:2015)
|
|
PCBA.
(1)
printed circuit board assembly
(ISO/IEC/IEEE 24765d:2015)
|
|
PCI DSS.
(1)
payment card industry data security standard
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
PCO.
(1)
Point of Control and Observation
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
PDCA.
(1)
Plan-Do-Check-Act
(ISO/IEC/IEEE 24765c:2014)
|
|
PDF.
(1)
Portable Document Format
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.2)
Syn: .pdf
|
|
PDL.
(1)
program design language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
PDR.
(1)
preliminary design review
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
peer desk check.
(1)
informal review where the author and a colleague walk through a work product
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.13)
|
|
peer review.
(1)
review of work products performed by others qualified to do the same work
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.14)
Note: often performed during development of the work products to identify defects for removal. The intent is to increase the quality of the work product as well as to reduce cost by fixing defects as soon as possible.
See Also: buddy check, inspection, structured walkthrough, work product
|
|
peer software.
(1)
piece of software that resides in the same layer as, and exchanges data with, another piece of software
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.21)
|
|
PEO.
(1)
program executive office
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
perceptual reference point.
(1)
reference point at which there is some interaction between the system and the physical world
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 15.3.2)
|
|
perfective maintenance.
(1)
modification of a software product to provide enhancements for users, improvements of information for users, and recording to improve software performance, maintainability, or other software attributes
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.1.9)
See Also: adaptive maintenance, corrective maintenance
|
|
perfective support.
(1)
in-service modification of a system to provide enhancements
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
See Also: additive support, adaptive support
|
|
performance.
(1)
degree to which a system or component accomplishes its designated functions within given constraints, such as speed, accuracy, or memory usage
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
extent to which the execution of an application in the production environment achieves its purpose in terms of speed of input, transfer, processing, storage and output (the response speed of an application observed by an end user)
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.26)
(3)
measurable result
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.42)
(4)
quantitative measure characterizing a physical or functional attribute relating to the execution of a process, function, activity, or task
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: Performance attributes include quantity (how many or how much), quality (how well), timeliness (how responsive, how frequent), and readiness (when, under which circumstances). Performance can relate to the management of activities, processes, products (including services), systems, or organizations.
|
|
performance analysis.
(1)
quantitative analysis of a real-time system (or software design) executing on a given hardware configuration with a given external workload applied to it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
performance baseline.
(1)
result from a normal execution of a performance workload against a system without performing disturbance injection
(ISO/IEC 25045:2010 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Evaluation module for recoverability, 4.1)
|
|
performance deficiency.
(1)
difference between the required (or desired) level of performance and the actual performance
(ISO/IEC 25064:2013 Systems and software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Common Industry Format (CIF) for usability: User needs report, 4.9)
Note: Performance deficiencies can include deficiencies in measured customer satisfaction. Deficiency data is obtainable only in environments where specific performance requirements exist.
|
|
performance efficiency.
(1)
capability of a product to perform its functions within specified time and throughput parameters and be efficient in the use of resources under specified conditions
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.2)
Note: Resources can include other software products, the software and hardware configuration of the system, and materials (e.g. print paper, storage media).
|
|
performance measurement baseline.
(1)
integrated scope, schedule, and cost baselines used for comparison to manage, measure, and control project execution
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: PMB
|
|
performance metrics.
(1)
metrics used to evaluate machine learning models that are used for classification
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.54)
Example: accuracy, precision, recall, F1-score
Syn: performance measures
|
|
performance requirement.
(1)
measurable criterion that identifies a quality attribute of a function or how well a functional requirement is accomplished
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
(2)
requirement specifying a performance characteristic of a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
requirement that imposes conditions on a functional requirement
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a requirement that specifies the speed, accuracy, or memory usage with which a given function is performed
Note: A performance requirement is an attribute of a functional requirement.
Syn: performance attribute
See Also: nonfunctional requirement
|
|
performance specification.
(1)
information item that identifies the performance characteristics of a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: often part of a requirements specification. These characteristics typically include speed, accuracy, and memory usage.
|
|
performance testing.
(1)
type of testing conducted to evaluate the degree to which a test item accomplishes its designated functions within given constraints of time and other resources
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.11)
Note: Load tests simulate a normal load on the system. Stress tests allow the load to increase to determine the maximum load at which the system still functions. Endurance tests load the system for a longer period to discover memory leaks or other problems which only manifest themselves after some time.
See Also: functional testing
|
|
performed process.
(1)
process that accomplishes the needed work to produce work products
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: satisfies the specific goals of the process area
|
|
performing organization.
(1)
an enterprise whose personnel are most directly involved in doing the work of the project or program
(ISO/IEC/IEEE 24765h:2019)
|
|
periodic I/O device interface task.
(1)
task that interfaces to a passive I/O device and polls it regularly
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
periodic task.
(1)
task that a timer event activates at regular intervals
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
peripheral equipment.
(1)
device that is controlled by and can communicate with a particular computer
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Example: external storage
|
|
permanence.
(1)
degree to which failures can affect object state changes due to completed transactions
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 13.7.1.5)
|
|
permission.
(1)
prescription that a particular behavior is allowed to occur
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.5)
|
|
perpetual license.
(1)
license for a software entitlement granted in perpetuity
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.18)
Note: The alternative to a perpetual license is a term or subscription-based license.
|
|
persistence.
(1)
property that an object continues to exist across changes of contractual context or of epoch
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.3.1)
|
|
persistence schema.
(1)
specification of constraints on the use of specific processing, storage and communication functions
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 16.5.1.1)
|
|
persistence transparency.
(1)
distribution transparency which masks, from an object, the deactivation and reactivation of other objects (or itself)
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.4.1.7)
Note: Deactivation and reactivation are often used to maintain the persistence of an object when a system is unable to provide it with processing, storage and communication functions continuously.
|
|
persistent storage.
(1)
storage which enables a functional process to store data beyond the life of the functional process, or which enables a functional process to retrieve data stored by another functional process, or stored by an earlier occurrence of the same functional process, or stored by some other process
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.22)
Note: As persistent storage is on the software side of the boundary; it is not considered to be a functional user of the software being measured.
|
|
persistent URI.
(1)
a reference that does not need to change at the link in a document, and can still reach the desired object even though that object may have changed locations
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.19)
Syn: persistent uniform resource identifier
|
|
persona.
(1)
model of a user with defined characteristics, based on research
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.29)
(2)
representation of a type of user that includes a concise summary of the characteristics of the user that is most informative to the design or illustrative of specific user requirements
(ISO/IEC 25063:2014 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) Common Industry Format (CIF) for usability: Context of use description)
(3)
archetypal user of a product, service, or system
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 3.1)
(4)
representation of a type of user that includes a concise summary of the characteristics and the behaviour of the user that is most informative to the design or illustrative of specific user requirements
(ISO/IEC 29110-5-1-2:2025 Systems and software engineering Life cycle profiles for very small entities (VSEs) Part 5-1-2: Software engineering guidelines for the generic Basic profile, 3.17)
Note: A persona typically includes behavior patterns, goals, skills, attitudes, and environment, with a few fictional personal details to make the persona a realistic character. Personas can represent the needs of a larger group in terms of their goals, expectations, and personal characteristics. They can help to guide decisions about system design and design targets.
|
|
personal computer (PC).
(1)
microcomputer primarily intended for stand-alone use by an individual
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
personal data.
(1)
information related to a natural person
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
(2)
information relating to an identified or identifiable natural person (data subject)
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
(3)
information that (a) can be used to identify the PII principal to whom such information relates, or (b) is or can be directly or indirectly linked to a PII principal
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.3.10)
Example: Data is personal by reference to an identifier, e.g., name, an identification number, location data; or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that natural person.
Note: In some jurisdictions personal data is a legal term; in other jurisdictions other terms, such as personally identifiable information or personal information, are used. The scope of PII can vary according to the applicable laws or regulations where the data originates or is processed.
Syn: personal information, PI, personally identifiable information, PII, personal identifiable information
|
|
personal maxim.
(1)
personal principle of what one wishes for, acts upon, and thinks that it should be applicable to everyone
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
|
|
personal protective equipment.
(1)
any device or appliance designed to be worn or held by an individual for protection against one or more health and safety hazards
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.26)
Syn: PPE
|
|
personally identifiable information protection conformance.
(1)
degree to which a service conforms to the standards, laws, or regulations applied to collection, processing, and disposal of PII (personally identifiable information)
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.5.4)
Syn: PII protection conformance
personal data protection conformance
|
|
personnel.
(1)
individual expected to perform duties on behalf of the organization, including officers, employees, and contractors
(ISO/IEC/IEEE 24765g:2018)
|
|
personnel management.
(1)
management of activities involving hiring, retaining, promoting, training, and terminating personnel
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
perspective-based reading.
(1)
form of role-based reviewing that uses checklists and involves the creation of prototype deliverables to check the completeness and other quality characteristics of the work product
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.15)
|
|
PERT.
(1)
program evaluation review technique
(ISO/IEC/IEEE 16326:2019 Systems and software engineering -- Life cycle processes -- Project management, 3)
|
|
pessimistic duration.
(1)
estimate of the longest activity duration that takes into account all of the known variables that can affect performance
(ISO/IEC/IEEE 24765h:2019)
|
|
PESTEL.
(1)
political, economic, social, technological, environmental, and legal
(ISO/IEC/IEEE 24765f:2016)
|
|
Petri net.
(1)
algebraic structure with two sets, one called places and the other called transitions, together with their associated relations and functions, and named after their inventor, Carl Adam Petri
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.25)
Note: A Petri net is usually represented as a graph having two types of nodes (called places and transitions) connected by arcs, and markings (called tokens) indicating dynamic properties.
Syn: PN
|
|
Petri net with priorities.
(1)
Petri net having priorities which can be used for selecting the enabled transitions according to the given priority scheme
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.26)
|
|
Petri net with time.
(1)
Petri net having timing constraints associated with the nodes or arcs
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.27)
|
|
phase.
(1)
period of time in the life cycle during which activities are performed that enable achievement of objectives for that phase
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.15)
See Also: stage
|
|
phase gate.
(1)
review at the end of a phase in which a decision is made to continue to the next phase, to continue with modification, or to end a project or program
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
PHP.
(1)
hypertext preprocessor
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
physical configuration audit (PCA).
(1)
audit conducted to verify that a configuration item, as built, conforms to the technical documentation that defines it
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(2)
evaluation to ensure that the operational system or product conforms to the operational and configuration documentation
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: Modified, "to ensure" changed to "to help ensure." For software, the purpose of the software physical configuration audit (PCA) is to help ensure that the design and reference documentation is consistent with the as-built software product.
See Also: functional configuration audit
|
|
physical interface.
(1)
physical link between two or more system elements
(ISO/IEC/IEEE 24748-6:2023 Systems and software engineering Life cycle management Part 6: System and software integration, 3.1.6)
Note: A physical interface can use solid, liquid, gas, vacuum, thermal, electromagnetic field, or other means.
|
|
physical requirement.
(1)
requirement that specifies a tangible, measurable characteristic of a system or system component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: material, shape, size, weight
See Also: design requirement, functional requirement, implementation requirement, interface requirement, performance requirement
|
|
physical source statement (PSS).
(1)
source statement considered as a line of code
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: logical source statement
|
|
PI.
(1)
personal information
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
PICS.
(1)
Protocol Implementation Conformance Statement
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 4)
(2)
platform for internet content selection
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
picture.
(1)
illustration that shows the actual appearance of physical objects
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.37)
Example: photograph, drawing
|
|
PII.
(1)
personally identifiable information
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
pilot project.
(1)
project designed to test a preliminary version of an information processing system under actual but limited operating conditions and which will then be used to test the definitive version of the system
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
PIN.
(1)
personal identification number
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
PIPEDA.
(1)
Personal Information Protection and Electronic Documents Act
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
pipeline.
(1)
software or hardware design technique in which the output of one process serves as input to a second, the output of the second process serves as input to a third, and so on, often with simultaneity within a single cycle time
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
|
|
pixel.
(1)
smallest element of a screen display; short for 'picture element'
(ISO/IEC/IEEE 24765a:2011)
|
|
PIXIT.
(1)
Protocol Implementation Extra Information for Testing
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 4)
|
|
place.
(1)
node of a net, usually represented by an ellipse
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.28)
|
|
place/transition net.
(1)
Petri Net comprising a net graph with positive integers associated with arcs and an initial marking function which associates a natural number of simple tokens ('black dots') with places
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 3.29)
Syn: P/T net, PTNG
|
|
plan.
(1)
information item that presents a systematic course of action for achieving a declared purpose, including when, how, and by whom specific activities are to be performed
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.16)
(2)
proposed means of accomplishing something
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
plan risk management.
(1)
the process of defining how to conduct risk management activities for a project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
plan standard.
(1)
standard that describes the characteristics of a scheme for accomplishing defined objectives or work within specified resources
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
planned process.
(1)
process that is documented by both a description and a plan
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The related process description and plan are coordinated, and the plan can include standards, requirements, objectives, resources, and assignments.
|
|
planned value (PV).
(1)
authorized budget assigned to scheduled work
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: budgeted cost of work scheduled (BCWS)
|
|
planning.
(1)
activities concerned with the specification of a plan
(ISO/IEC/IEEE 24748-5:2017 Systems and software engineering--Life cycle management--Part 5: Software development planning, 3.9)
|
|
planning horizon.
(1)
consistent time span used to compare the cost of alternatives
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
planning performance domain.
(1)
performance domain that addresses activities and functions associated with the initial, ongoing, and evolving organization and coordination necessary for delivering project deliverables and results
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
planning poker.
(1)
team-based estimation approach whereby relative estimates of the effort required to develop and test each user story are set via consensus
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.57)
Note: The approach uses cards that are typically based on a Fibonacci sequence, i.e. 1, 2, 3, 5, 8, 13.
|
|
planning process group.
(1)
those processes required to establish the scope of the project, refine the objectives, and define the course of action required to attain the objectives that the project was undertaken to achieve
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
plant.
(1)
assembly of different systems on a specific site
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.27)
|
|
plastic leaded chip carrier (PLCC).
(1)
rectangular chip unit, made of plastic for use in low-heat devices, usually with surface-mount or J-shaped (J-lead) connectors
(ISO/IEC/IEEE 24765c:2014)
|
|
platform.
(1)
type of computer or hardware device and/or associated operating system, or a virtual environment, on which software can be installed or run
(2)
combination of an operating system and hardware that makes up the operating environment in which a program runs
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.30)
(3)
type of computer or hardware device and/or associated operating system, or a virtual environment on which software can be installed or run
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.23)
Note: A platform is distinct from the unique instances of that platform, which are typically referred to as devices or instances.
See Also: device
|
|
platform as a service (PaaS).
(1)
provision of a complete environment of IT resources, such as programming languages, libraries, services, and tools supported by the service provider
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
Note: The level of control over the service provided to the customer can vary with the service provider. In DevOps, PaaS is automated as part of the DevOps pipeline.
See Also: IaaS, SaaS
|
|
platform provider.
(1)
organization responsible for the platform
(ISO/IEC 19770-2:2015 (corr 2017), Information technology -- Software asset management -- Part 2: Software identification tag, 3.1.2)
Note: The platform provider is typically the vendor of the relevant operating system or virtual environment.
|
|
PLC.
(1)
programmable logic controller
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
PLCC.
(1)
plastic leaded chip carrier
(ISO/IEC/IEEE 24765c:2014)
|
|
PM.
(1)
project manager
(ISO/IEC/IEEE 16326:2019 Systems and software engineering -- Life cycle processes -- Project management, 5)
(2)
program manager
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
PM&P.
(1)
parts, materials, and processes
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
PMB.
(1)
performance measurement baseline
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
PMBOK®.
(1)
Project Management Body of Knowledge
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
PMI.
(1)
Project Management Institute
(ISO/IEC/IEEE 24765i:2020)
|
|
PMO.
(1)
project management office
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
program management office
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
PMP.
(1)
Project Management Plan
(ISO/IEC/IEEE 16326:2019 Systems and software engineering -- Life cycle processes -- Project management, 3)
(2)
Program Management Plan
(ISO/IEC/IEEE 24765a:2011)
|
|
PNG.
(1)
Portable Network Graphics
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
PNML.
(1)
Petri Net Markup Language
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.2.5)
|
|
PNML Core Model.
(1)
metamodel defining the basic concepts and structure of net graph models that are common to all versions of Petri nets
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.9)
|
|
PNML document.
(1)
XML document that contains one or more net graphs
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.10)
Syn: Petri Net document
|
|
PNML high-level net document.
(1)
PNML Document that contains one or more net graphs, where all net graphs conform to high-level Petri nets
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.11)
|
|
PNML symmetric net document.
(1)
PNML Document that contains one or more net graphs, where all net graphs conform to symmetric nets
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format)
|
|
PO.
(1)
purchase order
(ISO/IEC/IEEE 24765l:2024)
|
|
point.
(1)
measure of vertical distance; there are approximately 28 points to the millimeter (72 points to the inch)
(ISO/IEC/IEEE 24765a:2011)
|
|
point design.
(1)
selection of one design that satisfies the requirements without examining other, potentially more effective, designs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
pointer.
(1)
data item that specifies the location of another data item
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a data item that specifies the address of the next employee record to be processed
|
|
policy.
(1)
clear and measurable statements of preferred direction and behavior to condition the decisions made within an organization
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.17)
(2)
intentions and direction of an organization, as formally expressed by its top management
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.43)
(3)
constraint on a system specification foreseen at design time, but whose detail is determined subsequent to the original design, and capable of being modified from time to time in order to manage the system in changing circumstances
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.8)
Note: A rule can be expressed as an obligation, an authorization, a permission, or a prohibition. Not every policy is a constraint. Some policies represent an empowerment. Direction includes mandates set by the organization.
|
|
policy declaration.
(1)
element in a specification defined in order to allow incorporation of future constraints, together with rules determining the allowed form of acceptable constraints and the circumstances in which such constraints can be applied
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.9)
|
|
policy envelope.
(1)
set of acceptable policy values that can be applied at a particular policy declaration
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.11)
|
|
policy value.
(1)
specific constraints associated with a policy in some particular epoch
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.10)
|
|
policy-setting behavior.
(1)
behavior defined in a specification via which a policy can be changed
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.12)
Syn: policy setting behavior
|
|
pop-up.
(1)
embedded, context-sensitive information that is displayed when invoked by user action
(ISO/IEC/IEEE 24765g:2018)
|
|
port.
(1)
surface feature through which clients and other elements of an application environment can interact with a component
(ISO/IEC/IEEE 24765l:2024)
|
|
port alias.
(1)
replacement relationship in a build specification that identifies a port of one unit with a port of a sub-unit and indicates that interactions at the two ports can be paired identically or compatibly
(ISO/IEC/IEEE 24765i:2020)
Note: A port alias is used to indicate identity or compatibility of two ports at different levels of assembly in which the port in a lower-level unit of assembly serves as a realization of a port at a higher-level unit of assembly.
|
|
port-to-port time.
(1)
elapsed time between the application of a stimulus to an input interface and the appearance of the response at an output interface
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: response time, think time, turnaround time
|
|
portability.
(1)
ease with which a system or component can be transferred from one hardware or software environment to another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
capability of a program to be executed on various types of data processing systems without converting the program to a different language and with little or no modification
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(3)
degree to which a cloud service provides the ability to move data and migrate applications from one cloud service to another
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.7)
(4)
property that the reference points of an object allow it to be adapted to a variety of configurations
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 15.4.1)
Syn: transportability
See Also: machine-independent
|
|
portability testing.
(1)
type of testing conducted to evaluate the ease with which a test item can be transferred from one hardware or software environment to another, including the level of modification needed for it to be executed in various types of environments
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.59)
|
|
portable computer.
(1)
microcomputer that can be hand-carried for use in more than one location
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Syn: PC
|
|
portfolio.
(1)
projects, programs, subsidiary portfolios, and operations managed as a group to achieve strategic objectives
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
portfolio management.
(1)
the centralized management of one or more portfolios to achieve strategic objectives
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
centralized management of one or more portfolios to achieve business objectives
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
|
|
positive control.
(1)
state of affirmative physical or non-physical control
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
Note: Human action (with automated assist) taken in response to direct observations. In contrast, passive control is monitoring only.
|
|
post-closure activities.
(1)
activities that occur after a software system has been formally accepted by its customer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: These activities include, but are not limited to, lessons-learned reviews and archiving project materials.
|
|
post-compile time.
(1)
collective name for link time and load time that are right after the compilation of components
(ISO/IEC 26557:2016 Software and systems engineering -- Methods and tools for variability mechanisms in software and systems product line, 3.9)
|
|
post-probe.
(1)
optional phase to prepare action plans for addressing challenge
(ISO/IEC 26561:2019 Software systems engineering--Methods and tools for product line technical probe, 3.3)
|
|
postcondition.
(1)
condition that is true after a successful property request
(ISO/IEC/IEEE 24765n:2025, 3.1.147)
(2)
constraint that is true when a use case has ended
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
predicate that a specification requires to be true immediately after the occurrence of an action
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.30)
Syn: post-condition
|
|
postmortem dump.
(1)
dump that is produced upon abnormal termination of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: post-mortem dump
See Also: change dump, dynamic dump, memory dump, selective dump, snapshot dump, static dump
|
|
postprocessor.
(1)
computer program or routine that carries out some final processing step after the completion of the primary process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a routine that reformats data for output
Syn: post-processor
See Also: preprocessor
|
|
power-down mode.
(1)
energy-saving operational state for a microcontroller unit (MCU)
(ISO/IEC/IEEE 24765e:2015)
|
|
powertype.
(1)
type, the instances of which are subtypes of another type called the 'partitioned type'
(ISO/IEC 24744:2014 Software Engineering--Metamodel for development methodologies, 3.12)
Example: The class TreeSpecies is a powertype of the class Tree, since each instance of TreeSpecies is also a subclass of Tree.
|
|
PP.
(1)
prioritization processor
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
See Also: P&P
|
|
PPE.
(1)
personal protective equipment
(ISO/IEC/IEEE 24765n:2025)
|
|
PPL.
(1)
Product Parts List
(ISO/IEC/IEEE 16326:2019 Systems and software engineering -- Life cycle processes -- Project management, 3)
|
|
PPP.
(1)
program protection plan
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
PPSL.
(1)
program parts selection list
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
PR&RPI.
(1)
Problem Reporting and Resolution Planned Information
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
practice.
(1)
specific type of activity that contributes to the execution of a process
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.8)
(2)
way of consistently performing activities that contributes to achieving a specific purpose
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.20)
See Also: conventions, standards
|
|
practitioner (PT).
(1)
person or team performing the activities within one or more process areas
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.58)
|
|
pre-probe.
(1)
phase to understand an organization's basic context such as current structure, terminology, product maturity level, implementation, and documentation
(ISO/IEC 26561:2019 Software systems engineering--Methods and tools for product line technical probe, 3.4)
|
|
pre-processing.
(1)
part of the machine learning (ML) workflow that transforms raw data into a state ready for use by the ML algorithm to create the ML model
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.57)
Note: Pre-processing can include analysis, normalization, filtering, reformatting, imputation, removal of outliers and duplicates, and evaluating the completeness of the dataset.
|
|
precautionary principle.
(1)
principle that the introduction of a new product or process whose ultimate effects are unknown or disputed should be resisted until such risks are appropriately mitigated
(ISO/IEC/IEEE 32430:2025, Software engineering Software non-functional size measurement, 3.1.30)
Note: The precautionary principle denotes a duty to prevent harm when it is within one's power to do so, even when all the evidence is not in. This principle has been codified in several international treaties and in international law.
|
|
precision.
(1)
degree of exactness or discrimination with which a quantity is stated
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
Within the quality management system, a measure of exactness.
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(3)
performance metric used to evaluate a classifier, which measures the proportion of predicted positives that were correct
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.55)
Example: a precision of 2 decimal places versus a precision of 5 decimal places
See Also: accuracy
|
|
precompiler.
(1)
computer program or routine that processes source code and generates equivalent code that is acceptable to a compiler
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: for example, a routine that converts structured FORTRAN to ANSI-standard FORTRAN
See Also: preprocessor
|
|
precondition.
(1)
condition that is required to be true before making a property request
(ISO/IEC/IEEE 24765n:2025, 3.1.148)
(2)
constraint that is true when a use case is invoked
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
predicate that a specification requires to be true for an action to occur
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview, 9.29)
Syn: pre-condition
|
|
predicate.
(1)
logical expression which evaluates to TRUE or FALSE, normally to direct the execution path in code
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.40)
|
|
predicate data use.
(1)
data use associated with the decision outcome of the predicate portion of a decision statement
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.37)
Syn: p-use
|
|
prediction.
(1)
machine learning function that results in a predicted target value for a given input
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.56)
Example: classification and regression functions
|
|
predictive action.
(1)
action to monitor the condition of an asset and predict the need for preventive action or corrective action
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.44)
Syn: condition monitoring, performance monitoring
|
|
predictive approach.
(1)
development approach in which the project scope, time, and cost are determined in the early phases of the life cycle
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
preliminary design.
(1)
analysis of design alternatives and definition of the architecture, components, interfaces, and timing and sizing estimates for a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: detailed design
|
|
preliminary design review (PDR).
(1)
review conducted to evaluate the progress, technical adequacy, and risk resolution of the selected design approach for one or more configuration items; to determine each design's compatibility with the requirements for the configuration item; to evaluate the degree of definition and assess the technical risk associated with the selected manufacturing methods and processes; to establish the existence and compatibility of the physical and functional interfaces among the configuration items and other items of equipment, facilities, software and personnel; and, as applicable, to evaluate the preliminary operational and support documents
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: critical design review, system design review
|
|
preparation time.
(1)
time which elapses before the task submission
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.12)
Note: The event of starting the preparation time depends on the definition of the task mode of the following task.
See Also: task mode
|
|
preprocessor.
(1)
computer program or routine that carries out some processing step prior to the primary process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a precompiler or other routine that reformats code or data for processing
See Also: postprocessor
|
|
prescription.
(1)
action that establishes a rule
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.3)
|
|
present worth.
(1)
representation of a cash flow as a single instance at the beginning of the planning horizon
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: future worth, annual equivalent
|
|
presentable.
(1)
retrievable and viewable
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.18)
|
|
presentation device.
(1)
device used to present data to the intended user of a system
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.30)
|
|
prestore.
(1)
to store data that are required by a computer program or routine before the program or routine is entered
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
prettyprinting.
(1)
use of indentation, blank lines, and other visual cues to show the logical structure of a program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
preventive action.
(1)
action to eliminate the cause of a potential nonconformity or other undesirable potential situation
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.45)
Note: Preventive action is taken to prevent occurrence and to preserve an asset's function, whereas corrective action is taken to prevent recurrence. Preventive action is normally carried out while the asset is functionally available and operable or prior to the initiation of functional failure. Preventive action includes the replenishment of consumables where the consumption is a functional requirement.
See Also: corrective action
|
|
preventive maintenance.
(1)
modification of a software product after delivery to correct latent faults in the software product before they occur in the live system
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.1.10)
|
|
preventive support.
(1)
in-service actions undertaken to correct latent faults or vulnerabilities before they are manifested as failures, to replenish or update resources, or to restore initial operating conditions to prevent software aging failures
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
previously developed software.
(1)
software that has been produced prior to or independent of the project for which the plan is prepared, including software that is obtained or purchased from outside sources
(IEEE 1228-1994 (R2002) IEEE Standard for Software Safety Plans, 3.1.2)
(2)
software that has been produced prior to or independent of the project for which the Plan is prepared, including software that is obtained or purchased from outside sources
(IEEE Std 1228-1994 IEEE Standard for Software Safety Plans, 3.1.2)
|
|
primary data.
(1)
data that is collected directly from a subject
(IEEE 7010-2020, IEEE Recommended Practice for Assessing the Impact of Autonomous and Intelligent Systems on Human Well-Being, 2.1)
(2)
data held by an organization that describes the entities that are both independent and fundamental for an enterprise that it needs to reference in order to perform its transaction
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.25)
Note: The term "master data" is deprecated.
|
|
primary Ent.
(1)
entitlement schema (Ent) which encapsulates basic information about an entitlement
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.19)
Note: Primary Ents have an |
|
primary entity-type.
(1)
in Mk II FPA, one of the main entity-types which has the attributes that the application has been designed to process and/or store
(ISO/IEC 20968:2002 Software engineering -- Mk II Function Point Analysis -- Counting Practices Manual, 10)
|
|
primary information structure.
(1)
information structure to which supplemental information structures may be linked
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.24)
Syn: primary info struct
|
|
primary intent.
(1)
intent that is first in importance
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.43)
|
|
primary key.
(1)
candidate key selected as the unique identifier of an entity
(ISO/IEC/IEEE 24765l:2024)
Note: [key style]
|
|
primary user.
(1)
person or entity who interacts with the system to achieve the primary goals
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.3.8)
(2)
user who interacts with the system to achieve the primary goals
(ISO/IEC 25030:2019 Systems and software engineering--Systems and software quality requirements and evaluation (SQuaRE)--Quality requirements framework, 3.11)
|
|
primitive.
(1)
lowest level for which data is collected
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: error, failure, fault, time, time interval, date, number of non-commentary source code statements, edges, and nodes
Note: Primitives are directly measurable or countable, or can be given a constant value or condition for a specific measure.
|
|
principal.
(1)
party that has delegated authority or a function to another
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.6.9)
|
|
printed circuit board (PCB).
(1)
configuration of connections between electronic components, typically using metallic paths etched on a non-conducting substrate (board)
(ISO/IEC/IEEE 24765d:2015)
|
|
printed circuit board assembly (PCBA).
(1)
printed circuit board with embedded components and devices
(ISO/IEC/IEEE 24765d:2015)
|
|
printed information for users.
(1)
information for users that is either provided in printed form, or provided in electronic form for the customer or user to print
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.38)
Syn: printed documentation
See Also: embedded information for users, onscreen information for users
|
|
prioritization matrix.
(1)
diagram that plots effort against value so as to classify items by priority
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
prioritization scheme.
(1)
methods used to prioritize portfolio, program, or project components, as well as requirements, risks, features, or other product information
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
priority ceiling protocol.
(1)
algorithm that provides bounded priority inversion
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: that is, at most one lower-priority task can block a higher-priority task
|
|
priority interrupt.
(1)
interrupt performed to permit execution of a process that has a higher priority than the process currently executing
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
priority inversion.
(1)
case where a task's execution is delayed because a lower priority task is blocking it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
privacy capabilities.
(1)
ability to process personal data in a fair and legitimate manner
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
privacy control.
(1)
monitoring prescribed for an information system or an organization, designed to achieve a privacy objective
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
privacy framework.
(1)
structure that helps the organization meet its privacy requirements, including policies and procedures, roles and responsibilities, training, and governance functions
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
privacy principles.
(1)
set of values that guide a system or an organization's personal data actions
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
privacy requirement.
(1)
specification for the processing of personal data to meet stakeholders desired privacy outcomes and obligations
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
privacy risk.
(1)
combination of the likelihood and impact that individuals or organizations will experience problems resulting from exposure, use, theft, or alteration of personal data
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
private.
(1)
responsibility that is visible only to the class or the receiving instance of the class (available only within methods of the class)
(ISO/IEC/IEEE 24765n:2025, 3.1.150)
(2)
known only within a single routine or module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: protected, public, hidden
|
|
private type.
(1)
data type whose structure and possible values are defined but are not revealed to the user of the type
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: information hiding
|
|
privileged instruction.
(1)
computer instruction that can be executed only by a supervisory program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
PRM.
(1)
process reference model
(ISO/IEC/IEEE 24765l:2024)
|
|
proactive approach.
(1)
approach of developing an innovative product line or product variations based on organizational predictions that anticipate a stated product need
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.15)
|
|
probabilistic estimating.
(1)
method used to develop a range of estimates along with the associated probabilities within that range
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
probabilistic system.
(1)
system whose behavior is described in terms of probabilities, such that its outputs cannot be perfectly predicted
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.58)
|
|
probability.
(1)
extent to which an event is likely to occur
(ISO/IEC/IEEE 24765j:2021)
(2)
mathematically, a real number in the scale 0 to 1 attached to a random event, related to a long-run relative frequency of occurrence or to a degree of belief that an event will occur
(ISO/IEC/IEEE 24765j:2021)
Note: For a high degree of belief, the probability is near 1. Frequency rather than probability can be used in describing risk. Degrees of belief about probability can be chosen as classes or ranks, such as rare/ unlikely/ moderate/ likely/ almost certain, or incredible/ improbable/ remote/ occasional/ probable/ frequent.
|
|
probability and impact matrix.
(1)
grid for mapping the probability of each risk occurrence and its impact on project objectives if that risk occurs
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
probe.
(1)
diagnostic process for investigating the organization's readiness to adopt, or ability to succeed with, product line engineering and management
(ISO/IEC 26561:2019 Software systems engineering--Methods and tools for product line technical probe, 3.7)
Syn: product line technical probe, technical probe
|
|
problem.
(1)
difficulty, uncertainty, or otherwise realized and undesirable event, set of events, condition, or situation that requires investigation and corrective action
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.26)
(2)
undesirable situation concerning an application, the application management organization, its processes or working methods, which demands structural analysis of the cause and a structural solution
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.27)
(3)
root cause of one or more incidents
(ISO/IEC 23531:2020, Systems and software engineering--Capabilities of issue management tools, 3.4)
(4)
difficulty or uncertainty experienced by one or more persons, resulting from an unsatisfactory encounter with a system in use
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
Note: A risk factor becomes a problem when a risk metric (an objective measure) crosses a predetermined threshold (the problem trigger). The root cause is not usually known at the time a problem record is created. A problem can concern a service, product or a process (-step) or other element of the organization.
|
|
problem definition.
(1)
statement of a problem, which can include a description of the data, the method, the procedures, and algorithms used to solve it
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Syn: problem description
|
|
problem report (PR).
(1)
document used to identify and describe problems detected in a product
(ISO/IEC/IEEE 14764:2021, Software engineering -- Software life cycle processes -- Maintenance, 3.1.11)
Note: PRs are either submitted directly to denote faults or established after impact analysis is performed on Modification Requests and faults are found.
|
|
problem state.
(1)
in the operation of a computer system, a state in which programs other than the supervisory program can execute
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: user state
See Also: supervisor state
|
|
problem-oriented language.
(1)
programming language designed for the solution of a given class of problems
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: list processing languages, information retrieval languages, simulation languages
|
|
procedural cohesion.
(1)
type of cohesion in which the tasks performed by a software module all contribute to a given program procedure, such as an iteration or decision process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: coincidental cohesion, communicational cohesion, functional cohesion, logical cohesion, sequential cohesion, temporal cohesion
|
|
procedural language.
(1)
programming language in which the user states a specific set of instructions that the computer performs in a given sequence
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: All widely used programming languages are of this type.
Syn: procedure-oriented language
See Also: nonprocedural language, algebraic language, algorithmic language, list processing language, logic programming language
|
|
procedural programming language.
(1)
computer programming language used to express the sequence of operations to be performed by a computer
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
Example: COBOL
See Also: nonprocedural programming language
|
|
procedure.
(1)
information item that presents an ordered series of steps to perform a process, activity, or task
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.19)
(2)
portion of a computer program that is named and that performs a specific action
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
routine that does not return a value
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
ordered series of steps that specify how to perform a task
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.39)
(5)
specified way to carry out an activity or process
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.25)
(6)
ordered series of steps that a user follows to do one or more tasks
(ISO/IEC/IEEE 26513:2017 Systems and software engineering--Requirements for testers and reviewers of information for users, 3.31)
Note: A procedure defines an established and approved way or mode of conducting business in an organization. It details permissible or recommended methods in order to achieve technical or managerial goals or outcomes. When a procedure is specified as an output, the resulting deliverable typically specifies what is done, by whom, and in what sequence. This is a more detailed level of specification than for a process. Procedures can be documented or not.
|
|
procedure testing.
(1)
type of functional suitability testing conducted to evaluate whether procedural instructions for interacting with a test item or using its outputs meet user requirements and support the purpose of their use
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.60)
|
|
process.
(1)
set of interrelated or interacting activities which transforms inputs into outputs.
(2)
set of interrelated or interacting activities which transforms inputs into outputs
(3)
set of interrelated or interacting activities that transforms inputs into outputs
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.45)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.27)
(4)
predetermined course of events defined by its purpose or by its effect, achieved under given conditions
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(5)
collection of steps taking place in a prescribed manner
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.3.6)
(6)
in data processing, the predetermined course of events that occur during the execution of all or part of a program
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(7)
system of activities, which use resources to transform inputs into outputs
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.22)
Note: The term "activities" covers use of resources. A process can have multiple starting points and multiple end points. The prescribed manner can be a partially ordered sequence. A process specification can be a workflow specification. An enterprise specification can define types of processes and process templates. A process can be viewed as a specific instantiation of life cycle processes, adapted within a life cycle model, to create the service or product for the specific requirements and context of a project. When a process definition is specified as an outcome, the resulting deliverable typically specifies inputs and outputs, and gives a general description of expected activities. However, it does not include the same level of detail as for a procedure.
|
|
process action plan.
(1)
plan, usually resulting from appraisals, that documents how specific improvements targeting the weaknesses uncovered by an appraisal will be implemented
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
process action team.
(1)
team that has the responsibility to develop and implement process improvement activities for an organization as documented in a process action plan
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
process architect.
(1)
person or group that has primary responsibility for creating and maintaining the software life cycle process (SLCP)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
process architecture.
(1)
ordering, interfaces, interdependencies, and other relationships among the process elements in a standard process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Process architecture also describes the interfaces, interdependencies, and other relationships between process elements and external processes, such as contract management.
|
|
process area.
(1)
cluster of related practices in an area that, when implemented collectively, satisfies a set of goals considered important for making improvement in that area
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
process assessment.
(1)
disciplined evaluation of an organizational unit's processes against a process assessment model
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.15)
(2)
determination of the extent to which the organization's standard processes contribute to the achievement of its business goals and help the organization focus on the need for continuous process improvement
(ISO/IEC/IEEE 24765d:2015)
|
|
process assessment model (PAM).
(1)
model suitable for the purpose of assessing a specified process quality characteristic, based on one or more process reference models
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.9)
Note: Process assessment models addressing a specific process quality characteristic can include the identification of the characteristic in the title; for example, a process assessment model addressing process capability can be termed a "process capability assessment model."
See Also: process reference model (PRM)
|
|
process asset library.
(1)
collection of information that can be useful to those who are defining, implementing, and managing processes in the organization.
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: process-related documentation such as policies, defined processes, checklists, lessons-learned documents, templates, standards, procedures, plans, and training materials
|
|
process attribute (PA).
(1)
measurable property of a process quality characteristic
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.3)
Syn: process quality attribute
|
|
process attribute outcome.
(1)
observable result of achievement of a specified process attribute
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.4)
|
|
process attribute rating.
(1)
judgment of the degree of achievement of the process attribute for the assessed process
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.5)
|
|
process capability.
(1)
characterization of the ability of a process to meet current or projected business goals
(ISO/IEC 33020:2019 Information technology--Process assessment--Process measurement framework for assessment of process capability, 3.4)
(2)
range of expected results that can be achieved by following a process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
process capability level.
(1)
characterization of a process on an ordinal measurement scale of process capability
(ISO/IEC 33020:2019 Information technology--Process assessment--Process measurement framework for assessment of process capability, 3.5)
Note: Each level builds on the capability of the level below.
|
|
process definition.
(1)
identification of the process purpose, outcomes, and a sequence of steps involving activities, constraints, and resources that are performed for a given purpose
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
process description.
(1)
documented expression of a set of activities performed to achieve a given purpose
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: A process description provides an operational definition of the major components of a process. The description specifies, in a complete, precise, and verifiable manner, the purpose, outcomes, activities and tasks, requirements, design, behavior, or other characteristics of a process. It also can refer to procedures for determining whether these provisions have been satisfied. Process descriptions can be applicable at the project or organizational level.
|
|
process dimension.
(1)
set of process elements in a process assessment model explicitly related to the processes defined in the relevant process reference models
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.10)
Note: The elements of the process dimension include processes, process purpose statements, process outcomes, and process performance indicators.
|
|
process group.
(1)
collection of related processes
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
team of specialists who facilitate the definition, maintenance, and improvement of processes used by the organization
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
process improvement.
(1)
actions taken to improve the quality of the organization's processes aligned with the business needs and the needs of other concerned parties
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.1.7)
(2)
result of activities that better the performance and maturity of the organization's processes
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.65)
|
|
process improvement objective.
(1)
set of target characteristics established to guide the effort to improve an existing process in a specific, measurable way, either in terms of resultant product or service characteristics, such as quality, performance, and conformance to standards, or in the way in which the process is executed, such as elimination of redundant process steps, combination of process steps, and improvement of cycle time
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
process improvement plan.
(1)
subsidiary plan of the project management plan that details the steps for analyzing processes to identify activities that enhance their value
(ISO/IEC/IEEE 24765h:2019)
|
|
process improvement support element.
(1)
way that an organization expresses support for process improvement projects or initiatives
(ISO/IEC TR 33014:2013 Information technology--Process assessment--Guide for process improvement, 3.2)
|
|
process infrastructure.
(1)
internal structure of the software life-cycle process, to include lifecycle phases, documentation, baselines, reviews, and products
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
process instance.
(1)
single specific and identifiable execution of a process
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.17)
(ISO/IEC 30103:2015 Software and Systems Engineering - Lifecycle Processes - Framework for Product Quality Achievement, 3.7)
|
|
process management.
(1)
direction, control, and coordination of work performed to develop a product or perform a service
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: quality assurance
|
|
process maturity.
(1)
extent to which an organizational unit consistently implements processes within a defined scope that contribute to the achievement of its business needs (current or projected)
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.23)
|
|
process measurement framework.
(1)
schema for use in characterizing a process quality characteristic of an implemented process
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.6)
|
|
process outcome.
(1)
observable result of the successful achievement of the process purpose
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.46)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.30)
See Also: output
|
|
process owner.
(1)
person (or team) responsible for defining and maintaining a process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: null
Note: At the organizational level, the process owner is the person (or team) responsible for the description of a standard process; at the project level, the process owner is the person (or team) responsible for the description of the defined process. A process can therefore have multiple owners at different levels of responsibility.
|
|
process performance.
(1)
extent to which the execution of a process achieves its purpose
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.7)
|
|
process performance indicator.
(1)
assessment indicator that supports the judgment of the process performance of a specific process
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.12)
|
|
process profile.
(1)
set of process attribute ratings for an assessed process
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.18)
|
|
process purpose.
(1)
high-level objective of performing the process and the likely outcomes of effective implementation of the process
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.47)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.29)
Note: The purpose of implementing a process is to provide benefits to the stakeholders.
|
|
process quality.
(1)
ability of a process to satisfy stated and implied stakeholder needs when used in a specified context
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.8)
|
|
process quality characteristic.
(1)
measurable aspect of process quality
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.9)
(2)
category of process attributes that are significant to process quality
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.9)
|
|
process quality determination.
(1)
systematic assessment and analysis of selected processes against a target process profile
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.2.19)
|
|
process quality dimension.
(1)
set of elements in a process assessment model explicitly related to the process measurement framework for the specified process quality characteristic
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.14)
|
|
process quality indicator.
(1)
assessment indicator that supports the judgment of the process quality characteristic of a specific process
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.15)
|
|
process quality level.
(1)
point on a scale of achievement of a process quality characteristic derived from the process attribute ratings for an assessed process
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.4.10)
|
|
process reference model (PRM).
(1)
model comprising definitions of processes in a domain of application described in terms of process purpose and outcomes, together with an architecture describing the relationships between the processes
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.48)
(ISO/IEC 33001:2015 Information technology--Process assessment--Concepts and terminology, 3.3.16)
(2)
model comprising definitions of processes in a life cycle described in terms of process purpose and outcomes, together with an architecture describing the relationships between the processes
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.68)
See Also: process assessment model (PAM)
|
|
process risk determination.
(1)
systematic assessment and analysis of selected processes against a target process profile, carried out with the aim of identifying process-related risks to meet a particular specified requirement
(ISO/IEC TR 33015:2019 Information technology--Process assessment--Guidance for process risk determination, 3.1)
|
|
process standard.
(1)
standard that deals with the series of actions or operations used in making or achieving a product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
process tailoring.
(1)
making, altering, or adapting a process description for a particular end
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: A project tailors its defined process from the organization's set of standard processes to meet objectives, constraints, and the environment of the project.
|
|
process view.
(1)
description of how a specified purpose and set of outcomes can be achieved by employing the activities and tasks of existing processes
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.2.2)
|
|
process-related risk.
(1)
risk resulting from weaknesses in the performance, management, or deployment of a process
(ISO/IEC TR 33015:2019 Information technology--Process assessment--Guidance for process risk determination, 3.2)
|
|
processing logic.
(1)
any of the requirements specifically requested by the user to complete an elementary process, such as validations, algorithms, or calculations, and reading or maintaining a file
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009)
|
|
processor.
(1)
in a computer, a functional unit that interprets and executes instructions
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: A processor consists of at least an instruction control unit and an arithmetic and logic unit
|
|
procurement management plan.
(1)
component of the project or program management plan that describes how a project team will acquire goods and services from outside the performing organization
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
producer object.
(1)
object which is the source of the information conveyed
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.4.3)
|
|
product.
(1)
result of a process
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.49)
(2)
intended or accomplished result of labor, or of a natural or artificial process
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.28)
(3)
artifact that is produced, is quantifiable, and can be either an end item in itself or a component item
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(4)
output of an organization that can be produced without any transaction taking place between the organization and the customer
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.32)
(5)
complete set of computer programs, procedures and associated documentation and data designed for delivery to a software consumer
(ISO/IEC 19770-2:2015 (corr 2017), Information technology -- Software asset management -- Part 2: Software identification tag, 4.1.19)
(6)
artifact that is produced, is quantifiable and is deliverable to the user as either an end item in itself or a component item
(ISO/IEC 25030:2019 Systems and software engineering--Systems and software quality requirements and evaluation (SQuaRE)--Quality requirements framework, 3.12)
(7)
item that is made or created by a person or machine
(ISO TR 25060:2023 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--General Framework for Common Industry Format (CIF) for usability-related information, 3.1.3)
Example: output of the software development activities (e.g., information item, code, or model)
Note: Generic product categories are hardware (e.g., engine mechanical part); software (e.g., computer program); services (e.g., transport); and processed materials (e.g., lubricant). Hardware and processed materials are generally tangible products, while software or services are generally intangible. Most products comprise elements belonging to different generic product categories. Whether the product is then called hardware, processed material, software, or service depends on the dominant element. Results can be components, systems, software, services, rules, documents, or many other items.
The result can in some cases be many related individual results.
See Also: activity, deliverable, result
|
|
product analysis.
(1)
evaluating a product by manual or automated means to determine if the product has certain characteristics
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
product asset instance.
(1)
instantiation of a shared asset specific to a member product, automatically produced by the product line engineering (PLE) factory configurator, corresponding to a bill-of-features for that member product
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.14)
Note: A product asset instance is analogous to an application asset with the proviso that it is produced by the product line engineering (PLE) factory configurator.
|
|
product backlog.
(1)
list of all requirements, normally represented as user stories, that need to be done for a given product
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.69)
(2)
prioritized listing of product requirements
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.22)
Note: the single source of work undertaken by the agile team
See Also: backlog, sprint backlog
|
|
product baseline.
(1)
description of the detailed design at a specific point in time, for production, fielding/deployment, and operations and support
(ISO/IEC/IEEE 24748-7:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.1)
Example: The product baseline prescribes all necessary physical form, fit, or function characteristics and selected functional characteristics designated for production acceptance testing and production test requirements.
Syn: product configuration baseline, production configuration
See Also: allocated baseline, developmental configuration, functional baseline, product configuration identification
|
|
product breakdown structure.
(1)
hierarchical structure reflecting a products components and deliverables
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
decomposition of the product into its components
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.32)
Note: The PBS begins with the complete product at the top of the hierarchy and below this the main components, which can also each be broken down again into components.
Syn: PBS
|
|
product configuration identification.
(1)
current approved or conditionally approved technical documentation defining a configuration item during the production, operation, maintenance, and logistic support phases of its life cycle
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: It prescribes all necessary physical or form, fit, and function characteristics of a configuration item, the selected functional characteristics designated for production acceptance testing, and the production acceptance tests.
See Also: allocated configuration identification, functional configuration identification, product baseline
|
|
product description.
(1)
document stating properties of software, with the main purpose of helping potential acquirers in the evaluation of the suitability for themselves of the software before purchasing it
(ISO/IEC 25051:2014 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, 4.1.44)
Note: The product description is not a specification; it serves a different purpose.
|
|
product engineering.
(1)
technical processes to define, design, and construct or assemble a product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
product identification.
(1)
software product name, version, variant, and date information
(ISO/IEC 25051:2014 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, 4.1.12)
|
|
product instances.
(1)
collection comprising the bill-of-features portfolio and product asset instances
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.15)
|
|
product life cycle.
(1)
series of phases that represent the evolution of a product, from concept through delivery, growth, maturity, and to retirement
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
product line.
(1)
set of products or services sharing explicitly defined and managed common and variable features and relying on the same domain architecture to meet the common and variable needs of specific markets
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.16)
(2)
paradigm for the creation, exploitation, and management of a common platform for a family of products
(ISO/IEC 26561:2019 Software systems engineering--Methods and tools for product line technical probe, 3.9)
(3)
family of similar products with variations in features
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.16)
(4)
group of products or services sharing a common, managed set of features that satisfy specific needs of a selected market or mission
(INCOSE Systems Engineering Handbook, 5th ed.)
Note: Typical goals of product lines are to lower costs, reduce time to market, and improve quality.
Syn: product family, software and systems product line. SSPL
|
|
product line adoption plan.
(1)
plan that describes the changes in process, organization structure, and product building methods to get from the current to product line engineering
(ISO/IEC 26561:2019 Software systems engineering--Methods and tools for product line technical probe, 3.5)
|
|
product line adoption scenario.
(1)
scenario that gives concrete sequence of actions related to product line adoption
(ISO/IEC 26561:2019 Software systems engineering--Methods and tools for product line technical probe, 3.6)
|
|
product line architecture.
(1)
architecture, including both domain architecture and application architecture
(ISO/IEC 26552:2019 Software and systems engineering--Tools and methods for product line architecture design, 3.8)
|
|
product line configuration.
(1)
snapshot of the product line that contains a collection of revisions of every domain asset and member product in the product line
(ISO/IEC 26563:2022. Software and systems engineering Methods and tools for product line configuration management, 3.4)
|
|
product line configuration delta.
(1)
difference between the two versions of product line configuration
(ISO/IEC 26563:2022. Software and systems engineering Methods and tools for product line configuration management, 3.5)
|
|
product line configuration item.
(1)
resulting artefacts that make up a product line
(ISO/IEC 26563:2022. Software and systems engineering Methods and tools for product line configuration management, 3.6)
Note: Product line configuration item is a generic term for configuration items of domain engineering, application engineering, and managerial support.
|
|
product line configuration management.
(1)
coordinated activities to direct and control product line configuration
(ISO/IEC 26563:2022. Software and systems engineering Methods and tools for product line configuration management, 3.7)
Note: Product line configuration management includes configuration management activities for domain engineering, application engineering, and organization and technical management.
|
|
product line engineering factory.
(1)
technological, organizational, and business infrastructure and processes to support a product line engineering (PLE) factory configurator producing product asset instances from shared asset supersets based on a bill-of-features for a member product
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.11)
Syn: PLE factory
|
|
product line engineering factory configurator.
(1)
automated mechanism that produces assets for a specific member product by processing the bill-of-features for that member product, and exercising the shared assets variation points in light of the feature selections made in that bill-of-features
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.12)
Syn: PLE factory configurator
|
|
product line engineering factory development environment.
(1)
toolset for creating, organizing, assembling, and maintaining a collection of elements in a feature catalog, bill-of-features portfolio, shared asset supersets, and a hierarchy of a product line of product lines
(ISO/IEC 26580:2021, Software and systems engineering Methods and tools for the feature-based approach to software and systems product line engineering, 3.13)
Syn: PLE factory development environment
|
|
product line institutionalization.
(1)
considering product line engineering as part of working culture by involved managers and staff members
(ISO/IEC 26562:2019 Software and systems engineering--Methods and tools for product line transition management, 3.2)
|
|
product line platform.
(1)
product line architecture, a configuration management plan, and domain assets, enabling application engineering to effectively reuse and produce a set of derivative products
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.18)
|
|
product line reference model.
(1)
abstract representation of the domain and application engineering life cycle processes; the roles and relationships of the processes; and the assets produced, managed, and used during product line engineering and management
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.19)
|
|
product line scoping.
(1)
process for defining the member products that will be produced within a product line and the major common and variable features among the products, analyzes the products from an economic point of view, and controls and schedules the development, production, and marketing of the product line and its products
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.20)
|
|
product line test strategy.
(1)
scope of domain testing and application testing
(ISO/IEC 26554:2018 Information technology--Software and systems engineering-Tools and methods for product line testing, 3.8)
Note: Many variants may not be implemented in domain engineering. To cope with the impacts of un-implemented variants to domain integration testing and system testing, the appropriate test strategy should be established.
|
|
product management.
(1)
definition, coordination, and control of the characteristics of a product during its development cycle
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
integration of people, data, processes, and business systems to create, maintain, and evolve a product or service throughout its life cycle
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Example: configuration management
|
|
product owner.
(1)
stakeholder responsible for the capabilities, acceptance, and use of a product
(ISO/IEC TR 24587:2021, Software and systems engineering--Agile development--Agile adoption considerations, 3.12)
(2)
designated stakeholder accountable for defining and accepting outcomes of the work and managing backlog, while aligning with the stakeholder needs
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.23)
(3)
person responsible for maximizing the value of the product and accountable for the end product
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: The product owner shares the product vision, required features and their priorities, and acceptance criteria.
Syn: PO
See Also: product authority
|
|
product quality.
(1)
capability of a system or its components to satisfy stated and implied quality needs when used under specific conditions
(ISO/IEC 25002:2024, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model overview and usage, 3.16)
(2)
capability of a system and/or software to satisfy stated and implied needs when used under specified conditions
(ISO/IEC 25020:2019 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE)--Quality measurement framework, 3.17)
(3)
degree to which the product satisfies stated and implied needs when used under specified conditions
(ISO/IEC 25041: 2012 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Evaluation guide for developers, acquirers and independent evaluators, 4.11)
(4)
capability of an ICT product or its components to satisfy stated and implied quality needs when used under specific conditions
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.3.9)
Note: This definition differs from the ISO 9000:2015 quality definition, because this definition refers to the satisfaction of stated and implied needs, while the ISO 9000 quality definition refers to the satisfaction of requirements. Quality is related to satisfying and even surpassing expectations with associated constraints and conditions.
Syn: system and software product quality
|
|
product requirement.
(1)
refinement of customer requirements into the developers' language, making implicit requirements into explicit derived requirements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
requirement that describes how a product, system, or item of software satisfies a business requirement and thereby provide value
(ISO/IEC/IEEE 41062:2024, Software engineering Life cycle processes Software acquisition, 3.1.15)
|
|
product risk.
(1)
risk that a product can be defective in some specific aspect of its function, quality, or structure
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.12)
|
|
product roadmap.
(1)
timeline with high-level milestones for a product life cycle, particularly the timeline for productive deployment of the product
(ISO/IEC 26556:2018 Information technology--Software and systems engineering--Tools and methods for product line organizational management, 3.2)
(2)
schedule when the products have to be ready for market launch
(ISO/IEC 26560:2019 Software and systems engineering -- Tools and methods for product line product management, 3.5)
See Also: technology roadmap
|
|
product safety label.
(1)
label on a product that informs of one or more potential hazards and describes the safety precautions or actions required to avoid the hazard
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.29)
|
|
product scope.
(1)
features and functions that characterize a product, service or result
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
product scoping.
(1)
subprocess of product line scoping that determines the product roadmap, that is 1) the targeted markets; 2) the product categories that the product line organization should be developing, producing, marketing, and selling; 3) the common and variable features that the products should provide in order to reach the long and short term business objectives of the product line organization, and 4) the schedule for introducing products to markets
(ISO/IEC 26550:2015 Software and systems engineering--Reference model for product line engineering and management, 3.20)
|
|
product specification.
(1)
document that specifies the design to be instantiated in production copies of a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
document that describes the characteristics of a planned or existing product for consideration by potential customers or users
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: For software, this document describes the as-built version of the software.
See Also: design description
|
|
product standard.
(1)
standard that defines what constitutes completeness and acceptability of items that are used or produced, formally or informally, during the software engineering process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
product support.
(1)
providing information, assistance, and training to install and make software operational in its intended environment and to distribute improved capabilities to users
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
production.
(1)
stage in the life cycle when completed software or documentation is prepared, published, and packaged for distribution
(ISO/IEC/IEEE 24765a:2011)
Note: Production sometimes refers to the stage when software is utilized in production operations.
|
|
production library.
(1)
software library containing software approved for current operational use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: software development library, software repository, system library
|
|
production plan.
(1)
description of how domain assets are to be used to develop member products in a product line
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.17)
|
|
production rate.
(1)
a measure of the amount of work completed per unit of time, such as user stories or features per week
(Software Extension to the PMBOK(R) Guide Fifth Edition)
See Also: burndown rate, velocity
|
|
productivity.
(1)
ratio of work product to work effort
(ISO/IEC/IEEE 24765a:2011)
|
|
professional standard.
(1)
standard that identifies a profession as a discipline and distinguishes it from other professions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
professionalism.
(1)
degree to which the content of the IT service is based on appropriate education, skill, expertise and qualification
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.5.2)
|
|
profile.
(1)
subset of appropriate standards processes and their outcomes, activities, and tasks combined to accomplish a particular function
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.70)
Note: [ISO/IEC TR 10000-1]
|
|
profile group.
(1)
collection of profiles which are related either by composition of processes, e.g. activities and tasks, or by capability level, or both
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.71)
|
|
program.
(1)
to write a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to design, write, modify, and test programs
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(3)
related projects, subprograms, and program activities managed in a coordinated way to obtain benefits not available from managing them individually
(IEEE 7000:2021, IEEE Standard Model Process for Addressing Ethical Concerns during System Design, 3.1)
(4)
Related projects, subsidiary programs, and program activities that are managed in a coordinated manner to obtain benefits not available from managing them individually
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: computer program
|
|
program construct.
(1)
set of one or more procedure parts and a control part which may be implicit
(ISO/IEC/IEEE 24765i:2020)
Note: Each procedure part consists of one or more operations to be performed or can be null.
|
|
program design language (PDL).
(1)
specification language with special constructs and, sometimes, verification protocols, used to develop, analyze, and document a program design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: hardware design language, pseudo code
|
|
Program Evaluation and Review Technique (PERT).
(1)
technique for estimating that applies a weighted average of optimistic, pessimistic, and most likely estimates when there is uncertainty with the individual activity estimates
(ISO/IEC/IEEE 24765h:2019)
|
|
program instruction.
(1)
computer instruction in a source program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: A program instruction is distinguished from a computer instruction that results from assembly, compilation, or other interpretation process.
|
|
program librarian.
(1)
person responsible for establishing, controlling, and maintaining a software development library
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
program listing.
(1)
printout or other human readable display of the source and, sometimes, object statements that make up a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
program maintenance manual.
(1)
document that provides the information necessary to maintain a program
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
program management.
(1)
application of knowledge, skills, and principles to a program to achieve the program objectives and obtain benefits and control not available by managing program components individually
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
program mutation.
(1)
computer program that has been purposely altered from the intended version to evaluate the ability of test cases to detect the alteration
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: mutation testing
|
|
program network chart.
(1)
diagram that shows the relationship between two or more computer programs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
program specification.
(1)
document that describes the structure and functions of a program in sufficient detail to permit programming and to facilitate maintenance
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
program status word (PSW).
(1)
computer word that contains information specifying the current status of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
special-purpose register that contains a program status word
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The information can include error indicators, the address of the next instruction to be executed, or currently enabled interrupts.
|
|
program synthesis.
(1)
use of software tools to aid in the transformation of a program specification into a program that realizes that specification
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
program-sensitive fault.
(1)
fault that causes a failure when some particular sequence of program steps is executed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: data-sensitive fault
|
|
programmable breakpoint.
(1)
breakpoint that automatically invokes a previously specified debugging process when initiated
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: code breakpoint, data breakpoint, dynamic breakpoint, epilog breakpoint, prolog breakpoint, static breakpoint
|
|
programmable counter array.
(1)
group of counter modules on a microcontroller unit that increases its timing capabilities
(ISO/IEC/IEEE 24765d:2015)
Example: The parameters for counting are configured programmatically.
|
|
programmable pulse generator.
(1)
part of a microcontroller unit that produces clock signals, adjustable through programming
(ISO/IEC/IEEE 24765d:2015)
|
|
programmable read-only memory (PROM).
(1)
read-only memory unit without a rewrite or an erase data function, which the user can program only once
(ISO/IEC/IEEE 24765c:2014)
Syn: programmable read only memory
|
|
programmable reload timer (PRT).
(1)
reconfigurable device to restart a function, using decrementing, status control, and reload registers
(ISO/IEC/IEEE 24765e:2015)
|
|
programmable terminal.
(1)
user terminal that has built-in data processing capability
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
programmatic reference point.
(1)
reference point at which a programmatic interface can be established to allow access to a function
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 15.3.1)
|
|
programmer manual.
(1)
document that provides the information necessary to develop or modify software for a given computer system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Typically described are the equipment configuration, operational characteristics, programming features, input/output features, and compilation or assembly features of the computer system.
See Also: diagnostic manual, installation manual, operator manual, support manual, user manual
|
|
programming.
(1)
general activity of software development
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
designing, writing, modifying, and testing of programs
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: especially construction activities.
See Also: construction
|
|
programming language.
(1)
language used to express computer programs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
artificial language for expressing programs
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
programming support environment.
(1)
integrated collection of software tools accessed via a single command language to provide programming support capabilities throughout the software life cycle
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: sometimes called integrated programming support environment. The environment typically includes tools for specifying, designing, editing, compiling, loading, testing, configuration management, and project management.
See Also: scaffolding
|
|
programming system.
(1)
set of programming languages and the support software (e.g., editors, compilers, linkers) necessary for using these languages with a given computer system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
progressive elaboration.
(1)
iterative process of increasing the level of detail in a project management plan as greater amounts of information and more accurate estimates become available
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
prohibition.
(1)
prescription that a particular behavior is not allowed
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.6)
|
|
project.
(1)
endeavor with defined start and finish criteria undertaken to create a product or service in accordance with specified resources and requirements
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.50)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.33)
(2)
undertaking with pre-specified objectives, magnitude, and duration
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(3)
temporary endeavor undertaken to create a unique product, service, or result
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(4)
endeavor with defined start and finish dates undertaken to create a product or service in accordance with specified resources and requirements
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.72)
(5)
set of work activities, both technical and managerial, required to satisfy the terms and conditions of a project agreement
Note: A project is sometimes viewed as a unique process comprising coordinated and controlled activities and can be composed of activities from the technical management and technical processes.
|
|
project balance.
(1)
representation, as a series of cash amounts at regular intervals, of the cumulative to-date value of an alternative
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
project brief.
(1)
high-level overview of the goals, deliverables, and processes for the project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project calendar.
(1)
calendar that identifies working days and shifts that are available for scheduled activities
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: resource calendar
|
|
project charter.
(1)
document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project control.
(1)
activities concerned with monitoring the progress of a project, its direction, quality, and resource utilization, as compared with project plan
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
project file.
(1)
central repository of material pertinent to a project
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Contents typically include memos, plans, technical reports, and related items.
Syn: project notebook
|
|
project governance.
(1)
framework, functions, and processes that guide project management activities in order to create a unique product, service, or result to meet organizational, strategic, and operational goals
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project lead.
(1)
person who helps the project team to achieve the project objectives, typically by orchestrating the work of the project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: project manager
|
|
project life cycle.
(1)
series of phases that a project passes through from its start to its completion
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project management (PM).
(1)
application of knowledge, skills, tools, and techniques to project activities to meet the project requirements
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
activities concerned with project planning and project control
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
Project Management Body of Knowledge (PMBOK®).
(1)
term that that describes the knowledge within the profession of project management
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project management office (PMO).
(1)
management structure that standardizes the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project management plan.
(1)
document that describes how the project will be executed, monitored and controlled, and closed
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
information item that describes how the project will be executed, monitored, and controlled
(ISO/IEC/IEEE 24748-5:2017 Systems and software engineering--Life cycle management--Part 5: Software development planning, 3.11)
|
|
project management process group.
(1)
logical grouping of project management inputs, tools and techniques, and outputs. The Project Management Process Groups include Initiating processes, Planning processes, Executing processes, Monitoring and Controlling processes, and Closing processes
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project management software.
(1)
applications specifically designed to aid the project management team with planning, monitoring, and controlling the project, including cost estimating, scheduling, collaboration, and risk analysis
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
project management team.
(1)
members of the project team who are directly involved in project management activities
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: project team
|
|
project manager (PM).
(1)
person assigned by the performing organization to lead the team that is responsible for achieving the project objectives
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
person with overall responsibility for the management and running of a project
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.42)
(3)
stakeholder with overall responsibility for the planning, execution, and closure of a project
(ISO/IEC/IEEE 24748-5:2017 Systems and software engineering--Life cycle management--Part 5: Software development planning, 3.10)
Syn: PJM
See Also: project lead
|
|
project performance.
(1)
derived measure that gives an indication of some attribute associated with how well, how quickly, how effectively, or how efficiently a project is carried out
(ISO/IEC 29155-1:2017 Systems and software engineering--Information technology project performance benchmarking framework--Part 1: Concepts and definitions, 2.8)
|
|
project phase.
(1)
collection of logically related project activities that culminates in the completion of one or more deliverables
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: stage
|
|
project plan.
(1)
document that describes the technical and management approach to be followed for a project
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: for example, a software development plan. The plan typically describes the work to be done, the resources required, the methods to be used, the procedures to be followed, the schedules to be met, and the way that the project will be organized.
|
|
project planning.
(1)
activities concerned with the specification of the components, timing, resources, and procedures of a project
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
project portfolio.
(1)
collection of projects that addresses the strategic objectives of the organization
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.38)
|
|
project procurement management.
(1)
Project procurement management includes the processes necessary to purchase or acquire products, services, or results needed from outside the project team.
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project resource constraint.
(1)
limitation or restraint placed on resource usage, such as what resource skills or disciplines are available and the amount of a given resource available during a specified time frame
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
project risk.
(1)
risk related to the management of a project
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.13)
Example: lack of staffing, strict deadlines, changing requirements
|
|
project schedule.
(1)
output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project schedule network diagram.
(1)
graphical display of the logical relationships among the project schedule activities
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: activity network diagram
|
|
project scope.
(1)
work performed to deliver a product, service, or result with the specified features and functions
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project scope statement.
(1)
description of the project scope, major deliverables, and exclusions
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project specification.
(1)
specification of the objectives, requirements, and scope of a project and its relations to other projects
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
project team.
(1)
project manager, and, for some projects, the project sponsor, and the group of persons who report either directly or indirectly to the project manager and who are responsible for performing project work as a regular part of their assigned duties, including the staff supporting project management
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
set of individuals performing the work of the project to achieve its objectives
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: project management team
|
|
project vision statement.
(1)
concise, high-level description of the project that states the purpose and inspires the team to contribute to the project
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
project work performance domain.
(1)
performance domain that addresses activities and functions associated with establishing project processes, managing physical resources, and fostering a learning environment
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
projectized organization.
(1)
organizational structure in which the project manager has full authority to assign priorities, apply resources, and direct the work of persons assigned to the project
(ISO/IEC/IEEE 24765h:2019)
|
|
prolog breakpoint.
(1)
breakpoint that is initiated upon entry into a program or routine
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: preamble breakpoint
See Also: epilog breakpoint, code breakpoint, data breakpoint, dynamic breakpoint, programmable breakpoint, static breakpoint
|
|
PROM.
(1)
programmable read-only memory
(ISO/IEC/IEEE 24765c:2014)
|
|
prompt.
(1)
symbol or message displayed by a computer system, requesting input from the user of the system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
visual or audible message sent by a program to request or guide the user's response
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
proof of concept.
(1)
realization of an idea or technology to demonstrate its feasibility
(INCOSE Systems Engineering Handbook, 5th ed.)
|
|
proof of correctness.
(1)
formal technique used to prove mathematically that a computer program satisfies its specified requirements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: assertion, formal specification, inductive assertion method, partial correctness, total correctness
|
|
property.
(1)
responsibility that is an inherent or distinctive characteristic or trait that manifests some aspect of an object's knowledge or behavior
(ISO/IEC/IEEE 24765n:2025, 3.1.151)
(2)
attribute of things
(ISO/IEC/IEEE 15026-2:2022, Systems and software engineering Systems and software assurance Part 2: Assurance case, 3.1.5)
Note: Three kinds of property are defined: attribute, participant properties due to relationships, and operations.
|
|
property to quantify.
(1)
property of a target entity that is related to a quality measure element and which can be quantified by a measurement method
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 4.11)
|
|
property-of-interest.
(1)
object whose loss is considered as a negative effect
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.4.12)
Note: The concept of property-of-interest is introduced in order to characterize negative effects of consequences. In the safety context, human lives and health are instances of properties-of-interest. Assets in the security context are instances of properties-of-interest.
|
|
proposal.
(1)
supplier's offer to provide a system or service, usually including benefits, costs, risks, opportunities, and other factors applicable to decisions
(ISO/IEC/IEEE 24765c:2014)
Note: includes business cases
|
|
proposed change.
(1)
report of anomaly, required or recommended enhancement from the time an idea is recorded until the disposition by a designated change authority
(ISO/IEC/IEEE 24765i:2020)
Note: The disposition can be to reject, to defer for further analysis, or to accept. Upon acceptance the proposed change becomes an approved modification. There can be a one-to-one, one-to-many, or many-to-many relationship between proposed changes and approved modifications.
|
|
proposition.
(1)
observable fact or state of affairs involving one or more entities, of which it is possible to assert or deny that it holds for those entities
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 6.2)
|
|
protected.
(1)
responsibility that is visible only to the class or the receiving instance of the class (available only within methods of the class or its subclasses)
(ISO/IEC/IEEE 24765n:2025, 3.1.152)
See Also: private, public, hidden
|
|
protection.
(1)
process to secure content
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.12)
|
|
protection exception.
(1)
exception that occurs when a program attempts to write into a protected area in storage
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: addressing exception, data exception, operation exception, overflow exception, underflow exception
|
|
protocol.
(1)
set of conventions that govern the interaction of processes, devices, and other components within a system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
protocol object.
(1)
engineering object in a channel, which communicates with other protocol objects in the same channel to achieve interaction between basic engineering objects (possibly in different clusters, possibly in different capsules, possibly in different nodes)
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.12)
|
|
prototype.
(1)
preliminary type, form, or instance of a system that serves as a model for later stages or for the final, complete version of the system
(ISO/IEC/IEEE 24765a:2011)
(2)
an experimental model, either functional or nonfunctional, of the system or part of the system
(3)
working model used to obtain early feedback on the expected product before actually building it
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(4)
model or preliminary implementation of a piece of software suitable for the evaluation of system design, performance or production potential, or for the better understanding of the software requirements
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.34)
Note: A prototype is used to get feedback from users for improving and specifying a complex human interface, for feasibility studies, or for identifying requirements.
|
|
prototyping.
(1)
hardware and software development technique in which a preliminary version of part or all of the hardware or software is developed to permit user feedback, determine feasibility, or investigate timing or other issues in support of the development process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: rapid prototyping
|
|
provision.
(1)
expression in the content of a normative document, that takes the form of a statement, an instruction, a recommendation or a requirement
(ISO/IEC 14143-2:2011 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1, 3.8)
Note: These types of provision are distinguished [in English] by the form of wording they employ, e.g., instructions are expressed in the imperative mood, recommendations by the use of the auxiliary "should", and requirements by the use of the auxiliary "shall".
|
|
PRR.
(1)
production readiness review
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
PRT.
(1)
programmable reload timer
(ISO/IEC/IEEE 24765e:2015)
|
|
PSB.
(1)
preventive support budget
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
PSCI.
(1)
Protocol Support for Computational Interactions
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 4)
|
|
pseudo instruction.
(1)
source language instruction that provides information or direction to the assembler or compiler and is not translated into a target language instruction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: an instruction specifying the desired format of source code listings
Syn: pragma, pseudo-op, pseud0-operation
|
|
pseudo-oracle.
(1)
independently derived variant of the test item used to generate results, which are compared with the results of the original test item based on the same test inputs
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.59)
Example: a system that already exists, a system developed by an independent team, or a system implemented using a different programming language
Syn: derived test oracle
|
|
pseudocode.
(1)
combination of programming language constructs and natural language used to express a computer program design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
general term for structured English or program design language
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
English-like statements used for low-level program design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: IF the data arrives faster than expected, THEN reject every third input ELSE process all data received ENDIF.
|
|
pseudostatic random access memory (PSRAM).
(1)
dynamic random access memory unit with an automatic refresh circuit on the unit
(ISO/IEC/IEEE 24765c:2014)
|
|
PSP.
(1)
product support plan
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
PSRAM.
(1)
pseudostatic random access memory
(ISO/IEC/IEEE 24765c:2014)
|
|
PSW.
(1)
program status word
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
psychometrics.
(1)
field of study concerned with the theory and technique for developing valid and reliable psychological measures
(ISO/IEC 25022:2016, Systems and software engineering -- Systems and software quality requirements and evaluation (SQuaRE) -- Measurement of quality in use, 4.14)
|
|
public.
(1)
responsibility that is not hidden
(ISO/IEC/IEEE 24765n:2025, 3.1.153)
(2)
known to multiple routines or modules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: That is, visible to any requester (available to all without restriction).
See Also: hidden, private, protected
|
|
publisher.
(1)
event source that can be connected to an arbitrary number of event sinks, which subscribe to the publisher event source
(ISO/IEC/IEEE 24765l:2024)
|
|
publishing pipeline.
(1)
series of defined processing steps that are connected to transform content from its source format into a final deliverable format
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.25)
|
|
pulse width modulation (PWM).
(1)
control of electrical signals with various cycle and duty ratios
(ISO/IEC/IEEE 24765d:2015)
Syn: pulse-width modulation
|
|
purpose of the count.
(1)
reason for performing the function point count
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.45)
|
|
PV.
(1)
planned value
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
PWM.
(1)
pulse width modulation
(ISO/IEC/IEEE 24765d:2015)
|
|
QA.
(1)
quality assurance
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
QC.
(1)
quality control
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
QE.
(1)
quality engineering
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.3)
|
|
QFP.
(1)
quad flat pack
(ISO/IEC/IEEE 24765c:2014)
|
|
QM.
(1)
quality management
(ISO/IEC/IEEE 24765b:2013)
(2)
quality measure
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 5 b))
|
|
QM-RM.
(1)
quality measurement reference model
(ISO/IEC 25020:2019 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE)--Quality measurement framework, 4)
|
|
QME.
(1)
quality measure element
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 5)
|
|
QMS.
(1)
quality management system
(ISO/IEC/IEEE 24765c:2014)
Note: [ISO 9000:2005]
|
|
QOS.
(1)
Quality of Service
(ISO/IEC 19793:2015 Information technology -- Open Distributed Processing -- Use of UML for ODP system specifications, 4)
|
|
QR.
(1)
quality requirements
(ISO/IEC TR 14143-4:2002 Information technology -- Software measurement -- Functional size measurement -- Part 4: Reference model, 4)
|
|
QTFF.
(1)
QuickTime File Format
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.2)
Note: The file extension is .mov
|
|
quad flat pack (QFP).
(1)
surface mount rectangular circuit package with gull-wing shaped leads extending from each of the four sides
(ISO/IEC/IEEE 24765c:2014)
Note: A low profile QFP (LQFP) is thinner than a QFP.
|
|
qualification.
(1)
process of demonstrating whether an entity is capable of fulfilling specified requirements
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.51)
(2)
specific professional recognition, title or token, which may indicate proficiency, skill or knowledge in a given domain, but which is done on a one-time basis only
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.14)
(3)
demonstrated education, training and work experience, where applicable
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.13)
Note: The process can include testing and analyzing hardware and software configuration items to prove that the design can survive the anticipated accumulation of acceptance test environments, plus its expected handling, storage, and operational environments, plus a specified qualification margin.
|
|
qualification body.
(1)
entity issuing certificates of qualification
(ISO/IEC/IEEE 24765h:2019)
|
|
qualification scheme.
(1)
requirements which, when satisfied, result in the issuance of a qualification
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.15)
|
|
qualification testing.
(1)
testing conducted to determine whether a system or component is suitable for operational use
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
(2)
testing conducted on a hardware element, software element, or system to evaluate conformance with specified requirements
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
See Also: acceptance testing, development testing, operational testing
|
|
qualitative risk analysis.
(1)
prioritizing risks for subsequent further analysis or action by assessing and combining their probability of occurrence and impact
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
quality.
(1)
ability of a product, service, system, component, or process to meet customer or user needs, expectations, or requirements
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.35)
(2)
degree to which a set of inherent characteristics fulfills requirements
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
quality analysis.
(1)
analysis of rating results for multiple quality properties to determine the objective score or acceptability for the quality of the target entity
(ISO/IEC 25040:2024 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Quality evaluation framework, 3.6)
|
|
quality assurance (QA).
(1)
part of quality management focused on providing confidence that quality requirements are fulfilled
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.34)
Note: There are both internal and external purposes for quality assurance: within an organization, quality assurance provides confidence to management; in contractual situations, quality assurance provides confidence to the customer or others. Some quality control and quality assurance actions are interrelated. Unless requirements for quality fully reflect the needs of the user, quality assurance does not necessarily provide adequate confidence.
See Also: quality management, quality control
|
|
quality attribute.
(1)
characteristic of software, or a generic term applying to quality factors
(ISO/IEC/IEEE 24765j:2021)
|
|
quality characteristic.
(1)
inherent characteristic of a product, process, or system related to a requirement
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.53)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.35)
(2)
category of quality attributes that bears on the quality of the ICT product or information system
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.3.12)
(ISO/IEC 25002:2024, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model overview and usage, 3.17)
Note: Critical quality characteristics commonly include those related to health, safety, security, assurance, reliability, availability and supportability.
|
|
quality control (QC).
(1)
monitoring service performance or product quality, recording results, and recommending necessary changes
(ISO/IEC/IEEE 24765c:2014)
See Also: control quality, quality assurance
|
|
quality evaluation.
(1)
systematic examination of the extent to which an entity is capable of fulfilling specified requirements
(ISO/IEC 25040:2024 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Quality evaluation framework, 3.7)
|
|
quality in use (measure).
(1)
extent to which the system or product, when it is used in a specified context of use, satisfies or exceeds stakeholders needs to achieve specified beneficial goals or outcomes
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.1.15)
(2)
degree to which a product or system can be used by specific users to meet their needs to achieve specific goals with effectiveness, efficiency, freedom from risk and satisfaction in specific contexts of use
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.24)
(3)
extent to which the behavioral and attitudinal outcomes and consequences of use of a product, system, or service meet the needs of users or other stakeholders in specific contexts of use
(ISO/IEC 25030:2019 Systems and software engineering--Systems and software quality requirements and evaluation (SQuaRE)--Quality requirements framework, 3.13)
Note: This definition of quality in use is similar to the definition of usability in ISO 9241-11. Before the product is released, quality in use can be specified and measured in a test environment designed and used exclusively by the intended users for their goals and contexts of use, e.g. User Acceptance Testing Environment.
Syn: quality-in-use
See Also: usability
|
|
quality in use measure.
(1)
measure of the degree to which a product or system can be used by specific users to meet their needs to achieve specific goals with effectiveness, efficiency, freedom from risk, satisfaction and content coverage in specific contexts of use
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.25)
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 4.12)
|
|
quality management.
(1)
coordinated activities to direct and control an organization with regard to quality
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.55)
Syn: QM
|
|
quality management plan.
(1)
component of the project or program management plan that describes how applicable policies, procedures, and guidelines will be implemented to achieve the quality objectives
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
quality measure.
(1)
derived measure that is defined as a measurement function of two or more values of quality measure elements
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 4.13)
See Also: software quality measure
|
|
quality measure element (QME).
(1)
measure defined in terms of a property and the measurement method for quantifying it, including optionally the transformation by a mathematical function
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.26)
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 4.14)
Note: The software quality characteristics or subcharacteristics of the entity are derived afterwards by calculating a software quality measure.
|
|
quality measure on external property.
(1)
measure of the degree to which a system or software product enables its behavior to satisfy stated and implied needs for the system including the software to be used under specified conditions
(ISO/IEC 25020:2019 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE)--Quality measurement framework, 3.15)
Example: The failure density against test cases found during testing is a quality measure on external property related to the number of faults present in the computer system. The two measures are not necessarily identical since testing may not find all faults, and a fault may give rise to apparently different failures in different circumstances.
Syn: QM on external property
|
|
quality measure on internal property.
(1)
measure of the degree to which a set of static attributes of a software product satisfies stated and implied needs for the software product to be used under specified conditions
(ISO/IEC 25020:2019 Systems and software engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE)--Quality measurement framework, 3.16)
Example: Complexity measures and the number, severity, and failure frequency of faults found in a walk through are typical quality measures on internal property made on the product itself.
Note: Quality measures on internal property are typically associated with quality requirements on static properties and attributes that can be specified in or derived from requirements.
Syn: QM on internal property
|
|
quality metric.
(1)
quantitative measure of the degree to which an item possesses a given quality attribute
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
function whose inputs are software data and whose output is a single numerical value that can be interpreted as the degree to which the software possesses a given quality attribute
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
quality metrics.
(1)
description of a project or product attribute and how to measure it
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: quality measure
|
|
quality model.
(1)
defined set of characteristics and of relationships between them, which provides a framework for specifying quality requirements and evaluating quality
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.27)
|
|
quality of service.
(1)
set of quality requirements on the collective behavior of one or more objects
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.2)
|
|
quality policy.
(1)
basic principles that should govern the organizations actions as it implements its system for quality management
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
quality property.
(1)
property of a target entity that is related to a quality measure element, and which can be quantified by a measurement method
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.1.18)
(ISO/IEC 25002:2024, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model overview and usage, 3.22)
|
|
quality rating module.
(1)
set of quality measures, operational environment, and methods for conducting quality measurements and quality ratings on a specific category of target entities
(ISO/IEC 25040:2024 Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Quality evaluation framework, 3.8)
|
|
quality record report.
(1)
report which is generated through dynamic test execution and code analysis to record test results and other output
(ISO/IEC 30130:2016 Software engineering --Capabilities of software testing tools, 3.1)
Note: including Test Result, Static Code Analysis Report, Test Incident Report, and Metrics.
|
|
quality report.
(1)
project document that includes quality management issues, recommendations for corrective actions, and a summary of findings from quality control activities and may include recommendations for process, project, and product improvements
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
quality requirement.
(1)
capability of a product to satisfy the stated and implied needs when used under specific conditions
(ISO/IEC TR 24766:2009 Information technology--Systems and software engineering--Guide for requirements engineering tool capabilities, 3.5)
(2)
requirement for quality properties or attributes of an information system and IT service system that satisfy needs which ensue from the purpose for which that information system and IT service system is to be used
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.1.19)
(3)
requirement for quality properties or attributes of an ICT product, data, or service that satisfy needs which ensue from the purpose for which that ICT product, data, or service is to be used
(ISO/IEC 25030:2019 Systems and software engineering--Systems and software quality requirements and evaluation (SQuaRE)--Quality requirements framework, 3.15)
See Also: non-functional requirement
|
|
quality subcharacteristic.
(1)
set of one or more quality properties that represent a unique aspect of a quality characteristic
(ISO/IEC 25019:2023, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality-in-use model, 3.1.20)
(ISO/IEC 25002:2024, Systems and software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model overview and usage, 3.24)
Note: Quality sub-characteristics can help subdivide quality characteristics into individual aspects that help in mapping them to quality properties.
Syn: quality sub-characteristic
|
|
quantitative risk analysis.
(1)
numerical analysis of the effect on overall project objectives of identified risks
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
query language.
(1)
language used to access information stored in a database
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: programming language, specification language
|
|
queue.
(1)
list in which items are appended to the last position of the list and retrieved from the first position of the list
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
quiescing.
(1)
process of bringing a device or system to a halt by rejecting new requests for work
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
R&D.
(1)
research and development
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
Syn: R & D
|
|
R&M.
(1)
reliability and maintainability
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
Syn: R & M
|
|
RACI.
(1)
responsible, accountable, consulted, and informed
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
Syn: ARCI
|
|
RAM.
(1)
responsibility assignment matrix
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
random access memory
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
RAM-C.
(1)
reliability, availability, maintainability, and cost
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
RAMT.
(1)
reliability, availability, maintainability, testability
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.2)
|
|
random failure.
(1)
failure whose occurrence is unpredictable except in a probabilistic or statistical sense
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: intermittent fault, transient error
|
|
random testing.
(1)
specification-based test design technique based on generating test cases to exercise randomly selected test item inputs
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.41)
|
|
random-access memory (RAM).
(1)
volatile semiconductor storage device which allows data to be written or accessed in approximately the same amount of time, regardless of the data's physical location
(ISO/IEC/IEEE 24765c:2014)
Note: often used for caches or main memory in a computer and embedded in an MCU chip. Compare to a CD where data is stored and accessed sequentially.
Syn: random access memory
|
|
rapid prototyping.
(1)
type of prototyping in which emphasis is placed on developing prototypes early in the development process to permit early feedback and analysis in support of the development process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: waterfall model, data structure-centered design, incremental development, input-process-output, modular decomposition
|
|
rate-monotonic algorithm.
(1)
real-time scheduling algorithm that assigns higher priorities to tasks with shorter periods
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
rating.
(1)
action of mapping the measured value to the appropriate rating level
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.28)
Note: used to determine the rating level associated with the software for a specific quality characteristic. Rating and rating levels can be applied to characteristics other than quality characteristics.
|
|
rating interval.
(1)
time interval of the measurement procedure from the time the SUT reaches a stable state of operation to the time the measurement results are fulfilling the required statistical significance
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.13)
|
|
rating level.
(1)
scale point on an ordinal scale, which is used to categorize a measurement scale
(ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.29)
Note: The rating level enables software product to be classified (rated) in accordance with the stated or implied needs. Appropriate rating levels can be associated with the different views of quality, i.e., Users', Managers,' or Developers.'
|
|
ratio scale.
(1)
scale in which the measurement values have equal distances corresponding to equal quantities of the attribute where the value of zero corresponds to none of the attribute
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: For example, the size of a software component in terms of LOC is a ratio scale, because the value of zero corresponds to no lines of code and each additional increment represents equal amounts of code.
See Also: interval scale, nominal scale, ordinal scale
|
|
RBAC.
(1)
role-based access control
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
RBS.
(1)
risk breakdown structure
(ISO/IEC/IEEE 24765n:2025)
(2)
resource breakdown structure
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
RBT.
(1)
risk-based testing
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
RC.
(1)
recovery complete
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
RDA.
(1)
Remote Database Access
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
RDBMS.
(1)
Relational Database Management System
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 5)
|
|
RDF.
(1)
Resource Description Framework
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.2)
|
|
RDN.
(1)
Relative Distinguished Name
(ISO/IEC 13235-3:1998 Information technology -- Open Distributed Processing -- Trading Function -- Part 3: Provision of Trading Function using OSI Directory service, 4)
|
|
reachability graph.
(1)
directed graph of nodes and edges, where the nodes correspond to reachable markings, and the edges correspond to transition occurrences
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.30)
|
|
reachable marking.
(1)
marking of the net that can be reached from the initial marking by the occurrence of transitions
(ISO/IEC 15909-1:2019 Systems and software engineering--High-level Petri nets--Part 1: Concepts, definitions and graphical notation, 3.31)
|
|
reactivation.
(1)
cloning a cluster following its deactivation
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.26)
|
|
reactive approach.
(1)
approach of developing a product line or product variations in response to stated needs or customer requirements
(ISO/IEC 26553:2018 Information technology -- Software and systems engineering-- Tools and methods for product line realization, 3.16)
|
|
reactiveness.
(1)
degree to which the IT service promptly responds to user requests
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.6.2)
|
|
read.
(1)
to access data from a storage device or data medium
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
data movement type that moves a data group from persistent storage within reach of the functional process which requires it
(ISO/IEC 19761:2011 Software engineering -- COSMIC: a functional size measurement method, 2.23)
Note: A read is considered to include certain associated data manipulations necessary to achieve the read.
Syn: read type
See Also: destructive read, nondestructive read, write
|
|
read arc.
(1)
special kind of arc that tests the presence of some tokens in the related place, without consumption
(ISO/IEC 15909-3:2021. Systems and software engineering--High-level Petri nets--Part 3: Extensions and structuring mechanisms, 3.5)
|
|
read-only.
(1)
property that causes no state changes
(ISO/IEC/IEEE 24765n:2025, 3.1.155)
Note: That is, it does no updates.
Syn: read only
|
|
read-only memory (ROM).
(1)
non-volatile semiconductor storage device, from which data cannot be removed once it is written
(ISO/IEC/IEEE 24765d:2015)
Syn: read only memory
|
|
readability.
(1)
ease with which a system's source code can be read and understood, especially at the detailed, statement level
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
reader note.
(1)
comment made by a reader about a diagram and placed on the diagram page
(ISO/IEC/IEEE 24765m:2024, 2.1.97)
Note: A reader note is not part of the diagram itself, but rather is used for communication about a diagram during model development.
|
|
reading reference.
(1)
data storage entity or record, or interface record from another software or system containing data retrieved in a BFC
(ISO/IEC 29881:2010 Information technology--Software and systems engineering--FiSMA 1.1 functional size measurement method, 3.8)
Note: The number of reading references is equal to 0 for all BFC types where it is applicable.
|
|
ready.
(1)
statement on the required quality attributes a backlog item or other work product meets before it starts a specified activity or task
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.14)
Syn: definition of ready
See Also: done
|
|
ready to use software product (RUSP).
(1)
software product available to any user, at cost or not, to use without the need to conduct development activities
(ISO/IEC 25051:2014 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, 4.1.6)
Note: includes the product description (including cover information, data sheet, and website information; the user documentation necessary to install and use the software, including any configuration of the operating system or target computer required to operate the product; the software contained on a computer sensible media (e.g., disk or CD-ROM) or internet downloadable. Includes software produced and supported without typical commercial fees and licensing considerations.
Syn: ready-to-use software product
See Also: commercial off the shelf (COTS)
|
|
real address.
(1)
address of a storage location in the main storage part of a virtual storage system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: virtual address
|
|
real storage.
(1)
main storage portion of a virtual storage system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: virtual storage
|
|
real type.
(1)
data type whose members can assume real numbers as values and can be operated on by real number arithmetic operations, such as addition, subtraction, multiplication, division, and square root
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: character type, enumeration type, integer type, logical type
|
|
real-time.
(1)
problem, system, or application that is concurrent and has timing constraints whereby incoming events are processed within a given timeframe
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
pertaining to a system or mode of operation in which computation is performed during the actual time that an external process occurs, in order that the computation results can be used to control, monitor, or respond in a timely manner to the external process
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: realtime, real time
|
|
real-time clock.
(1)
integrated circuit that tracks the current time in human units
(ISO/IEC/IEEE 24765d:2015)
|
|
real-time clock (RTC).
(1)
integrated circuit that tracks the current time in human units
(ISO/IEC/IEEE 24765d:2015)
Syn: real time clock
|
|
real-time operating system (RTOS).
(1)
operating system intended to handle transaction requests immediately upon receipt
(ISO/IEC/IEEE 24765c:2014)
|
|
real-time scheduling theory.
(1)
theory for priority-based scheduling of concurrent tasks with hard deadlines
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: It addresses how to determine whether a group of tasks, whose individual CPU utilization is known, will meet their deadlines.
|
|
real-world object.
(1)
entity that exists in a three-dimensional form and, by association, implies similar properties or behavior to software functions
(ISO/IEC/IEEE 24765k:2022)
Example: printer, filing cabinet, file folder, and sheet of paper
|
|
realization.
(1)
representation of interface responsibilities through specified algorithms and representation properties
(ISO/IEC/IEEE 24765n:2025, 3.1.156)
(2)
stage for detailed design and construction
(ISO/IEC 26557:2016 Software and systems engineering -- Methods and tools for variability mechanisms in software and systems product line, 3.10)
Note: The realization states "how" a responsibility is met; it is the statement of the responsibility's method. Realization consists of any necessary representation properties together with the algorithm (if any). A realization can involve representation properties or an algorithm, or both.
|
|
reasonably foreseeable misuse.
(1)
use of a product or system in a way not intended by the supplier, but which can result from readily predictable human behavior
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.30)
Note: Readily predictable human behavior includes the behavior of all types of users.
|
|
reasoning technique.
(1)
form of artificial intelligence that generates conclusions from available information using logical techniques, such as deduction and induction
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.60)
|
|
recall.
(1)
performance metric used to evaluate a classifier that measures the proportion of actual positives that were predicted correctly
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.61)
Syn: sensitivity
|
|
receptacle.
(1)
operation interface in which a computational component plays a client role
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 7.1.16)
|
|
recommendation.
(1)
provision that conveys advice or guidance
(ISO/IEC 14143-2:2011 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1, 3.9)
|
|
record.
(1)
set of related data items treated as a unit
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.20)
(2)
[verb] set down in a manner that can be retrieved and viewed
(ISO/IEC/IEEE 24748-5:2017 Systems and software engineering--Life cycle management--Part 5: Software development planning, 3.12)
Example: In stock control, the data for each invoice can constitute one record. Audit reports, incident reports, training records or minutes of meetings.
|
|
record element type (RET).
(1)
user-recognizable sub-group of data element types within a data function
(ISO/IEC 20926:2009 Software and systems engineering -- Software measurement -- IFPUG functional size measurement method 2009, 3.46)
|
|
records management system.
(1)
processes, related control functions, and tools that identify, store, retrieve, and retain data
(ISO/IEC/IEEE 24765h:2019)
|
|
recoverability.
(1)
capability of a product in the event of an interruption or a failure to recover the data directly affected and re-establish the desired state of the system
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.5.4)
(2)
degree to which object state changes resulting from failed transactions are cancelled
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 13.7.1.4)
(3)
degree to which a service supports its critical business functions to an acceptable level within a predetermined period of time following a disaster
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.4.3)
(4)
ability of a system to mitigate the duration and lossage of impairments; the extent to which a system can self-correct after operating at degraded level acceptable to stakeholders or dependent systems
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: As a quantitative component of dependability, recoverability and its elements can be expressed as a requirement parameter (threshold), as a probability (a prediction or estimate), or as a measurement obtained during test or in-service operation (observation)
See Also: survivability
|
|
recovery.
(1)
restoration of a system, program, database, or other system resource to a state in which it can perform required functions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
cloning a cluster after cluster failure or deletion
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 8.1.25)
See Also: backward recovery, checkpoint, forward recovery
|
|
recursion.
(1)
process of defining or generating a process or data structure in terms of itself
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
repeating the application of the same process or set of processes to successive levels of system elements in the system structure
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.31)
See Also: simultaneous recursion
|
|
recursive.
(1)
pertaining to a software module that calls itself
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
pertaining to a process or data structure that is defined or generated in terms of itself
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: reflexive
|
|
redundancy.
(1)
in fault tolerance, the presence of auxiliary components in a system to perform the same or similar functions as other elements for the purpose of preventing or recovering from failures
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: active redundancy, diversity, homogeneous redundancy, standby redundancy
|
|
reengineering.
(1)
examination and alteration of software to reconstitute it in a new form, including the subsequent implementation of the new form
(ISO/IEC TR 19759:2016 Software Engineering -- Guide to the Software Engineering Body of Knowledge (SWEBOK), 5.4.2)
(2)
complete cycle of performing reverse engineering followed by forward engineering
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
reentrant.
(1)
pertaining to a software module that can be entered as part of one process while also in execution as part of another process and still achieve the desired results
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: reenterable, re-entrant
|
|
reentry point.
(1)
place in a software module at which the module is reentered following a call to another module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: re-entry point
|
|
refactor.
(1)
to restructure software code without altering its behavior for the purpose of improving quality attributes, easing future extension or adaptation, or adhering to an architectural style
(Software Extension to the PMBOK(R) Guide Fifth Edition)
See Also: factoring
|
|
reference architecture.
(1)
core architecture that captures the high-level architecture concept of domain architecture and application architecture
(ISO/IEC 26552:2019 Software and systems engineering--Tools and methods for product line architecture design, 3.9)
|
|
reference body of knowledge.
(1)
body of knowledge that is used for the comparison of a particular body of knowledge associated with a certification scheme
(ISO/IEC 24773-1:2019 Software and systems engineering-Certification of software and systems engineering professionals-Part 1: General requirements, 3.12)
|
|
reference framework.
(1)
structure for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.26)
|
|
reference FSM method.
(1)
an FSM method to be used for comparison reasons when verifying the functional size measurement results
(ISO/IEC TR 14143-4:2002 Information technology -- Software measurement -- Functional size measurement -- Part 4: Reference model, 3.3)
|
|
reference information.
(1)
information that is intended to provide quick access to specific details for users who are generally familiar with the product's functions
(ISO/IEC/IEEE 26514:2022, Systems and software engineering -- Design and development of information for users, 3.1.43)
|
|
reference node.
(1)
node of a Petri net that is a representative of another node, possibly defined on another page of the net graph
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.14)
|
|
reference place.
(1)
reference node that represents a place and refers to either another reference place or to a place
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.15)
|
|
reference point.
(1)
interaction point defined in an architecture for selection as a conformance point in a specification which is compliant with that architecture
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 10.6)
|
|
reference transition.
(1)
reference node that represents a transition and refers to either another reference transition to a transition
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.1.16)
|
|
reference user requirement collection (RUR Collection).
(1)
a subset of RUR which is selected to match the purpose in a specific evaluation
(ISO/IEC TR 14143-4:2002 Information technology -- Software measurement -- Functional size measurement -- Part 4: Reference model, 3.5)
|
|
reference user requirements (RUR).
(1)
a standard set of user requirements which conforms to the requirements
(ISO/IEC TR 14143-4:2002 Information technology -- Software measurement -- Functional size measurement -- Part 4: Reference model, 3.4)
|
|
referential integrity.
(1)
guarantee that a reference refers to an object that exists
(ISO/IEC/IEEE 24765n:2025, 3.1.157)
(2)
guarantee that all specified conditions for a relationship hold true
(ISO/IEC/IEEE 24765n:2025, 3.1.157)
Example: If a class is declared to require at least one instance of a related state class, it would be invalid to allow an instance that does not have such a relationship.
|
|
refinement.
(1)
process of transforming one specification into a more detailed specification
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.6)
|
|
reflective construct.
(1)
construct that is viewed as the cause of measures in the relationship between a construct and its measures
(ISO/IEC 33003:2015 Information technology--Process assessment--Requirements for process measurement frameworks, 3.13)
|
|
reflexive.
(1)
in a relationship, the condition when the same data object plays both (binary or many (n-ary)) roles
(ISO/IEC 15476-4:2005 Information technology--CDIF semantic metamodel--Part 4: Data models, 6.5)
See Also: recursive
|
|
reflexive ancestor (of a class).
(1)
class itself or any of its generic ancestors
(ISO/IEC/IEEE 24765n:2025, 3.1.158)
See Also: generic ancestor
|
|
refresh.
(1)
method to keep data in volatile memory by rewriting the data before it disappears from the memory
(ISO/IEC/IEEE 24765c:2014)
Note: needed for memory with a circuit architecture in single stable state
|
|
Regex.
(1)
regular expression
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.26)
|
|
regid.
(1)
registration identifier
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.27)
|
|
register.
(1)
written record of regular entries for evolving aspects of a project, such as risks, stakeholders, or defects
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
small storage unit in a processing unit
(ISO/IEC/IEEE 24765c:2014)
Note: Registers can be set up in CPU, microcontroller, digital signal processor, or microprocessor.
|
|
register bank.
(1)
group of registers in a microprocessor chip
(ISO/IEC/IEEE 24765e:2015)
|
|
registration identifier.
(1)
unique identifier for an entity
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.27)
Syn: regid
|
|
registry.
(1)
book or system for keeping an official list or record of work products and the associated information items
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.18)
Note: Repository and library items can be recorded in registries to enable better management and governance of these items.
|
|
regression.
(1)
machine learning function that results in a numerical or continuous output value for a given input
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.62)
|
|
regression analysis.
(1)
analytic technique where a series of input variables are examined in relation to their corresponding output results in order to develop a mathematical or statistical relationship
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
regression test.
(1)
retesting to detect faults introduced by modification
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
regression testing.
(1)
testing performed following modifications to a test item or to its operational environment, to identify whether failures in unmodified parts of the test item occur
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.64)
Note: Regression testing differs from retesting in that it does not test that the modification works correctly, but that other parts of the system have not been accidentally affected by the change.
|
|
regular expression (Regex).
(1)
string of characters that allows patterns to be used to match search results
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.1.26)
Example: ^admin* - Find all matches that start with 'admin' and contain any sequence of characters afterwards
\d{5}$ - Find all matches that end with the number 5
^[0-9()-]+$ - Find matches that contain a 10-digit phone number
Note: Patterns can dictate that matches start or end with specific sequences of characters or allow the use of wildcards to match any characters in a sequence.
|
|
regulation.
(1)
requirement imposed by a governmental body. These requirements can establish product, process or service characteristics, including applicable administrative provisions that have government-mandated compliance
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
regulatory context.
(1)
laws, regulations, or any other requirements within the jurisdictions where the system can operate
(IEEE 7002:2022, IEEE Standard for Data Privacy Process, 3.1)
|
|
regulatory standard.
(1)
standard promulgated by a regulatory agency
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.63)
|
|
reinforcement learning.
(1)
task of building a ML model using a process of trial and reward to achieve an objective
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.64)
Note: A reinforcement learning task can include the training of a machine learning model in a way similar to supervised learning, plus training on unlabeled inputs gathered during the operation phase of the AI system. Each time the model makes a prediction, a reward is calculated, and further trials are run to optimize the reward. In reinforcement learning, the objective, or definition of success, can be defined by the system designer. In reinforcement learning, the reward can be a calculated number that represents how close the artificial intelligence system is to achieving the objective for a given trial.
|
|
relation.
(1)
set of relationships of the same relationship type
(ISO/IEC 14769:2001 Information technology -- Open Distributed Processing -- Type Repository Function, 3.2.3)
(2)
association between two or more domains of entities
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.13)
|
|
relational database management system.
(1)
management system for relational database
(ISO/IEC 25024:2015 Systems and software engineering - Systems and software Quality Requirements and Evaluation (SQuaRE) - Measurement of data, 4.34)
Note: In order to use a relational data base management systems (RDBMS), it is necessary to represent a relational model of data that organizes data with specific characteristics (e.g., tables or relations, unique key)
|
|
relationship.
(1)
real-world association among one or more entities
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
(2)
association between two (not necessarily distinct) classes that is deemed relevant within a particular scope and purpose
(ISO/IEC/IEEE 24765n:2025, 3.1.159)
(3)
semantic connection between model elements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(4)
association between two or more entities
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 8.14)
(5)
predicate involving two or more roles with assigned values
(ISO/IEC 14769:2001 Information technology -- Open Distributed Processing -- Type Repository Function, 3.2.1)
Note: The association is named for the sense in which the instances are related. A relationship can be represented as a time-varying binary relation between the instances of the current extents of two state classes.
|
|
relationship instance.
(1)
association of specific instances of the related classes
(ISO/IEC/IEEE 24765n:2025, 3.1.160)
|
|
relationship manager (RM).
(1)
role that develops and manages interactions with customers or suppliers
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.75)
|
|
relationship name.
(1)
verb or verb phrase that reflects the meaning of the relationship expressed between the two entities shown on the diagram on which the name appears
(ISO/IEC/IEEE 24765n:2025, 3.1.161)
Note: [key style]
|
|
relationship type.
(1)
type of relationship which expresses the number and type of the roles
(ISO/IEC 14769:2001 Information technology -- Open Distributed Processing -- Type Repository Function, 3.2.2)
|
|
relative address.
(1)
address that is adjusted by the addition of an offset to determine the address of the storage location to be accessed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: absolute address, base address, indexed address, self-relative address
|
|
relative chain frequency.
(1)
relative frequency of using the l-th chain type by an emulated user of the i-th type
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.14)
|
|
relative estimating.
(1)
method for creating estimates that are derived from performing a comparison against a similar body of work, taking effort, complexity, and uncertainty into consideration
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
relative time.
(1)
tick from a source that increments it according to a reference activity other than absolute time
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Example: the number of CPU seconds executing an application process in a multi-core virtualized environment, or the customary business hours and days in a certain locale
See Also: absolute time, natural unit
|
|
RELAX NG.
(1)
regular language description for XML/New Generation
(ISO/IEC 15909-2:2011 Software and system engineering--High-level Petri nets--Part 2: Transfer format, 4.2.6)
|
|
release.
(1)
particular version of a configuration item that is made available for a specific purpose
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.12)
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.43)
(2)
collection of new or changed configuration items that are tested and introduced into a live environment together
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(3)
collection of one or more new or changed configuration items deployed into the live environment as a result of one or more changes
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.28)
(4)
software version that is made formally available to a wider community
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(5)
delivered version of an application which includes all or part of an application
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(6)
set of grouped change requests, established in the Application Change Management Process, which are designed, developed, tested, and deployed as a cohesive whole
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.28)
(7)
distribution of a product increment to a customer or users
(ISO/IEC TR 24587:2021, Software and systems engineering--Agile development--Agile adoption considerations, 3.13)
(8)
one or more components of one or more products, which are intended to be put into production at the same time
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Example: source code, code for execution, or multiple software assets packaged into an internal production release and tested for a target platform, test release
Note: Release management includes defining acceptable quality levels for release, authority to authorize the release, and release procedures.
See Also: version
|
|
release backlog.
(1)
subset of product backlog planned for the next release
(ISO/IEC 33202:2024, Software and systems engineering Core agile practices, 3.24)
|
|
release engineer.
(1)
person responsible for coordinating development toward a release
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The release engineer monitors pending issues for a given release, oversee the code freeze, and tag the release once it gets out the door.
|
|
release map.
(1)
a displayed forecast of when software features will be released and how they will be grouped into releases
(Software Extension to the PMBOK(R) Guide Fifth Edition)
|
|
release package.
(1)
collection of configuration items and other artifacts necessary to install or update a software system
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: Typically includes application software media, documentation, utilities, configuration files, licensing materials, and installation utilities. These items are typically associated with a unique configuration identifier or version number of the system of interest and can be further identified by a license key or other identifier of the user or target environment.
|
|
release plan.
(1)
plan that describes what portions of system functionality will be implemented in which releases and the rationale for each release
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(2)
plan that sets expectations for the dates, features, and/or outcomes expected to be delivered over the course of multiple iterations
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: It includes or provides reference to a description of release contents, release schedule, release impacts, and release notifications.
|
|
release planning.
(1)
process of identifying a high-level plan for releasing or transitioning a product, deliverable, or increment of value
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
relevant stakeholder.
(1)
stakeholder that is identified for involvement in specified activities and is included in a plan
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
reliability.
(1)
capability of a product to perform specified functions under specified conditions for a specified period of time without interruptions and failures
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.5)
(2)
degree to which an object or an object's services provide agreed or expected functionality during a defined time period under specified conditions
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.29)
(3)
ability of a system or component to perform its required functions under stated conditions for a specified period of time
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.27)
(4)
ability of a system to operate without countable failures in a specified environment for a specified time span; its failure intensity
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: Dependability characteristics include availability and its inherent or external influencing factors, such as availability, reliability (including fault tolerance and recoverability), security (including confidentiality and integrity), maintainability, durability, and maintenance support. Wear or aging does not occur in software. Limitations in reliability are due to faults in requirements, design, and implementation, or due to contextual changes. As a quantitative component of dependability, reliability can be expressed as a requirement parameter (threshold), as a probability (a failure rate prediction or estimate), or as a failure intensity measurement obtained during test or in-service operation (observation).
See Also: availability, MTBF
|
|
reliability class.
(1)
category for subsetting system requirements and behaviors according to 1) the canonical quality characteristics of safety, security, functionality, performance, or utilization, 2) the universal reliability class (no subset of capability types), or 3) one or more system-specific reliability classes
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: A reliability class is the basis for specifying, observing, and evaluating the failure intensity of that class.
|
|
reliability growth.
(1)
improvement in reliability that results from correction of faults
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
reliability testing.
(1)
type of testing conducted to evaluate the ability of a test item to perform its required functions, including evaluating the frequency with which failures occur, when it is used under stated conditions for a specified period of time
(ISO/IEC/IEEE 29119-1:2022, Software and systems engineering--Software testing--Part 1: General concepts, 3.66)
|
|
relocatable.
(1)
pertaining to code that can be loaded into any part of main memory
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The starting address is established by the loader, which then adjusts the addresses in the code to reflect the storage locations into which the code has been loaded.
See Also: relocating loader
|
|
relocatable address.
(1)
address that is to be adjusted by the loader when the computer program containing the address is loaded into memory
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: absolute address
|
|
relocatable code.
(1)
code containing addresses that are to be adjusted by the loader to reflect the storage locations into which the code is loaded
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: absolute code
|
|
relocate.
(1)
to move machine code from one portion of main memory to another and to adjust the addresses so that the code can be executed in its new location
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
relocating assembler.
(1)
assembler that produces relocatable code
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: absolute assembler
|
|
relocating loader.
(1)
loader that reads relocatable code into main memory and adjusts the addresses in the code to reflect the storage locations into which the code has been loaded
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: relative loader
See Also: absolute loader
|
|
relocation dictionary.
(1)
part of an object module or load module that identifies the addresses that are adjusted when a relocation occurs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
relocation transparency.
(1)
distribution transparency which masks relocation of an interface from other interfaces bound to it
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.4.1.5)
Example: null
|
|
relocator.
(1)
object that manages a repository of locations for interfaces, including locations of management functions for the cluster supporting those interfaces
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 14.3.1.1)
|
|
remote job entry (RJE).
(1)
submission of jobs through a remote input device connected to a computer through a data link
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: remote batch entry
|
|
remote terminal emulator (RTE).
(1)
data processing system realizing a set of emulated users
(ISO/IEC 14756:1999 Information technology -- Measurement and rating of performance of computer-based software systems, 4.15)
|
|
repair.
(1)
corrective, emergency, or preventative support action undertaken to mitigate a system fault or a failure
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
(2)
corrective maintenance of defective or damaged parts or functions of a product
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.31)
Example: missing functions that do not result in application failure (external design error) or errors resulting in a stop-run situation (code error)
Syn: defect removal
|
|
reparent.
(1)
to move the changes developed under one branch into another
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The changes are not committed to the original branch.
|
|
repeatability (of results of measurements).
(1)
closeness of the agreement between the results of successive measurements of the same measurand carried out under the same conditions of measurement
(ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.8)
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 4.15)
Note: These conditions are called repeatability conditions. Repeatability conditions include the same measurement procedure, the same observer, the same measuring instrument, used under the same conditions; the same location; repetition over a short period of time. Repeatability is expressed quantitatively in terms of the dispersion characteristics of the results.
|
|
repetitive addressing.
(1)
method of implied addressing in which the operation field of a computer instruction is understood to address the operands of the last instruction executed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: one-ahead addressing
|
|
replaceability.
(1)
capability of a product to replace another specified product for the same purpose in the same environment
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.8.4)
Note: Replaceability of a new version of a software product is important to the user when upgrading. Replaceability can reduce lock-in risk, because other software products can be used in place of the present one,
See Also: adaptability, installability
|
|
replication.
(1)
copying a software product from one medium to another
(ISO/IEC/IEEE 90003:2018 Software engineering -- Guidelines for the application of ISO 9001:2015 to computer software, 3.13)
|
|
replication schema.
(1)
specification of constraints on the replication of an object including both constraints on the availability of the object and constraints on the performance of the object
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 16.7.1.1)
|
|
replication transparency.
(1)
distribution transparency which masks the use of a group of mutually behaviorally compatible objects to support an interface
(ISO/IEC 10746-3:2009 Information technology -- Open Distributed Processing -- Reference Model: Architecture, 4.4.1.6)
Note: Replication is often used to enhance performance and availability.
|
|
repo bloat.
(1)
changes recorded in the repository that do not contribute anything useful to the project's history
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: a large erroneous commit and its associated back-out operation
Note: A repo master can reduce repo bloat through repo surgery.
|
|
repo surgery.
(1)
changes made directly to the version control system's repository, bypassing the system's commands
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: by issuing database commands or directly manipulating system files
Note: Through repo surgery, a repo master can perform operations that the version control system does not directly support.
|
|
report.
(1)
information item that describes the results of activities such as investigations, observations, assessments, or tests
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.21)
(2)
formal record or summary of information
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Example: a document detailing the exposure of personally identifying information (PII), the corrective action taken to mitigate the exposure of PII, and the impact on consent agreements
Note: The output medium used is not relevant and the report can pertain to both an external output and an external inquiry.
|
|
report standard.
(1)
standard that describes the characteristics of describing results of engineering and management activities
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
reporting system.
(1)
facilities, processes and procedures used to generate or consolidate reports from one or more information management systems and distribute reports to stakeholders
(ISO/IEC/IEEE 24765h:2019)
|
|
repository.
(1)
organized and persistent data storage that allows data retrieval
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.24)
(2)
location/format in which such a collection is stored
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(3)
collection of all software-related artifacts belonging to a system
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.1)
(4)
place where work products and the associated information items are or can be stored for preservation and retrieval
(ISO/IEC/IEEE 42020:2019 Software, systems and enterprise -- Architecture processes, 3.19)
Note: Artifacts are, for example, the software engineering environment. Benchmarking repository is a repository which is designated for use as the source of comparative measures for the purpose of benchmarking. In a repository, work products and other items are preserved for future retrieval when needed,
whereas in a library, working data is temporarily stored and retrieved as necessary.
|
|
repository owner.
(1)
person or organization that owns and maintains a benchmarking repository
(ISO/IEC 29155-2:2013 Systems and software engineering--Information technology project performance benchmarking framework--Part 2: Requirements for benchmarking, 3.2)
Syn: repository administrator
|
|
representation.
(1)
logical portrayal of a physical, operational, or conceptual image or situation
(ISO/IEC/IEEE 24765e:2015)
(2)
one or more properties used by an algorithm for the realization of a responsibility
(ISO/IEC/IEEE 24765n:2025, 3.1.162)
Example: picture, drawing, block diagram, description, icon, symbol
|
|
representation property.
(1)
property on which an algorithm operates
(ISO/IEC/IEEE 24765n:2025, 3.1.163)
|
|
representation standard.
(1)
standard that describes the characteristics of portraying aspects of an engineering or management product
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
reproducibility (of results of measurements).
(1)
closeness of the agreement between the results of measurements of the same measurand carried out under changed conditions of measurement
(ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.9)
(ISO/IEC 25021:2012 Software engineering--Software product Quality Requirements and Evaluation (SQuaRE)--Quality measure elements, 4.16)
Note: A valid statement of reproducibility requires specification of the conditions changed. The changed conditions include the principle of measurement; method of measurement; observer; measuring instrument; reference standard; location; conditions of use; time. Reproducibility can be expressed quantitatively in terms of the dispersion characteristics of the results. Results are here usually understood to be corrected results.
|
|
request.
(1)
a message sent from one object (the sender) to another object (the receiver), directing the receiver to fulfill one of its responsibilities
(ISO/IEC/IEEE 24765n:2025, 3.1.164)
(2)
message issued by a client to cause a service to be performed
(ISO/IEC/IEEE 24765l:2024)
(3)
information item that initiates a defined course of action or change to fulfill a need
(ISO/IEC/IEEE 15289:2019 Systems and software engineering--Content of life-cycle information items (documentation), 5.22)
Note: Specifically, a request can be for the value of an attribute, for the value of a participant property, for the application of an operation, or for the truth of a constraint.
See Also: message
|
|
request for change.
(1)
proposal for a change to be made to a system, service, component, or the service management system
(ISO/IEC/IEEE 24765c:2014)
(2)
proposal for a functional or non-functional change to be made to an existing application
(ISO/IEC 16350-2015 Information technology--Systems and software engineering--Application management, 4.30)
Note: A change to a service includes the provision of a new service or the removal of a service which is no longer required.
See Also: change request, modification request
|
|
request for proposal (RFP).
(1)
document used by the acquirer as the means to announce its intention to potential bidders to acquire a specified system, software product, or software service
(2)
collection of formal documents that includes a description of the desired form of response from a potential supplier, the relevant statement of work for the supplier, and required provisions in the supplier agreement
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: request for tender, solicitation package
|
|
required inputs.
(1)
set of items necessary to perform the minimum verification and validation (V&V) tasks mandated within any life cycle activity
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
|
|
required outputs.
(1)
set of items produced as a result of performing the minimum verification and validation tasks mandated within any life cycle activity
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
|
|
requirement.
(1)
statement that translates or expresses a need and its associated constraints and conditions
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 4.1.31)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.36)
(2)
condition or capability that is met or possessed by a system, system component, product, or service to satisfy an agreement, standard, specification, or other formally imposed documents
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
(3)
provision that conveys criteria to be fulfilled
(ISO/IEC 14143-2:2011 Information technology -- Software measurement -- Functional size measurement -- Part 2: Conformity evaluation of software size measurement methods to ISO/IEC 14143-1, 3.10)
(4)
condition or capability that is necessary to be present in a product, service, or result to satisfy a business need
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(5)
need or expectation that is stated, generally implied, or obligatory
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.47)
(6)
condition or capability that is necessary in a system, system component, product, or service to satisfy an agreement, standard, specification, or other formally imposed documents
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Example: software component requirement
Note: Requirements exist at different tiers and express the need in high-level form. A requirement is denoted by the word 'shall' and includes both the exclusive and applicable optional requirements. Requirements provide value when delivered, satisfied, or met. Requirements include the quantified and documented needs, wants, and expectations of the sponsor, customer, and other stakeholders. Well-formed requirements are unambiguous, clear, unique, consistent, stand-alone (not grouped), verifiable, and necessary for stakeholder acceptability.
See Also: design requirement, functional requirement, implementation requirement, interface requirement, performance requirement, physical requirement
|
|
requirement standard.
(1)
a standard that describes the characteristics of a requirements specification
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
requirements allocation.
(1)
assignment or budgeting of top-level functional or nonfunctional requirements among the lower-level partitioned functions for accomplishment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: In this manner, the system elements that perform all or part of specific requirements are identified.
|
|
requirements analysis.
(1)
process of studying user needs to arrive at a definition of system, hardware, or software requirements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
process of studying and refining system, hardware, or software requirements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
systematic investigation of user requirements to arrive at a definition of a system
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
(4)
determination of product- or service-specific performance and functional characteristics based on analyses of customer needs, expectations, and constraints; operational concept; projected utilization environments for people, products, services, and processes; and measures of effectiveness
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
requirements attributes.
(1)
set of properties associated with requirements
(ISO/IEC TR 24766:2009 Information technology--Systems and software engineering--Guide for requirements engineering tool capabilities, 3.7)
|
|
requirements derivation.
(1)
changing or translation of a requirement through analysis into a form that is suitable for low-level analysis or design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
in a hierarchical structure, the next lower level that is associated with a given element
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
requirements document.
(1)
document containing any combination of requirements or regulations to be met by a ready to use software product (RUSP)
(ISO/IEC 25051:2014 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Requirements for quality of Ready to Use Software Product (RUSP) and instructions for testing, 4.1.13)
Example: a technical or ergonomic standard, a requirements list (or model requirements specification) from a group (e.g. a market sector, technical or user association), a law or a decree
See Also: requirements documentation
|
|
requirements documentation.
(1)
record of product requirements and other product information, along with whatever is recorded to manage it
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
requirements elicitation.
(1)
use of systematic techniques, such as prototyping and structured surveys, to proactively identify and document customer and end-user needs
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 3.1.20)
|
|
requirements engineering.
(1)
interdisciplinary function that mediates between the domains of the acquirer and supplier to establish and maintain the requirements to be met by the system, software or service of interest
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.1.19)
Note: Requirements engineering is concerned with discovering, eliciting, developing, analyzing, determining verification methods, validating, communicating, documenting, and managing requirements
See Also: software requirements engineering
|
|
requirements flow-down.
(1)
systematic decomposition of system requirements into allocated and derived requirements, appropriately assigned to low-level functional components
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
requirements management.
(1)
activities that help ensure requirements are identified, documented, maintained, communicated and traced throughout the life cycle of a system, product, or service
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.1.20)
(2)
provision of storing and editing capabilities, tracking history of edition, versioning, author identification, change management, time stamping, user notification for content changes, security rights control
(ISO/IEC TR 24766:2009 Information technology--Systems and software engineering--Guide for requirements engineering tool capabilities, 3.3)
See Also: software requirements management
|
|
requirements management plan.
(1)
component of the project or program management plan that describes how requirements will be analyzed, documented, and managed
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
requirements partitioning.
(1)
separation or decomposing of a top-level requirement or design into successively lower-level detailed requirements or design
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: decomposition
|
|
requirements phase.
(1)
period of time in the software life cycle during which the requirements for a software product are defined and documented
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
requirements review.
(1)
process or meeting during which the requirements for a system, hardware item, or software item are presented to project personnel, managers, users, customers, or other interested parties for comment or approval
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Types include system requirements review, software requirements review.
See Also: code review, design review, formal qualification review, test readiness review
|
|
requirements specification.
(1)
document that specifies the requirements for a system or component
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Typically included are functional requirements, performance requirements, interface requirements, design requirements, and development standards.
See Also: design description, functional specification, performance specification
|
|
requirements specification language.
(1)
specification language with special constructs and, sometimes, verification protocols, used to develop, analyze, and document hardware or software requirements
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: design language
|
|
requirements traceability.
(1)
identification and documentation of the derivation path (upward) and allocation/ flow-down path (downward) of requirements in the requirements set
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 3.1.23)
(2)
discernible association between a requirement and related requirements, implementations, and verifications
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
traceabilities in domain and application requirements respectively and those between them
(ISO/IEC 26551:2016 Software and systems engineering --Tools and methods for product line requirements engineering, 3.18)
|
|
requirements traceability matrix (RTM).
(1)
structured information artifact that links requirements to their higher-level requirements or needs or to lower-level implementation
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 3.1.24)
(2)
grid that links product requirements from their origin to the deliverables that satisfy them
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
requirements traceability tool.
(1)
software development tool that establishes a traceability among itemized software requirements specifications, design elements, code elements, and test cases
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: It also supports various associated query, analysis, and report-generation capabilities.
|
|
requirements validation.
(1)
confirmation that requirements (individually and as a set) define the right system as intended by the stakeholders
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.1.22)
See Also: requirements verification, software requirements validation
|
|
requirements verification.
(1)
confirmation by examination that requirements (individually and as a set) are well formed
(ISO/IEC/IEEE 29148:2018 Systems and software engineering-Life cycle processes-Requirements engineering, 4.1.23)
Note: This means that a requirement or a set of requirements has been reviewed to help ensure that the characteristics of good requirements are achieved.
See Also: requirements validation, software requirements verification
|
|
requirements-based testing.
(1)
specification-based test case design technique based on exercising atomic requirements
(ISO/IEC/IEEE 29119-4:2021 Software and systems engineering -- Software testing -- Part 4: Test techniques, 3.42)
|
|
reseller.
(1)
organization that purchases goods or services with an intention of selling them to another customer and possibly supporting them
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.29)
|
|
reserve.
(1)
provision in the project management plan to mitigate cost and/or schedule risk. Often used with a modifier (e.g., management reserve, contingency reserve) to provide further detail on what types of risk are meant to be mitigated
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Syn: contingency allowance
See Also: buffer
|
|
reserve analysis.
(1)
method used to evaluate the amount of risk on the project and the amount of schedule and budget reserve to determine whether the reserve is sufficient for the remaining risk
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
reserved word.
(1)
word in a programming language, of which the meaning is fixed by the rules of that language and which, in certain or all contexts, cannot be used by the programmer for any purpose other than its intended one
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Example: IF, THEN, WHILE
|
|
reset.
(1)
to set a variable, register, or other storage location back to a prescribed state
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: clear, initialize
|
|
reset arc.
(1)
special kind of arc that empties an input place
(ISO/IEC 15909-3:2021. Systems and software engineering--High-level Petri nets--Part 3: Extensions and structuring mechanisms, 3.6)
|
|
residual control.
(1)
microprogramming technique in which the meaning of a field in a microinstruction depends on the value in an auxiliary register
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: bit steering, two-level encoding
|
|
residual risk.
(1)
risk remaining after risk treatment
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.3.7)
|
|
resilience.
(1)
degree to which a service recovers its operational condition quickly after a failure occurs
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.4.2)
(2)
ability of the system to deliver required capability in the face of adversity
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.28)
|
|
resistance.
(1)
capability of a product to sustain operations while under attack from a malicious actor
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.6.6)
|
|
resource.
(1)
asset that is utilized or consumed during the execution of a process
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.45)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.37)
(2)
entity that is utilized or consumed during the execution of a process
(ISO/IEC/IEEE 24641:2023. Systems and Software engineering--Methods and tools for model-based systems and software engineering, 3.1.29)
(3)
role (with respect to that action) in which the enterprise object fulfilling the role is essential to the action, requires allocation, or can become unavailable
(ISO/IEC 15414:2015 Information technology -- Open distributed processing -- Reference model -- Enterprise language, 6.3.5)
Example: diverse entities such as funding, personnel, facilities, capital equipment, tools, and utilities such as power, water, fuel, and communication infrastructures. IT resources include CPU, memory, disk, and network.
Note: Allocation of a resource can constrain other behaviors for which that resource is essential. Resources can be reusable, renewable, or consumable. A consumable resource can become unavailable after some amount of use or after some amount of time (in case a duration or expiry has been specified for the resource).
|
|
resource allocation.
(1)
allocation (partitioning) of responsibility to different organizational units
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
resource breakdown structure (RBS).
(1)
hierarchical representation of resources by category and type
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
resource leveling.
(1)
technique in which start and finish dates are adjusted based on resource constraints with the goal of balancing demand for resources with the available supply
(ISO/IEC/IEEE 24765h:2019)
See Also: resource optimization technique, resource smoothing
|
|
resource management plan.
(1)
component of the project management plan that describes how project resources are acquired, allocated, monitored, and controlled
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
resource monitor task.
(1)
task ensuring sequential access to a resource
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
resource pooling.
(1)
feature where physical or virtual resources can be aggregated to provide a service to one or more service customers
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.1.2)
|
|
resource utilization.
(1)
capability of a product to use no more than the specified amount of resources to perform its function under specified conditions
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.2.2)
See Also: efficiency
|
|
resource utilization measurement (RUM).
(1)
structure that provides information about resources associated with an IT asset in order to facilitate its management
(ISO/IEC 19770-4:2017 Information technology -- IT asset management -- Part 4: Resource utilization measurement, 3.8)
Note: The RUM structure specifically contains information about the consumption of resources in relation to an IT asset.
|
|
resource-limited schedule.
(1)
project schedule whose schedule activity, scheduled start dates and scheduled finish dates reflect expected resource availability
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
respecialize.
(1)
change by an instance from being an instance of its current subclass to being an instance of one of the other subclasses in its current cluster
(ISO/IEC/IEEE 24765n:2025, 3.1.165)
See Also: specialize, unspecialize
|
|
responding object.
(1)
object taking part in a communication, which is not the initiating object
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 13.4.2)
|
|
response time.
(1)
elapsed time between the end of an inquiry or command to an interactive computer system and the beginning of the system's response
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: RT
See Also: port-to-port time, think time, turnaround time
|
|
responsibility.
(1)
ability to give account to somebody or some organization for ones actions
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.1)
(2)
an assignment that can be delegated within a project management plan such that the assigned resource incurs a duty to perform the requirements of the assignment
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: Refers to the actions and their consequences that a person executes out of free will, knowing what they are doing. For objects, an instance possesses knowledge, exhibits behavior, and obeys rules. These are collectively referred to as the instance's responsibilities. A class abstracts the responsibilities in common to its instances. A responsibility can apply to each instance of the class (instance-level) or to the class as a whole (class-level).
|
|
responsibility assignment matrix (RAM).
(1)
grid that shows the project resources assigned to each work package
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
responsive web design (RWD).
(1)
method for web page construction to detect the user's screen size and orientation and dynamically change the layout accordingly
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.20)
|
|
responsiveness.
(1)
degree to which an IT service responds and provides outcomes in a prompt and timely way
(ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.6)
|
|
restart.
(1)
to cause a computer program to resume execution after a failure, using status and results recorded at a checkpoint
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
restart point.
(1)
point in a computer program at which execution can be restarted following a failure
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: rescue point
|
|
result.
(1)
information returned to the client
(ISO/IEC/IEEE 24765l:2024)
(2)
output from performing project management processes and activities
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: deliverable, outcome, product
|
|
retainage.
(1)
portion of a contract payment that is withheld until contract completion to help ensure full performance of the contract terms
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
retesting.
(1)
testing performed to check that modifications made to correct a fault have successfully removed the fault
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.15)
Note: When retesting is performed it is often complemented by regression testing, to help ensure that other unmodified parts of the test item have not been accidentally adversely affected by the modifications.
Syn: confirmation testing
|
|
retirement.
(1)
withdrawal of active support by the operation and maintenance organization, partial or total replacement by a new system, or installation of an upgraded system
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.46)
(2)
withdrawal of active support by the operation and maintenance organization, partial or total replacement by a new system, installation of an upgraded system, or final decommissioning and disposal
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.38)
|
|
retirement phase.
(1)
period of time in the software life cycle during which support for a software product is terminated
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: software life cycle, system life cycle
|
|
retrospective.
(1)
regularly occurring workshop in which participants explore their work and results in order to improve both the process and product
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
retrospective meeting.
(1)
a team meeting at the end of an iterative cycle or at the end of a software project to reflect on what went well, what was learned, and what should be done differently next time
(Software Extension to the PMBOK(R) Guide Fifth Edition)
|
|
retrospective trace.
(1)
trace produced from historical data recorded during the execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: This differs from an ordinary trace, which is produced cumulatively during program execution.
See Also: execution trace, subroutine trace, symbolic trace, variable trace
|
|
return.
(1)
to transfer control from a software module to the module that called it
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
to assign a value to a parameter that is accessible by a calling module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
computer instruction or process that performs a return
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: return code
|
|
return code.
(1)
code used to influence the execution of a calling module following a return from a called module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
return on investment (ROI).
(1)
ratio of revenue from output (product or service) to development and production costs, which determines whether an organization benefits from performing an action to produce something
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
return value.
(1)
value assigned to a parameter by a called module for access by the calling module
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
reusability.
(1)
capability of a product to be used as assets in more than one system, or in building other assets
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.7.2)
See Also: generality
|
|
reusable.
(1)
pertaining to a software module or other work product that can be used in more than one computer program or software system
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
reusable product.
(1)
system, software, or hardware product developed for one use but having other uses, or one developed specifically to be usable on multiple projects or in multiple roles on one project
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
Example: commercial off-the-shelf (COTS) products, acquirer-furnished products, products in reuse libraries, and preexisting developer products
Note: Each use can include all or part of the product and can involve its modification. This term can be applied to any software or system product (for example, requirements or architectures), not just to software or system itself.
|
|
reuse.
(1)
use of an asset in the solution of different problems
(ISO/IEC/IEEE 24765j:2021)
(2)
building a software system at least partly from existing pieces to perform a new application
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
reused source statement.
(1)
unmodified source statement obtained for the product from an external source
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
revealed requirement.
(1)
requirement that is derived when a system produces an anomaly or behavior that no explicit requirement prohibits or allows
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: An anomaly or behavior can be judged to be acceptable or detrimental, resulting in a revealed requirement to allow or prohibit the behavior. A revealed requirement is considered to have the same standing as an explicit requirement.
|
|
revenue alternative.
(1)
alternative that is described in terms of its complete cash-flow stream with expense and income
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: service alternative
|
|
reverse engineering.
(1)
determining what existing software will do and how it is constructed (to make intelligent changes)
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
software engineering approach that derives a system's design or requirements from its code
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
obtaining a high-level representation of the software from the source code
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
Syn: inverse engineering
|
|
reversibility.
(1)
degree to which a cloud service provides the process for the customer to retrieve their data and application artifacts and for the provider to delete all customer data as well as contractually specified cloud service-derived data after the agreed-upon period
(ISO/IEC TS 25052-1:2022, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE): cloud services--Part 1: Quality model, 3.1.6.2)
|
|
reversible execution.
(1)
debugging technique in which a history of program execution is recorded and then replayed under the user's control, in either the forward or backward direction
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: backward execution, playback, replay, reverse execution
|
|
review.
(1)
process, which can include a meeting, in which work products are presented to some stakeholders for comment or approval
(IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2)
(2)
process or meeting during which a work product or a set of work products, is presented to project personnel, managers, users, customers, or other stakeholders for comment or approval
(ISO/IEC 29110-1-2:2024, Systems and software engineering Lifecycle profiles for Very Small Entities (VSEs) Part 1-2: Vocabulary, 3.79)
|
|
review folder.
(1)
entity for binding one or more related reviews, including a list of the reviews and information common to the reviews
(ISO/IEC 23396:2020, Systems and software engineering Capabilities of review tools, 3.2)
Note: The information common to the reviews can include information on members who can participate in or organize the reviews, and information on the classification given to the issues identified during the reviews.
|
|
review/audit output.
(1)
review or audit artifacts that are expected through conduct of the technical review or audit and that can be considered elements of exit criteria
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.1)
Syn: review output, audit output
|
|
revocation.
(1)
process of revoking an entitlement or entitlement schema
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.21)
Note: An entitlement is sometimes revoked by the organization which originally issued it. The entitlement schema (Ent) enables the recording of entitlement revocations. Specific Ent transactions can also be revoked, e.g., to correct errors or record the rescinding of entitlement allocations.
|
|
reward hacking.
(1)
activity performed by an agent to maximize its reward function to the detriment of meeting the original objective
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 6.1.65)
|
|
rework.
(1)
action taken to bring a defective or nonconforming component into compliance with requirements or specifications
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
RFC.
(1)
request for change
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 2.2)
|
|
RFI.
(1)
request for information
(ISO/IEC/IEEE 24765n:2025)
(2)
radio frequency interference
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)
|
|
RFID.
(1)
radio frequency identification
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
RFP.
(1)
request for proposal
(ISO/IEC/IEEE 24765n:2025)
|
|
RFQ.
(1)
request for quotation
(ISO/IEC/IEEE 24765n:2025)
|
|
RFR.
(1)
recovery failure intensity
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
right.
(1)
privilege or benefit granted by a software entitlement
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.22)
|
|
risk.
(1)
effect of uncertainty on objectives
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.48)
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition, 3.44)
(ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.47)
(ISO/IEC/IEEE 16085:2021 Systems and software engineering--Life cycle processes--Risk management, 3.5)
(ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.39)
(2)
combination of the likelihood of occurrence and the consequences of a given future undesirable event
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
(3)
combination of the likelihood of an abnormal event or failure and the consequences of that event or failure to a system's components, operators, users, or environment
(IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1)
(4)
combination of the probability of occurrence of harm and the severity of that harm
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.32)
Note: Risk is often expressed in terms of a combination of the consequences of an event and the associated likelihood of occurrence. The probability of occurrence includes the exposure to a hazardous situation, the occurrence of a hazardous event, and the possibility to avoid or limit the harm.
See Also: opportunity
|
|
risk acceptance.
(1)
risk response strategy whereby the project team decides to acknowledge the risk and not take any action unless the risk occurs
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
the decision to accept a risk
(ISO/IEC/IEEE 16085:2021 Systems and software engineering--Life cycle processes--Risk management, 3.6)
Syn: risk assumption
|
|
risk analysis.
(1)
process of examining identified risk factors for probability of occurrence, potential loss, and potential risk-handling strategies
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
risk appetite.
(1)
degree of uncertainty an entity is willing to accept in anticipation of a reward
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
risk audit.
(1)
examination and documentation of the effectiveness of risk responses in dealing with identified risks and their root causes, as well as the effectiveness of the risk management process
(ISO/IEC/IEEE 24765h:2019)
|
|
risk avoidance.
(1)
course of action that removes a risk factor from further consideration
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
risk response strategy whereby the project team acts to eliminate the threat or protect the project from its impact
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Example: changing the requirements, extending the schedule, or transferring the risk factor to another domain
|
|
risk breakdown structure (RBS).
(1)
hierarchical representation of potential sources of risks
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
risk category.
(1)
a class or type of risk
(ISO/IEC/IEEE 24765n:2025)
(ISO/IEC/IEEE 16085:2021 Systems and software engineering--Life cycle processes--Risk management, 3.8)
Example: technical, legal, organizational, safety, economic, engineering, cost, schedule
Note: A risk category is a characterization of a source of risk.
See Also: source
|
|
risk enhancement.
(1)
risk response strategy whereby the project team acts to increase the probability of occurrence or impact of an opportunity
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
risk escalation.
(1)
risk response strategy whereby the team acknowledges that a risk is outside its sphere of influence and shifts the ownership of the risk to a higher level of the organization where it is more effectively managed
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
risk exploiting.
(1)
risk response strategy whereby the project team acts to ensure that an opportunity occurs
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: Modified, "to ensure" changed to "to help ensure"
|
|
risk exposure.
(1)
potential loss presented to an individual, project, or organization by a risk
(ISO/IEC/IEEE 16085:2021 Systems and software engineering--Life cycle processes--Risk management, 3.10)
(2)
aggregate measure of the potential impact of all risks at any given point in time in a project, program, or portfolio
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: Risk exposure is commonly defined as the product of a probability and the magnitude of a consequence, that is, an expected value or expected exposure.
|
|
risk factor.
(1)
potential problem that would be detrimental to a planned activity, project, or program, characterized by the probability of problem occurrence (0 _ p _ 1) and a potential loss (of life, money, property, reputation, and so on) if the problem occurs
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Both probability and potential loss can change over time.
|
|
risk handling.
(1)
course of action taken in response to a risk factor
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: includes risk acceptance, risk avoidance, risk transfer, and risk mitigation.
|
|
risk identification.
(1)
organized, systematic approach to determining the risk factors associated with a planned activity, project, or program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
capability of a product to identify a course of events or operations that can expose life, property, or the environment to unacceptable risk
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.9.2)
See Also: identify risks
|
|
risk leverage factor (rlf).
(1)
rlf _ (reb _ rea)/rmc, where reb is risk exposure before risk mitigation, rea is risk exposure after risk mitigation, and rmc is the risk mitigation activity's cost
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Larger rlfs indicate better mitigation strategies.
|
|
risk management.
(1)
organized process for identifying and handling risk factors
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
an organized means of identifying and measuring risk (risk assessment) and developing, selecting, and managing options (risk analysis) for resolving (risk handling) these risks.
(3)
organized, analytic process to identify what can cause harm or loss (identify risks); to assess and quantify the identified risks; and to develop and, if needed, implement an appropriate approach to prevent or handle causes of risk that can result in significant harm or loss
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: The primary goal of risk management is to identify and respond to potential problems with sufficient lead-time to avoid a crisis situation. It includes initial identification and handling of risk factors as well as continuous risk management.
|
|
risk management plan.
(1)
component of the project, program or portfolio management plan that describes how risk management activities will be structured and performed
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: risk register
|
|
risk metric.
(1)
objective measure associated with a risk factor to be mitigated
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
risk mitigation.
(1)
risk response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: includes executing contingency plans when a risk metric crosses a predetermined threshold (when a risk becomes an issue or results in a problem)
|
|
risk monitoring and control.
(1)
tracking identified risks, monitoring residual risks, identifying new risks, executing risk response plans, and evaluating their effectiveness throughout the project life cycle
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
risk profile.
(1)
description of any set of risks
(ISO/IEC/IEEE 16085:2021 Systems and software engineering--Life cycle processes--Risk management, 3.8)
Note: The set of risks can contain those that relate to the whole organization, part of the organization, or one or more projects.
|
|
risk reassessment.
(1)
identifying new risks, reassessing current risks, and closing risks that are outdated
(ISO/IEC/IEEE 24765h:2019)
|
|
risk reduction.
(1)
reducing the probability or potential impact of a risk factor
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: Risk reduction can involve research, prototyping, and other means of exploration.
|
|
risk reduction measure.
(1)
steps taken to reduce or mitigate risk
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.3.9)
|
|
risk register.
(1)
repository in which outputs of risk management processes are recorded
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: The risk register details all identified risks, including description, category, cause, probability of occurring, impact(s) on objectives, proposed responses, owners, and current status. It can be kept in a database.
See Also: risk management plan
|
|
risk report.
(1)
project document that summarizes information on individual project risks and the level of overall project risk
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
risk review.
(1)
process of analyzing the status of existing risks and identifying new risks
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
See Also: risk reassessment
|
|
risk sharing.
(1)
risk response strategy whereby the project team allocates ownership of an opportunity to a third party who is best able to capture the benefit of that opportunity
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
risk source.
(1)
element that, alone or in combination, has the intrinsic potential to give rise to risk
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.3.10)
Note: A hazard in ISO Guide 73:2009 is an instance of a risk source. A fault, an error, or a failure in the context of reliability can be a risk source. A threat in the context of security, a threat agent, or an adverse action can be a risk source.
|
|
risk threshold.
(1)
measure of the level of uncertainty or the level of impact at which a stakeholder may have a specific interest
(ISO/IEC/IEEE 16085:2021 Systems and software engineering--Life cycle processes--Risk management, 3.9)
(2)
measure of acceptable variation around an objective that reflects the risk appetite of the organization and stakeholders
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
Note: Different risk thresholds can be defined for each risk, risk category or combination of risks, based on differing risk criteria. Below that risk threshold, the organization accepts the risk. Above that risk threshold, the organization does not tolerate the risk.
|
|
risk tolerance.
(1)
the degree, amount, or volume of risk that an organization or individual will withstand
(ISO/IEC/IEEE 16085:2021 Systems and software engineering--Life cycle processes--Risk management, 3.10)
|
|
risk transfer.
(1)
transferring responsibility for managing a risk factor to another organization or functional entity better able to mitigate the risk factor
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
risk transference.
(1)
risk response strategy whereby the project team shifts the impact of a threat to a third party, together with ownership of the response
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
risk treatment.
(1)
process to eliminate risk or reduce it to a tolerable level
(ISO/IEC/IEEE 15026-1:2019 Systems and software engineering--Systems and software assurance--Part 1: Concepts and vocabulary, 3.3.11)
(2)
process to modify a risk
(ISO/IEC TR 7052:2023, Software engineering--Controlling frequently occurring risks during development and maintenance of custom software, 3.38)
Note: Risk treatment can create new risks or modify existing risks. Risk treatment that deals with negative consequences is sometimes referred to as risk mitigation, risk elimination, risk prevention or risk reduction. Risk treatment can involve avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk; taking or increasing risk in order to pursue an opportunity; removing the risk source; changing the likelihood of harm or damage; changing the consequences; sharing the risk with another party or parties, including contracts and risk financing; or retaining the risk based on an informed decision.
|
|
risk treatment measure.
(1)
action or means to eliminate hazards or reduce risks
(ISO/IEC 25059:2023, Software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model for AI systems, 3.1.4)
Syn: protective measure
|
|
risk trigger.
(1)
predetermined threshold value of a risk metric that triggers invocation of a contingency plan when the risk metric crosses the threshold
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
risk-adjusted backlog.
(1)
backlog that includes product work and actions to address threats and opportunities
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
risk-based testing.
(1)
testing in which the management, selection, prioritization, and use of testing activities and resources are consciously based on corresponding types and levels of analyzed risk
(ISO/IEC/IEEE 29119-2:2021, Software and systems engineering--Software testing--Part 2: Test processes, 3.16)
|
|
risk-free MARR.
(1)
minimum attractive rate of return (MARR) that has not been adjusted to address the risk in an alternative, because the risk is considered insignificant in the decision analysis
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
RJE.
(1)
remote job entry
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
RM-ODP.
(1)
Reference Model of Open Distributed Processing
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
(ISO/IEC 19793:2015 Information technology -- Open Distributed Processing -- Use of UML for ODP system specifications, 4)
(2)
Open Distributed Processing: Reference Model
(ISO/IEC 14752:2000 Information technology -- Open Distributed Processing -- Protocol support for computational interactions, 4)
|
|
RNG.
(1)
regular language for XML next generation
(ISO/IEC/IEEE 26531:2023 Systems and software engineering -- Content management for product lifecycle, user and service management information for users, 3.2)
|
|
roadmap.
(1)
detailed plan to guide progress towards a goal
(ISO/IEC/IEEE 26511:2018 Systems and software engineering--Requirements for managers of information for users of systems, software, and services, 3.1.25)
(2)
high-level timeline that depicts such things as milestones, significant events, reviews, and decision points
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
robot.
(1)
programmed actuated mechanism with a degree of autonomy, moving within its environment, to perform intended tasks
(ISO/IEC TR 29119-11:2020, Software and systems engineering--Software testing--Part 11: Guidelines on the testing of AI-based systems, 3.1.66)
Note: A robot includes the control system and interface of the control system. Robots can be classified into industrial robots or service robots, according to their intended application.
|
|
robotics.
(1)
techniques involved in designing, building, and using robots
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
|
|
robustness.
(1)
degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
degree to which an AI system can maintain its level of functional correctness under any circumstances
(ISO/IEC 25059:2023, Software engineering Systems and software Quality Requirements and Evaluation (SQuaRE) Quality model for AI systems, 3.2.5)
See Also: error tolerance, fault tolerance
|
|
ROC.
(1)
receiver operating characteristic
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
ROCOF.
(1)
rate of occurrence of failures
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
ROI.
(1)
return on investment
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
role.
(1)
participation of an entity in a relationship
(ISO/IEC 15474-1:2002 Information technology -- CDIF framework -- Part 1: Overview, 4.2)
(2)
defined function to be performed by a project team member, such as testing, filing, inspecting, coding
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(3)
expression of an object playing a part in a relationship
(ISO/IEC 15476-4:2005 Information technology--CDIF semantic metamodel--Part 4: Data models, 6.5)
(4)
formal placeholder in the specification of a composite object that identifies those aspects of the behavior of some component object required for it to form part of the composite and links them as constraints on an actual object in an instance of the composite
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 9.17)
|
|
role name.
(1)
name that more specifically names the nature of a related value class or state class
(ISO/IEC/IEEE 24765n:2025, 3.1.167)
(2)
name assigned to a foreign key attribute to represent the use of the foreign key in the entity
(ISO/IEC/IEEE 24765n:2025, 3.1.167)
Note: For a relationship, a role name is a name given to a class in a relationship to clarify the participation of that class in the relationship, that is, connote the role played by a related instance. For an attribute, a role name is a name used to clarify the sense of the value class in the context of the class for which it is a property.
|
|
role-based reviewing.
(1)
technique where reviewers review a work product from the perspective of different stakeholder roles
(ISO/IEC 20246:2017 Software and systems engineering -- Work product reviews, 3.16)
Note: Typical stakeholder roles include specific user types, such as work product maintainer, tester, and developer.
|
|
role-playing session.
(1)
technique of engagement including the relevant stakeholders in an interactive simulation of the dynamic interactions that are part of the system design
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
|
|
roll in.
(1)
to transfer data or computer program segments from auxiliary storage to main storage
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: roll out, swap
|
|
roll out.
(1)
to transfer data or computer program segments from main storage to auxiliary storage for the purpose of freeing main storage for other uses
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: roll in, swap
|
|
rolling wave planning.
(1)
iterative planning technique in which the work to be accomplished in the near term is planned in detail, while the work in the future is planned at a higher level
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
ROM.
(1)
read only memory
(ISO/IEC TR 29119-13:2022, Software and systems engineering Software testing Part 13: Using the ISO/IEC/IEEE 29119 series in the testing of biometric systems, 3.2)
|
|
root arrow segment.
(1)
arrow segment of a junction from which other arrow segments branch or to which other arrow segments join
(ISO/IEC/IEEE 24765m:2024, 2.1.99)
Syn: root, root segment
|
|
root cause.
(1)
source of a defect such that if it is removed, the defect is decreased or removed
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
|
|
root cause analysis.
(1)
analytical method used to determine the basic underlying reason that causes a variance or a defect or a risk
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
(2)
determination of the underlying cause(s) of a risk factor or problem
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Syn: root-cause analysis
|
|
root compiler.
(1)
compiler whose output is a machine independent, intermediate-level representation of a program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: A root compiler, when combined with a code generator, comprises a full compiler.
|
|
ROU.
(1)
responsible organizational unit
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
routine.
(1)
subprogram that is called by other programs and subprograms
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
function or procedure invocable for a single purpose
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
program, or part of a program, that has some general or frequent use
(ISO/IEC 2382:2015 Information technology -- Vocabulary)
Note: The terms 'routine,' 'subprogram,' and 'subroutine' are defined and used differently in different programming languages.
See Also: coroutine, subroutine
|
|
RPC.
(1)
Remote Procedure Call
(ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview)
|
|
RPO.
(1)
recovery point objective
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
RPP.
(1)
request for prototype proposal
(ISO/IEC/IEEE 41062:2024, Software engineering Life cycle processes Software acquisition, 3.2)
|
|
RS.
(1)
run start
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.2)
|
|
RSR.
(1)
recovery success rate
(IEEE 828-2012 IEEE Standard for Configuration Management in Systems and Software Engineering, 3.2)
|
|
RTC.
(1)
real-time clock
(ISO/IEC/IEEE 24765d:2015)
|
|
RTM.
(1)
requirements traceability matrix
(ISO/IEC/IEEE 24765:2017 Systems and software engineering--Vocabulary)
|
|
RTOS.
(1)
real-time operating system
(ISO/IEC/IEEE 24765c:2014)
|
|
rule.
(1)
constraint on a system specification
(ISO/IEC 10746-2:2009 Information technology -- Open Distributed Processing -- Reference Model: Foundations, 11.2.7)
(2)
single column through the condition and action entry parts of the decision table, defining a unique set of conditions to be satisfied and the actions to be taken in consequence
(ISO 5806:1984 Information processing -- Specification of single-hit decision tables, 3.4)
Note: A rule is satisfied if all conditions meet the condition entries of the rule.
|
|
rule-based language.
(1)
nonprocedural language that permits the user to state a set of rules and to express queries or problems that use these rules
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
See Also: declarative language, interactive language
|
|
RUM.
(1)
resource utilization measurement
(ISO/IEC 19770-4:2017 Information technology -- IT asset management -- Part 4: Resource utilization measurement, 3.8)
|
|
RUM creator.
(1)
entity that initially creates a RUM
(ISO/IEC 19770-4:2017 Information technology -- IT asset management -- Part 4: Resource utilization measurement, 3.9)
Example: The RUM creator can be the IT asset manufacturer or a third-party organization. The RUM creator can also be a separate software tool that is used to measure usage of an IT asset.
Syn: resource utilization measurement creator
|
|
run.
(1)
entire activation, execution, and shut-down cycle of a system of interest, however simple or complex its runtime architecture may be
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
(2)
to execute a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
in software engineering, a single, usually continuous, execution of a computer program
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
Note: When a system of interest is installed at multiple sites, each execution cycle at each site constitutes a distinct run. The use of "run" does not imply any limitation to batch or transactional execution technologies. The specific operational actions, system architecture, and software activation strategies of a run are system-specific.
See Also: run time
|
|
run time.
(1)
instant at which a computer program begins to execute
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(2)
period of time during which a computer program is executing
(ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)
(3)
stage that a member product is executed
(ISO/IEC 26557:2016 Software and systems engineering -- Methods and tools for variability mechanisms in software and systems product line, 3.11)
Syn: running time
See Also: execution time
|
|
runtime environment.
(1)
specific instance of a configuration of hardware and software, as provisioned for a specific operational environment, on which an installed system of interest runs
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
Note: A runtime environment includes executable application software, data stores, utility programs, locally hosted services, operating systems, network interfaces, and physical computer systems necessary for system of interest (SOI) execution, but not the SOI itself.
|
|
runtime platform.
(1)
set of hardware and software components that implement the services utilized by the application software
(ISO/IEC/IEEE 24765l:2024)
|
|
RUR.
(1)
Reference User Requirements
(ISO/IEC TR 14143-4:2002 Information technology -- Software measurement -- Functional size measurement -- Part 4: Reference model, 4)
|
|
RWD.
(1)
responsive web design
(ISO/IEC/IEEE 23026:2023 Systems and software engineering--Engineering and management of websites for systems, software, and services information, 3.1.20)
|
|
S-curve.
(1)
graph that displays cumulative costs over a specified period of time
(A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Seventh Edition)
|
|
SaaS.
(1)
software as a service
(IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1)
|
|
SACM.
(1)
structured assurance case metamodel
(ISO/IEC/IEEE 15026-2:2022, Systems and software engineering Systems and software assurance Part 2: Assurance case, 3.2)
|
|
SAD.
(1)
software architecture description
(ISO/IEC/IEEE 24748-8:2019, Systems and software engineering Life cycle management Part 7: Application of systems engineering on defense programs, 3.2)
|
|
SAF.
(1)
sensor availability flag
(IEEE 7005 2021, IEEE Standard for Transparent Employer Data Governance, 3.2)
|
|
safe integration.
(1)
capability of a product to maintain safety during and after integration with one or more components
(ISO/IEC 25010:2023, Systems and software engineering--Systems and software Quality Requirements and Evaluation (SQuaRE)--Product quality model, 3.9.5)
|
|
safety criteria.
(1)
limits of acceptable risk associated with a hazard
(ISO/IEC TS 33064:2025, Information technology Process assessment Process assessment model for safety processes, 3.3)
Note: These limits can be defined as imposed safety targets or developed from analysis or development policy.
|
|
safety demonstration.
(1)
body of evidence and rationale that shows an item is justified as being safe within allowed limits on risk
(ISO/IEC TS 33064:2025, Information technology Process assessment Process assessment model for safety processes, 3.4)
Example: that an item was designed and integrated correctly to approved standards by competent people in accordance with approved procedures with sufficient mitigation, and tested sufficiently
|
|
safety failure.
(1)
system behaviors or their absence, such that one or more requirements of the safety reliability class are not met
(IEEE 982:2024, Standard for Measures of the Software Aspects of Dependability, 3.1)
|
|
safety integrity requirement.
(1)
likelihood of a safety-related system satisfactorily performing the required safety functions under stated conditions
(ISO/IEC TS 33064:2025, Information technology Process assessment Process assessment model for safety processes, 3.5)
|
|
safety life cycle.
(1)
project or product life cycle in which safety processes are performed
(ISO/IEC TS 33064:2025, Information technology Process assessment Process assessment model for safety processes, 3.6)
|
|
safety note.
(1)
safety-related information that is collected or grouped in a document or section of a document in a meaningful organizational system to explain safety measures, raise safety awareness, and provide a basis for safety-related training of persons
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.33)
|
|
safety requirement.
(1)
requirement that is needed to help ensure the safety of the product
(ISO/IEC TS 33064:2025, Information technology Process assessment Process assessment model for safety processes, 3.7)
|
|
safety sign.
(1)
sign giving a general safety message, obtained by a combination of color and geometric shape and which, by the addition of a graphical symbol, gives a particular safety message
(IEC/IEEE 82079-1:2019 Preparation of information for use (instructions for use) of products: Part 1: Principles and general requirements, 3.34)
|
|
safety validation.
(1)
assurance, based on examination and tests, that the safety goals are sufficient and have been achieved
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.32)
|
|
safety-critical software.
(1)
software whose failure or malfunction can result in death or serious injury to people, loss of or severe damage to equipment or property, or damage to the natural environment
(ISO/IEC 29110-5-1-2:2025 Systems and software engineering Life cycle profiles for very small entities (VSEs) Part 5-1-2: Software engineering guidelines for the generic Basic profile, 3.27)
|
|
safety-critical system.
(1)
system whose failure or malfunction can result in one (or more) of the following outcomes: death or serious injury to people, loss or severe damage to equipment or property, or environmental harm
(ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.15)
Example: critical infrastructures, medical equipment, transportation, and nuclear power plants
Note: Software engineering for safety-critical systems emphasizes (1) process engineering and management; (2) selecting the appropriate tools and environment for the system; (3) adherence to requirements.
Syn: life-critical system, safety-critical product
|
|
SAIV.
(1)
schedule as independent variable
(Software Extension to the PMBOK(R) Guide Fifth Edition)
|
|
SAM.
(1)
software asset management
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.2)
|
|
SAM owner.
(1)
individual at a senior organization-wide level who is identified as being responsible for SAM
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.30)
|
|
SAM practitioner.
(1)
individual involved in the practice or role of managing software assets
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.31)
Note: A SAM practitioner is often involved in the collection or reconciliation of software inventory and software entitlements.
|
|
SAM program scope.
(1)
clear statement listing of all parts of the organization and types of software, assets, and platforms covered by a SAM program
(ISO/IEC 19770-5:2015 Information technology--IT asset management--Overview and vocabulary, 3.32)
|
|
SAM tool.
(1)
software used to assist in and automate parts of the process of management of software assets
(ISO/IEC 19770-3:2016 Information technology--IT asset management--Part 3: Entitlement schema, 3.1.25)
Syn: software asset management tool
|
|
SAMP.
(1)
strategic asset management plan
(ISO/IEC 19770-1:2017 Information technology -- IT asset management -- Part 1: IT asset management systems--Requirements, 3.53)
|
|
sample instance diagram.
(1)
form of presenting example instances in which instances are shown as separate graphic objects
(ISO/IEC/IEEE 24765n:2025, 3.1.169)
Note: The graphic presentation of instances can be useful when only a few instances are presented.
See Also: sample instance table
|