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 applicable product-line life-cycle phases (see Figure 5-3) 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 technical management processes for planning, assessing, and controlling the implementation of the system design and product realization
processes and to guide technical decisionmaking (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-line life-cycle phase exit criteria while meeting
stakeholder expectations within cost, schedule, and risk constraints.
Figure 3‑1 SE Engine
3.1.2
The context in which the common technical processes are used is provided below.
3.1.2.1
The common technical processes are applied to a product-based Work Breakdown Structure (WBS) model 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). 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.2.2
The common technical processes are applied to design a system solution definition for each WBS model down and across each level of the
system structure and to realize the WBS model end products up and across the system structure. Figure 3-2 illustrates how the three major
sets of processes of the SE Engine (system design processes, product realization processes, and technical management processes)
are applied to a WBS model within a system structure (a hierarchy of product-based WBS models).
Figure 3-2 Application of SE Engine Processes within System Structure
3.1.2.3
The common technical processes are used to define the WBS models of the system structure in each applicable phase of the relevant
product-line life cycle (see Figure 5-3) to generate work products and system products needed to satisfy the exit criteria of the
applicable phase. System engineering continues well into the operations and maintenance phase of a project, i.e., after the system
products are delivered. For example, in the course of operating, maintaining, and disposing of an existing system, all upgrades,
enhancements, supporting or enabling developments, and reconfigurations must apply the common SE technical processes.
3.1.2.4
The common technical processes are applied by assigned technical teams and individuals of the NASA workforce trained in the
requirements of this SE NPR.
3.1.2.5
The assigned technical teams and individuals should use the appropriate and available sets of tools and methods to accomplish required
common technical process activities. This would include the use of modeling and simulation as applicable to the product-line phase,
location of the WBS model in the system structure, and the applicable phase exit criteria.
3.1.3
The assigned technical teams shall define in the project SEMP how the required 17 common technical processes,
as implemented by Center documentation, will be applied to the various levels of project WBS model system structure during each applicable
life-cycle phase and have their approach approved by the DGA.
For the statements below "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.
3.2.1 Stakeholder Expectations Definition Process
3.2.1.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for the definition of stakeholder expectations for the applicable WBS model.
3.2.1.2
The stakeholder expectations definition process is used to elicit and define use cases, scenarios, operational concepts, and
stakeholder expectations for the applicable product-line life-cycle phases and WBS model. This includes requirements for: (a) operational
end products and life-cycle-enabling products of the WBS model; (b) expected skills and capabilities of operators or users; (c) expected
number of simultaneous users, (d) system and human performance criteria, (e) technical authority, standards, regulations, and laws; (f)
factors such as safety, quality, security, context of use by humans, reliability, availability, maintainability, electromagnetic
compatibility, interoperability, testability, transportability, supportability, usability, and disposability; and (g) local management
constraints on how work will be done (e.g., operating procedures). The baselined stakeholder expectations are used for validation of the
WBS model end product during product realization.
3.2.1.3
Typical practices of this process are defined in Appendix C.1.1.
3.2.2 Technical Requirements Definition Process
3.2.2.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for definition of the technical requirements from the set of agreed upon stakeholder expectations for the applicable WBS
model.
3.2.2.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 WBS model end
product and related enabling products.
3.2.2.3
Typical practices of this process are defined in Appendix C.1.2.
3.2.3 Logical Decomposition Process
3.2.3.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for logical decomposition of the validated technical requirements of the applicable WBS model.
3.2.3.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, 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 input to the design solution definition process.
3.2.3.3
Typical practices of this process are defined in Appendix C.1.3.
3.2.4 Design Solution Definition Process
3.2.4.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for designing product solution definitions within the applicable WBS model that satisfy the derived technical requirements.
3.2.4.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-line life-cycle phase and WBS model 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 technical requirements. 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 WBS model 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.4.3
Typical practices of this process are defined in Appendix C.1.4.
3.2.5 Product Implementation Process
3.2.5.1
The Center Directors or designees shall establish and maintain a 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 WBS model.
3.2.5.2
The product implementation process is used to generate a specified product of a WBS model through buying, making, or reusing in a form
consistent with the product-line life-cycle phase exit criteria and that satisfies the design solution definition specified requirements
(e.g., drawings, specifications).
3.2.5.3
Typical practices of this process are defined in Appendix C.2.1
3.2.6 Product Integration Process
3.2.6.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation for the integration of lower level products into an end product of the applicable WBS model in accordance with its design
solution definition.
3.2.6.2
The product integration process is used to transform the design solution definition into the desired end product of the WBS model through
assembly and integration of lower level, validated end products in a form consistent with the product-line life-cycle phase exit
criteria and that satisfies the design solution definition requirements (e.g., drawings, specifications).
3.2.6.3
Typical practices of this process are defined in Appendix C.2.2.
3.2.7 Product Verification Process
3.2.7.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for verification of end products generated by the product implementation process or product integration process
against their design solution definitions.
3.2.7.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-line life-cycle phase and the location of the WBS
model end product in the system structure. Special attention is given to demonstrating satisfaction of the measures of performance (MOPs)
defined for each measure of effectiveness (MOEs) during conduct of the technical requirements definition process.
3.2.7.3
Typical practices of this process are defined in Appendix C.2.3.
3.2.8 Product Validation Process
3.2.8.1
The Center Directors or designees shall establish and maintain a 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.
3.2.8.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-line life-cycle phase and in accordance with an applicable customer agreement.
3.2.8.3
Typical practices of this process are defined in Appendix C.2.4.
3.2.9 Product Transition Process
3.2.9.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for transitioning end products to the next higher level WBS-model customer or user.
3.2.9.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-line life-cycle phase exit criteria and the location within the system structure of the WBS model in which the end product
exits.
3.2.9.3
Typical practices of this process are defined in Appendix C.2.5.
3.2.1 Technical Planning Process
3.2.10.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for planning the technical effort.
3.2.10.2
The technical planning process is used to plan for the application and management of each common technical process and to identify,
define, and plan the technical effort applicable to the product-line life-cycle phase for WBS model location within the system structure
and to meet project objectives and product-line life-cycle phase exit criteria. A key document generated by this process is the SEMP.
(See Chapter 6.)
3.2.10.3
Typical practices of this process are defined in Appendix C.3.1.
3.2.11 Requirements Management Process
3.2.11.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for management of requirements defined and baselined during the application of the system design processes.
3.2.11.2
The requirements management process is used to: (a) manage the product requirements identified, baselined, and used in the definition of
the WBS model products during system design; (b) provide bidirectional traceability back to the top WBS model requirements; and (c) manage
the changes to established requirement baselines over the life cycle of the system products.
3.2.11.3
Typical practices of this process are defined in Appendix C.3.2.
3.2.12 Interface Management Process
3.2.12.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for management of the interfaces defined and generated during the application of the system design processes.
3.2.12.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.12.3
Typical practices of this process are defined in Appendix C.3.3.
3.2.13 Technical Risk Management Process
3.2.13.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for management of the technical risk identified during the technical effort. (NPR 8000.4, Risk Management Procedural
Requirements, is to be used as a source document for defining this process, and NPR 8705.5, Probabilistic Risk Assessment (PRA)
Procedures for NASA Programs and Projects, provides one means of identifying and assessing technical risk.)
3.2.13.2
The technical risk management process is used to examine on a continuing basis the risks of technical deviations from the project plan and
identify potential technical problems before they occur so that risk-handling activities can be planned and invoked as needed across the
life of the product or project to mitigate impacts on achieving product-line life-cycle phase exit criteria and meeting technical
objectives.
3.2.13.3
Typical practices of this process are defined in Appendix C.3.4.
3.2.14 Configuration Management Process
3.2.14.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for configuration management.
3.2.14.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.14.3
Typical practices of this process are defined in Appendix C.3.5.
3.2.15 Technical Data Management Process
3.2.15.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for management of the technical data generated and used in the technical effort.
3.2.15.2
The technical data management process is used to: (a) provide the basis for identifying and controlling data requirements; (b)
responsively and economically acquire, access, and distribute data needed to develop, manage, operate, and support system products
over their product-line life; (c) manage and disposition data as records; (d) analyze data use; (e) if any of the technical effort
is performed by an external contractor, obtain technical data feedback for managing the contracted technical effort; and (f) assess the
collection of appropriate technical data and information.
3.2.15.3
Typical practices of this process are defined in Appendix C.3.6.
3.2.16 Technical Assessment Process
3.2.16.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for making assessments of the progress of planned technical effort and progress toward requirements satisfaction.
3.2.16.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.
3.2.16.3
Typical practices of this process are defined in Appendix C.3.7.
3.2.17 Decision Analysis Process
3.2.17.1
The Center Directors or designees shall establish and maintain a process to include activities, requirements, guidelines, and
documentation, for making technical decisions.
3.2.17.2
The decision analysis process, including data collection (e.g., engineering performance, quality, and reliability data), is used to help
evaluate technical decision issues, technical alternatives, and their uncertainties to support decisionmaking. This process is used
throughout technical management, system design, and product realization processes to evaluate the impact of decisions on performance,
cost, schedule, and technical risk.
3.2.17.3
Typical practices of this process are defined in Appendix C.3.8.
DISTRIBUTION:
NODIS
This Document is Obsolete and Is No Longer Used.
Check the NODIS Library to access the current version:
http://nodis3.gsfc.nasa.gov
![[NASA Logo]](../Images/nasaball.gif)