![[NASA Logo]](../Images/nasaball.gif) |
NASA Procedures and Guidelines |
||||
This Document is Obsolete and Is No Longer Used.
|
|||||
|
|
|||||
|
|
||||
| | TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | ALL | | |||||
3.1.1 This chapter establishes the core set of common technical processes and requirements to be used by NASA programs or projects in engineering system products during all life-cycle phases to meet phase success criteria and program/project objectives. The 17 common technical processes are enumerated according to their description in this chapter and their interactions shown in Figure 3-1. This SE common technical processes model illustrates the use of:
a. System design processes for "top-down" design of each product in the system structure.
b. Product realization processes for "bottom-up" realization of each product in the system structure.
c. Cross-cutting technical management processes for planning, assessing, and controlling the implementation of the system design and product realization processes and to guide technical decision making (decision analysis).
3.1.2 The SE common technical processes model is referred to as an "SE engine" in this NPR to stress that these common technical processes are used to drive the development of the system products and associated work products required by management to satisfy the applicable product life-cycle phase success criteria while meeting stakeholder expectations within cost, schedule, and risk constraints.
3.1.3 This chapter identifies the following for each of the 17 common technical processes:
a. The specific requirement for Program/Project Managers to identify and implement (as defined in Section 3.2.1) the ETA-approved process.
b. A brief description of how the process is used as an element of the Systems Engineering Engine.
3.1.4 Typical practices for each process are identified in NASA/SP-2016-6105, where each process is described in terms of purpose, inputs, outputs, and activities. It should be emphasized that the practices documented in the handbook do not represent additional requirements that need to be executed by the technical team but provide best practices associated with the 17 common technical processes. As the technical team develops a tailored and customized approach for the application of these processes, sources of SE guidance and technical standards, such as NASA/SP-2016-6105 and endorsed industry standards, should be considered. Appendix I provides a list of NASA and endorsed military and industry standards applicable to Systems Engineering and available on the NASA Technical Standards System, found at https://standards.nasa.gov/endorsed_standards, and should be applied as appropriate for each program or project. For additional guidance on mapping HSI into the SE Engine, refer to NASA/SP-2015-3709, Section 3.0.
Figure 3 1 - Systems Engineering (SE) Engine
3.1.5 The context in which the common technical processes are used is provided below: (Refer to "The Common Technical Processes and the SE Engine" in NASA/SP-2016-6105 for further information.)
3.1.5.1 The common technical processes are applied to each product layer to concurrently develop the products that will satisfy the operational or mission functions of the system (end products) and that will satisfy the life-cycle support functions of the system (enabling products). In this document, a product layer is a horizontal slice of the product breakdown hierarchy and includes both the end product and its associated enabling products. The enabling products facilitate the activities of system design, product realization, operations and mission support, sustainment, and end-of-product-life disposal or recycling by having the products and services available when needed.
3.1.5.2 The common technical processes are applied to design a system solution definition for each product layer down and across each level of the system structure and to realize the product layer end products up and across the system structure. Figure 3-2 illustrates how the three major sets of processes of the Systems Engineering (SE) Engine (system design processes, product realization processes, and technical management processes) are applied to each product layer within a system structure.
Figure 3-2 - Application of SE Engine Common Technical Processes
Within System Structure
3.1.5.3 The common technical processes are used to define the product layers of the system structure in each applicable phase of the relevant life-cycle to generate work products and system products needed to satisfy the success criteria of the applicable phase. Figure 3-3 depicts the sequencing of the processes.
Figure 3-3 - Sequencing of the Common Technical Processes
3.1.5.4 There are four system design processes applied to each product-based product layer from the top to the bottom of the system structure:
a. Stakeholder Expectation Definition.
b. Technical Requirements Definition.
c. Logical Decomposition.
d. Design Solution Definition. (See Figure 3-1 and Figure 3-2.)
3.1.5.5 During the application of these four processes to a product layer, it is expected that there will be a need to apply activities from other processes yet to be completed and to repeat process activities already performed to arrive at an acceptable set of requirements and solutions. There also will be a need to interact with the technical management processes to aid in identifying and resolving issues and making decisions between alternatives. For software products, the technical team ensures that the process executions comply with NPR 7150.2, software design requirements. The technical team also ensures that human capabilities and limitations are understood and how those human capabilities or limitations impact the hardware and software of any given system in terms of design. Refer to NASA/SP-2015-3709.
3.1.5.6 There are five product realization processes. Four of the product realization processes are applied to each end product of a product layer from the bottom to the top of the system structure:
a. Either Product Implementation for the lowest level or Product Integration for subsequent levels.
b. Product Verification.
c. Product Validation.
d. Product Transition. (See Figure 3-1 and Figure 3-2.)
3.1.5.7 The form of the end product realized will depend on the applicable product life-cycle phase, location within the system structure of the product layer containing the end product, and the success criteria of the phase. Typical early phase products are reports, models, simulations, mockups, prototypes, or demonstrators. Typical later phase products may take the form of qualification units, final mission products, and fully assembled payloads and instruments.
3.1.5.8 There are eight technical management processes—Technical Planning, Technical Requirements Management, Interface Management, Technical Risk Management, Configuration Management, Technical Data Management, Technical Assessment, and Decision Analysis. (See Figure 3-1 and Figure 3-2.) These technical management processes supplement the program and project management directives (e.g., NPR 7120.5), which specify the technical activities for which program and project managers are responsible.
3.1.5.9 Note that during the design and realization phases of a project, all 17 processes are used. After the end product is developed and placed into operations the Technical Management processes in the center chamber of the SE Engine will continue to be employed. For more information on the use of the SE Engine during the operational phase, refer to NASA/SP-2016-6105.
3.1.5.10 The common technical processes are applied by assigned technical teams and individuals trained in the requirements of this NPR.
3.1.5.11 The assigned technical teams and individuals use the appropriate and available sets of tools and methods to accomplish required common technical process activities. This includes the use of modeling and simulation as applicable to the product phase, location of the product layer in the system structure, and the applicable phase success criteria.
3.1.6 Relationship of the SE Engine to the SE Vee.
The NASA SE Engine is a highly versatile representation of the core SE processes necessary to properly engineer a system. It can be used for any type of life-cycle including waterfall, spiral, and agile. It allows for use in very simple to highly complex systems. The NASA SE Engine had its heritage in a classic SE Vee, and if being used for a simple one-pass waterfall-type life-cycle, the right and left chambers of the engine can be represented as shown in Figure 3-4. For a more detailed description of how the SE Engine evolved from the SE Vee, refer to the NASA Systems Engineering Handbook.
Figure 3-4 - SE Engine Implemented for a Simple Single-Pass Waterfall-Type Life Cycle
3.2.1 For Section 3.2, "identify" means to either use an approved process or a customized process that is approved by the ETA or their delegate. "Implement" includes documenting and communicating the approved process, providing resources to execute the process, providing training on the process, and monitoring and controlling the process. The technical team is responsible for the execution of these 17 required processes per Section 2.1.5.
3.2.2 Stakeholder Expectations Definition Process
3.2.2.1 Program/Project Managers shall identify and implement an ETA-approved Stakeholder Expectations Definition process to include activities, requirements, guidelines, and documentation, as tailored and customized for the definition of stakeholder expectations for the applicable product layer [SE-07].
3.2.2.2 The Stakeholder Expectations Definition process is used to elicit and define use cases, scenarios, concept of operations, and stakeholder expectations for the applicable product life-cycle phases and product layer. This includes expectations such as:
a. Operational end products and life-cycle-enabling products of the product layer.
b. Affordability.
c. Operator or user interfaces.
d. Expected skills and capabilities of operators or users.
e. Expected number of simultaneous users.
f. System and human performance criteria.
g. Technical authority, standards, regulations, and laws.
h. Factors such as health and medical, safety, planetary protection, orbital debris, quality, cybersecurity, context of use by humans, reliability, availability, maintainability, electromagnetic compatibility, interoperability, testability, transportability, supportability, usability, and disposability.
i. For crewed missions, crew health and performance capabilities and limitations, risk posture, crew survivability, and system habitability.
j. Local management constraints on how work will be done (e.g., operating procedures).
3.2.2.3 The baselined stakeholder expectations are used for validation of the product layer end product during product realization. At this point, Measures of Effectiveness (MOEs) are defined. For more information of MOEs refer to NASA/SP-2016-6105, NASA Systems Engineering Handbook.
3.2.3 Technical Requirements Definition Process
3.2.3.1 Program/Project Managers shall identify and implement an ETA-approved Technical Requirements Definition process to include activities, requirements, guidelines, and documentation, as tailored and customized for the definition of technical requirements from the set of agreed upon stakeholder expectations for the applicable product layer [SE-08].
3.2.3.2 The technical requirements definition process is used to transform the baselined stakeholder expectations into unique, quantitative, and measurable technical requirements expressed as "shall" statements that can be used for defining a design solution for the product layer end product and related enabling products. This process also includes validation of the requirements to ensure that the 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. As part of this process, Measures of Performance (MOPs) and Technical Performance Measures (TPMs) are defined. For more information of MOPs and TPMs, refer to NASA/SP-2016-6105, NASA Systems Engineering Handbook.
3.2.4 Logical Decomposition Process
3.2.4.1 Program/Project Managers shall identify and implement an ETA-approved Logical Decomposition process to include activities, requirements, guidelines, and documentation, as tailored and customized for logical decomposition of the validated technical requirements of the applicable product layer [SE-09].
3.2.4.2 The logical decomposition process is used to improve understanding of the defined technical requirements and the relationships among the requirements (e.g., functional, behavioral, performance, and temporal) and to transform the defined set of technical requirements into a set of logical decomposition models and their associated set of derived technical requirements for lower levels of the system and for input to the design solution definition process.
3.2.5 Design Solution Definition Process
3.2.5.1 Program/Project Managers shall identify and implement an ETA-approved Design Solution Definition process to include activities, requirements, guidelines, and documentation, as tailored and customized for designing product solution definitions within the applicable product layer that satisfy the derived technical requirements [SE-10].
3.2.5.2 The Design Solution Definition process is used to translate the outputs of the logical decomposition process into a design solution definition that is in a form consistent with the product life-cycle phase and product layer location in the system structure and that will satisfy phase success criteria. This includes transforming the defined logical decomposition models and their associated sets of derived technical requirements into alternative solutions, then analyzing each alternative to be able to select a preferred alternative and fully defining that alternative into a final design solution definition that will satisfy the requirements.
3.2.5.3 These design solution definitions will be used for generating end products, either by using the product implementation process or product integration process, as a function of the position of the product layer in the system structure and whether there are additional subsystems of the end product that need to be defined. The output definitions from the design solution (end product specifications) will be used for conducting product verification.
3.2.6 Product Implementation Process
3.2.6.1 Program/Project Managers shall identify and implement an ETA-approved Product Implementation process to include activities, requirements, guidelines, and documentation, as tailored and customized for implementation of a design solution definition by making, buying, or reusing an end product of the applicable product layer [SE-11].
3.2.6.2 The Product Implementation Process is used to generate a specified product of a product layer through buying, making, or reusing in a form consistent with the product life-cycle phase success criteria and that satisfies the design solution definition (e.g., drawings, specifications).
3.2.7 Product Integration Process
3.2.7.1 Program/Project Managers shall identify and implement an ETA-approved Product Integration process to include activities, requirements, guidelines, and documentation, as tailored and customized for the integration of lower level products into an end product of the applicable product layer in accordance with its design solution definition [SE-12].
3.2.7.2 The Product Integration Process is used to transform lower level, verified and validated end products into the desired end product of the higher level product layer through assembly and integration.
3.2.8 Product Verification Process
3.2.8.1 Program/Project Managers shall identify and implement an ETA-approved Product Verification process to include activities, requirements/specifications, guidelines, and documentation, as tailored and customized for verification of end products generated by the product implementation process or product integration process against their design solution definitions [SE-13].
3.2.8.2 The Product Verification process is used to demonstrate that an end product generated from product implementation or product integration conforms to its requirements as a function of the product life-cycle phase and the location of the product layer end product in the system structure. Special attention is given to demonstrating satisfaction of the MOPs defined for each MOE during performance of the technical requirements definition process.
3.2.9 Product Validation Process
3.2.9.1 Program/Project Managers shall identify and implement an ETA-approved Product Validation process to include activities, requirements, guidelines, and documentation, as tailored and customized for validation of end products generated by the product implementation process or product integration process against their stakeholder expectations [SE-14].
3.2.9.2 The Product Validation process is used to confirm that a verified end product generated by product implementation or product integration fulfills (satisfies) its intended use when placed in its intended environment and to ensure that any anomalies discovered during validation are appropriately resolved prior to delivery of the product (if validation is done by the supplier of the product) or prior to integration with other products into a higher level assembled product (if validation is done by the receiver of the product). The validation is done against the set of baselined stakeholder expectations. Special attention should be given to demonstrating satisfaction of the MOEs identified during performance of the stakeholder expectations definition process. The type of product validation is a function of the form of the product and product life-cycle phase and in accordance with an applicable customer agreement.
3.2.10 Product Transition Process
3.2.10.1 Program/Project Managers shall identify and implement an ETA-approved Product Transition process to include activities, requirements, guidelines, and documentation, as tailored and customized for transitioning end products to the next higher level product layer customer or user [SE-15].
3.2.10.2 The Product Transition process is used to transition a verified and validated end product that has been generated by product implementation or product integration to the customer at the next level in the system structure for integration into an end product or, for the top-level end product, transitioned to the intended end user. The form of the product transitioned will be a function of the product life-cycle phase and the location within the system structure of the product layer in which the end product exists.
3.2.11 Technical Planning Process
3.2.11.1 Program/Project Managers shall identify and implement an ETA-approved Technical Planning process to include activities, requirements, guidelines, and documentation, as tailored and customized for planning the technical effort [SE-16].
3.2.11.2 The Technical Planning process is used to plan for the application and management of each common technical process, including tailoring of organizational requirements and requirements specified in this NPR. It is also used to identify, define, and plan the technical effort applicable to the product life-cycle phase for product layer location within the system structure and to meet program/project objectives and product life-cycle phase success criteria. A key document generated by this process is the SEMP (See Chapter 6).
3.2.12 Requirements Management Process
3.2.12.1 Program/Project Managers shall identify and implement an ETA-approved Requirements Management process to include activities, requirements, guidelines, and documentation, as tailored and customized for management of requirements throughout the system life-cycle [SE-17].
3.2.12.2 The Requirements Management process is used to:
a. Manage the product requirements identified, baselined, and used in the definition of the product layer products during system design.
b. Provide bidirectional traceability back to the top product layer requirements.
c. Manage the changes to established requirement baselines over the life-cycle of the system products.
3.2.13 Interface Management Process
3.2.13.1 Program/Project Managers shall identify and implement an ETA-approved Interface Management process to include activities, requirements, guidelines, and documentation, as tailored and customized for management of the interfaces defined and generated during the application of the system design processes [SE-18].
3.2.13.2 The Interface Management process is used to:
d. Establish and use formal interface management to assist in controlling system product development efforts when the efforts are divided between Government programs, contractors, and/or geographically diverse technical teams within the same program or project.
e. Maintain interface definition and compliance among the end products and enabling products that compose the system, as well as with other systems with which the end products and enabling products will interoperate.
3.2.14 Technical Risk Management Process
3.2.14.1 Program/Project Managers shall identify and implement an ETA-approved Technical Risk Management process to include activities, requirements, guidelines, and documentation, as tailored and customized for management of the risk identified during the technical effort [SE-19].
3.2.14.2 The Technical Risk Management process is used to make risk-informed decisions and examine, on a continuing basis, the potential for deviations from the program/project plan and the consequences that could result should they occur. This enables risk-handling activities to be planned and invoked as needed across the life of the program or project to mitigate impacts on achieving product life-cycle phase success criteria and meeting technical objectives. The technical team supports the development of potential health and medical, safety, cost, and schedule impacts for identified technical risks and any associated mitigation strategies. NPR 8000.4, Agency Risk Management Procedural Requirements, is to be used as a source document for defining this process and NPR 8705.5, Technical Probabilistic Risk Assessment (PRA) Procedures for Safety and Mission Success for NASA Programs and Projects, provides one means of identifying and assessing technical risk. While the focus of this process is the management of technical risk, the highly interdependent nature of health and medical, safety, technical, cost, and schedule risks require the broader program/project team to consistently address risk management with an integrated approach. NASA/SP-2011-3422, NASA Risk Management Handbook, provides guidance for managing risk in an integrated fashion.
3.2.15 Configuration Management Process
3.2.15.1 Program/Project Managers shall identify and implement an ETA-approved Configuration Management process to include activities, requirements, guidelines, and documentation, as tailored and customized for configuration management [SE-20].
3.2.15.2 The Configuration Management process for end products, enabling products, and other work products placed under configuration control is used to:
a. Identify the items to be placed under configuration control.
b. Identify the configuration of the product or work product at various points in time.
c. Systematically control changes to the configuration of the product or work product.
d. Maintain the integrity and traceability of the configuration of the product or work product throughout its life.
e. Preserve the records of the product or end product configuration throughout its life-cycle, dispositioning them in accordance with NPR 1441.1, NASA Records Management Program Requirements.
3.2.16 Technical Data Management Process
3.2.16.1 Program/Project Managers shall identify and implement an ETA-approved Technical Data Management process to include activities, requirements, guidelines, and documentation, as tailored and customized for management of the technical data generated and used in the technical effort [SE-21].
3.2.16.2 The Technical Data Management Process is used to plan for, acquire, access, manage, protect, and use data of a technical nature to support the total life-cycle of a system. This process is used to capture trade studies, cost estimates, technical analyses, reports, and other important information.
3.2.17 Technical Assessment Process
3.2.17.1 Program/Project Managers shall identify and implement an ETA-approved Technical Assessment process to include activities, requirements, guidelines, and documentation, as tailored and customized for making assessments of the progress of planned technical effort and progress toward requirements satisfaction [SE-22].
3.2.17.2 The Technical Assessment process is used to help monitor progress of the technical effort and provide status information for support of the system design, product realization, and technical management processes. A key aspect of the technical assessment process is the conduct of life-cycle and technical reviews throughout the system life-cycle in accordance with Chapter 5.
3.2.18 Decision Analysis Process
3.2.18.1 Program/Project Managers shall identify and implement an ETA-approved Decision Analysis process to include activities, requirements, guidelines, and documentation, as tailored and customized for making technical decisions [SE-23].
3.2.18.2 The Decision Analysis process, including processes for identification of decision criteria, identification of alternatives, analysis of alternatives, and alternative selection, is applied to technical issues to support their resolution. It considers relevant data (e.g., engineering performance, quality, and reliability) and associated uncertainties. Decision analysis is used throughout the system life-cycle to formulate candidate decision alternatives and evaluate their impacts on health and medical, safety, technical, cost, and schedule performance. NASA/SP-2010-576, NASA Risk-Informed Decision Making Handbook, provides guidance for analyzing decision alternatives in a risk-informed fashion.
| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | AppendixK | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |