NASA Procedures and Guidelines
This Document is Obsolete and Is No Longer Used. Check the NODIS Library to access the current version: http://nodis3.gsfc.nasa.gov
NPR 7123.1C Eff. Date: February 14, 2020 Cancellation Date:	NASA Systems Engineering Processes and Requirements (w/Change 2)
| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | ALL |

Appendix A. Definitions

Acceptable Risk: The risk that is understood and agreed to by the program/project, governing PMC, Mission Directorate, and other customers such that no further specific mitigating action is required. (Some mitigating actions might have already occurred.)

Activity: A set of tasks that describe the technical effort to accomplish a process and help generate expected outcomes.

Affordability: The practice of balancing system performance and risk with cost and schedule constraints over the system life, satisfying system operational needs in concert with strategic investment and evolving stakeholder value.

Approve (with respect to Technology Maturation Products from Appendix F): Used for a product, such as Concept Documentation, that is not expected to be put under classic configuration control but still requires that changes from the “approved” version are documented at each subsequent “update.”

Baseline: An agreed-to set of requirements, designs, or documents that will have changes controlled through a formal approval and monitoring process.

Baseline (with respect to Technology Maturation Products from Appendix F): Indicates putting the product under configuration control so that changes can be tracked, approved, and communicated to the team and any relevant stakeholders. The expectation on products labeled “baseline” is that they will be at least final drafts going into the designated review and baselined coming out of the review. Baselining a product does not necessarily imply that it is fully mature at that point in the life-cycle. Updates to baselined documents require the same formal approval process as the original baseline.

Bidirectional Traceability: The ability to trace any given requirement/expectation to its parent requirement/expectation and to its allocated children requirements/expectations.

Brassboard: A medium fidelity functional unit that typically tries to make use of as much of the final product as possible and begins to address scaling issues associated with the operational system. It does not have the engineering pedigree in all aspects but is structured to be able to operate in simulated operational environments in order to assess performance of critical functions

Breadboard: A low fidelity unit that demonstrates function only, without respect to form or fit. It often uses commercial and/or ad hoc components and is not intended to provide definitive information regarding operational performance.

Certification Package: The body of evidence that results from the verification activities and other activities such as reports, special forms, models, waivers, or other supporting documentation that is evaluated to indicate the design is certified for flight/use.

Component Facilities: Complexes that are geographically separated from the NASA Center or institution to which they are assigned but are still part of the Agency.

Concept of Operations (ConOps): Developed early in Pre-Phase A, describes the overall high-level concept of how the system will be used to meet stakeholder expectations, usually in a time sequenced manner. It describes the system from an operational perspective and helps facilitate an understanding of the system goals. It stimulates the development of the requirements and architecture related to the user elements of the system. It serves as the basis for subsequent definition documents and provides the foundation for the long-range operational planning activities (for nominal and contingency operations). It provides the criteria for the validation of the system. In cases where an Operations Concept (OpsCon) is developed, the ConOps feeds into the OpsCon and they evolve together. The ConOps becomes part of the Concept Documentation.

Construction of Facilities: A NASA corporate program that funds planning for future facility needs, design of facilities projects, revitalization projects (repair, rehabilitation, and modification of existing facilities), construction of new facilities, and acquisition of collateral equipment.

Contractor: For the purposes of this NPR, an individual, partnership, company, corporation, association, or other service having a contract with the Agency for the design, development, manufacture, maintenance, modification, operation, or supply of items or services under the terms of a contract to a program or project within the scope of this NPR. Research grantees, research contractors, and research subcontractors are excluded from this definition.

Corrective Action: Action taken on a product to correct and preclude recurrence of a failure or anomaly, e.g., design change, procedure change, personnel training.

Critical Event: An event in the operations phase of the mission that is time sensitive and is required to be accomplished successfully in order to achieve mission success. These events will be considered early in the life-cycle as drivers for system design.

Customer: The organization or individual that has requested a product and will receive the product to be delivered. The customer may be an end user of the product, the acquiring agent for the end user, or the requestor of the work products from a technical effort. Each product within the system hierarchy has a customer.

Customizing: The modification of recommended SE practices that are used to accomplish the SE requirements. Examples of these practices are in NASA/SP-2016-6105.

Decision Authority: The individual authorized by the Agency to make important decisions for programs and projects under their authority.

Derived Requirements: Requirements arising from constraints, consideration of issues implied but not explicitly stated in the high-level direction provided by Agency and Center institutional requirements or factors introduced by the selected architecture and design.

Deviation: A documented authorization releasing a program or project from meeting a requirement before the requirement is put under configuration control at the level the requirement will be implemented.

Documentation: Captured information and its support medium that is suitable to be placed under configuration control. Note that the medium may be paper, photograph, electronic storage (digital documents and models), or a combination thereof.

Enabling Products: The life-cycle support products and services (e.g., production, test, deployment, training, maintenance, and disposal) that facilitate the progression and use of the operational end product through its life-cycle. Since the end product and its enabling products are interdependent, they are viewed as a system. Program/project responsibility thus extends to responsibility for acquiring services from the relevant enabling products in each life-cycle phase. When a suitable enabling product does not already exist, the program/project that is responsible for the end product can also be responsible for creating and using the enabling product. An example is below in Figure A-1.

Figure A-1 – Enabling Product Relationship to End Products

Engineering Technical Authority: One of the three identified lines of technical authority (i.e., Engineering, Safety and Mission Assurance, and Health and Medical). ETA includes individuals who have been formally delegated Technical Authority that flows from the Administrator to the NASA Chief Engineer and to the Center Directors for further delegation to Center engineering leadership and individuals. These individuals are funded independent from a program or project and are a key part of NASA’s system of checks and balances that provides independent oversight of programs and projects in support of safety and mission success. The ETA establishes and is responsible for the engineering processes, specifications, rules, best practices, and other activities throughout the life-cycle, necessary to fulfill programmatic mission performance requirements. The ETA for the program or project leads and manages the engineering activities, including systems engineering, design, development, sustaining engineering, and operations.

Engineering Unit: A high fidelity unit that demonstrates critical aspects of the engineering processes involved in the development of the operational unit. Engineering test units are intended to closely resemble the final product (hardware/software) to the maximum extent possible and are built and tested so as to establish confidence that the design will function in the expected environments. In some cases, the engineering unit can become the final product, assuming proper traceability has been exercised over the components and hardware handling.

Entrance Criteria: Guidance for minimum accomplishments the program or project fulfills prior to a life-cycle review.

Expectation: A statement of needs, desires, capabilities, and wants that are not expressed as a requirement (not expressed as a “shall” statement). Once the set of expectations from applicable stakeholders is collected, analyzed, and converted into a “shall” statement, the “expectation” becomes a “requirement.” Expectations can be stated in either qualitative (non-measurable) or quantitative (measurable) terms. Expectations can be stated in terms of functions, behaviors, or constraints with respect to the product being engineered or the process used to engineer the product.

Federal Records: All books, papers, maps, photographs, machine-readable materials, digital models, or other documentary materials, regardless of physical form or characteristics, made or received by an agency of the U.S. Government under Federal law or in connection with the transaction of public business and preserved or appropriate for preservation by that agency or its legitimate successor as evidence of the organization, functions, policies, decisions, procedures, operations, or other activities of the Government or because of the informational value of the data in them.

Final (with respect to Technology Maturation Products from Appendix F): Applied to products that are expected to exist in a specified form (e.g., minutes and final reports).

Formulation Phase: The first part of the NASA management life cycle defined in NPR 7120.5, where system requirements are baselined, feasible concepts are determined, a system definition is baselined for the selected concept(s), and preparation is made for progressing to the Implementation phase.

Human Systems Integration (HSI): An interdisciplinary and comprehensive management and technical process that focuses on the integration of human considerations into the system acquisition and development processes to enhance human system design, reduce life-cycle ownership cost, and optimize total system performance. Human system domain design activities associated with operations, training, human factors engineering, safety, quality, maintainability and supportability, habitability, and survivability are considered concurrently and integrated with all other SE design activities.

Identify (with respect to identification of processes in Chapter 3): To either use an approved process or a customized process that is approved by the ETA or their delegate.

Implement (with respect to Implementation of processes in Chapter 3): To document and communicate the approved process, provide resources to execute the process, provide training on the process, and monitor and control the process.

Implementation Phase: The part of the NASA management life-cycle defined in NPR 7120.5, where the detailed design of system products is completed and the products to be deployed are fabricated, assembled, integrated, and tested and the products are deployed to their customers or users for their assigned use or mission.

Information Technology Plan: A plan that provides the Information System Description, which encompasses the complete set of interconnected IT systems, their subsystems and components, and the system dataset and log data. This plan includes the IT system configuration management, network diagram, the system interconnections, the data flow, the data type, and the data categorization/data tagging/metadata. This plan is a foundational element for the IT System Security Plan and facilitates correct reporting for the Federal Information Technology Acquisition Reform Act (FITARA). This plan is required for all programs and projects. It would include corporate IT, industrial control systems, and mission IT (including all computing systems, avionics buses, and other related components). For a space system the network diagram would include all IT nodes such as, but not limited to, the Launch Control Center, mission control center, data processing center(s), science operations center, and on-board system IT.

Information Technology System Security Plan: The formal document prepared by the information system owner (or common security controls owner for inherited controls) that provides an overview of the security requirements for the system and describes the security controls in place or planned for meeting those requirements. The plan can also contain as supporting appendices or as references, other key security-related documents such as a risk assessment, privacy impact assessment, system interconnection agreements, contingency plan, security configurations, configuration management plan, and incident response plan.

Initial (with respect to Technology Maturation Products from Appendix F): Applied to products that are continually developed and updated as the program or project matures.

Insight: An element of Government surveillance that monitors contractor compliance using Government-identified metrics and contracted milestones. Insight is a continuum that can range from low intensity, such as reviewing quarterly reports, to high intensity, such as performing surveys and reviews.

Institutional Authority: Institutional Authority encompasses all those organizations and authorities not in the Programmatic Authority. This includes Engineering, Safety and Mission Assurance, and Health and Medical organizations; Mission Support organizations; and Center Directors.

Iterative: Application of a process to the same product or set of products to correct a discovered discrepancy or other variation from requirements. (See Recursive and Repeatable.)

Joint Confidence Level: A process and product that helps inform management of the likelihood of a project’s programmatic success. The probability that cost will be equal to or less than the targeted cost and that schedule will be equal to or less than the targeted schedule date.

Key Decision Point (KDP): The event at which the Decision Authority determines the readiness of a program/project to progress to the next phase of the life cycle (or to the next KDP).

Key Performance Parameters (KPP): Those capabilities or characteristics (typically engineering-based or related to health and medical, safety, or operational performance) considered most essential for successful mission accomplishment. Failure to meet a KPP threshold can be cause for the program, project, system, or advanced technology development to be reevaluated or terminated or for the system concept or the contributions of the individual systems to be reassessed. A program/project’s KPPs are identified and quantified in the program/project baseline. (See Technical Performance Parameter.)

Laboratory Environment: An environment that does not address in any manner the environment to be encountered by the system, subsystem, or component (hardware or software) during its intended operation. Tests in a laboratory environment are solely for the purpose of demonstrating the underlying principles of technical performance (functions) without respect to the impact of environment.

Leading Indicator: A measure for evaluating the effectiveness of how a specific activity is applied on a program or project in a manner that provides information about impacts likely to affect the system performance objectives. A leading indicator may be an individual measure or collection of measures predictive of future system (and project) performance before the performance is realized. The goal of the indicators is to provide insight into potential future states to allow management to take action before problems are realized. A technical leading indicator is a subset of the Technical Performance Measures (TPMs) that provides insight into the potential future states.

Logical Decomposition: The decomposition of the defined technical requirements by functions, time, and behaviors to determine the appropriate set of logical and data architecture models and related derived technical requirements. Models may include functional flow block diagrams, timelines, data control flow, states and modes, behavior diagrams, operator tasks, system data, metadata, data standards, taxonomy, and functional failure modes.

Loosely Coupled Programs: Programs that address specific objectives through multiple space flight projects of varied scope. While each individual project has an assigned set of mission objectives, architectural and technological synergies and strategies that benefit the program as a whole are explored during the Formulation process. For instance, Mars orbiters designed for more than one Mars year in orbit are required to carry a communication system to support present and future landers.

Measure of Effectiveness (MOE): A measure by which a stakeholder’s expectations will be judged in assessing satisfaction with products or systems produced and delivered in accordance with the associated technical effort. An MOE is deemed to be critical to not only the acceptability of the product by the stakeholder but also critical to operational/mission usage. An MOE is typically qualitative in nature or not able to be used directly as a “design-to” requirement.

Measure of Performance (MOP): A quantitative measure that, when met by the design solution, will help ensure that an MOE for a product or system will be satisfied. MOPs are given special attention during design to ensure that the MOEs with which they are associated are met. There are generally two or more measures of performance for each MOE.

Operational Environment: The environment in which the final product will be operated. In the case of space flight hardware/software, it is space. In the case of ground-based or airborne systems that are not directed toward space flight, it will be the environments defined by the scope of operations. For software, the environment will be defined by the operational platform.

Operations Concept (OpsCon): Developed later in the life-cycle and baselined at PDR, a more detailed description of how the flight system and the ground system are used together to ensure that the concept of operation is reasonable. This might include how mission data of interest, such as engineering data, scientific data, and data standards/metadata are captured, returned to Earth, processed, made searchable, accessible, and available to users, and archived for future reference. The OpsCon should describe how the flight system and ground system work together across mission phases for planning, training, launch, cruise, critical activities, science observations, and end of mission to achieve the mission. This product should be informed by the ConOps and they should evolve together. They may exist as a single product or separate products.

Other Interested Parties: Groups or individuals that are not customers of a planned technical effort but may be affected by the resulting product, the manner in which the product is realized or used, or who have a responsibility for providing life-cycle support services. A subset of “stakeholders.” (See Stakeholder.)

Oversight: An element of Government surveillance that occurs in line with the contractor’s processes in which the Government retains and exercises the right to concur or non-concur with the contractor’s decisions.

Peer Review: See Peer Review in Appendix G, Table G-19.

Preliminary (with respect to Technology Maturation Products from Appendix F): The documentation of information as it stabilizes but before it goes under configuration control. It is the initial development leading to a baseline. Some products will remain in a preliminary state for multiple reviews. The initial preliminary version is likely to be updated at a subsequent review but remains preliminary until baselined.

Process: A set of activities used to convert inputs into desired outputs to generate expected outcomes and satisfy a purpose.

Product: A part of a system consisting of end products that perform operational functions and enabling products that perform life-cycle services related to the end product or a result of the technical efforts in the form of a work product (e.g., plan, baseline, or test result).

Product Layer: The end product is decomposed into a hierarchy of smaller and smaller products. The product layer is defined as a horizontal slice of this product breakdown hierarchy and includes both the end product and associated enabling products.

Product Realization: The act of making, buying, or reusing a product or the assembly and integration of lower level realized products into a new product, as well as the verification and validation that the product satisfies its appropriate set of requirements and the transition of the product to its customer.

Program: A strategic investment by a Mission Directorate (or mission support office) that has defined goals, objectives, architecture, funding level, and a management structure that supports one or more projects.

Program Commitment Agreement: The contract between the Administrator and the cognizant Mission Directorate Associate Administrator (MDAA) or Mission Support Office Directorate (MSOD) Associate Administrator for implementation of a program.

Project: A specific investment having defined goals, objectives, requirements, life-cycle cost, a beginning, and an end. A project yields new or revised products or services that directly address NASA’s strategic needs. They may be performed wholly in-house; by Government, industry, or academia partnerships; or through contracts with private industry.

Prototype Unit: The prototype unit demonstrates form, fit, and function at a scale deemed to be representative of the final product operating in its operational environment. A subscale test article provides fidelity sufficient to permit validation of analytical models capable of predicting the behavior of full-scale systems in an operational environment.

Radio Frequency Authorization: Given by the National Telecommunications and Information Administration (NTIA) for the use of radio frequency spectrum for radio transmissions for telecommunications or for other purposes.

Realized Product: The desired output from application of the five Product Realization Processes. The form of this product is dependent on the phase of the product life-cycle and the phase success criteria.

Recursive: Value that is added to the system by the repeated application of processes to design next lower layer system products or to realize next upper layer end products within the system structure. This also applies to repeating application of the same processes to the system structure in the next life-cycle phase to mature the system definition and satisfy phase success criteria.

Relevant Environment: Not all systems, subsystems, and/or components need to be operated in the operational environment in order to satisfactorily address performance margin requirements. Consequently, the relevant environment is the specific subset of the operational environment that is required to demonstrate critical “at risk” aspects of the final product performance in an operational environment. It is an environment that focuses specifically on “stressing” the technology advance in question.

Relevant Stakeholder: A subset of the term “stakeholder” that applies to people or roles that are designated in a plan for stakeholder involvement. Since “stakeholder” may describe a very large number of people, attempting to deal with all of them might require unnecessary time and effort. For this reason, “relevant stakeholder” is used in most practice statements to describe the people identified to contribute to a specific task.

Repeatable: In the context of systems engineering, a repeatable process is a characteristic that can be applied to products at any level of the system structure or within any life-cycle phase.

Request for Action/Review Item Discrepancy (RFA/RID): The most common names for the comment forms that reviewers submit during life-cycle reviews that capture their comments, concerns, and/or issues about the product or documentation. Each Center defines their own RFA/RID disposition process.

Requirement: The agreed upon need, capability, capacity, or demand for personnel, equipment, facilities, or other resources or services by specified quantities for specific periods of time or at a specified time expressed as a “shall” statement. Acceptable form for a requirement statement is individually clear, correct, feasible to obtain, unambiguous in meaning, and can be validated at the level of the system structure at which stated. In pairs of requirement statements or as a set, collectively, they are not redundant, are adequately related with respect to terms used, and are not in conflict with one another.

Review Trends: Metrics that show how the identified life-cycle and technical reviews are progressing such as tracking the closure of action items, RIDs, or RFAs throughout the life-cycle.

Risk: In the context of mission execution, the potential for performance shortfalls, which may be realized in the future, with respect to achieving explicitly established and stated performance requirements. The performance shortfalls may be related to any one or more of the following mission execution domains: (1) safety, (2) technical, (3) cost, and (4) schedule. (See NPR 8000.4.)

Single Point Failure: An independent element of a system (hardware, software, or human), the failure of which would result in loss of objectives, hardware, or crew.

Single-Project Programs: Programs that tend to have long development and/or operational lifetimes, represent a large investment of Agency resources, and have contributions from multiple organizations/agencies. These programs frequently combine program and project management approaches, which they document through tailoring.

Software: In this directive, “software” is defined as (1) computer programs, procedures and possibly 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 system; (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 software, and open-source software components. This definition applies to software developed by NASA, software developed for NASA, commercial-off-the-shelf (COTS) software, Government-off-the-shelf (GOTS) software, modified-off-the-shelf (MOTS) software, reused software, auto-generated code, embedded software, the software executed on processors embedded in Programmable Logic Devices (see NASA-HDBK-4008), and open-source software components.

Specification: A document or data that prescribes, in a complete, precise, verifiable manner, the requirements, design, behavior, or characteristics of a system or system component. In this document, specification is treated as a requirement.

Spectrum Certification: A program or project obtains certification by the NTIA (located within the Department of Commerce) that the radio frequency required can be made available before a program or project submits estimates for the development or procurement of major radio spectrum-dependent communication-electronics systems (including all systems employing space satellite techniques).

Spectrum Certification Stage 1, Conceptual: The initial planning effort has been completed, including proposed frequency bands and other available characteristics. Certification of spectrum support for telecommunication systems or subsystems at Stage 1 provides guidance, from the NTIA, on the feasibility of obtaining certification of spectrum support at subsequent stages. The guidance provided will indicate any modifications, including more suitable frequency bands, necessary to assure conformance with the NTIA Manual. (Refer to NPR 2570.1.)

Spectrum Certification Stage 2, Experimental: The preliminary design has been completed and radiation impact assessment, using such things as test equipment or preliminary models may be required. Certification of spectrum support for telecommunication systems or subsystems at Stage 2 is a prerequisite for NTIA authorization of radiation in support of experimentation for systems. It also provides guidance for assuring certification of spectrum support at subsequent stages. (Refer to NPR 2570.1.)

Spectrum Certification Stage 3, Developmental: The major design has been completed, and radiation impact assessment may be required during testing. Certification of spectrum support for telecommunication systems or subsystems at Stage 3 is a prerequisite for NTIA authorization of radiation in support of developmental testing for systems. It also provides guidelines for assuring certification of spectrum support at Stage 4. At this point, the intended frequency band will have been determined and certification at Stage 3 will be required for testing of proposed operational hardware and potential equipment configurations. (Refer to NPR 2570.1.)

Spectrum Certification Stage 4, Operational: Development has been essentially completed, and final operating constraints or restrictions required to assure compatibility need to be identified. Certifying spectrum support for major telecommunication systems or subsystems at Stage 4 is a prerequisite for NTIA authorization to radiate. Tracking, telemetry, and telecommand operations for major satellite networks require NTIA Stage 4 certification of spectrum support before the launch of the spacecraft. Stage 4 certification provides restrictions on the operation of the system or subsystem as may be necessary to prevent harmful interference. (Refer to NPR 2570.1.)

Stakeholder: A group or individual who is affected by or has an interest or stake in a program or project. See “Customer,” “Relevant Stakeholder,” and “Other Interested Parties.”

Success Criteria: Specific accomplishments that need to be satisfactorily demonstrated to meet the objectives of a life-cycle and technical review so that a technical effort can progress further in the life-cycle. Success criteria are documented in the corresponding technical review plan.

System: The combination of elements that function together to produce the capability required to meet a need. The elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose. (Refer to NPR 7120.5.)

Systems Approach: The application of a systematic, disciplined engineering approach that is quantifiable, recursive, iterative, and repeatable for the development, operation, and maintenance of systems integrated into a whole throughout the life-cycle of a project or program.

Systems Engineering Engine: The NASA SE model shown in Figure 3-1 that provides the 17 technical processes and their relationship with each other. The model is called an “SE Engine” in that the appropriate set of processes is applied to the products being engineered to drive the technical effort.

Systems Engineering Management Plan: The SEMP identifies the roles and responsibility interfaces of the technical effort and how those interfaces will be managed. The SEMP is the vehicle that documents and communicates the technical approach, including the application of the common technical processes; resources to be used; and key technical tasks, activities, and events along with their metrics and success criteria.

System of Interest: The system whose characteristics are under consideration regardless of where it lies in the product hierarchy.

System Safety: The application of engineering and management principles, criteria, and techniques to optimize safety within the constraints of operational effectiveness, time, and cost throughout all phases of the system life-cycle.

Tailoring: The process used to seek relief from SE NPR requirements consistent with program or project objectives, allowable risk, and constraints. The tailoring process results in the generation of deviations and waivers depending on the timing of the request.

Technical Authority: Part of NASA’s system of checks and balances that provides independent oversight of programs and projects in support of safety and mission success through the selection of individuals at delegated levels of authority. These individuals are the Technical Authorities. Technical Authority delegations are formal and traceable to the Administrator. Individuals with Technical Authority are funded independently of a program or project. TA originates with the Administrator and is formally delegated to the NASA AA and then to the NASA Chief Engineer for Engineering Technical Authority; the Chief, Safety and Mission Assurance for SMA Technical Authority; the NASA Chief Health and Medical Officer for Health and Medical Technical Authority; and then to the Center Directors.

Technical Performance Measures: The set of performance measures that are monitored by comparing the current actual achievement of the parameters with that anticipated at the current time and on future dates. Used to confirm progress and identify deficiencies that might jeopardize meeting a system requirement. Assessed parameter values that fall outside an expected range around the anticipated values indicate a need for evaluation and corrective action. Technical performance measures are typically selected from the defined set of Measures of Performance (MOPs).

Technical Requirements: The requirements that capture the characteristics, features, functions and performance that the end product will have to meet stakeholder expectations.

Technical Risk: Risk associated with the achievement of a technical goal, criterion, or objective. It applies to undesired consequences related to technical performance, human health and medical, safety, mission assets, or environment.

Technical Team: Members of a multidisciplinary team responsible for defining and implementing the technical aspects of a program or project.

Technology Readiness Level: A scale against which to measure the maturity of a technology. TRLs range from 1 (Basic Technology Research) to 9 (Systems Test, Launch, and Operations).

Tightly Coupled Programs: Programs with multiple projects that execute portions of a mission(s). No single project is capable of implementing a complete mission. Typically, multiple NASA Centers contribute to the program. Individual projects may be managed at different Centers. The program may also include other agency or international partner contributions.

Transition: The act of delivery or moving a product from one location to another location. This act can include packaging, handling, storing, moving, transporting, installing, and sustainment activities.

Uncoupled Programs: Programs implemented under a broad theme and/or a common program implementation concept, such as providing frequent flight opportunities for cost-capped projects selected through AO or NASA Research Announcements. Each such project is independent of the other projects within the program.

Update (with respect to Technology Maturation Products from Appendix F): Applied to products that are expected to evolve as the formulation and implementation processes evolve. Only expected updates are indicated. However, any document may be updated as needed.

Validation (of a product): The process of showing proof that the product accomplishes the intended purpose based on stakeholder expectations and the Concept of Operations. May be determined by a combination of test, analysis, demonstration, and inspection. (Answers the question, “Am I building the right product?”)

Validation (of requirements): The continuous process of ensuring that requirements are well-formed (clear and unambiguous), complete (agrees with customer and stakeholder needs and expectations), consistent (conflict free), and individually verifiable and traceable to a higher level requirement or goal. (Answers the question, “Will I build the right product?”)

Verification (of a product): Proof of compliance with requirements/specifications. Verification may be determined by test, analysis, demonstration, inspection, or a combination thereof. (Answers the question, “Did I build the product right?”)

Waiver: A documented authorization releasing a program or project from meeting a requirement after the requirement is put under configuration control at the level the requirement will be implemented.

DISTRIBUTION:
NODIS