![[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 | ALL | | |||||
3.1.1 This chapter establishes the core set of common technical processes and requirements to be used by NASA projects in engineering system products during all life-cycle phases to meet phase exit criteria and 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: (1) the system design processes for "top-down" design of each product in the system structure; (2) the product realization processes for "bottom-up" realization of each product in the system structure; and (3) the 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). The SE common technical processes model is referred to as an "SE engine" in this SE 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 exit criteria while meeting stakeholder expectations within cost, schedule, and risk constraints.
3.1.2 This chapter identifies the following for each of the 17 common technical processes:
a. The specific requirement for Center Directors or designees to establish and maintain the process;
b. A brief description of how the process is used as an element of the Systems Engineering Engine; and
c. A reference to typical practices for the process as identified in Appendix C.
3.1.3 It should be emphasized that the Practices for Common Technical Processes documented in Appendix C do not represent additional requirements that must be implemented by the technical team. Appendix C is provided as a summary of typical best practices associated with the 17 common technical processes. As such, it should be considered in conjunction with other sources of systems engineering guidance such as NASA/SP-2007-6105, NASA Systems Engineering Handbook, as the technical team develops a customized approach for the application of these processes consistent with requirements implemented by Center documentation.
Figure 3 1 - Systems Engineering (SE) Engine
3.1.4 The context in which the common technical processes are used is provided below:
3.1.4.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, product layer is defined as the product breakdown hierarchy that includes both the end product and enabling product hierarchy. 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.4.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.4.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 exit criteria of the applicable phase.
3.1.4.4 The common technical processes are applied by assigned technical teams and individuals trained in the requirements of this SE NPR.
3.1.4.5 The assigned technical teams and individuals are using 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 exit criteria.
3.2.1 For this section, "establish" means developing policy, work instructions, or procedures to implement process activities. "Maintain" includes planning the process, providing resources, assigning responsibilities, training people, managing configurations, identifying and involving stakeholders, and monitoring and controlling the process. The technical team is responsible for the execution of these 17 required processes per Paragraph 2.1.5.
3.2.2 Stakeholder Expectations Definition Process
3.2.2.1 Center Directors or designees shall establish and maintain a Stakeholder Expectations Definition process to include activities, requirements, guidelines, and documentation 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 safety, planetary protection, orbital debris, quality, security, context of use by humans, reliability, availability, maintainability, electromagnetic compatibility, interoperability, testability, transportability, supportability, usability, and disposability; and (i) local management constraints on how work will be done (e.g., operating procedures). 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.
3.2.2.3 Typical practices of this process are defined in Appendix C.1.1.
3.2.3 Technical Requirements Definition Process
3.2.3.1 Center Directors or designees shall establish and maintain a Technical Requirements Definition process to include activities, requirements, guidelines, and documentation 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.
3.2.3.3 Typical practices of this process are defined in Appendix C.1.2.
3.2.4 Logical Decomposition Process
3.2.4.1 Center Directors or designees shall establish and maintain a Logical Decomposition process to include activities, requirements, guidelines, and documentation 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.4.3 Typical practices of this process are defined in Appendix C.1.3.
3.2.5 Design Solution Definition Process
3.2.5.1 Center Directors or designees shall establish and maintain a Design Solution Definition process to include activities, requirements, guidelines, and documentation 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 exit 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.5.4 Typical practices of this process are defined in Appendix C.1.4.
3.2.6 Product Implementation Process
3.2.6.1 Center Directors or designees shall establish and maintain a Product Implementation process to include activities, requirements, guidelines, and documentation 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 exit criteria and that satisfies the design solution definition (e.g., drawings, specifications).
3.2.6.3 Typical practices of this process are defined in Appendix C.2.1.
3.2.7 Product Integration Process
3.2.7.1 Center Directors or designees shall establish and maintain a Product Integration process to include activities, requirements, guidelines, and documentation 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, validated end products into the desired end product of the higher level product layer through assembly and integration.
3.2.7.3 Typical practices of this process are defined in Appendix C.2.2.
3.2.8 Product Verification Process
3.2.8.1 Center Directors or designees shall establish and maintain a Product Verification process to include activities, requirements/specifications, guidelines, and documentation 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 design solution definition 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 conduct of the technical requirements definition process.
3.2.8.3 Typical practices of this process are defined in Appendix C.2.3.
3.2.9 Product Validation Process
3.2.9.1 Center Directors or designees shall establish and maintain a Product Validation process to include activities, requirements, guidelines, and documentation 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 conduct 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.9.3 Typical practices of this process are defined in Appendix C.2.4.
3.2.10 Product Transition Process
3.2.10.1 Center Directors or designees shall establish and maintain a Product Transition process to include activities, requirements, guidelines, and documentation 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.10.3 Typical practices of this process are defined in Appendix C.2.5.
3.2.11 Technical Planning Process
3.2.11.1 Center Directors or designees shall establish and maintain a Technical Planning process to include activities, requirements, guidelines, and documentation 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. 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 project objectives and product life-cycle phase exit criteria. A key document generated by this process is the SEMP (See Chapter 6).
3.2.11.3 Typical practices of this process are defined in Appendix C.3.1.
3.2.12 Requirements Management Process
3.2.12.1 Center Directors or designees shall establish and maintain a Requirements Management process to include activities, requirements, guidelines, and documentation 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; and (c) manage the changes to established requirement baselines over the life cycle of the system products.
3.2.12.3 Typical practices of this process are defined in Appendix C.3.2.
3.2.13 Interface Management Process
3.2.13.1 Center Directors or designees shall establish and maintain an Interface Management process to include activities, requirements, guidelines, and documentation 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: (a) 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; and (b) 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 must interoperate.
3.2.13.3 Typical practices of this process are defined in Appendix C.3.3.
3.2.14 Technical Risk Management Process
3.2.14.1 Center Directors or designees shall establish and maintain a Technical Risk Management process to include activities, requirements, guidelines, and documentation 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 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 product or project to mitigate impacts on achieving product life-cycle phase exit criteria and meeting technical objectives. The technical team supports the development of potential health and 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 requirement is the management of technical risk, the process applies to the management of programmatic risks as well. The highly interdependent nature of health and 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.14.3 Typical practices of this process are defined in Appendix C.3.4.
3.2.15 Configuration Management Process
3.2.15.1 Center Directors or designees shall establish and maintain a Configuration Management process to include activities, requirements, guidelines, and documentation 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 configuration of the product or work product at various points in time; (b) systematically control changes to the configuration of the product or work product; (c) maintain the integrity and traceability of the configuration of the product or work product throughout its life; and (d) preserve the records of the product or end product configuration throughout its life cycle, dispositioning them in accordance with NPR 1441.1, NASA Records Retention Schedules.
3.2.15.3 Typical practices of this process are defined in Appendix C.3.5.
3.2.16 Technical Data Management Process
3.2.16.1 Center Directors or designees shall establish and maintain a Technical Data Management process to include activities, requirements, guidelines, and documentation 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.16.3 Typical practices of the technical data management process are defined in Appendix C.3.6.
3.2.17 Technical Assessment Process
3.2.17.1 Center Directors or designees shall establish and maintain a Technical Assessment process to include activities, requirements, guidelines, and documentation 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.17.3 Typical practices of this process are defined in Appendix C.3.7.
3.2.18 Decision Analysis Process
3.2.18.1 Center Directors or designees shall establish and maintain a Decision Analysis process to include activities, requirements, guidelines, and documentation 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 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.
3.2.18.3 Typical practices of this process are defined in Appendix C.3.8.
| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | ALL | |
| | NODIS Library | Program Formulation(7000s) | Search | |