2.120.3 Product Integration Process

Manual Transmittal

October 14, 2015

Purpose

(1) This transmits a revised Engineering, Product Integration Process.

Material Changes

(1) Updated to current IPM template.

(2) Editorial changes only.

Effect on Other Documents

Version 1.0 dated July 17, 2014 is superseded

Audience

The Product Integration Process is applicable to all ACIO areas with responsibility for Product Integration.

Effective Date

(10-14-2015)

Terence V. Milholland
Chief Technology Officer

Introduction

  1. This document describes the formal process for implementing the requirements of the Product Integration process. It provides an operational definition of the major components of the process and how to perform each step in the process. This document also describes the logical arrangements of steps that are essential to successfully completing the process and achieving its desirable outcome.

Administration

  1. All proposed changes to this document must be submitted in writing, with supporting rationale, to Solution Engineering.

Overview

  1. A process is defined as “A set of related of activities that accomplish a common goal”. The process definition laid out in this document further breaks down these Activities into Tasks, each of which have a complete set of attributes defined such as data and tool specifications and the role(s) responsible for executing the tasks. The document also includes process goal and objectives, metrics, role definitions, policies and other process related attributes.

Process Description

  1. The Product Integration (PI) Process addresses the integration of product components into more complex product components or into complete products.

Goal

  1. The process goal describes a specific purpose or achievement toward which the efforts of the process are directed. Each process has a specific focus and when combined with the other processes, forms a comprehensive framework for delivering and managing services.

Objectives

  1. Process objectives describe material outcomes that are produced or achieved by the process. The following is a list of objectives for this process:

    • To establish a product integration strategy

    • To establish a product integration environment

    • To establish product integration procedures and criteria

    • To manage product component interfaces

    • To assemble, evaluate, package, and deliver products or product components

Workflow

  1. A workflow consists of Activities and Tasks, Inputs and Outputs, Roles, and Flow Diagrams. It describes the tasks, procedural steps, organizations or people involved, required input and output information, and tools needed for each step of the process.

Main Process Diagram

  1. Product Integration Process

    Figure 2.120.3-1

    This is an Image: 59978001.gif

    Please click here for the text description of the image.

Inputs

  1. Process inputs are used as triggers to initiate the process and to produce the desired outputs. Users, stakeholders or other processes provide inputs. The following is a list of inputs for this process:

    Name Description Supplier
    Design Specification Report The DSR documents the logical and physical design of a proposed solution from all applicable perspectives. The DSR is created in the Preliminary Design phase (MS 3) and is updated with physical design details during the Detailed Design phase (MS 4A). Technical Solution Process
    Government Equipment List The GEL provides a complete listing of equipment to be installed for use in various system environments. The system environments needing a GEL are: Development, Unit Test, Integration, Production and Disaster Recovery. The purpose of the GEL is to identify and track the incremental hardware and software required by a project for the proposed system. Technical Solution Process
    Interface Control Document The ICD defines the details for boundary conditions and data at the design solution interfaces. The purpose of the ICD is to establish an agreement of responsibilities among the organizations owning the interfacing entities. The ICD is first created in the Preliminary Design phase (MS 3) and is subsequently updated during the Detailed Design phase (MS 4A). Technical Solution Process
    Business System Requirements Reports (BSRR) The BSRR documents a feasible, quantified, verifiable set of requirements that define and bound the business system or subsystem(s) being developed or enhanced by the project. These requirements form the basis for the business system design, development, integration, and deployment. The requirements in the BSRR document the nature and scope, or boundary, of the business system Requirements Management Process

Outputs

  1. Each process produces tangible outputs. These outputs can take the form of products or data and can be delivered to a user or stakeholder, or, they can be used as inputs to other processes. Outputs are measurable in terms of quantity and quality.

    Name Description Recipient
    Product Integration Strategy The product integration strategy describes the approach for receiving, assembling, and evaluating the product components that comprise the product.
    • Solution Engineering

    • Enterprise Operations

    Product Integration Environment The environment for product integration can either be acquired or developed. To establish an environment, requirements for the purchase or development of equipment, software, or other resources will need to be developed. These requirements are gathered when implementing the processes associated with the Requirements Development process area. The product integration environment can include the reuse of existing organizational resources. The decision to acquire or develop the product integration environment is addressed in the processes associated with the Technical Solution process area.
    • Solution Engineering

    • Enterprise Operations

    Product Integration Procedure Product Integration procedures for the integration of the product components can include such things as the number of incremental iterations to be performed and details of the expected tests and other evaluations to be carried out at each stage.
    • Solution Engineering

    • Enterprise Operations

    Product Integration Criteria Product Integration criteria indicate the readiness of a product component for integration or its acceptability.
    • Solution Engineering

    • Enterprise Operations

    Delivered Products Products installed at the operational site and confirmed to operate correctly.
    • Enterprise Operations

Activities

  1. An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. Identify the activities in the process and provide a brief description. The activities must correspond with the high-level process flow diagram above.

    ID Name Description
    PI 1.0 Prepare for Product Integration
    • Establish and maintain a product integration strategy that describes the approach for receiving, assembling, and evaluating the product components and aligns with the technical approach.

    • Establish and maintain the environment needed to support the integration of product components.

    • Establish and maintain procedures and criteria for integration of the product components.

    PI 2.0 Review Interface Descriptions for Completeness The purpose of this step is to ensure that implemented interfaces are complete and compatible.
    PI 3.0 Manage Interfaces The purpose of this step is to manage the interfaces to ensure consistency of the interfaces throughout the life of the system, compliance with architectural decisions and constraints, and resolution of conflict, noncompliance, and change issues.
    PI 4.0 Confirm Readiness of System Components for Integration The purpose of this step is to ensure that the properly identified system component that meets its description can actually be assembled according to the product integration strategy and procedures.
    PI 5.0 Assemble System Components The purpose of this step is to assemble system components according to the product integration strategy and procedures.
    PI 6.0 Evaluate Assembled System Components The purpose of this step is to ensure the compatibility of the interfaces. This evaluation involves examining and testing assembled product components for performance, suitability, security, and readiness using the product integration procedures, criteria, and environment.
    PI 7.0 Package and Deliver the System or System Components The purpose of this step is to assemble the system for independent testing.

Roles

  1. Each process defines at least one role. Each role is assigned to perform specific tasks within the process. The responsibilities of a role are confined to the specific process. They do not imply any functional standing within the hierarchy of an organization. For example, the process manager role does not imply the role is associated with or fulfilled by someone with functional management responsibilities within the organization. Within a specific process, there can be more than one individual associated with a specific role. Additionally, a single individual can assume more than one role within the process although typically not at the same time.

    Name Description
    Lead Integrator Responsible for:
    • Planning and executing the integration of system components into a larger system

    Component Designer Responsible for:
    • Integration of system components into larger system components or into the final system

    • Management of component and sub-component interfaces both internal and external

    • Design of components and sub-components

    Developer Responsible for:
    • Creating and /or modifying code

    • Performing own unit testing on the created code and notifying their lead integrator when unit testing is completed

    • Documenting code

    • Ensuring that all development work products are completed

    Stakeholder Responsible for:
    • Ensuring the needs and concerns are considered

    • These are the specific people or groups who have a stake, or an interest, in the outcome of the project

    • The stakeholders may be different for each step or activity

    Quality Assurance Responsible for:
    • Verification of the execution of each of the process steps and the work products produced by them

    Operations Personnel Responsible for:
    • Site preparation

    • Product Installation

    • Confirms correct operation of installed system

    Tester Responsible for:
    • Defined verification tests against requirements

    Security Responsible for:
    • Security requirements, criteria, and procedures comply with Security standards

Process Control

  1. Activities involved in ensuring a process is predictable, stable, and consistently operating at the target level of performance.

Controls

  1. Process controls represent the policies and guiding principles on how the process will operate. Controls provide direction over the operation of processes and define constraints or boundaries within which the process must operate.

    Name Description
    Product Integration Policy Product Integration is a required activity mandated by the IRS CTO.
    Scope The Product Integration process is limited to all ACIO areas with responsibility for Product Integration.
    Process Metrics The Product Integration Process Monitors will continuously verify to what degree the Product Integration Process is being used.

Metrics

  1. Metrics are used for the quantitative and periodic assessment of a process. They should be associated with targets that are set based on specific business objectives. Metrics provide information related to the goals and objectives of a process and are used to take corrective action when desired results are not being achieved and can be used to drive continual improvement of process effectiveness and efficiency.
    Management will regularly set targets for process performance, gather quantifiable data related to different functions of the Product Integration process, and review that data in order to make informed decisions and take appropriate corrective action, if necessary. All Measurements will have a defined data dictionary, map to the organizational strategic goals, and be documented in a Process Measurement Plan. The Process Measurement Plan template is available in the IT PAL.

Policies

  1. Policies outline a set of plans or courses of action that are intended to influence and determine decisions or actions of a process. Policies provide an element of governance over the process that provides alignment to business vision, mission and goals.

Process Management
  1. Statement: The Product Integration process will have a single Process Owner and a separate Process Manager, responsible for implementation and ensuring adherence to the process. The process will be reviewed regularly to ensure that it continues to support the business requirements of the enterprise. The process will be designed and developed based on ROI to the business. Process metrics will be focused on providing relevant information as opposed to merely presenting raw data.

People
  1. Statement: Roles and responsibilities for the process must be clearly defined and appropriately staffed with people having the required skills and training. Upper management to the staff and business customers of IT must clearly and regularly communicate the mission, goals, scope and importance of the process. All IT staff (direct and indirect users of the process) shall be trained at the appropriate level to enable them to support the process.
    Rationale: It is imperative that people working in, supporting or interacting with the process in any manner understand what they are supposed to do. Without that understanding Product Integration will not be successful.

Process
  1. Statement: The Process Owner must approve modifications to the Product Integration process. The design of the process must include appropriate interfaces with other processes to facilitate data sharing, escalation and workflow. The process must be capable of providing data to support real-time requirements as well as historical/trending data for overall process improvement initiatives. The process must be fully documented, published and accessible to the various stakeholders of the process. The process will be reviewed on a periodic basis in order to ensure it continues to support organizational goals and objectives (continuous improvement). The process must include Inputs, Outputs, Controls, Metrics, Activities, Tasks, Roles and Responsibilities, Tool and Data requirements along with documented process flows. The process will be kept straight forward, rational, and easy to understand.
    Rationale: The process must meet operational and business requirements.

Technology and Tools
  1. Statement: All tools selected must conform to the enterprise architectural standards and direction. Existing in-house tools and technology will be used wherever possible, new tools will only be entertained if they satisfy a business need that cannot be met by current in-house tools. The selection of supporting tools must be process driven and based on the requirements of the business. Selected tools must provide ease of deployment, customization and use. The selected tools must support heterogeneous platforms. Automated workflow, notification and escalation will be deployed wherever possible to minimize delays, ensure consistency, reduce manual intervention and ensure appropriate parties are made aware of issues requiring their attention. The tools used by this process are the following:

    • Solution Engineering Sharepoint

    Rationale: Technology and tools should be used to augment the process capabilities, not become an end themselves.

Tailoring Guidelines

  1. The tailoring guidelines identify the allowable variations of the IT organizations standard process as needed for adjustments (adding, deleting, modifying) relative to specific operational or functional needs of another organization. Process tailoring is about roles and procedures, not the standard process or major activities defined in this process. All tailoring request, with supporting rationale, must be submitted in writing to and approved by the Product Integration owner.

Training

  1. Process training involves training all stakeholders about key processes that are crucial for an organization to deliver business objectives. Training provides clarity to employees on a set of procedures that needs to be carried out as part of the process and the best possible way to do them. List below the training resources available for this process:

    • Product Integration Overview, ELMS course #52794

Procedure

  1. Procedure

Activities

  1. Activities
    An activity is a major unit of work to be completed in achieving the objectives of the process. A process consists of a sequence of related activities that transforms inputs into outputs and performed by the roles defined in the process. Identify the activities in the process and provide a brief description. The activities must correspond with the high-level process flow diagram above.

    ID Name Description
    PI 1.0 Prepare for Product Integration The purpose of preparing for Product Integration is to:
    • Establish and maintain a product integration strategy that describes the approach for receiving, assembling, and evaluating the product components and aligns with the technical approach.

    • Establish and maintain the environment needed to support the integration of product components.

    • Establish and maintain procedures and criteria for integration of the product.

    PI 2.0 Review Interface Descriptions for Completeness The purpose of this step is to ensure that implemented interfaces are complete and compatible.
    PI 3.0 Manage Interfaces The purpose of this step is to manage the interfaces to ensure consistency of the interfaces throughout the life of the system, compliance with architectural decisions and constraints, and resolution of conflict, noncompliance, and change issues.
    PI 4.0 Confirm Readiness of System Components for Integration The purpose of this step is to ensure that the properly identified system component that meets its description can actually be assembled according to the product integration strategy and procedures.
    PI 5.0 Assemble System Components The purpose of this step is to assemble system components according to the product integration strategy and procedures.
    PI 6.0 Evaluate Assembled System Components The purpose of this step is to ensure the compatibility of the interfaces. This evaluation involves examining and testing assembled product components for performance, suitability, security, and readiness using the product integration procedures, criteria, and environment.
    PI 7.0 Package and Deliver the System or System Components The purpose of this step is to assemble the system for independent testing.
PI 1.0:
  1. Prepare for Product Integration

    ID Task Name and Description Role RACI
    PI 1.1 Identify the system components to be integrated.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.2 Identify the verifications to be performed during the integration of the system components. This identification includes verifications to be performed on interfaces.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.3 Identify alternative system component integration strategies. Developing an integration strategy can involve specifying and evaluating several alternative integration strategies or sequences.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.4 Select the best integration strategy.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.5 Periodically review the product integration strategy and revise as needed.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.6 Record the rationale for decisions made and deferred.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.7 Identify the requirements for the product integration environment.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.8 Identify verification procedures and criteria for the product integration environment.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.9 Decide whether to make or buy the needed product integration environment.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.10 Develop an integration environment if a suitable environment cannot be acquired.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.11 Maintain the product integration environment throughout the project.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.12 Dispose of those portions of the environment that are no longer useful.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.13 Establish and maintain criteria for system component integration and evaluation.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 1.14 Establish and maintain criteria for validation and delivery of the integrated system.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

Flow Diagram
  1. PI 1.0 Flow Diagram

    Figure 2.120.3-2

    This is an Image: 59978002.gif

    Please click here for the text description of the image.

PI 2.0
  1. Review Interface Descriptions for Completeness

    ID Task Name and Description Role RACI
    PI 2.1 Review interface data for completeness and ensure complete coverage of all interfaces.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 2.2 Ensure that system components and interfaces are marked to ensure easy and correct connection to the joining system component.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 2.3 Periodically review the adequacy of interface descriptions.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 2.4 Conditional Activity: If interface issues are discovered, advise the Technical.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 2.5 Solution (TS) Process practitioner return to TS Process Step 4 in order to correct the issues. When the interface issues have been corrected, resume Product Integration Step 2.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

Flow Diagram
  1. PI 2.0 Flow Diagram

    Figure 2.120.3-3

    This is an Image: 59978003.gif

    Please click here for the text description of the image.

PI 3.0
  1. Manage Interfaces

    ID Task Name and Description Role RACI
    PI 3.1 Ensure the compatibility of the interfaces throughout the life of the system
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 3.2 Resolve conflict, noncompliance, and change issues
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 3.3 Create and maintain a repository for interface data accessible to all project participants
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 3.4 Update Configuration Item information if required
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

Flow Diagram
  1. PI 3.0 Flow Diagram

PI 4.0
  1. Confirm Readiness of System Components for Integration

    ID Task Name and Description Role RACI
    PI 4.1 Track the status of all system components as soon as they become available for integration.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.2 Ensure that system components are delivered to the product integration environment in accordance with the product integration strategy and procedures.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.3 Confirm the receipt of each properly identified system component.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.4 Ensure that each received system component meets its description.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.5 Check the configuration status against the expected configuration.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.6 Perform a pre-check (e.g., by a visual inspection, using basic measures) of all the physical interfaces before connecting system components together.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.7 Conditional Activity: If system component design issues are discovered, advise the Technical Solution (TS) Process practitioner return to TS Process Step 5 in order to correct the issues. When the system component design issues have been corrected, resume Product Integration Process Step 2.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    PI 4.8 Conditional Activity: If system component implementation issues are discovered, advise the Technical Solution (TS) Process practitioner return to TS Process Step 7 in order to correct the issues. When the system component implementation issues have been corrected, resume Product Integration Process Step 2.
    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

Flow Diagram
  1. PI 4.0 Flow Diagram

    Figure 2.120.3-5

    This is an Image: 59978005.gif

    Please click here for the text description of the image.

PI 5.0
  1. Assemble System Components

    ID Task Name and Description Role RACI
    PI 5.1 Ensure the readiness of the product integration environment.
    • Component Designer

    • Developer

    • R

    • C

    PI 5.2 Conduct integration in accordance with the product integration strategy, procedures, and criteria.
    • Component Designer

    • Developer

    • R

    • C

    PI 5.3 Record all appropriate information (e.g., configuration status, serial numbers of the system components, types, calibration date of the meters).
    • Component Designer

    • Developer

    • R

    • C

    PI 5.4 Revise the product integration strategy, procedures, and criteria as appropriate.
    • Component Designer

    • Developer

    • R

    • C

Flow Diagram
  1. PI 5.0 Flow Diagram

    Figure 2.120.3-6

    This is an Image: 59978006.gif

    Please click here for the text description of the image.

PI 6.0
  1. Evaluate Assembled System Components

    ID Task Name and Description Role RACI
    PI 6.1 Conduct the evaluation of assembled system components following the product integration strategy, procedures, and criteria.
    • Lead Integrator

    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    • C

    PI 6.2 Record the evaluation results.
    • Lead Integrator

    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    • C

    PI 6.3 Conditional Activity: If issues are discovered regarding the assembled components, advise the Technical Solution (TS) Process practitioner return to TS Process Step 7 in order to correct the issues. When the issues regarding assembled components have been corrected, resume Product Integration Process Step 2.
    • Lead Integrator

    • Component Designer

    • Developer

    • Stakeholder

    • R

    • C

    • C

    • C

Flow Diagram
  1. PI 6.0 Flow Diagram

    Figure 2.120.3-7

    This is an Image: 59978007.gif

    Please click here for the text description of the image.

PI 7.0
  1. Package and Deliver the System or System Components

    ID Task Name and Description Role RACI
    PI 7.1 Review the requirements, design, system, verification results, and documentation to ensure that issues affecting the packaging and delivery of the system are identified and resolved.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 7.2 Use effective methods to package and deliver the assembled system.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 7.3 Satisfy the applicable requirements and standards for packaging and delivering the system.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 7.4 Prepare the operational site for installation of the system.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 7.5 Preparing the operational site may be the responsibility of the customer or end users.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 7.6 Deliver the system and related documentation and confirm receipt.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 7.7 Install the system at the operational site and confirm correct operation.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

    PI 7.8 Conditional Activity: If target environment integration issues are discovered, advise the Technical Solution (TS) Process practitioner return to TS Process Step 1 in order to correct the issues. When the target environment integration issues have been corrected, resume Product Integration Process Step 2.
    • Lead Integrator

    • Component Designer

    • Stakeholder

    • R

    • C

    • C

Flow Diagram
  1. PI 7.0 Flow diagram

    Figure 2.120.3-8

    This is an Image: 59978008.gif

    Please click here for the text description of the image.

Exhibits

  1. Acronyms and Glossary

Exhibit A:

  1. Acronyms

    Acronym Definition
    API Application Programming Interface
    BSRR Business System Requirements Report
    CMMI Capability Maturity Model Integrated
    DSR Design Specification Report
    ELC Enterprise Life Cycle
    GEL Government Equipment List
    ICD Interface Control Document
    IPM Integrated Process Management
    IRM Internal Revenue Manual
    IRS Internal Revenue Service
    ITIL Information Technology Infrastructure Library
    ITSM Information Technology Service Management
    PAL Process Asset Library
    PD Process Description
    PI Product Integration
    PIA Privacy Impact Assessment
    PMI Project Management Institute
    QA Quality Assurance
    RACI Responsible, Accountable, Consulted, and Informed
    TS Technical Solution

Exhibit B:

  1. Glossary

    Term Definition
    Defined Process A managed process that is tailored from the organization’s set of standard processes according to the organization’s tailoring guidelines; has a maintained process description; and contributes process related experiences to the organizational process asset. (See also managed process).
    Design Specification Report A collection of items that can include the following if such information is appropriate to the type of product and product component (e.g., material and manufacturing requirements may not be useful for product components associated with software services or processes):
    • Product architecture description

    • Allocated requirements

    • Product component descriptions

    • Product related lifecycle process descriptions if not described as separate product components

    • Key product characteristics

    • Required physical characteristics and constraints

    • Interface requirements

    • Materials requirements (bills of material and material characteristics)

    • Fabrication and manufacturing requirements (for both the original equipment manufacturer and field support)

    • Verification criteria used to ensure requirements have been achieved

    • Conditions of use (environments) and operating/usage scenarios, modes and states for operations, support, training, manufacturing, disposal, and verifications throughout the life of the product

    • Rationale for decisions and characteristics (e.g., requirements, requirement allocations, design choices)

    Managed Process A performed process that is planned and executed in accordance with policy; employs skilled people having adequate resources to produce controlled outputs; involves relevant stakeholders; is monitored, controlled, and reviewed; and is evaluated for adherence to its process description. (See also performed process.)
    Performed Process A process that accomplishes the needed work to produce work products; the specific goals of the process area are satisfied.
    Product Integration The integration of system components into more complex system components or into complete systems.
    RACI The RACI model is based on the principle that people act in one of four ways when executing a task. It accounts for the fact that more than one role may be active in performing a specific task while clearly defining specific responsibilities for that role. While many roles may be involved in a task only one is Accountable for the results. The actions are: R Responsible for the action (may do the task) A Accountable for the action (including approval) C Required to be Consulted on the action I Required to be Informed of the action If a task does not have an Accountable role indicated then the Responsible role is assumed to be accountable for the task.
    System Requirements A refinement of customer requirements into the developers’ language, making implicit requirements into explicit derived requirements.