| NODIS Library | Program Formulation(7000s) | Search |

NASA Ball NASA
Procedural
Requirements
NPR 7123.1B
Effective Date: April 18, 2013
Expiration Date: April 18, 2018
COMPLIANCE IS MANDATORY
Printable Format (PDF)

(NASA Only)

Subject: NASA Systems Engineering Processes and Requirements

Responsible Office: Office of the Chief Engineer


| TOC | ChangeHistory | Preface | Chapter1 | Chapter2 | Chapter3 | Chapter4 | Chapter5 | Chapter6 | AppendixA | AppendixB | AppendixC | AppendixD | AppendixE | AppendixF | AppendixG | AppendixH | AppendixI | AppendixJ | ALL |

Appendix C. Practices for Common Technical Processes

This appendix contains best practices as extracted from industry, national and international standards, and within the Agency. The practices may be used by Centers in preparing directives, policies, rules, work instructions, and other documents implementing SE processes. The practices of this appendix may also be used in the future assessments of those plans and processes to provide feedback to the OCE and Centers on the strengths and weaknesses in the Centers' implementation of this SE NPR. These practices can be expanded and updated as necessary.

Each process is described in terms of purpose, inputs, outputs, and activities. Notes are provided both to further explain a process and to help understand the best practices included. A descriptive figure is also provided for each process to illustrate notional relationships between activities within a process as well as the sources of inputs and destinations of outputs. Figures in this appendix are not intended to include all possible inputs, outputs, or intermediate work products.1 Additional guidance and examples can be found in NASA/SP-2007-6105 NASA Systems Engineering Handbook.


1 The SEMP is an input to the common technical processes, but it is not shown in each process diagram in this appendix.


Hardware, software, and human systems integration considerations should be assessed in all aspects of these processes. For human rating products, the technical team should refer to NPR 8705.2. The technical team should also ensure that the process implementations comply with NPR 8705.2 for human rating aspects of the system.

C.1 System Design Processes

a. There are four system design processes applied to each product-based product layer from the top to the bottom of the system structure: (1) Stakeholder Expectation Definition, (2) Technical Requirements Definition, (3) Logical Decomposition, and (4) Design Solution Definition. (See Figure 3-1 and Figure 3-2.)

b. 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 will also be a need to interact with the technical management processes to aid in identifying and resolving issues and making decisions between alternatives.

c. For software products, the technical team refers to NPR 7150.2 software design requirements. The technical team also ensures that the process implementations comply with NPR 7150.2 software design requirements.

C.1.1 Stakeholder Expectations Definition Process

C.1.1.1 Purpose

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. The baselined stakeholder expectations are used for validation of the product layer end product during product realization.

C.1.1.2 Inputs and Sources:

a. Customer expectations (from users and program and/or project).

b. Other stakeholder expectations (from project and/or other interested parties of the products of this layerâ?"recursive loop).

c. Customer flow-down requirements from previous level products (from Design Solution Definition Processâ?"recursive loopâ?"and Requirements Management and Interface Management Processes).

Note: This would include requirements for initiating enabling product development to provide appropriate life-cycle support products and services to the mission or operational/research end product of the product layer.

C.1.1.3 Outputs and Destinations:

a. Set of validated stakeholder expectations, including interface requirements (to Technical Requirements Definition, Requirements Management, and Interface Management Processes).

b. Baseline concept of operations (to Technical Requirements Definition Process and Configuration Management Processes).

c. Baseline set of enabling product support strategies (to Technical Requirements Definition Process and Configuration Management Processes).

d. Measures of Effectiveness (MOEs) (to Technical Requirements Definition Process and Technical Data Management Process).

C.1.1.4 Activities

For the products of this layer in the system structure, the following activities are typically performed:

a. Establish a list that identifies customers and other stakeholders that have an interest in the system and its products.

b. Elicit customer and other stakeholder expectations (needs, wants, desires, capabilities, external interfaces, and constraints) from the identified stakeholders.

c. Establish concept of operations and support strategies based on stakeholders' expected use of the system products over the system's life.

Note: Defined scenarios and concept of operations include functionality and performance of intended uses and relevant boundaries, constraints, and environments in which the product (s) will operate. Support strategies include provisions for fabrication, test, deployment, operations, sustainment, and disposal.

d. Define stakeholder expectations in acceptable statements that are complete sentences and have the following characteristics: (1) are individually clear, correct, and feasible to satisfy; are not stated as to how they are to be satisfied; are implementable; have only one interpretation of meaning; have one actor-verb-object expectation; and can be validated at the level of the system structure at which they are stated; and (2) in pairs or as a set, have no redundancy, are consistent with respect to terms used, so they do not conflict with one another, and do not contain stakeholder expectations of questionable utility or that have an unacceptable risk for being satisfied.

e. Analyze stakeholder expectation statements to establish a set of measures (MOEs) by which overall system or product effectiveness will be judged and customer satisfaction will be determined.

Note 1: A set of MOEs is developed from the set of defined stakeholder expectation statements. It represents an expectation that is critical to the success of the system, and failure to satisfy these measures will cause the stakeholder to deem the system unacceptable. Examples of typical MOEs are weight, availability, mobility, user/operator comfort, Central Processing Unit (CPU) capacity, and parameters associated with critical events during operations. Whereas weight is generally stated in quantitative terms and can be easily allocated to lower level system products, other MOEs may be qualitative or not easily allocated and thus will need measures of performance (MOPs) derived that can be used as design-to requirements. MOPs are derived during technical requirements definition process activities.

Note 2: Trade studies or other analysis may have to be performed to resolve conflicting stakeholder expectations.

f. Validate that the resulting set of stakeholder expectation statements are upward and downward traceable to reflect the elicited set of stakeholder expectations and that any anomalies identified are resolved.

g. Obtain commitments from customer and other stakeholders such that the resultant set of stakeholder expectation statements is acceptable.

Note: This can be done through the equivalent of a systems requirement review with appropriate formality as a function of the location of the product in the system structure, the agreement affecting the development effort, and the type of NASA project.

h. Baseline the agreed-to set of stakeholder expectation statements.

Note 1: Products generated by the product implementation process or product integration process will be validated against this set of baselined stakeholder expectations.

Note 2: The baselines are generated and placed under change control using the requirements and interface management processes and configuration management process, to the formality required and the location of the product layer in the system structure. Bidirectional traceability of expectations and requirements are initiated at this point for tracking changes from initial stakeholder inputs through design solution definition outputs.

Note 3: The baseline information should include rationale for decisions made, assumptions with respect to the decisions made, and other information that will provide an understanding of the stakeholder expectations baseline.

i. Capture work products from stakeholder expectation activities.

Note: The work products generated during the above activities should be captured along with key decisions made, supporting decision rationale and assumptions, and lessons learned in performing the stakeholder expectation definition process activities.

C.1.1.5 Process Flow Diagram

A typical process flow diagram for the stakeholder expectations definition process is provided in Figure C-1 with inputs and their sources and the outputs and their destinations. The activities of the stakeholder expectations definition process are truncated to indicate the action and object of the action.

The customer flow-down requirements from the design solution definition process are applicable at levels of the system structure below the top level. The other stakeholder expectations are applicable at each level of the system structure to reflect the local management policies, applicable standards and regulations, and enabling product support needs for the lower level products of this layer.


Figure C 1 - Stakeholder Expectation Definition Process

C.1.2 Technical Requirements Definition Process

C.1.2.1 Purpose

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 definition for the end product and related enabling products of this layer.

C.1.2.2 Inputs and Sources:

a. Baselined set of stakeholder expectations, including interface requirements (from Stakeholder Expectations Definition and Configuration Management Processes).

b. Baselined Concept of Operation (from Stakeholder Expectations Definition and Configuration Management Processes).

c. Baselined Enabling Product Support Strategies (from Stakeholder Expectations Definition and Configuration Management Processes).

d. Measures of Effectiveness (from Stakeholder Expectations Definition and Technical Data Management Processes).

C.1.2.3 Outputs and Destinations:

a. Set of validated technical requirements that represents a reasonably complete description of the problem to be solved, including interface requirements (to Logical Decomposition and Requirements and Interface Management Processes).

b. Sets of MOPs that when met will satisfy the MOEs to which a set is related (to Logical Decomposition and Technical Data Management Processes).

c. A set of critical technical performance measures (TPMs) that if not met will put the project in cost, schedule, or performance risk status (to Technical Assessment Process).

Note: If process requirements were identified during this activity, they should be captured in distinct sections, volumes, or documents. These process requirements will not be verified as part of the product verification process but will be verified in other manners such as audits.

C.1.2.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Analyze the scope of the technical problem to be solved to identify and resolve the design boundaries that identify: (1) which system functions are under design control and which are not; (2) expected interaction among system functions (data flows, human responses, and behaviors); (3) external physical and functional interfaces (mechanical, electrical, thermal, data, procedural) with other systems; (4) required capacities of system products; (5) timing of events, states, modes, and functions related to operational scenarios; and (6) emerging or maturing technologies necessary to make requirements.

b. Define constraints affecting the design of the system or products or how the system or products will be able to be used.

Note: Constraints that affect the design include cost, schedule, physical product constraints (e.g., color, texture, size, weight, buoyancy, use environment, rate of use, life-cycle services) and human constraints (e.g., operator physical and performance capabilities, operator work environment, and interfaces). Constraints are typically not able to be changed based on tradeoff analyses. Applicable industry standards should be referenced for possible constraints.

c. Define functional and behavioral expectations for the system or product in acceptable technical terms for the range of anticipated uses of system products as identified in the concept of operations. This permits separating defined stakeholder expectation functions and behaviors that belong to a lower level in the system structure and allocating them to the appropriate level.

d. Define the performance requirements associated with each defined functional and behavioral expectation.

Note: The performance requirements are expressed as the quantitative part of a requirement to indicate how well each product function is expected to be accomplished. Any qualitative performance expectations should be analyzed and quantified, and the performance requirements that can be changed by tradeoff analysis should be identified.

e. Define technical requirements in acceptable "shall" statements that are complete sentences with a single "shall" per numbered statement and have the following characteristics: (1) are individually clear, correct, and feasible; are not stated as to how it is to be satisfied; are implementable; have only one interpretation of meaning; have one actor-verb-object requirement; and can be validated at the level of the system structure at which they are stated; and (2) in pairs or as a set, have no redundancy, are consistent with terms used, are not in conflict with one another, and form a set of "design-to" requirements.

f. Validate that the resulting technical requirement statements: (1) have bidirectional traceability to the baselined stakeholder expectations; (2) were formed using valid assumptions; and (3) are essential to and consistent with designing and realizing the appropriate product solution form that will satisfy the applicable product life-cycle phase exit criteria.

g. Define MOPs for each identified MOE that cannot be directly used as a design-to technical requirement.

Note: Typically each qualitative MOE will have two or more MOPs made up of functional and performance requirement combinations. These quantitative MOPs, appropriately determined and defined, when designed in the design solution definition and met by a product generated by the product implementation process or product integration process, should help ensure that the qualitative MOEs (e.g., the seat is comfortable, no damage to the mission vehicle is caused by booster engine separation) will be satisfied.

h. Define appropriate TPMs by which technical progress will be assessed.

Note: TPMs are used for progress measurement and must meet certain criteria to be a valid TPM: (1) be a significant qualifier of the system (e.g., mass, power, weight, range, capacity, response time, safety parameter) that will be monitored at critical events (e.g., inspections, planned tests); (2) can be measured; and (3) projected progress profiles can be established (e.g., from historical data or based on test planning). TPMs provide an early warning method to flag potential technical problems in that the project will be put at technical performance, cost, or schedule risk if the requirement is not met. TPMs are typically selected from the MOPs.

i. Establish the technical requirements baseline.

Note: The baseline would be established and placed under change control by invoking the activities of the requirements management, interface management, and configuration management processes.

j. Capture the work products from technical requirements definition activities.

Note: The work products generated during the above activities should be captured along with key decisions made, supporting decision rationale and assumptions, and lessons learned in performing the technical requirements process activities to provide an understanding of the technical requirements baseline.

C.1.2.5 Process Flow Diagram

A typical process flow diagram for the technical requirements definition process is provided in Figure C-2 with inputs and their sources and the outputs and their destinations. The activities of the technical requirements definition process are truncated to indicate the action and object of the action.


Figure C 2 - Technical Requirements Definition Process

C.1.3 Logical Decomposition Process

C.1.3.1 Purpose

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.

C.1.3.2 Inputs and Sources:

a. The baseline set of validated technical requirements, including interface requirements (from Technical Requirements Definition and Configuration Management Processes).

b. The defined MOPs (from Technical Requirements Definition and Technical Data Management Processes).

C.1.3.3 Outputs and Destinations:

a. Set of validated derived technical requirements, including interface requirements (to Design Solution Definition and Requirements and Interface Management Processes).

b. The set of logical decomposition models (to Design Solution Definition and Configuration Management Processes).

c. Logical decomposition work products (to Technical Data Management Processes).

C.1.3.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Define one or more logical decomposition models based on the defined technical requirements to gain a more detailed understanding and definition of the design problem to be solved.

Note 1: The defined technical requirements can be decomposed and analyzed by functions, time, behaviors, data flow, objects, states and modes, and failure modes and effects, as pertinent to the program/project, to define sets of logical decomposition models. The models may include functional flow block diagrams, timelines, data control flow, states and modes, behavior diagrams, operator tasks, or functional failure modes and should be based on performance, cost, schedule, health and safety, and risk analyses.

Note 2: Use of existing products, which helps reduce development time and cost, may be considered in establishing logical decomposition models. New interfaces may appear with the introduction of existing products. These interfaces need to be included in the technical requirements, thus requiring an iteration of the technical requirements definition process.

Note 3: New technology insertion is considered at this point. The use of new technologies can provide a competitive edge but needs to be balanced against the risks of their insertion.

b. Allocate the technical requirements to the logical decomposition models to form a set of derived technical requirement statements that have the following characteristics:

Describe functional and performance, service and attribute, time, and data flow requirements, etc., as they pertain to the selected set of logical decomposition models.

Individually are complete sentences and are clear, correct, and feasible; not stated as to how to be satisfied; implementable; only have one interpretation of meaning, one actor-verb-object expectation; and can be validated at the level of the system structure at which it is stated.

In pairs or as a set, have an absence of redundancy, are adequately related with respect to terms used, and are not in conflict with one another.

Form a set of detailed "design-to" requirements.

Note: Traceability for the allocated MOPs should be maintained throughout the logical decomposition process. This is essential in that particular attention should be paid to demonstrating satisfaction of the MOPs during verification of a product generated by the product implementation process or product integration process.

c. Resolve derived technical requirement conflicts.

Note 1: The logical decomposition models and derived technical requirements should be analyzed to identify possible conflicts. The established set of performance criteria, cost, schedule, and risks should be used in conducting tradeoff analyses for conflict resolution.

Note 2: Conflicts among derived technical requirements are always a problem. This logical decomposition process activity is designed to discover such conflicts early and resolve them before the design solution definition is too far underway. Understanding the problem to be solved in more detail is helpful for obtaining a better and more cost-effective design solution definition.

d. Validate that the resulting set of derived technical requirements have: (1) bidirectional traceability with the set of validated technical requirements and (2) assumptions and decision rationales consistent with the source set of technical requirements.

Note 1: There may be some technical requirements that cannot be allocated to the logical decomposition models. If so, then these should be allocated directly to the physical entities that will make up the alternatives for design solution definition.

Note 2: Bidirectional requirements traceability is used for tracking changes to the technical requirements based on the logical decomposition models and their allocated derived technical requirements.

e. Establish the derived technical requirements baseline.

Note: The baselines would be established and placed under change control by invoking the activities of the requirements management, interface management, and configuration management processes.

f. Capture work products from logical decomposition activities.

Note: The work products generated during the definition of the derived technical requirements should be captured along with key decisions made, supporting decision rationale and assumptions, and lessons learned in performing the logical decomposition process activities to provide an understanding of the derived technical requirements baseline and the logical decomposition models and to permit traceability to technical requirements, stakeholder expectations, and logical decomposition models.

C.1.3.5 Process Flow Diagram

A typical process flow diagram for logical decomposition is provided in Figure C-3 with inputs and their sources and the outputs and their destinations. The activities of the logical decomposition process are truncated to indicate the action and object of the action.


Figure C 3 - Logical Decomposition Process

C.1.4 Design Solution Definition Process

C.1.4.1 Purpose

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 define that alternative into a final design solution 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 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.

C.1.4.2 Inputs and Sources:

a. A baselined set of logical decomposition models (from Logical Decomposition and Configuration Management Processes).

b. A baseline set of derived technical requirements, including interface requirements (from Logical Decomposition and Configuration Management Processes).

Note: If there were unallocated technical requirements, these requirements would also be inputs to the design solution definition process.

C.1.4.3 Outputs and Destinations:

The specified requirements that describe the system design solution definition for the products of the product layer under development include:

a. A product layer design solution definition set of requirements for the system, including specification configuration documentation and external interface specification (to Requirements and Interface Management Process).

b. A baseline set of "make-to," "buy-to," "reuse-to," or set of "assemble and integrate-to" specified requirements (e.g., specifications, engineering drawings, computer-aided design (CAD) models, analytical models and configuration documents) for the desired end product of the product layer, including interface specifications (to Requirements and Interface Management Process).

Note: The specifications should include not only the product characteristics and functional and performance requirements, but also how each requirement will be evaluated during verification and/or acceptance tests.

c. The initial specifications for product layer subsystems for flow down to the next applicable lower level product layers, including interface specifications (to Stakeholder Expectations Definition, and Requirements and Interface Management Processes).

Note: If there is not a need for further development of end product subsystems, the product implementation process is the applicable destination of the end product specified requirements. (See C.1.4.2 above.)

d. The requirements for enabling products that will be needed to provide life-cycle support to the end products, including interface requirements (to Stakeholder Expectations Definition Process for development of enabling products or to Product Implementation Process for acquisition of existing enabling products, and Requirements and Interface Management Processes).

e. A product verification plan that will be used to demonstrate that the product generated from the design solution definition conforms to the design solution definition specified requirements (to Product Verification Process).

Note: The technical planning process should be used to develop this plan based on the product design solution definition process activities and the product verification process activities.

f. A product validation plan that will be used to demonstrate that the product generated from the design solution definition conforms to its set of stakeholder expectations (to Product Validation Process).

Note: The technical planning process should be used to develop this plan based on the product design solution definition process activities and the product validation process activities.

g. Baseline operate-to and logistics procedures (to Technical Data Management Process).

C.1.4.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Define alternative solutions for the system end product being developed or improved that are consistent with the allocated and derived technical requirements.

Note 1: The derived technical requirements should be partitioned based on their associated logical decomposition model to potential physical elements that will make up the end product (e.g., hardware, software, human/manual operations, data, processes, and/or composites of these).

Note 2: Alternative solutions can be formed by packaging the physical elements in such a way that the derived technical requirements will be satisfied.

Note 3: Criteria should be established by which alternative solutions can be evaluated.

b. Analyze each alternative solution against defined criteria, such as satisfaction of external interface requirements; technology requirements; off-the-shelf availability of products; physical failure modes, effects, and criticality; life-cycle cost and support considerations; capacity to evolve; make vs. buy; standardization of products; integration concerns; and context of use issues of operators considering tasks, location, workplace equipment, and ambient conditions.

c. Select the best solution alternative based on the analysis results of each alternative solution and technical decision analysis recommendations.

Note: The decision analysis process is used to make an evaluated recommendation of the best or favored solution.

d. Generate the full design description of the selected alternative solution in a form appropriate to the product life-cycle phase, location of the product layer in the system structure, and phase exit criteria to include: (1) system specification and external interface specifications; (2) end product specifications, configuration description documents, and interface specifications; (3) end product subsystem initial specifications, if subsystems are required; (4) requirements for associated supporting enabling products; (5) end product verification plan; (6) end product validation plan; and (7) applicable logistics and operate-to procedures.

Note 1: The first application of the system design processes to develop a system structure typically results in a set of top-level requirements and one or more concepts. The form of design solution definition output could be, for example, a simulation model or paper study report.

Note 2: The output of the design solution definition process is typically called a technical data package. This package evolves from phase to phase starting with conceptual sketches or models and ending before fabrication, assembly and integration of the product with complete drawings, parts list, and other details needed for product implementation or product integration.

Note 3: Branches of the system structure tree end when there are no subsystems needed to make up an end product within a product layer. At that point the end product can be made, bought, or reused using the product implementation process. Any end product that consists of lower level subsystem products will be realized by the product integration process. The form of the product will be dependent on the product life-cycle phase, the location of the product layer in the system structure, and the phase exit criteria.

Note 4: The concept of operations for the end product should be updated to reflect the design solution definition selected ensuring that stakeholder expectations are still met.

e. Verify that the design solution definition: (1) is realizable within constraints imposed on the technical effort; (2) has specified requirements that are stated in acceptable statements and have bidirectional traceability with the derived technical requirements, technical requirements, and stakeholder expectations; and (3) has decisions and assumptions made in forming the solution consistent with its set of derived technical requirements, separately allocated technical requirements, and identified system product and service constraints.

Note 1: The use of peer reviews is recommended to evaluate the resulting design solution definition documentation against a set of established criteria consistent with the product life-cycle phase exit criteria and the product layer's location in the system structure.

Note 2: Identified anomalies should be resolved during the verification of the design solution definition.

f. Baseline the design solution definition specified requirements, including the specifications and configuration descriptions.

Note: The baselines would be established and placed under change and/or configuration control by invoking the activities of the requirements management, interface management, and configuration management processes.

g. Initiate development or acquisition of the life-cycle supporting enabling products needed for research, development, fabrication, integration, test, deployment, operations, sustainment, and disposal.

Note 1: Schedules should be such that the enabling products will be available when needed to support the product life-cycle phase activities.

Note 2: Development of enabling products and services relies on the same processes used to develop their associated operational products in the product layer.

h. Initiate development of the system products of the next lower level product layer, if any.

Note 1: Development of the next lower level of system products using the same design processes is an example of the recursive application of the repeatable system design processes.

Note 2: If this activity is not applicable, then the end product should be reviewed for making, buying, or reuse using the product implementation process.

i. Capture work products from the design solution definition activities.

Note: The work products generated during the above activities should be captured along with key decisions made, supporting decision rationale and assumptions, and lessons learned in performing the design solution definition process activities.

C.1.4.5 Process Flow Diagram

A typical process flow diagram for design solution definition is provided in Figure C-4 with inputs and their sources and the outputs and their destinations. The activities of the design solution definition process are truncated to indicate the action and object of the action.


Figure C-4 - Design Solution Definition Process

C.2 Product Realization Processes

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: (1) either product implementation or product integration, (2) product verification, (3) product validation, and (4) product transition. (See Figure 3-1 and Figure 3-2.) 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 exit criteria of the phase. Typical early phase products are in the form of reports, models, simulations, mockups, prototypes, or demonstrators. Later phase product forms include the final mission products, including payloads and experiment equipment. The product realization process descriptions that follow assume that each lowest level product goes through the sequencing shown in Figure C-5. Exceptions will need to be planned according to what has and has not been already performed.


Figure C 5 - Sequencing of Product Realization Processes

C.2.1 Product Implementation Process

C.2.1.1 Purpose

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 specified requirements (e.g., drawings, specifications).

C.2.1.2 Inputs and Sources:

a. Raw materials needed to make the end product (from existing resources or external sources).

b. End product design solution definition specified requirements (specifications) and configuration documentation for the end product of the applicable product layer, including interface specifications, in the form appropriate to satisfying the product life-cycle phase exit criteria (from Configuration Management Process).

c. Product implementation enabling products (from existing resources or Product Transition Process for enabling product realization).

C.2.1.3 Outputs and Destinations:

a. Made, bought, or reused end product in the form appropriate to the product life-cycle phase and to satisfy exit criteria (to Product Verification Process).

Note: For early life-cycle phases, products generated by the product implementation process can be in the form of reports, models, simulations, mockups, prototypes, and demonstrators. In later phases, the form may be mission-ready products, including payloads and experiment equipment.

b. Documentation and manuals in a form appropriate for satisfying the life-cycle phase exit criteria, including "as-built" product descriptions and "operate-to" and maintenance manuals (to Technical Data Management Process).

Note: "As-built" descriptions include materials for made, bought, or reused products. For early life-cycle phases, documents can be in draft form. In later phases, the documents/manuals should be in mission- or experiment-ready procedural form.

c. Product implementation work products needed to provide reports, records, and other outcomes of process activities (to Technical Data Management Process).

C.2.1.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Prepare to conduct product implementation including: (1) prepare a product implementation strategy and detailed planning and procedures and (2) determine whether the product configuration documentation is adequately complete to conduct the type of product implementation as applicable for the product life-cycle phase, location of the product in the system structure, and phase exit criteria.

b. If the strategy is for buying an existing product, participate in the buy of the product including: (1) review the technical information made available by vendors to determine if the product meets the technical requirements; (2) assist the preparation of requests for acquiring the product from a vendor; (3) assist the inspection of the delivered product and the accompanying documentation; (4) determine whether the vendor conducted product validation or if it will need to be done by a project technical team; and (5) determine the availability of enabling products to provide test, operations, and maintenance support and disposal services for the product.

c. If the strategy is to reuse a product that exists in the Government inventory, participate in acquiring the reused product including: (1) review the technical information made available for the specified product to be reused to determine if the product meets the technical requirements; (2) determine supporting documentation and user manuals' availability; (3) determine the availability of enabling products to provide test, operations, and maintenance support and disposal services for the product; (4) assist the requests for acquiring the product from Government sources; and (5) assist the inspection of the delivered product and the accompanying documentation.

d. If the strategy is to make the product:

(1) Evaluate the readiness of the product implementation enabling products to make the product.

(2) Make the specified product in accordance with the specified requirements, configuration documentation, and applicable standards.

(3) Prepare appropriate product support documentation, such as integration constraints and/or special procedures for performing product verification and product validation.

e. Capture work products and related information generated while performing the product implementation process activities.

Note: Work products include procedures used, rationale for decisions made, assumptions made in product implementation, and decisions made, actions taken to correct identified anomalies, lessons learned in performing the product implementation activities, and updated product configuration and support documentation.

C.2.1.5 Process Flow Diagram

C.2.1.5.1 A typical process flow diagram for product implementation is provided in Figure C-6 with inputs and their sources and outputs and their destinations. The activities of the product implementation process are truncated to indicate the action and object of the action.

C.2.1.5.2 The path that products from the three sources in Figure C-6 take with respect to product verification, product validation, and product transition vary based on:

a. Whether the products bought have been verified and/or validated by the vendor.

b. Whether reuse products that come from within the organization have been verified and/or validated.

c. Whether the customer for the product desires to do the product validation or have the developer perform the product validation.


Figure C 6 - Product Implementation Process

C.2.2 Product Integration Process

C.2.2.1 Purpose

The product integration process is used to transform the design solution definition into the desired end product of the product layer through assembly and integration of lower level validated end products in a form consistent with the product life-cycle phase exit criteria and that satisfies the design solution definition requirements (e.g., drawings, specifications).

C.2.2.2 Inputs and Sources:

a. Lower level products to be assembled and integrated (from Product Transition Process).

b. End product design definition specified requirements (specifications) and configuration documentation for the applicable product layer, including interface specifications, in the form appropriate to satisfying the product life-cycle phase exit criteria (from Configuration Management Process).

c. Product integration enabling products (from existing resources or Product Transition Process for enabling product realization).

C.2.2.3 Outputs and Destinations:

a. Integrated product (s) in the form appropriate to the product life-cycle phase and to satisfy phase exit criteria (to Product Verification Process).

Note: For early life-cycle phases, products generated by the product integration process can be in the form of reports, models, simulations, mockups, prototypes, and demonstrators. In later phases, the form may be in mission-ready products, including payloads and experiment equipment.

b. Documentation and manuals in a form appropriate for satisfying the life-cycle phase exit criteria, including "as-integrated" product descriptions and "operate-to" and maintenance manuals (to Technical Data Management Process).

Note: "As-integrated" descriptions include descriptive materials for integrated products. For early life-cycle phases, documents can be in draft form. In later phases, the documents or manuals should be in mission- or experiment-ready procedural form.

c. Product integration work products needed to provide reports, records, and other outcomes of process activities (to Technical Data Management Process).

C.2.2.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Prepare to conduct product integration to include: (1) preparing a product integration strategy, detailed planning for the integration, and integration sequences and procedures; and (2) determining whether the product configuration documentation is adequately complete to conduct the type of product integration applicable for the product life-cycle phase, location of the product in the system structure, and management phase exit criteria.

b. Obtain lower level products required to assemble and integrate into the desired product.

c. Confirm that the received products that are to be assembled and integrated have been validated to demonstrate that the individual products satisfy the agreed upon set of stakeholder expectations, including interfaces requirements. Note: Documented evidence that the correct products are provided for this activity is necessary. This validation can be completed by the providing organization or by an assigned technical team within the project.

d. Prepare the integration environment in which assembly and integration will take place to include evaluating the readiness of the product-integration enabling products and the assigned workforce.

Note: The product integration enabling products include, as a function of the product life-cycle phase, facilities, equipment, jigs, tooling, and assembly areas/lines. The integration environment includes test equipment, simulators (for products not available), storage areas, and recording devices.

e. Assemble and integrate the received products into the desired end product in accordance with the specified requirements, configuration documentation, interface requirements, applicable standards, and integration sequencing and procedures.

Note: This activity includes managing, evaluating, and controlling physical, functional, and data interfaces among the products being integrated.

f. Prepare appropriate product support documentation, such as special procedures for performing product verification and product validation.

g. Capture work products and related information generated while performing the product integration process activities.

Note: Work products include procedures used, rationale for decisions made, assumptions made in product integration, and decisions made, actions taken to correct identified anomalies, lessons learned in performing the product integration process activities, and updated product configuration and support documentation.

C.2.2.5 Process Flow Diagram

A typical process flow diagram for product integration is provided in Figure C-7 with inputs and their sources and the outputs and their destinations. The activities of the product integration process are truncated to indicate the action and object of the action.


Figure C 7 - Product Integration Process

C.2.3 Product Verification Process

C.2.3.1 Purpose

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.

Note: Product verification can be accomplished by inspections, analyses, demonstrations, or test in accordance with the verification plan and as a function of the product life-cycle phase.

C.2.3.2 Inputs and Sources:

a. End product to be verified (from Product Implementation Process or Product Integration Process).

b. End product specification and configuration baselines, including interface specifications, to which the product being verified was generated (from Technical Data Management Process).

Note: The baselines would be updated design solution definition specifications and configuration documents based on corrections made during product implementation or product integration.

c. Product verification plan (from Design Solution Definition Process and Technical Planning Process).

d. Product verification enabling products (from existing resources or Product Transition Process for enabling product realization).

C.2.3.3 Outputs and Destinations:

a. A verified end product (to Product Validation Process).

b. Product verification results (to Technical Assessment Process).

c. Completed verification report to include for each specified requirement: (1) the source paragraph references from the baseline documents for derived technical requirements, technical requirements, and stakeholder expectations; (2) bidirectional traceability among these sources; (3) verification type(s) to be used in performing verification of the specified requirement; (4) reference to any special equipment, conditions, or procedures for performing the verification; (5) results of verification conducted; (6) variations, anomalies, or out-of-compliance results; (7) corrective actions taken; and (8) results of corrective actions (to Technical Data Management Process).

Note: The information in this report is captured in what is often referred to as a verification matrix. This matrix is typically established and maintained once requirements traceability is initiated after obtaining stakeholder commitment to the set of stakeholder expectations.

d. Product verification work products needed to provide reports, records, and other outcomes of process activities (to Technical Data Management Process).

C.2.3.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Prepare to conduct product verification to include as applicable to the product life-cycle phase and product layer location in the system structure: (1) reviewing the product verification plan for specific procedures, constraints, conditions under which verification will take place, pre- and post-verification actions, and criteria for determining the success or failure of verification methods and procedures; (2) arranging the needed product verification enabling products and support resources; (3) obtaining the end product to be verified; (4) obtaining the specification and configuration baseline against which the verification is to be made; and (5) establishing and checking the verification environment to ensure readiness for performing the verification.

b. Perform the product verification in accordance with the product verification plan and defined procedures to collect data on each specified requirement with specific attention given to MOPs.

c. Analyze the outcomes of the product verification, including identifying verification anomalies, establishing recommended corrective actions, and establishing conformance to each specified requirement under controlled conditions.

Note: Remedial and corrective actions should be assessed using the technical assessment process and decision analysis process with recommendations made and executed by planning the technical effort again, repeating the system design processes, and/or repeating the product verification.

d. Prepare a product verification report providing the evidence of product conformance with the applicable design solution definition specified requirements baseline to which the product was generated, including bidirectional requirements traceability and actions taken to correct anomalies of verification results.

Note: The recommended content of this report is provided in C.2.3.3.c.

e. Capture the work products from the product verification.

Note: Work products include verification outcomes; records of procedural steps taken against planned procedures; any failures or anomalies in the planned verification procedures, equipment, or environment; and records citing satisfaction or nonsatisfaction of verification criteria. Also records should document:

(1) the version of the set of specification and configuration documentation used;

(2) the version of the end product verified;

(3) the version or standard for tools and equipment used, together with applicable calibration data;

(4) results of each verification, including pass or fail declarations; and

(5) discrepancies between expected and actual results.

(6) Remedial and/or corrective action taken to resolve failures or anomalies to ensure end product conformance to the specified requirements.

(7) Waivers for any requirements that were not met.

C.2.3.5 Process Flow Diagram

A typical process flow diagram for product verification is provided in Figure C-8 with inputs and their sources and the outputs and their destinations. The activities of the product verification process are truncated to indicate the action and object of the action.


Figure C 8 - Product Verification Process

C.2.4 Product Validation Process

C.2.4.1 Purpose

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 assure 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, product life-cycle phase, and applicable customer agreement.

Note 1: A product should be validated against its stakeholders' expectations before being integrated into a higher level product.

Note 2: Product validation is conducted through demonstration, inspection, analysis test, or combination thereof.

C.2.4.2 Inputs and Sources:

a. End product to be validated (from Product Verification Process).

b. Baselined stakeholder expectations (from Configuration Management Process).

Note: The baselines would be updated based on corrections made during product implementation or product integration or as a result of correcting verification anomalies.

c. Product validation plan (from Design Solution Definition Process and Technical Planning Process).

d. Product validation enabling products (from existing resources or Product Transition Process for enabling product realization).

C.2.4.3 Outputs and Destinations:

a. A validated end product (to Transition Process).

b. Product validation results (to Technical Assessment Process).

c. Completed validation report for each stakeholder expectation or subset of stakeholder expectations involved with the validation, for example: (1) the source requirement paragraph reference from the stakeholder expectations baseline; (2) validation type(s) to be used in establishing compliance with selected set of stakeholder expectations and match with each source expectation referenced; (3) identification of any special equipment, conditions, or procedures for performing the validation, which includes referenced expectation; (4) results of validation conducted with respect to the referenced expectation; (5) deficiency findings (variations, anomalies, or out-of-compliance results); (6) corrective actions taken; and (7) results of corrective actions (to Technical Data Management Process).

Note: The information in this report is captured in what is often referred to as a validation cross-reference matrix. This matrix is typically established and maintained once requirements traceability is initiated after obtaining stakeholder commitment to the set of stakeholder expectations and establishing the stakeholder expectations baseline.

d. Product validation work products needed to provide reports, records, and other outcomes of process activities (to Technical Data Management Process).

C.2.4.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Prepare to conduct product validation including, as applicable to the product life-cycle phase and product location in the system structure: (1) reviewing the product validation plan for specific procedures, constraints, conditions under which validation will take place, pre- and post-validation actions, and criteria for determining the success or failure of validation methods and procedures; (2) arranging the needed product validation enabling products and support resources; (3) obtaining the end product to be validated; (4) obtaining the stakeholder expectations baseline against which the validation is to be made; and (5) establishing and evaluating the validation environment to ensure readiness for performing the validation.

Note: Product validation environmental considerations include: measurement tools (scopes, electronic devices, probes); temporary embedded test software; recording equipment (capture test results); simulated subsystems in the loop (by software, electronics, or mechanics); simulated external interfacing products of other systems/products (representations of external threats or constraints); actual external interfacing products of other systems (aircraft, vehicles, boosters, humans); facilities; and skilled operators.

b. Perform the product validation in accordance with the product validation plan and defined procedures to collect data on performance of the product against stakeholder expectations with specific attention given to MOEs.

Note 1: Perform again any validation steps that were not in compliance with planned validation procedures or the planned environment, including equipment, measurement, or data capture failures.

Note 2: The validation environment may be a representative or simulated environment when it is not possible or cost prohibitive to use the operational environment.

c. Analyze the outcomes of the product validation to include identifying validation anomalies, establishing recommended remedial and corrective actions, and establishing conformance to stakeholder expectations under operational conditions (actual, analyzed, or simulated).

Note: Corrective actions should be assessed using the technical assessment process and decision analysis process with recommendations made and executed by planning the technical effort again and repeating the systems design processes and product realization processes.

d. Prepare a product validation report providing the evidence of product conformance with the stakeholder expectations baseline, including corrective actions taken to correct anomalies of validation results.

Note: The recommended content of this report is provided in C.2.4.3.c.

e. Capture the work products from the product validation.

Note: Work products include validation outcomes; records of procedural steps taken against planned procedures; any failures or anomalies in the planned validation procedures, equipment, or environment; and records citing satisfaction or nonsatisfaction of validation criteria. Also records should document:

(1) the version of the stakeholder expectations baseline used;

(2) the version of the end product validated;

(3) the version or standard for tools and equipment used, together with applicable calibration data;

(4) results of the product validation, including pass or fail declarations;

(5) discrepancies between expected and actual results; and

(6) waivers.

C.2.4.5 Process Flow Diagram

A typical process flow diagram for product validation is provided in Figure C-9 with inputs and their sources and the outputs and their destinations. The activities of the product validation process are truncated to indicate the action and object of the action.


Figure C 9 - Product Validation Process

C.2.5 Product Transition Process

C.2.5.1 Purpose

The product transition process is used to transition to the customer at the next level in the system structure a verified and validated end product that has been generated by product implementation or product integration for integration into an end product. For the top level end product, the transition is to the intended end user. The form of the product transitioned will be a function of the product life-cycle phase exit criteria and the location within the system structure of the product layer in which the end product exists.

Note 1: Planning for transition includes preparation of packaging, handling, transporting, storing, training or certification activities and operations, users, or installation manuals for the product life-cycle phase and the location of the end product in the system structure.

Note 2: Depending on the agreement and the product life-cycle phase, the product transition process may include installation, training, and sustainment tasks.

Note 3: For transitions during early life-cycle phases, products may be in paper form, electronic form, physical models, or technology demonstration prototypes. During later life-cycle phases, products may be a one-of-a-kind operational/mission product or one of many to be produced and delivered in a single package or container.

C.2.5.2 Inputs and Sources:

a. End product or products to be transitioned (from Product Validation Process).

b. Documentation including manuals, procedures, and processes that are to accompany the end product (from Technical Data Management Process).

Note: In early product life-cycle phases, these manuals and documents would be in draft. In later phases, the manuals and documents should be in a form ready for use and should have been verified and/or validated that they meet end product and user support needs.

c. Product transition enabling products to include packaging materials, containers, handling equipment, and storage, receiving and shipping facilities (from existing resources or Product Transition Process for enabling product realization).

C.2.5.3 Outputs and Destinations:

a. Delivered end product with applicable documentation, including manuals, procedures, and processes in a form consistent with the product life-cycle phase and location of the product in the system structure (to end user or Product Integration Processâ?"recursive loop).

Note 1: If a physical form of the product is delivered, the product should have been transitioned in protective packaging by appropriate handling and transporting mechanisms and/or stored in appropriate protective environments.

Note 2: If the end product is an enabling product providing life-cycle support (e.g., for product implementation, product integration, product verification, product validation, or product transition for the end product), the development or acquisition of the enabling product is needed to be initiated early so that it will be available when needed.

Note 3: The manuals and documents to be considered for delivery with the end product are the training modules, installation manuals, and operations and sustaining engineering processes to prepare users, installers, or maintainers to do their functions with respect to the transitioned product.

b. Product transition work products needed to provide reports, records, and other outcomes of process activities (to Technical Data Management Process).

c. Realized enabling products (to Product Implementation, Integration, Verification, Validation, and Transition Processes).

C.2.5.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Prepare to conduct product transition to include: (1) preparing a product implementation strategy to establish the type of product transition to be made (to the next higher level customer for product integration or to an end user); and (2) reviewing related end product stakeholder expectations and design solution definition specified requirements to identify special transition procedures and enabling product needs for the type of product transition, if any, for packaging, storage, handling, shipping/transporting, site preparation, installation, or sustainment.

Note 1: The product life-cycle phase and the location of the end product in the system structure will influence the form of the end product and the packaging, storage, handling, and shipping/transporting required.

Note 2: The requirements for readying the product for transition are typically addressed in stakeholder expectations and end product design solution definition specified requirements. Included are packaging requirements for protection, security, and prevention of deterioration for products placed in storage or when it is necessary to transport or ship between and within organizational facilities or between organizations by land, air, and/or water vehicles. The end product requirements should state the spectrum of environmental and stress conditions specified for the package. Particular emphasis needs to be on protecting surfaces from physical damage and preventing corrosion, rodent damage to electronic wiring or cabling, shock or stress damage, heat warping or cold fractures, and moisture and other particulate intrusion that would damage moving parts. Other packaging considerations include: economy and ease of handling or transporting (e.g., containerization); accountability (e.g., tracking system in transit); and ease and safety of unpacking (e.g., shrink wrapping, sharp edges, strength of binding materials, environmental hazards of packing materials, and weight).

Note 3: The requirements for transporting the end product are typically addressed in enabling product requirements. Factors to consider include: safety to the product, property, and humans during moving; cost of transport options in terms of acquisition, installation, and maintenance; distances involved; environments through which the product will move; volume, space and weight restrictions on transport options; and handling to/from locations/transporters.

b. Evaluate the end product, personnel, and enabling product readiness for product transition including: (1) availability and appropriateness of the documentation that will be packaged and shipped with the end product; (2) adequacy of procedures for conducting product transition; (3) availability and skills of personnel to conduct product transition; and (4) availability of packaging materials/containers, handling equipment, storage facilities, and shipping/transporter services.

Note: Evaluations should include: (1) packaging, handling, shipping, and storage procedures; (2) installation procedures; (3) use instructions; and (4) other relevant documentation such as manuals and processes for developers, users, operators, trainers, installers, and support personnel.

c. Prepare the end product for transition to include the packaging and moving the product to the shipping/transporting location and any intermediate storage.

d. Prepare sites, as required, where the end product will be stored, assembled, integrated, installed, used, or maintained, as appropriate for the life-cycle phase, position of the end product in the system structure, and customer agreement.

Note: This may include making the end product ready for assembly and integration into an upper level product; bringing the product to operational/mission readiness (with appropriate acceptance and certification tests having been completed); placing the product into operation/use; training personnel such as users, operators, and maintainers; or providing in-service support (sustainment) of the end product for operations/use, monitoring, and maintenance.

e. Transition the end product with required documentation to the customer, based on the type of transition required, e.g., to the next higher level product layer for product integration or to the end user.

f. Capture work products from product transition process activities.

Note: Work products include procedures used, rationale for decisions made, assumptions made in product transition, and decisions made, actions taken to correct identified anomalies, lessons learned in performing the product transition process activities, and updated support documentation.

C.2.5.5 Process Flow Diagram

A typical process flow diagram for product transition is provided in Figure C-10 with inputs and their sources and the outputs and their destinations. The activities of the product transition process are truncated to indicate the action and object of the action.


Figure C 10 - Product Transition Process

C.3 Technical Management Processes

There are eight technical management processesâ?"Planning, Requirements Management, Interface Management, Risk Management, Configuration Management, Technical Data Management, Assessment, and Decision Analysis. (See Figure 3-1 and Figure 3-2.) These technical management processes are intended to supplement the management requirements defined in NPR 7120.5. The NPR provides program and project managers with the technical activities that they are required to be cognizant of and are responsible for. On the other hand, the technical management process in this SE NPR: (1) provides the technical team its requirements for planning, monitoring, and controlling the technical effort as well as the technical decision analysis requirements for performing tradeoff and effectiveness analyses to support decision making throughout the technical effort; (2) focuses on (a) completion of technical process planning (preparation of the SEMP and other technical plans), (b) technical progress assessment (using technical measures and conducting life-cycle and technical reviews to assess progress against the SEMP and defined technical requirements), and (c) control of product requirements, product interfaces, technical risks, configurations, and technical data; and (3) ensures that common technical process implementations comply with NPR 7150.2 software requirements for software aspects of the system. Documentation produced through each technical management process should be managed and disposed as Federal records.

C.3.1 Technical Planning Process

C.3.1.1 Purpose

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

Note: The results of this technical planning effort should be summarized and provided to the project manager as input to the technical summary section of the project plan required by NPR 7120.5.

C.3.1.2 Inputs and Sources:

a. Project technical effort requirements and project resource constraints (from the project).

b. Agreements, capability needs and applicable product life-cycle phase(s) (from the project).

c. Applicable policies, procedures, standards, and organizational processes (from the project).

d. Prior product life-cycle phase or baseline plans (from Technical Data Management Process).

e. Replanning needs (from Technical Assessment and Technical Risk Management Processes).

C.3.1.3 Outputs and Destinations:

a. Technical work cost estimates, schedules, and resource needs, e.g., funds, workforce, facilities, and equipment (to project).

b. Product and process measures needed to assess progress of the technical effort and the effectiveness of processes (to Technical Assessment Process).

c. The SEMP and other technical plans that support implementation of the technical effort (to all processes; applicable plans to Technical Processes).

d. Technical work directives, e.g., work packages or task orders with work authorization (to applicable technical teams).

e. Technical planning work products needed to provide reports, records, and other outcomes of process activities (to Technical Data Management Process).

C.3.1.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Prepare to conduct technical planning to include:

(1) Preparing or updating a planning strategy for each of the common technical processes of this SE NPR. Determining:

(a) deliverable work products from technical efforts;

(b) technical reporting requirements;

(c) other technical information needs for reviews or satisfying product life-cycle management phase entry or exit criteria;

(d) product and process measures to be used in measuring technical performance, cost, and schedule progress;

(e) key or critical technical events with entry and success criteria;

(f) data management approach for data collection and storage and how measurement data will be analyzed, reported, and dispositioned as Federal records;

(g) technical risks that need to be addressed in the planning effort;

(h) tools and engineering methods to be employed in the technical effort; and

(i) approach to acquiring and maintaining the technical expertise needed (training and skills development plan).

b. Define the technical work to be done, including associated technical, support, and management tasks needed to generate the deliverable products and satisfy entry and success criteria of key technical events and the applicable product life-cycle management phase.

Note: Accurate identification of tasks is needed to help: (1) create viable schedules, (2) identify staffing needs, (3) determine resource loading, and (4) make acceptable cost estimations.

c. Schedule, organize, and determine the cost of the technical effort.

Note: Based on the defined technical work and identified critical events: (1) event-based and calendar-based schedules are prepared; (2) resource needs are established; (3) costs estimate are established; and (4) workforce, staff, and skill/training needs are identified and requested.

d. Prepare the SEMP and other technical plans needed to support the technical effort and perform the technical processes.

Note 1: The SEMP is described in Chapter 6, and an annotated outline is provided in Appendix D.

Note 2: Other technical plans include the product verification plan and product validation plan developed to support the product verification process and product validation process, respectively, and based on the design solution definition specified requirements to which the product to be evaluated will be generated.

Note 3: Larger projects can find descriptions of other technical plans that may be applicable to the project in ANSI/EIA 632. Smaller projects may include the provisions of applicable plans in the project plan. The key is to ensure that necessary technical activities and considerations are included in the technical effort.

e. Obtain stakeholder commitments to the technical plans.

Note: Review SEMP and other technical plans and reconcile them to reflect work and resource levels.

f. Issue authorized technical work directives to implement the technical work.

Note: Work packages or task orders that implement planned technical efforts are prepared and appropriate work authorizations requested. Authorized work directives are issued to technical teams assigned to perform the technical, support, and management activities of the planned technical effort.

g. Capture work products from technical planning activities.

Note: Work products include the planning strategy for developing any needed technical plans, procedures used for technical planning, rationale for decisions made, assumptions made during technical planning, and, with respect to decisions made, actions taken to correct identified anomalies, lessons learned in performing the technical planning activities, and updated support documentation.

C.3.1.5 Process Flow Diagram

A typical process flow diagram for technical planning is provided in Figure C-11 with inputs and their sources and the outputs and their destinations. The activities of the technical planning process are truncated to indicate the action and object of the action.


Figure C 11 - Technical Planning Process

C.3.2 Requirements Management Process

C.3.2.1 Purpose

The requirements management process is used to:

a. manage the product requirements identified, baselined, and used in the definition of the products of this layer 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.

C.3.2.2 Inputs and Sources:

a. Stakeholder expectations and technical requirements to be managed (from System Design Processes).

b. Requirement change requests (from the project and Technical Assessment Process).

c. TPM estimation/evaluation results (from Technical Assessment Process).

d. Product verification and product validation results (from Product Verification and Validation Processes).

C.3.2.3 Outputs and Destinations:

a. Requirement documents (to Configuration Management Process).

b. Approved changes to requirement baselines (to Configuration Management Process).

c. Requirements management work products needed to provide reports, records, and other outcomes of process activities (to Technical Data Management Process).

Note: Bidirectional traceability status would be included as one of the work products and used in product verification and product validation reports.

C.3.2.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Prepare to conduct requirements management, to include:

(1) Preparing or updating a strategy and procedures for:

(a) establishing that expectation and requirement statements, singularly and as a whole, are prepared in accordance with established formats and rules;

(b) identifying expectations and requirements to be managed, expectation and requirement sources, and allocation and traceability of requirements and linking product expectations and requirements with costs, weight, and power allocations, as applicable; and

(c) formal initiation, assessment, review, approval, and disposition of engineering change proposals and changes to expectation and requirements baseline.

(2) Selecting or updating an appropriate requirements management tool.

(3) Training technical team members in the established requirements management procedures and in the use of the selected/updated requirements management tool.

b. Conduct requirements management, to include: (1) capturing, storing, and documenting the expectations and requirements; (2) establishing that expectation and requirement statements are compliant with format and other established rules; (3) confirming that each established requirements baseline has been validated; and (4) identifying and analyzing out-of-tolerance system-critical technical parameters and unacceptable validation and verification results and proposing requirement-appropriate changes to correct out-of-tolerance requirements.

c. Conduct expectation and requirements traceability to include: (1) tracking expectations and requirements between baselines, especially MOEs, MOPs, and TPMs; and (2) establishing and maintaining appropriate requirements compliance matrixes that contain the requirements, bidirectional traceability, compliance status, and any actions to complete compliance.

d. Manage expectation and requirement changes to include: (1) reviewing engineering change proposals (ECPs) to determine any changes to established requirement baselines; (2) implementing formal change procedures for proposed and identified expectation or requirement changes; and (3) disseminating the approved change information.

e. Capture work products from requirements management process activities to include maintaining and reporting information on the rationale for and disposition and implementation of change actions, current requirement compliance status, and expectation and requirement baselines.

C.3.2.5 Process Flow Diagram

A typical process flow diagram for requirements management is provided in Figure C-12 with inputs and their sources and the outputs and their destinations. The activities of the requirements management process are truncated to indicate the action and object of the action.


Figure C-12 - Requirements Management Process

C.3.3 Interface Management Process

C.3.3.1 Purpose

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.

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.

Note: A less formal interface management approach can be used in conjunction with requirements management and/or configuration management process activities when the technical effort is co-located in the same project.

C.3.3.2 Inputs and Sources:

a. Internal and external functional and physical interface requirements for the products of a product layer (from user or program and System Design Processes).

b. Interface change requests (from project and Technical Assessment Processes).

C.3.3.3 Outputs and Destinations:

a. Interface control documents (to Configuration Management Processes).

b. Approved interface requirement changes (to Configuration Management Process).

c. Interface management work products needed to provide reports, records, and other outcomes of process activities (to Technical Data Management Process).

C.3.3.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Prepare or update interface management procedures for: (1) establishing interface management responsibilities for those interfaces that are part of agreement boundaries; (2) maintaining and controlling identified internal and external physical and functional interfaces; (3) preparing and maintaining appropriate physical and functional interface specifications or interface control documents and drawings to describe and control interfaces external to the system end product; (4) identifying interfaces between system products (including humans) and among configuration management items; (5) establishing and implementing formal change procedures for interface evolution; (6) disseminating the needed interface information for integration into technical effort activities and for external interface control; and (7) training technical teams and other applicable support and management personnel in the established interface management procedures.

Note: During application of the system design processes several kinds of interface requirements are baselined and thus need to be managed for each product layer:

(1) System (External). This external interface specifies the vertical functional, physical, electromagnetic, and human and interoperability requirements and characteristics in a system-to-system environment, e.g., end products with parent platform and external end products.

(2) End Product (Internal). This interface specification has horizontal internal interfaces with other end products and with the enabling products of the product layer.

(3) Enabling Product (Internal and External). This interface specification encompasses the horizontal interfaces with other enabling products and the end products of the same product layer and possibly vertical interfaces to other system end products and enabling products.

(4) Subsystem (Internal). This interface specification details the horizontal internal interfaces with the subsystem end products of the same parent within the product layer to ensure effective product integration with respect to form and fit, and, when the subsystem products are not physically mated together except by cabling or electronics, with respect to function.

b. Conduct interface management during system design activities for each product layer in the system structure to include: (1) integrating the interface management activities with requirements management activities; (2) analyzing the concept of operations to identify critical interfaces not included in the stakeholder set of expectations; (3) documenting interfaces both external and internal to each Product layer as the development of the system structure emerges and interfaces are added and existing interfaces are changed; (4) documenting origin, destination, stimulus, and special characteristics of interfaces; (5) maintaining the design solution definition for internal horizontal and vertical interfaces between Product layers in the system structure; (6) maintaining horizontal traceability of interface requirements across interfaces and capturing status in the established requirements compliance matrix; and (7) confirming that each interface control document or drawing that is established has been validated with parties on both sides of the interface.

c. Conduct interface management during product integration activities to include: (1) reviewing product integration procedures to ensure that interfaces are marked for easy and correct assembly/connection with other products; (2) identifying product integration planning to identify interface discrepancies, if any, and report to the proper technical team or technical manager; (3) confirming that a pre-check is completed on all physical interfaces before connecting products; (4) evaluating assembled products for interface compatibility; (5) confirming that product verification and product validation plans/procedures include confirming internal and external interfaces; and (6) preparing an interface evaluation report upon completion of integration, product verification, and product validation.

d. Conduct interface control to include: (1) managing interface changes within the system structure; (2) identifying and tracking proposed and directed changes to interface specifications and interface control documents and drawings; (3) confirming that the vertical and horizontal interface issues are analyzed and resolved when a change affects products on both sides of the interface; (4) controlling traceability of interface changes including source of the change, processing methods, and approvals; and (5) disseminating the approved interface change information for integration into technical efforts at every level of the project.

Note 1: Typically, an interface control working group (ICWG) establishes communication links between those responsible for design of interfacing systems, end products, enabling products, and subsystems. The ICWG has the responsibility to ensure accomplishment of the planning, scheduling, and execution of all interface activities. ICWGs are typically a technical team with appropriate technical membership from the project, each contractor, significant vendor, and program.

Note 2: An interface control document or drawing (ICD) is a document that establishes and defines the detailed interface between two or more systems, end products, system elements, or configuration items. It is used to control the defined interface early in the product life cycle and thus to reduce design changes due to poorly identified, managed, or controlled interfaces. Formal ICDs are typically necessary at external interfaces. Interfaces within the program/project may also be necessary and controlled either formally or informally to enable efficient design flexibility while still levying necessary internal interface requirements.

e. Capture work products from interface management activities. Note: Work products include the strategy and procedures for conducting interface management, rationale for interface decisions made, assumptions made in approving or denying an interface change, actions taken to correct identified interface anomalies, lessons learned in performing the interface management activities, and updated support and interface agreement documentation.

C.3.3.5 Process Flow Diagram

A typical process flow diagram for interface management is provided in Figure C-13 with inputs and their sources and the outputs and their destinations. The activities of the interface management process are truncated to indicate the action and object of the action.


Figure C-13 - Interface Management Process

C.3.4 Technical Risk Management Process

C.3.4.1 Purpose

The technical risk management process is used to examine on a continuing basis the risks of technical deviations from program/project plans and to identify potential problems before they occur. Risk management is performed across the life of the program.

C3.4.2 Inputs and Sources

a. Program/Project Risk Management Plan (from program/project).

b. Technical risks (from program/project and other common technical processes).

c. Technical risk status measurements (from Technical Assessment and Decision Analysis Processes).

d. Technical risk reporting requirements (from program/project and Technical Planning Process).

C.3.4.3 Outputs and Destinations:

a. Technical risk mitigation and/or contingency actions (to Technical Planning Process for replanning and/or redirection).

b. Technical risk reports (to project and Technical Data Management Process).

c. Work products from technical risk management activities (to Technical Data Management Process).

C.3.4.4 Activities

For the product layer in the system structure, the following activities are typically performed: (NPR 8000.4, Agency Risk Management Procedural Requirements, is to be used as a source document for defining this process and implementing procedures. Additionally, NASA/SP-2011-3422, NASA Risk Management Handbook provides guidance for managing risk in an integrated fashion.)

a. Prepare a strategy to conduct technical risk management to include: (1) documenting how the program/project risk management plan will be implemented in the technical effort; (2) planning identification of technical risk sources and categories; (3) analyzing technical risks for likelihood and consequence; (4) characterizing and prioritizing technical risks; (5) planning informed technical management (mitigation) actions; (6) tracking technical risk status against established triggers; (7) resolving technical risk by taking planned action if established triggers are tripped; and (8) communicating technical risk status and mitigation actions taken, when appropriate.

b. Identify technical risks to include: (1) identifying sources of risks related to the technical effort; (2) anticipate what could go wrong in each of the source areas to create technical risks; (3) analyzing identified technical risks for cause and importance; (4) preparing clear, understandable, and standard form risk statements; and (5) coordinating with relevant stakeholders associated with each identified technical risk.

Note 1: Typical technical risk areas include: poorly defined technical tasks, cost estimations, calendar-driven scheduling, poor definition of requirements and interfaces, new technology, environmental conditions, planning assumptions, procedures used in performing technical processes, resource availability, workforce, budget, facilities, materials, and industrial base/supply chain.

Note 2: Technical risks are typically defined by relative time frame of risk occurrence, concerns or doubts about risk circumstances, limits or boundary of risk applicability, and potential consequences.

c. Conduct technical risk assessment to include: (1) categorize the severity of consequences for each identified technical risk in terms of performance, cost, schedule, and health and safety impacts to the technical effort and project; (2) analyze the likelihood and uncertainties of events associated with each technical risk either quantitatively (by determining the probabilities) or qualitatively (e.g., very high, high, moderate, low, or very low) the probability of occurrence in accordance with program/project risk management plan rules; and (3) prioritize risks for mitigation.

Note: Typically the prioritization of the technical risk is based on whether the risk is a near- or far-term concern; possible risk mitigation options and how long the options are viable; the coupling between various sources and characteristics of risk (e.g., technologies, requirements, interfaces, test approaches, manufacturing capacity, human error, logistics, workforce capability, schedules, and costs); how the occurrence of risk can be detected; and influences of other factors (e.g., quality, health and safety, security, and interoperability).

d. Prepare for technical risk mitigation to include: (1) selecting risks for mitigation and monitoring; (2) selecting an appropriate risk-handling approach; (3) establishing the risk level or threshold when risk occurrence becomes unacceptable and triggers execution of a risk mitigation action plan, which determines whether (a) a decision or general awareness/visibility to the next higher management level is needed, (b) a request for additional required resources for effective mitigation is needed, (c) there is a potential for transfer of risk tracking and/or control functions, and (d) coordination/integration is needed with other organizations/stakeholders both inside and outside the office; (4) integrating risk mitigation activities and milestones into the integrated master schedule; (5) selecting contingency actions and triggers should risk mitigation not work to prevent a problem occurrence; (6) preparing risk mitigation and contingency action plans identifying responsibilities and authorities.

e. Monitor the status of each technical risk periodically to include: (1) tracking risk status to determine whether conditions or situations have changed so that risk monitoring is no longer needed or new risks have been discovered; (2) comparing risk status and risk thresholds; (3) reporting risk status to decision authorities when a threshold has been triggered and by an action plan implemented; (4) preparing technical risk status reports as required by the program/project risk management plan; (5) communicating risk status during life-cycle and technical reviews in the form specified by the program/project risk management plan.

f. Implement technical risk mitigation and contingency action plans when the applicable thresholds have been triggered to include: (1) monitoring the results of the action plan implemented; (2) modifying the action plan as appropriate to the results of the actions; (3) continuing actions until the residual risk and/or consequences impacts are acceptable or become a problem to be solved; (4) communicate to the project when risks are beyond the scope of the technical effort to control, will affect a product higher in the system structure, or represent a significant threat to the technical effort or project success; (5) preparing action plan effectiveness reports as required by the project risk management plan; and (6) communicating action plan effectiveness during life-cycle and technical reviews in the form specified by the program/project risk management plan.

g. Capture work products from technical risk management activities.

Note: Work products include the strategy and procedures for conducting technical risk management; rationale for technical risk management decisions made; assumptions made in prioritizing, handling, and reporting technical risks and action plan effectiveness; actions taken to correct action plan implementation anomalies; and lessons learned in performing the technical risk management activities.

C.3.4.5 Process Flow Diagram

A typical process flow diagram for technical risk management is provided in Figure C-14 with inputs and their sources and the outputs and their destinations. The activities of the technical risk management process are truncated to indicate the action and object of the action.


Figure C-14 - Technical Risk Management Process

C.3.5 Configuration Management Process

C.3.5.1 Purpose

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, disposing them in accordance with NPR 1441.1, NASA Records Retention Schedules.

C.3.5.2 Inputs and Sources:

a. Project configuration management plan, if any (from project).

b. Engineering Change Proposals (ECPs) from contractors, if any, and technical teams.

c. Expectations and requirement outputs to include stakeholder expectations, technical requirements, derived technical requirements, system and end product specifications, requirement documents, and interface control documents/drawings (from Requirements and Interface Management Processes).

d. Approved requirement baseline changes, including interface requirement changes (from Requirements Management and Interface Management Processes).

e. Concepts of operations, enabling product strategies, logical decomposition models, SEMP, technical plans, and other configuration items identified in the list of configuration items to be controlled (from Stakeholder Expectation Definition, Logical Decomposition, Technical Planning, and other technical processes).

f. Those identified risks with the potential to impact end products, enabling products, and other work products placed under configuration control.

C.3.5.3 Outputs and Destinations:

a. List of configuration items to be placed under control (to applicable technical processes).

b. Current baselines (to Technical Requirements Definition, Logical Decomposition, Design Solution Definition, and Product Implementation, Integration, Verification, and Validation Processes).

Note: A configuration management baseline identifies an agreed upon description of the attributes of a work product or set of work products at a point in time and provides a known configuration to which changes are addressed. Three example baselines for flight systems and ground support systems that are often referenced are the "functional," "allocated," and "product" baselines. Functional baselines are established for each product layer system element prior to the start of preliminary design. Allocated baselines are established for each Product layer end product with the successful completion of a Preliminary Design Review (PDR) at each level of the system structure. The product baseline represents the configuration of each end product.

c. Configuration management reports (to project and Technical Data Management Process).

d. Work products from configuration management activities (to Technical Data Management Process).

C.3.5.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Prepare a strategy to conduct configuration management for the system products and designated work products to include: (1) documenting how the project configuration management plan, if any, will be implemented; (2) identifying items to be put under configuration control; (3) identifying schema of identifiers to accurately describe a configuration item and its revisions or versions; (4) controlling changes to configuration items; (5) maintaining and reporting disposition and implementation of change actions to appropriate stakeholders, including technical teams within the project; (6) ensuring that products are in compliance with specifications and configuration documentation during reviews and audits; (7) providing the appropriate reference configuration at the start of each product life-cycle phase; (8) obtaining appropriate tools for configuration management; and (9) training appropriate technical team members and other technical support and management personnel in the established configuration management strategy and any configuration management procedures and tools.

b. Identify baselines to be under configuration control to include: (1) listing the configuration items to control; (2) providing each configuration item with a unique identifier; (3) identifying acceptance requirements for each baseline identified for control; (4) identifying the owner of each configuration item; and (5) establishing a baseline configuration for each configuration item.

Note: Typical acceptance requirements for a baseline include: product life-cycle management phase and entry or exit criteria to be satisfied; when the baseline will be approved; when work products will be ready for evaluation; degree of control desired; cost and schedule limitations; and customer requirements.

c. Manage configuration change control to include: (1) establishing change criteria, procedures, and responsibilities; (2) receive, record, and evaluate change requests; (3) tracking change requests to closure; (4) obtaining appropriate approvals before implementing a change; (5) incorporating approved changes in appropriate configuration items; (6) releasing changed configuration items for use; and (7) monitoring implementation to determine whether changes resulted in unintended effects (e.g., have compromised safety or security of baseline product).

Note: A configuration management change board is typically established to receive, review, and approve change requests such as an engineering change proposal submitted by a contractor.

d. Maintain the status of configuration documentation to include: (1) maintaining configuration item description records and records that verify readiness of configuration items for testing, delivery, or other related technical efforts; (2) maintaining change requests, disposition action taken, and history of change status; (3) maintaining differences between successive baselines; and (4) controlling access to and release of configuration baselines.

e. Conduct configuration audits to include: (1) auditing baselines under control to confirm that the actual work product configuration matches the documented configuration, the configuration is in conformance with product requirements, and records of all change actions are complete and up to date; (2) identifying risks to the technical effort based on incorrect documentation, implementation, or tracking of changes; (3) assessing the integrity of the baselines; (4) confirming the completeness and correctness of the content of configuration items with applicable requirements; (5) confirming compliance of configuration items with applicable configuration management standards and procedures; and (6) tracking action items to correct anomalies from audit to closure.

f. Capture work products from configuration management activities to include a list of identified configuration items; description of configuration items placed under control; change requests, disposition of the requests, and rationale for the dispositions; documented changes with reason for changes and change actions; archive of old baselines; and required reports on configuration management outcomes.

C.3.5.5 Process Flow Diagram

A typical process flow diagram for configuration management is provided in Figure C-15 with inputs and their sources and the outputs and their destinations. The activities of the configuration management process are truncated to indicate the action and object of the action.


Figure C-15 - Configuration Management Process

C.3.6 Technical Data Management Process

C.3.6.1 Purpose

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 life;

c. manage and dispose 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.

g. effectively manage authoritative data that defines, describes, analyzes, and characterizes a product life cycle.

h. ensure consistent, repeatable use of effective PDLM processes, best practices, interoperability approaches, methodologies, and traceability.

i. Ensure product data accessibility and availability, including a method to archive the data.

C.3.6.2 Inputs and Sources:

a. Technical data and work products to be managed (from all technical processes and contractors).

b. Requests for technical data (from all technical processes and project).

C.3.6.3 Outputs and Destinations:

a. Form of technical data products (to all technical processes and contractors).

b. Technical data electronic exchange formats (to all technical processes and contractors).

c. Delivered technical data (to project and all technical processes).

C.3.6.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Prepare a strategy for the conduct of technical data management to include: (1) determining required data content and form and electronic data exchange interfaces in accordance with international standards or agreements; (2) establishing a framework for technical data flow within the project technical processes and to/from contractors; (3) designating technical data management responsibilities and authorities regarding origination, generation, capture, archiving, security, privacy, and disposition of technical data work products; (4) establishing the rights, obligations, and commitments regarding the retention of, transmission of, and access to technical data items; (5) establishing relevant data storage, transformation, transmission, and presentation standards and conventions to be used; (6) establishing project or program policy and agreements or legislative constraints; (7) describing the methods, tools, and metrics used during the technical effort and for technical data management; and (8) training appropriate technical team members and support and management personnel in the established technical data management strategy and related procedures and tools.

b. Collect and store required technical data to include: (1) identifying existing sources of technical data that are designated as outputs of the common technical processes; (2) collecting and storing technical data in accordance with the technical data management strategy and procedures; (3) recording and distributing lessons learned; (4) performing technical data integrity checks on collected data to confirm compliance with content and format requirements and identifying errors in specifying or recording data; and (5) prioritizing, reviewing, and updating technical data collection and storage procedures. c. Maintain stored technical data to include: (1) managing the databases to maintain proper quality and integrity of the collected and stored technical data and to confirm that the technical data is secure and is available to those with authority to have access; (2) performing technical data maintenance as required; (3) preventing the stored data from being used or accessed inappropriately; (4) maintaining the stored technical data in a manner that protects it against foreseeable hazards, such as fire, flood, earthquake, and riots; and (5) maintaining periodic backups of each technical database.

d. Provide technical data to authorized parties to include: (1) maintaining an information library or reference index to provide data available and access instructions; (2) receiving and evaluating requests for technical data and delivery instructions; (3) confirming that required and requested technical data is appropriately distributed to satisfy the needs of the requesting party and in accordance with established procedures, directives, and agreements; (4) confirming that electronic access rules are followed before allowing access to the database and before any data is electronically released/transferred to the requester; and (5) providing proof of correctness, reliability, and security of technical data provided to internal and external recipients.

e. Capture work products from technical data management activities.

Note: The work products generated during the above activities should be captured along with key decisions made, supporting decision rationale and assumptions, and lessons learned in performing the technical data management process.

C.3.6.5 Process Flow Diagram

A typical process flow diagram for technical data management is provided in Figure C-16 with inputs and their sources and the outputs and their destinations. The activities of the technical data management process are truncated to indicate the action and object of the action.


Figure C-16 - Technical Data Management Process

C.3.7 Technical Assessment Process

C.3.7.1 Purpose

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.

C.3.7.2 Inputs and Sources:

a. Process and product measures (from Technical Planning Process).

b. Technical plans, including the SEMP (from Technical Planning Process).

c. Risk reporting requirements during life-cycle and technical reviews (from project).

d. Technical cost and schedule status reports (from project).

e. Product measurements (from Product Verification and Product Validation Processes).

f. Decision support recommendations and impacts (from Decision Analysis Process).

C.3.7.3 Outputs and Destinations:

a. Assessment results and findings, including technical performance measurement estimates of measures (to Technical Planning, Technical Risk Management, and Requirements Management Processes).

b. Analysis support requests (to Decision Analysis Process).

c. Life-cycle and technical review reports (to project and Technical Data Management Process).

d. Corrective action and requirement change recommendations, including actions to correct out-of-tolerance TPMs (to Technical Planning, Requirements Management, and Interface Management Processes).

e. Work products from technical assessment activities (to Technical Data Management Process).

C.3.7.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Prepare a strategy for conducting technical assessments to include: (1) identifying the plans against which progress and achievement of the technical effort are to be assessed; (2) establishing procedures for obtaining cost expenditures against work planned and task completions against schedule; (3) identifying and obtaining technical requirements against which product development progress and achievement will be assessed and establishing the procedures for conducting the assessments; (4) establishing events when TPMs, estimation or measurement techniques, and rules for taking action when out-of-tolerance conditions exist will be assessed; (5) identifying and planning for phase-to-phase life-cycle and technical reviews and product layer vertical progress reviews, as well as establishing review entry and success criteria, review board members, and close-out procedures; (6) establishing which technical effort work products will undergo peer review, the team members who will perform the peer reviews, and reporting requirements; and (7) training team members, support staff, and managers involved in conducting technical assessment activities.

b. Assess technical work productivity (progress and achievement against plans) to include: (1) identifying, collecting, and analyzing process measures (e.g., earned value measurements for measuring progress against planned cost, schedule, resource use, and technical effort tasks) and identifying and reporting cost-effective changes to correct variances; (2) monitoring stakeholder involvement according to the SEMP; and (3) monitoring technical data management against plans.

c. Assess product quality (progress and achievements against technical requirements) to include: (1) identifying, collecting, and analyzing the degree of technical requirement and TPM satisfaction; (2) assessing the maturity of the product layer products and services as applicable to the product life-cycle phases; (3) determining any variances from expected values of product performance and identifying and defining cost-effective changes to correct variances.

Note: Product measures tell the degree of satisfaction of stakeholder expectations and deliver an ever improving value to the customers of system products and services. Product measures also indicate that the design process is continuing in the direction of an acceptable solution. An example of an input product measure is the quality of materials and skills of assigned project personnel. An example of an output metric is a TPM. A TPM provides an early warning of the adequacy of a design in satisfying selected critical technical parameter requirements. A "critical technical parameter" is one that characterizes a significant total system qualifier (e.g., one or more of the MOPs). TPMs also examine the marginal cost benefit of performance in excess of requirements. In addition, it should be possible to project the evolution of the parameter as a function of time toward the desired value at the completion of development. The projection can be based on test, planning, or historical data.

d. Conduct technical reviews to include: (1) identifying the type of life-cycle and technical reviews and each review's purpose and objectives (see Chapter 5 for specific life-cycle reviews that apply); (2) determining progress toward satisfying entry criteria; (3) establishing the makeup of the review team; (4) preparing the review presentation materials; and (5) identifying and resolving action items resulting from the review.

Note 1: Reviews are typically closed out when the minutes have been prepared, approved, and distributed; action items have been resolved; and the review completion documented and approved by the review chairperson.

Note 2: This activity includes peer reviews, which are planned, focused reviews by technical team peers on a single work product with the intent of identifying issues prior to that work product moving on to the next step. A peer review includes planning, preparing, conducting, analyzing outcomes, and identifying and implementing corrective actions.

e. Capture work products from the conduct of technical assessment activities to include: (1) identifying variances resulting from technical assessments; (2) identifying and reporting changes to correct variances; (3) recording methods used in doing assessment activities; (4) documenting assumptions made in arriving at the process and product measure outcomes; and (5) reporting corrective action recommendations.

C.3.7.5 Process Flow Diagram

A typical process flow diagram for technical assessment is provided in Figure C-17 with inputs and their sources and the outputs and their destinations. The activities of the technical assessment process are truncated to indicate the action and object of the action.


Figure C 17 - Technical Assessment Process

C.3.8 Decision Analysis Process

C.3.8.1 Purpose

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. This process is used throughout the system life cycle to evaluate the impact of decisions 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.

C.3.8.2 Inputs and Sources:

a. Decisions needed, alternatives, issues, or problems and supporting data (from all Technical Processes).

b. Analysis support requests (from Technical Assessment Process).

C.3.8.3 Outputs and Destinations:

a. Alternative selection recommendations and impacts (to all Technical Processes).

b. Decision support recommendations and impacts (to Technical Assessment Process).

c. Work products of decision analysis activities (to Technical Data Management Process).

C.3.8.4 Activities

For the product layer in the system structure, the following activities are typically performed:

a. Establish guidelines to determine which technical issues are subject to a formal analysis/evaluation process to include: (1) when to use a formal decision-making procedure, for example, as a result of an effectiveness assessment, a technical tradeoff, a problem needing to be solved, action needed as a response to risk exceeding the acceptable threshold, verification or validation failure, make/buy choice, evaluating a solution alternative, or resolving a requirements conflict; (2) what needs to be documented; (3) who will be the decision makers and their responsibilities and decision authorities; and (4) how decisions will be handled that do not require a formal evaluation procedure.

b. Define the criteria for evaluating alternative solutions to include: (1) the types of criteria to consider, including technology limitations, environmental impact, health and safety, risks, total ownership and life-cycle costs, and schedule impact; (2) the acceptable range and scale of the criteria; and (3) the rank of each criterion by its importance.

c. Identify alternative solutions to address decision issues to include alternatives for consideration in addition to those that may be provided with the issue.

d. Select evaluation methods and tools/techniques based on the purpose for analyzing a decision and on the availability of the information used to support the method and/or tool.

Note: Typical evaluation methods include: simulations; weighted trade-off matrices; engineering, manufacturing, cost, and technical opportunity studies; surveys; extrapolations based on field experience and prototypes; user analysis; and testing.

e. Evaluate alternative solutions with the established criteria and selected methods to include: (1) evaluation of assumptions related to evaluation criteria and of the evidence that supports the assumptions; and (2) evaluation of whether uncertainty in the values for alternative solutions affects the evaluation; (3) assessment of models and simulations, where applicable, to determine acceptability for the specific use and subsequent credibility of the produced results. The extent of these modeling and simulation assessments are to be determined by the criticality of the results, the risk of using incorrect results, and the degree to which the results influence a decision. Procedures for this are outlined in NASA STD-7009 and its associated Handbook (NASA-HDBK-7009).

f. Select recommended solutions from the alternatives based on the evaluation criteria to include documenting the information that justifies the recommendations and gives the impacts of taking the recommended course of action.

g. Report the analysis/evaluation results/findings with recommendations, impacts, and corrective actions.

h. Capture work products from decision analysis activities to include: (1) decision analysis guidelines generated and strategy and procedures used; (2) analysis/evaluation approach, criteria, and methods and tools used; (3) analysis/evaluation results, assumptions made in arriving at recommendations, uncertainties, and sensitivities of the recommended actions or corrective actions; and (4) lessons learned and recommendations for improving future decision analyses.

C.3.8.5 Process Flow Diagram

A typical process flow diagram for technical decision analyses is provided in Figure C-18 with inputs and their sources and the outputs and their destinations. The activities of the decision analysis process are truncated to indicate the action and object of the action.


Figure C 18 - Decision Analysis Process



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

DISTRIBUTION:
NODIS


This Document Is Uncontrolled When Printed.
Check the NASA Online Directives Information System (NODIS) Library
to Verify that this is the correct version before use: http://nodis3.gsfc.nasa.gov