Search Results

44 results were found.

verification. (1) confirmation, through the provision of objective evidence, that specified requirements have been fulfilled (ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.43) (ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.72) (ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.55) (2) evaluation of whether or not a product, service, or system complies with a regulation, requirement, specification, or imposed condition (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Eighth Edition) (3) process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase (IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1.36) (4) process of providing objective evidence that the system, software, or hardware and its associated products conform to requirements (e.g., for correctness, completeness, consistency, and accuracy) for all life cycle activities during each life cycle process (acquisition, supply, development, operation, and maintenance), satisfy standards, practices, and conventions during life cycle processes, and successfully complete each life cycle activity and satisfy all the criteria for initiating succeeding life cycle activities (IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1) (5) confirmation in a timely manner, using automated techniques where possible, through the provision of objective evidence, that specified requirements have been fulfilled (IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1) Note: Verification is a set of activities that compares a system or system element to the required characteristics. This can include, but is not limited to, specified requirements, design description, and the system itself. The system has been built right. "Verified" is used to designate the corresponding status. Verification of interim work products is essential for proper understanding and assessment of the life cycle phase products. A system can be verified to meet the stated requirements, yet be unsuitable for operation by the actual users. See Also: validation

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)

verification and validation (V&V) effort. (1) work associated with performing the V&V processes, activities, and tasks (IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1.37)

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)

verification method. (1) method for producing objective evidence that specified requirements of a system have been fulfilled (ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.34) (2) a method that tests an FSM method, and provides objective evidence of the extent to which a particular performance property is exhibited (ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.1) Note: Verification of an FSM method typically produces a result that indicates the extent to which a performance property is exhibited, or whether a performance property is exhibited to a stated extent. For this reason, there is no concept of "pass" or "fail". An FSM method can be considered to be either "verified" or "not verified", for a particular performance property, based on whether or not the appropriate verification has been conducted.

verification sponsor. (1) the person or organization that requires the verification to be performed and provides financial or other resources to carry it out (ISO/IEC TR 14143-3:2003 Information technology -- Software measurement -- Functional size measurement -- Part 3: Verification of functional size measurement methods, 3.11)

verification and validation (V&V). (1) process of determining whether the requirements for a system or component are complete and correct, the products of each development phase fulfill the requirements or conditions imposed by the previous phase, and the final system or component complies with specified requirements (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: independent verification and validation

software design verification. (1) evaluation of a design to determine correctness with respect to stated requirements, conformance to design standards, system efficiency, and other criteria (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary)

software requirements verification. (1) process of ensuring that the software requirements specification complies with the system requirements, conforms to document standards of the requirements phase, and is an adequate basis for the architectural (preliminary) design phase (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: requirements verification, requirements validation

verification test. (1) test of a system to prove that it meets all its specified requirements at a particular stage of its development (ISO/IEC 2382:2015 Information technology -- Vocabulary)

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

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)

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)

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)

semi-formal verification. (1) method based on a description given in semi-formal notation (ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.18)

target of verification (TOV). (1) software or a set of software items or units to be verified, e.g. in terms of safety and security (ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.26)

verification tool. (1) instrument that can be used during verification to collect information about the target of verification, to interpret information, or to automate part of the verification (ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.35)

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)

validation. (1) confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled (ISO/IEC 25000:2014 Systems and software Engineering--Systems and software product Quality Requirements and Evaluation (SQuaRE) -- Guide to SQuaRE, 4.41) (ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.71) (2) process of providing evidence that the system, software, or hardware and its associated products satisfy requirements allocated to it at the end of each life cycle activity, solve the right problem (e.g., correctly model physical laws, implement business rules, and use the proper system assumptions), and satisfy intended use and user needs (IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1.35) (3) assurance that a product, service, or system meets the needs of the customer and other identified stakeholders (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Eighth Edition) (4) confirmation in a timely manner, through automated techniques where possible, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled (IEEE 2675-2021, IEEE Standard for DevOps: Building Reliable and Secure Systems Including Application Build, Package, and Deployment, 3.1) Note: Validation in a system life cycle context is the set of activities for gaining confidence that a system is able to accomplish its intended use, goals, and objectives (meet stakeholder requirements) in the intended operational environment. The right system has been built or is operating to meet business objectives. Validation demonstrates that the system can be used by the users for their specific tasks. "Validated" is used to designate the corresponding status. See Also: verification

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)

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)

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)

traceability. (1) discernible association among two or more logical entities, such as requirements, system elements, verifications, or tasks (ISO/IEC/IEEE 15288:2023 Systems and software engineering--System life cycle processes, 3.52) (2) degree to which a relationship can be established among two or more logical entities, especially entities having a predecessor-successor relationship to one another, such as requirements, system elements, verifications, or tasks (ISO/IEC/IEEE 12207:2026 Systems and software engineering--Software life cycle processes, 3.1.69) (3) degree to which each element in a software development product establishes its reason for existing (ISO/IEC TR 18018:2010 Information technology--Systems and software engineering--Guide for configuration management tool capabilities, 3.14) (4) degree to which the IT service outcomes can be traced to or from the user needs (ISO/IEC TS 25011:2017 Information technology--Systems and software Quality Requirements and Evaluation (SQuaRE)--Service quality models, 3.2.3.3) Example: the degree to which the requirements and design of a given system element match, the degree to which each element in a bubble chart references the requirement that it satisfies Note: Software features and test cases are typically traced to software requirements.

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:2026, Systems and software engineering -- Life cycle management -- Part 7: Application of systems engineering on defence programs, 3.1.1) See Also: developmental configuration, functional baseline, product baseline, allocated configuration identification

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

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

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

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

software testing. (1) activity in which a system or component is executed under specified conditions, the results are observed or recorded, and an evaluation is made of some aspect of the system or component (IEEE 730-2014 IEEE Standard for Software Quality Assurance Processes, 3.2) (2) dynamic verification that a program provides expected behaviors on a finite set of test cases, suitably selected from the usually infinite executions domain (ISO/IEC TR 19759:2016 Software Engineering -- Guide to the Software Engineering Body of Knowledge (SWEBOK), 4)

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:2026, Systems and software engineering -- Life cycle management -- Part 7: Application of systems engineering on defence programs, 3.1.5) See Also: allocated baseline, developmental configuration, product baseline

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

V&V. (1) verification and validation (IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2) Syn: V & V

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)

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)

software requirements engineering. (1) science and discipline concerned with analyzing and documenting software requirements (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) (2) software requirements elicitation, analysis, specification, verification, and management (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) Note: It involves transforming system requirements into a description of software requirements, performance parameters, and a software configuration using an iterative process of definition, analysis, trade-off studies, and prototyping. See Also: requirements engineering

software requirements management. (1) process of planning and controlling the identification, allocation, and flow-down of requirements from the system level to the module or part level, including interfaces, verification, modifications, and status monitoring (ISO/IEC/IEEE 24765:2017 Systems and software engineering-Vocabulary) See Also: requirements management

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

test traceability matrix. (1) document, spreadsheet, or other automated tool used to identify related items in documentation and software, such as requirements with associated tests (ISO/IEC/IEEE 29119-3:2021 Software and systems engineering--Software testing--Part 3: Test documentation, 3.26) Note: Different test traceability matrices can have different information, formats, and levels of detail. Syn: verification cross reference matrix, requirements test matrix, requirements verification table See Also: traceability matrix

VVP. (1) verification and validation plan (IEEE 1012-2024 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.2)

TOV. (1) target of verification (ISO/IEC 23643:2020, Software and systems engineering--Capabilities of software safety and security verification tools, 3.26)

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)

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 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