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.1B Eff. Date: April 18, 2013 Cancellation Date:	NASA Systems Engineering Processes and Requirements (Updated w/Change 4)
| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | ALL |

Appendix A. Definitions

Acceptable Risk: The risk that is understood and agreed to by the program/project, governing PMC, Mission Directorate, and other customer(s) 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.

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.

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

Customization: The modification of recommended SE practices that are used to accomplish the SE requirements. Examples of these practices are in Appendix C or in the NASA Systems Engineering Handbook, NASA/SP-2007-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.

Designated Governing Authority: The Center Director or the person that has been designated by the Center Director to ensure the appropriate level of technical management oversight. For large program/projects, this will usually be the identified Engineering Technical Authority. For small activities/projects, the DGA may be delegated to a line manager or other appropriate technical expert.

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.

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. An example is below in Figure A-1.

Figure A-1 - Enabling Product Relationship to End Products

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

Establish (with respect to each process in Chapter 3): Develop policy, work instructions, or procedures to implement process activities.

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

Federal Records: All books, papers, maps, photographs, machine-readable materials, 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: 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 manpower, personnel, training, human factors engineering, safety, health, habitability, and survivability are considered concurrently and integrated with all other systems engineering design activities.

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.

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 Projects (IP): Projects that build or maintain the institutional infrastructure to support the NASA missions.

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

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

Key Performance Parameters: Those capabilities or characteristics (typically engineering-based or related to health and 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.)

Leading Indicator: A measure for evaluating the effectiveness of how a specific activity is applied on a program 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 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 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.

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.

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

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

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 or scientific data, are captured, returned to Earth, processed, made available to users, and archived for future reference. The Operations Concept should describe how the flight system and ground system work together across mission phases for launch, cruise, critical activities, science observations, and end of mission to achieve the mission.

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 nonconcur with the contractors' decisions.

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's moving into a milestone review or approval cycle.

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.

Process Requirements: Requirements on people or organizations capturing functions, capabilities, or tasks that must be performed so that the entire system can meet the stakeholder expectations.

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. Each of these product layers 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 Director (MSOD) 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.

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 four Product Realization Processes. The form of this product is dependent on the phase of the product life cycle and the phase exit 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 exit criteria.

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

Remedial Action: Action taken to bring a product that has failed to meet a technical requirement into compliance; e.g., remove and replace failed item, rework to print.

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.

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.

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, Agency Risk Management Procedural Requirements.)

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: Computer programs, procedures, rules, and associated documentation and data pertaining to the development and operation of a computer system. Software also includes commercial off the shelf (COTS), Government off the shelf (GOTS), modified off the shelf (MOTS), embedded software, reuse, heritage, legacy, autogenerated code, firmware, and open source software components.

Specification: A document 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, 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, 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 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. Certification of spectrum support for telecommunication systems or subsystems at Stage 4 is a prerequisite for NTIA authorization to radiate. Tracking, telemetry, and telecommand operations for 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. There are two main classes of stakeholders. See "customers" 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.

Surveillance-Type Projects: A project where prime or external contractors do the majority of the development effort that requires NASA oversight and insight.

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

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.

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 Team: A multidisciplinary group of individuals with appropriate domain knowledge, experience, competencies, and skills assigned to a specific technical task.

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

Technical Requirements: The requirements that capture the characteristics, features, functions and performance that the end product must 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 safety, mission assets, or environment.

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