Appendix A. Definitions

A.1 Activity:

(1) Any of the project components or research functions that are executed to deliver a product or service or provide support or insight to mature technologies. (2) A set of tasks that describe the technical effort to accomplish a process and help generate expected outcomes.

A.2 Advanced Technology Development:

ATD is one of four interrelated NASA product lines. ATD programs and projects are investments that produce entirely new capabilities or that help overcome technical limitations of existing systems. ATD is seen as a bridge between BAR and actual application in NASA, such as FS&GS projects or elsewhere. ATD projects typically fall within a Technology Readiness Level (TRL) range of 4 to 6.

A.3 Baseline:

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

A.4 Basic and Applied Research:

Research whose results expand the knowledge base, provide scientific and technological breakthroughs that are immediately applicable, or evolve into an advanced technology development (ATD). Basic research addresses the need for knowledge, while applied research directs this new knowledge toward a practical application.

A.5 Component Facilities:

Complexes that are geographically separated from the NASA Center or institution to which they are assigned.

A.6 Contractor:

For the purposes of this NPR, a "contractor" is 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.

A.7 Critical Event

(also referred to as a Key Event in this NPR): An event that requires monitoring in the projected life cycle of a product that will generate critical requirements that would affect system design, development, manufacture, test, and operations (such as with an MOE, MOP, Technical Performance Measure (TPM), or KPP).

A.8 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.

A.9 Decision Authority:

The Agency's responsible individual who authorizes the transition at a KDP to the next life-cycle phase for a program/project.

A.10 Designated Governing Authority:

The management entity above the program, project, or activity level with technical oversight responsibility.

A.11 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. 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 project that is responsible for the end product can also be responsible for creating and using the enabling product.

A.12 Entry Criteria:

Minimum accomplishments each project needs to fulfill to enter into the next life-cycle phase or level of technical maturity.

A.13 Establish (with respect to each process in Chapter 3)

The act of developing policy, work instructions or procedures to implement process activities.

A.14 Exit Criteria

Specific accomplishments that should be satisfactorily demonstrated before a project can progress to the next product-line life-cycle phase.

A.15 Expectation:

Statements of needs, desires, capabilities and wants that are not expressed as a requirement (not expressed as a "shall" statement) is to be referred to as an "expectation." 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 (nonmeasurable) or quantitative (measurable) terms. Requirements are always stated in quantitative 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.

A.16 Flight Systems and Ground Support

FS&GS is one of four interrelated NASA product lines. FS&GS projects result in the most complex and visible of NASA investments. To manage these systems, the Formulation and Implementation phases for FS&GS projects follow the NASA project life-cycle model consisting of phases A (Concept Development) through F (Closeout). Primary drivers for FS&GS projects are safety and mission success.

A.17 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.

A.18 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.

A.19 Institutional Projects:

Projects that build or maintain the institutional infrastructure to support other NASA product lines.

A.20 Information Systems and Technology Projects:

All NASA projects for or including the development, modernization, enhancement, or steady-state operations of information systems and technologies. This includes projects for or containing computer and/or communications systems, ancillary equipment, hardware, software applications, firmware, or networks for the generation, processing, storage, access, manipulation, exchange or safeguarding of information.

A.21 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.")

A.22 Key Decision Point

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

A.23 Key Event:

See Critical Event.

A.24 Key Performance Parameters

Those capabilities or characteristics (typically engineering-based or related to safety or operational performance) considered most essential for successful mission accomplishment. Failure to meet a KPP threshold can be cause for the 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 project's KPPs are identified and quantified in the project baseline. (See Technical Performance Parameter.)

A.25 Logical Decomposition

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

A.26 Maintain

(with respect to establishment of processes in Chapter 3): The act of planning the process, providing resources, assigning responsibilities, training people, managing configurations, identifying and involving stakeholders, and monitoring process effectiveness.

A.27 Measure of Effectiveness

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

A.28 Measure of Performance:

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

A.29 Other Interested Parties:

A subset of "stakeholders," other interested parties are 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 have a responsibility for providing life-cycle support services. A subset of "stakeholders." (See Stakeholder.)

A.30 Peer Review:

Independent evaluation by internal or external subject matter experts who do not have a vested interest in the work product under review. Peer reviews can be planned, focused reviews conducted on selected work products by the producer's peers to identify defects and issues prior to that work product moving into a milestone review or approval cycle.

A.31 Process:

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

A.32 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).

A.33 Product-Based WBS Model:

See WBS model.

A.34 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.

A.35 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.

A.36 Program Commitment Agreement

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

A.37 Project

(1) 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, academia partnerships; or through contracts with private industry. (2) A unit of work performed in programs, projects, and activities.

A.38 Realized Product:

The desired output from the application of the four Product Realization Processes. The form of this product is dependent on the phase of the product-line life cycle and the phase exit criteria.

A.39 Recursive:

Value 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 exit criteria.

A.40 Relevant Stakeholder

See Stakeholder.

A.41 Repeatable:

A characteristic of a process that can be applied to products at any level of the system structure or within any life-cycle phase.

A.42 Requirement

The agreed upon need, desire, want, 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.

A.43 Risk:

The combination of the probability that a program or project will experience an undesired event (some examples include a cost overrun, schedule slippage, safety mishap, health problem, malicious activities, environmental impact, failure to achieve a needed scientific or technological breakthrough or mission success criteria) and the consequences, impact, or severity of the undesired event, were it to occur. Both the probability and consequences may have associated uncertainties. (Reference 7120.5.)

A.44 Software

As defined in NPD 2820.1, NASA Software Policy.

A.45 Specification

A document that prescribes, in a complete, precise, verifiable manner, the requirements, design, behavior, or characteristics of a system or system component.

A.46 Stakeholder

A group or individual who is affected by or is in some way accountable for the outcome of an undertaking. The term "relevant stakeholder" is a subset of the term "stakeholder" and describes people or roles that are designated in a plan for stakeholder involvement. Since "stakeholder" may describe a very large number of people, a lot of time and effort would be consumed by attempting to deal with all of them. For this reason, "relevant stakeholder" is used in most practice statements to describe the people identified to contribute to a specific task. There are two main classes of stakeholders. See "customers" and "other interested parties."

A.47 Success Criteria

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

A.48 Surveillance-Type Projects:

A project where prime or external contractors do the majority of the development effort that requires NASA oversight.

A.49 System

(a) The combination of elements that function together to produce the capabil-ity 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.) (b) The end product (which performs operational functions) and enabling products (which provide life-cycle support services to the operational end products) that make up a system. (See WBS definition.)

A.50 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.

A.51 Systems Engineering Engine:

The SE model shown in Figure 3-1 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 are applied to the products being engineered to drive the technical effort.

A.52 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.

A.53 System Safety Engineering

The application of engineering and management principles, criteria, and techniques to achieve acceptable mishap risk, within the constraints of operational effectiveness and suitability, time, and cost, throughout all phases of the system life cycle.

A.54 System Structure

A system structure is made up of a layered structure of product-based WBS models. (See WBS definition.)

A.55 Tailoring

The documentation and approval of the adaptation of the process and approach to complying with requirements underlying the specific program or projects. Tailoring considerations include system size and complexity, level of system definition detail, scenarios and missions, constraints and requirements, technology base, major risk factors, and organizational best practices and strengths. Critical project considerations (e.g., public safety, security, litigation exposures) may preclude tailoring out required process activities, regardless of cost, manpower available, or other considerations. (From Systems Engineering Fundamentals, Defense Acquisition University, January 2001.)

A.56 Technical Performance Measures:

The set of critical or key performance parameters 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).

A.57 Technical Team:

A group of multidisciplinary individuals with appropriate domain knowledge, experience, competencies, and skills assigned to a specific technical task.

A.58 Technology Readiness Level

Provides 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. Typically, a TRL of 6 (i.e., technology demonstrated in a relevant environment) is required for a technology to be integrated into an SE process.

A.59 Technical Risk:

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

A.60 Transition:

The act of delivery or moving of a product from the location where the product has been implemented or integrated, as well as verified and validated, to a customer. This act can include packaging, handling, storing, moving, transporting, installing, and sustainment activities.

A.61 Transition Process

In the context of this SE NPR, the Transition Process transfers a product to a customer higher in the system structure for assembly and integration into a higher level product or to the intended end use customer.

A.62 Validation (of a product):

Proof that the product accomplishes the intended purpose. Validation may be determined by a combination of test, analysis, and demonstration.

A.63 Validated Requirements

A set of requirements that are well-formed (clear and un-ambiguous), complete (agrees with customer and stakeholder needs and expectations), consistent (conflict free), and individually verifiable and traceable to a higher-level requirement or goal.

A.64 Verification (of a product>):

Proof of compliance with specifications. Verification may be determined by test, analysis, demonstration, and inspection.

A.65 Waiver:

A documented agreement intentionally releasing a program or project from meeting a requirement. (Some Centers use deviations prior to Implementation and waivers during Implementation).

A.66 WBS Model:

Model that describes a system that consists of end products and their subsystems (perform the operational functions of the system), the supporting or enabling products (for development; fabrication, assembly, integration, and test; operations; sustainment; and end-of-life product disposal or recycling), and any other work products (plans, baselines) required for the development of the system. See the example product-based WBS for an aircraft system and one of its subsystems (navigation subsystem) below:

Figure A-1 Product-Based WBS Model Example