Terms

1.  measurable qualitative or quantitative attribute that is stipulated for a requirement and that indicates a circumstance or event under which a requirement applies
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
3. true or false logical predicate
4. logical predicate involving one or more behavior model elements
5. Boolean expression containing no Boolean operators. 

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 

2. component of infrastructure or an item that is or will be under control of configuration management

3. aggregation of work products that is designated for configuration management and treated as a single entity in the configuration management process

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

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. (Source IEEE Definition)

When software assurance or software safety personnel perform the specified software assurance and software safety activities themselves.

1.  occurrence of a particular set of circumstances
2. external or internal stimulus used for synchronization purposes
3. change detectable by the subject software
4. fact that an action has taken place
5. singular moment in time at which some perceptible phenomenological change (energy, matter, or information) occurs at the port of a unit. 

[1] Item or function that must retain its operational capability to assure no mission failure (i.e., for mission success).

[2] An item or function, the failure of which may result in the inability to retain operational capability for mission continuation if corrective action is not successfully performed. (Source NASA-STD-8729.1

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

(2) collect project performance data with respect to a plan, process, produce performance measures and report and disseminate performance information.

Software assurance does the action specified. Perform may include making comparisons of independent results with similar activities performed by engineering; performing audits; and reporting results to engineering.

(1) selective retesting of a system or component to verify that modifications have not caused unintended effects and that the system or component still complies with its specified requirements (2) testing following modifications to a test item or its operational environment, to identify whether regression failures occur. (Source IEEE Definition)

The combination of (1) the probability (qualitative or quantitative) of experiencing an undesired event, (2) the consequences, impact, or severity that would occur if the undesired event were to occur, and (3) the uncertainties associated with the probability and consequences. (Source NPR 8715.3) 

A risk is an uncertain future event or combination of events, that could threaten the achievement of performance objectives or requirements. A "problem," on the other hand, describes an issue that is certain or near certain to exist now, or an event that has been determined with certainty or near certainty to have occurred and is threatening the achievement of an objective or requirement. It is generally at the discretion of the decision authority to define at what level of certainty (i.e., likelihood) an event may be classified and addressed as a “problem” rather than as a “risk.” A risk may be conditional upon a problem, i.e., an existing issue may or may not develop into performance-objective consequences or the extent to which it may be at present uncertain.

Freedom from those conditions that can cause death, injury, occupational illness, damage to or loss of equipment or property, or damage to the environment. In a risk-informed context, safety is an overall mission and program condition that provides sufficient assurance that accidents will not result from the mission execution or program implementation, or, if they occur, their consequences will be mitigated. This assurance is established by means of the satisfaction of a combination of deterministic criteria and risk criteria. (Source NPR 8715.3)

1. Causes or contributes to a system hazardous condition/event,
2. Provides control or mitigation for a system hazardous condition/event,
3. Controls safety-critical functions,
4. Mitigates damage if a hazardous condition/event occurs,
5. Detects, reports, and takes corrective action if the system reaches a potentially hazardous state.

defined as: 

(1) computer programs, procedures, and associated documentation and data pertaining to the operation of a computer system

(2) all or a part of the programs, procedures, rules, and associated documentation of an information processing

(3) program or set of programs used to run a computer

(4) all or part of the programs which process or support the processing of digital information

(5) part of a product that is the computer program or the set of computer programs.

This definition applies to software developed by NASA, software developed for NASA, software maintained by or for NASA, Commercial-Off-The-Shelf (COTS), Government-Off-The-Shelf (GOTS), Modified-Off-The-Shelf (MOTS), Open Source Software (OSS), reused software components, auto-generated code, embedded software, the software executed on processors embedded in programmable logic devices (see NASA-HDBK-4008), legacy, heritage, applications, freeware, shareware, trial or demonstration software, and OSS components.

(1) a set of activities that assess adherence to, and the adequacy of the software processes used to develop and modify software products. Software assurance also determines the degree to which the desired results from software quality control are being obtained.

(2) set of activities that define and assess the adequacy of software processes to provide evidence that establishes confidence that the software processes are appropriate for and produce software products of suitable quality for their intended purposes. (Source IEEE Definition)

Note: A key attribute of software assurance is the objectivity of the software assurance function with respect to the project.

1. Totality of activities required to provide cost-effective support to a software system.
2. Entitlement of additional rights (such as additional functionality, upgrade, or support) for a previously granted software entitlement. 
3. A set of services a Publisher can sell to a Customer for the ongoing development and delivery of software bug fixes and product upgrades.

1. Separately compilable piece of code.
2. The lowest element in one or more software components.

(1) confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled

(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

(3) the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders

(4) process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements

(5) 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. (Source IEEE Definition)

Note: Validation in a system life cycle context is the set of activities ensuring and 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. Multiple Validation can be carried out if there are different intended uses. 

1. The estimated amount or percentage by which an observed or calculated value may differ from the true value.
2. A broad and general term used to describe an imperfect state of knowledge or a variability resulting from a variety of factors including, but not limited to, lack of knowledge, the applicability of information, physical variation, randomness or stochastic behavior, indeterminacy, judgment, and approximation. (Source: NPR 8000.4).

1. Testing of individual routines and modules by the developer or an independent tester (ISO/IEC/IEEE 24765). 
2. A test of individual programs or modules in order to ensure that there are no analysis or programming errors (ISO/IEC 2382-20). 
3. Test of individual hardware or software units or groups of related units. (ISO/IEC/IEEE 24765). 

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:2017 Systems and software engineering--Software life cycle processes, 3.1.71) (ISO/IEC/IEEE 15288:2015 Systems and software engineering--System life cycle processes, 4.1.53) (ISO/IEC TS 24748-1:2016 Systems and software engineering--Life cycle management--Part 1: Guide for life cycle management, 2.61).
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-2017 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1.35).
3. the assurance that a product, service, or system meets the needs of the customer and other identified stakeholders. It often involves acceptance and suitability with external customers. (A Guide to the Project Management Body of Knowledge (PMBOK(R) Guide) -- Fifth Edition) (4) process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements (IEEE 1012-2017 IEEE Standard for System, Software, and Hardware Verification and Validation, 3.1) Note: Validation in a system life cycle context is the set of activities ensuring and gaining confidence that a system is able to accomplish its intended use, goals, and objectives. The right system has been built. Validation demonstrates that the system can be used by the users for their specific tasks. "Validated" is used to designate the corresponding status. [ISO 9000:2005] Multiple validations can be carried out if there are different intended uses.