DID FinderBack
Source
DI-SESS-81757A

Design Review Information Package (DRIP)

The Design Review Information Package (DRIP) is used by the government to assess system maturity for the next development phase, containing format and content instructions for data products delineated in the contract.

Approval DateApril 6, 2010
AMSC NumberN9129
Preparing Activity—
Project Number—
OPRSH/PEO IWS 1.0
DTIC Applicable—
GIDEP Applicable—
Limitation—
Applicable Forms—
Approval Limitation—
Form Version—
DID Formatfree_text
963C CompliantNo
DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.
Supersedes
—
Related
—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

The Design Review Information Package (DRIP) is used by the government to determine and ensure that the emerging system has demonstrated sufficient maturity to enter the next phase of development. This Data Item Description (DID) contains the format and content preparation instructions for the data product resulting from the discrete task requirements as delineated in the contract.

Preparation Instructions

1Format.The DRIP shall be in contractor's format.
2Content.The DRIP shall contain the following sections:
2.1Section 1 – Alternative System Review (ASR).The ASR section of the DRIP shall contain the following:
2.1.1System purpose.
2.1.2Existing system shortfalls.
2.1.3Threat/Targets.
2.1.4Design Reference Mission (DRM).
2.1.5Operational requirements status.
2.1.6System architecture of each alternative concept.
2.1.7Key technologies for each alternative concept.
2.1.8Technology risk and abatement approaches.
2.1.9Approach to estimating performance aspect of the system concepts and their architectures.
2.1.10Key metrics and how they were measured.
2.1.11Estimates of performance for each system concept.
2.1.12System and human performance estimates for the best overall system concept alternative.
2.1.13Operational impacts to the selection of each concept alternative.
2.1.14Key Information Assurance (IA) considerations that impact the certification and accreditation risks for concept alternatives.
2.1.15Technical performance measures to assess Hardware (HW), Software (SW) and human performance.
2.1.16Risk assessment measures to assess risk and the effectiveness of mitigation upon those risks.
2.1.17Alternative selection decision approach.
2.1.18Preferred concept selection and standing.
2.1.19Technical review team recommendation of the preferred concept.
2.1.20Status of the requirements documentation along with the development and approval schedule and document hierarchy scheme.
2.1.21Key system technical and IA requirements and allocations to subsystems.
2.1.22An overview of the proposed system development, acquisition schedule, and test and operational evaluation.
2.1.23Detailed schedule and costs associated with the next phase of development.
2.1.24Overall acquisition cost and plans for completion.
2.1.25Technical review team recommendation on the system development plans.
2.2Section 2 – System Requirements Review (SRR).The SRR section of the DRIP shall contain the following:
2.2.1System mission.
2.2.2Operational views and documentation of the operational requirements.
2.2.3Scenarios, campaigns, and threats that comprise the DRM for the system, the manner in which the DRM shall be utilized in subsequent system development, and development status.
2.2.4Description of the capability development document, system threat assessment report, and concept of operations.
2.2.5Description of the system architecture.
2.2.6System boundaries describing the system apart from other systems and its environment.
2.2.7Internal system structure describing the division of the systems into subsystems, major foreseen interface relationships between the major divisions, and boundaries between security-critical and non-critical functions.
2.2.8Unique states of the system and identification of all static and dynamic modes.
2.2.9System trades and analyses.
2.2.10Key performance parameters, technologies, system concept, anticipated human performance requirements, and the differences between the system concept used at the SRR and the ASR.
2.2.11Results of the system effectiveness and performance assessment.
2.2.12Status of the development of the requirements documentation.
2.2.13Identification of the required threat and the IA threat.
2.2.14System capability requirements.
2.2.15Requirements not related to mission capabilities.
2.2.16How the system requirements will be qualified.
2.2.17Description of the process of the allocation of requirements from the system-level to the subsystem level and major system requirements allocations to subsystems.
2.2.18Remaining schedule of the entire system development and acquisition.
2.2.19Near term schedule and costs plans for the next phase of development.
2.2.20Estimation of cost and progress for the overall acquisition program.
2.2.21Description of the approach to management of the system requirements, architecture, design, and the special configuration management requirements of security-critical elements.
2.3Section 3 – System Functional Review (SFR).The SFR section of the DRIP shall contain the following:
2.3.1Description of the functional architecture.
2.3.2Performance specifications.
2.3.3System Requirements Document (SRD).
2.3.4Draft prime item performance and prime item detail specifications.
2.3.5Design data defining the overall system.
2.3.6Risk assessment results.
2.3.7Risk mitigation plans.
2.3.8Trade studies and analyses.
2.3.9Technical performance measurements.
2.3.10Draft enabling product plans, Systems Engineering Plan (SEP) and a summary of comments.
2.4Section 4 – Software Specification Review (SSR).The SSR section of the DRIP shall contain the following:
2.4.1Description of the system architecture.
2.4.2An overview of the system requirements.
2.4.3Growths of requirements for each system build.
2.4.4Allocation of system requirements to Software Configuration Items (SCIs).
2.4.5Identification of security-critical and non-critical SCIs.
2.4.6Interfaces between the Configuration Items (CIs), broken out into builds.
2.4.7Layers of the architecture, if layers have been defined.
2.4.8User interfaces, including displays and the rational for their selection.
2.4.9Operator job descriptions, based on functions allocated to humans.
2.4.10Planned locations for new and reused software, Commercial Off-The-Shelf (COTS), Non-Developmental Items (NDI), legacy equipment, and Government Furnished Information (GFI).
2.4.11Plans for how reused software will meet IA requirements.
2.4.12An overview of the SCI requirements, both functional and IA.
2.4.13Where the SCI fits into the system architecture and the system build plan.
2.4.14Description of how the system requirements are allocated to the various CIs.
2.4.15A breakdown of how the requirements are allocated across builds.
2.4.16References defining which Software Requirements Specification (SRS) requirements are allocated to which builds.
2.4.17System requirements changes made since the SFR.
2.4.18Safety critical requirements.
2.4.19Quality requirements (including reliability, availability, maintainability).
2.4.20Requirements supporting test and analysis.
2.4.21Human Machine Interface (HMI) requirements.
2.4.22How the build plan for the SCI is consistent with the overall system build plan.
2.4.23Dates when technical agreements are needed on the content of the various requirements and design documentation artifacts.
2.4.24Description of the software development processes/methods and tools that will be used, as documented in the Software Development Plan (SDP).
2.4.25Explanation of any process and tool changes made since the SDP was released, why the changes were made, and an assessment of the impact of these changes on the SDP.
2.4.26Processes and measures to be used in developing the HMI and evaluating its usability and impact on operator performance and workload.
2.4.27Progress made in SCI development compared to the plan defined in the system development landscape.
2.4.28Requirements and implementation constraints allocated to the SCI.
2.4.29Performance requirements of the SCI.
2.4.30Test approaches planned for qualification of the requirements
2.4.31Summary of the risk items and mitigation plans identified for the SCI that will impact successful completion of the SCI.
2.5Section 5 – Hardware Preliminary Design Review (HPDR).The HPDR section of the DRIP shall contain the following:
2.5.1Description of the system architecture.
2.5.2An overview of the total system requirements.
2.5.3Allocation of requirements to each of the hardware configuration items (HWCIs).
2.5.4Allocation of requirements to any SCI hosted by the HWCI.
2.5.5User interfaces, including displays.
2.5.6Connectivity among system HWCIs as defined in the Interface Design Specifications (IDSs).
2.5.7Identification of all NDIs, Government Furnished Equipment (GFE), and legacy equipment.
2.5.8Operator and maintainer job descriptions.
2.5.9An overview of the HWCI requirements and any associated SCI/firmware documentation.
2.5.10Where the HWCI fits into the system architecture and system development schedule.
2.5.11How the system requirements are allocated to the various HWCIs.
2.5.12Requirements applicable to the production equipment, but not the Engineering Development Model (EDM).
2.5.13A breakdown of the requirements relative to SCI/firmware builds associated with the particular HWCI.
2.5.14Requirement changes made since the SSR.
2.5.15Safety critical requirements.
2.5.16Quality requirements (including reliability, availability and maintainability).
2.5.17Requirements supporting test and analysis.
2.5.18Design error budgets for meeting allocated requirements.
2.5.19Ship integration requirements.
2.5.20System security/IA requirements.
2.5.21Environmental requirements.
2.5.22How the equipment and SCI/firmware build plans for the HWCI are consistent with the overall SDP.
2.5.23Dates when technical agreements are needed on the content of the various requirements and design documentation.
2.5.24Description of the equipment development process/methods and tools that are to be used, as documented in the SDP.
2.5.25Description of the processes and methodologies for assessing the ergonomics and operational suitability of the hardware configurations.
2.5.26Description of the intra-HWCI landscape.
2.5.27Where, within the architecture, development/new and reuse components will be located, including NAVSEA Data Environment, COTS, legacy equipment and GFE.
2.5.28How reused components will meet IA requirements.
2.5.29Where industry and government standards are applied.
2.5.30Description of the maturity of the functional/subsystem design.
2.5.31Description of the HWCI's performance requirements, including design margins.
2.5.32Metrics to include plan vs. specified parameters, Earned Value Metrics (EVMs), and the programs' Work Breakdown Structure (WBS).
2.5.33Summary of the risk items identified for the HWCI that impact successful completion of the HWCI.
2.5.34Test approaches planned for the HWCI.
2.5.35Lower-level tests to be performed on the HWCI components, modules and subsystems.
2.5.36Degree of functional and environmental coverage planned for the tests.
2.6Section 6 – Software Preliminary Design Review (SPDR).The SPDR section of the DRIP shall contain the following:
2.6.1Description of the system architecture.
2.6.2An overview of the system requirements.
2.6.3Allocation of system requirements to SCIs.
2.6.4User interfaces, including displays.
2.6.5Growths of requirements for each system build.
2.6.6Interfaces between the CIs, broken out into builds.
2.6.7Layers of the architecture (if layers have been defined).
2.6.8Locations of new and reused software, including COTS, NDI, legacy, and GFI.
2.6.9Plans for how reused CIs will meet IA requirements.
2.6.10An overview of the SCI requirements.
2.6.11Where the CI fits into the system architecture and system build plan.
2.6.12How the system requirements are allocated to the various CIs.
2.6.13A breakdown of how the requirements are allocated across builds.
2.6.14Documentation defining which SRS requirements is allocated to which builds.
2.6.15Requirements changes made since SSR.
2.6.16Security critical requirements.
2.6.17Quality requirements (including reliability, availability and maintainability).
2.6.18Requirements supporting test and analysis.
2.6.19Safety critical requirements.
2.6.20How the SCI build plan is consistent with the overall system build plan.
2.6.21Dates when technical agreements are needed on the content of the various requirements and design documentation.
2.6.22Description of the software development process/methods and tools that are to be used, as documented in the SDP.
2.6.23Explanation of any process and tool changes that have been made since the SSR, why the changes were made, and an assessment of the impact of these changes on the SDP.
2.6.24Description of the measures to be used in assessing human performance and operator workload (cognitive/temporal/physical).
2.6.25Description of the intra-SCI landscape.
2.6.26An overview of the system architecture.
2.6.27Identification of all Computer Software Components (CSCs).
2.6.28Documentation defining the SCI's architecture.
2.6.29Where, within the architecture, development/new and reuse components are located, including NDI, COTS, legacy equipment and GFI.
2.6.30How reused components will meet IA requirements.
2.6.31Where industry standards are applied.
2.6.32Maturity of the functional/subsystem design.
2.6.33Description of the SCI's performance requirements.
2.6.34Summary of risk items identified for the SCI that impact successful completion of the SCI.
2.6.35Test approaches planned for the SCI testing.
2.6.36Lower-level tests to be performed on the components, from unit-level to top-level.
2.7Section 7 - Software Design Review (SDR).The SDR section of the DRIP shall contain the following:
2.7.1Description of the system architecture.
2.7.2An overview of the system requirements.
2.7.3Allocation of system requirements to SCIs.
2.7.4User interfaces, including displays.
2.7.5Growths of requirements for each system build.
2.7.6Interfaces between the CIs, both HW and SW, broken out into builds.
2.7.7Layers of the architecture, if layers have been defined.
2.7.8Locations of new and reused software, including COTS, NDI, legacy, and GFI.
2.7.9Plans for how reused CIs will meet IA requirements.
2.7.10An overview of the SCI requirements.
2.7.11Where the SCI fits into the system architecture and system build plan.
2.7.12How the system requirements are allocated to the various CIs.
2.7.13A breakdown of how the requirements are allocated across builds.
2.7.14Documentation defining which SRS requirements is allocated to which builds.
2.7.15Requirements changes made since the SSR and the previous SWDR.
2.7.16Security critical requirements.
2.7.17Quality requirements (including reliability, availability and maintainability).
2.7.18Requirements supporting test and analysis.
2.7.19Safety critical requirements.
2.7.20How the SCI build plan is consistent with the overall system build plan.
2.7.21Dates when technical agreements are needed on the content of the various requirements and design documentation.
2.7.22Description of the software development process/methods and tools that are to be used, as documented in the SDP.
2.7.23Explanation of any process and tool changes that have been made since the SSR, why the changes were made, and an assessment of the impact of these changes on the SDP.
2.7.24Description of the measures to be used in assessing human performance and operator workload (cognitive/temporal/physical).
2.7.25Description of the intra-SCI landscape.
2.7.26An overview of the system architecture.
2.7.27Identification of all CSCs.
2.7.28Documentation defining the SCI's architecture.
2.7.29Where, within the architecture, development/new and reuse components are located, including NDI, COTS, legacy equipment and GFI.
2.7.30How reused components will meet IA requirements.
2.7.31Where industry standards are applied.
2.7.32Maturity of the functional/subsystem design.
2.7.33Description of the SCI's performance requirements.
2.7.34Summary of risk items identified for the SCI that impact successful completion of the SCI.
2.7.35Test approaches planned for the SCI testing.
2.7.36Lower-level tests to be performed on the SCI components, from unit-level to top-level.
2.7.37Formal Qualification tTest (FQT) descriptions of the SCI.
2.8Section 8 - Hardware Critical Design Review (HCDR).The HCDR section of the DRIP shall contain the following:
2.8.1Description of the system architecture.
2.8.2An overview of the total system requirements as defined in the system specifications.
2.8.3Allocation of system requirements to each of the HCIs comprising the system.
2.8.4User interfaces, including displays.
2.8.5Connectivity among system HCIs.
2.8.6Identification of all NDIs, GFE, and legacy equipment.
2.8.7An overview of the HCI requirements and associated SCI and firmware documentation.
2.8.8Where the HCI fits into the system architecture and the system development schedule.
2.8.9How the system requirements are allocated to the various HCIs.
2.8.10Requirements applicable to the production equipment, but not the EDM.
2.8.11A breakdown of the requirements relative to SCI/Firmware builds associated with the particular HCI.
2.8.12Requirements changes made since PDR.
2.8.13Safety critical requirements.
2.8.14Quality requirements (including reliability, availability and maintainability).
2.8.15Requirements supporting test and analysis.
2.8.16Design error budgets for meeting allocated requirements.
2.8.17Ship integration requirements.
2.8.18System security/IA requirements.
2.8.19Environmental requirements.
2.8.20Processes for assessing the ergonomics and suitability of hardware configurations.
2.8.21How the equipment and SCI/firmware build plans for the HCI is consistent with the overall SDP.
2.8.22Dates when technical agreements are needed on the content of the various requirements and design documentation.
2.8.23Equipment development process/methods being followed and tools that are to be used, as documented in the SDP.
2.8.24Detailed explanation of any process and tool changes that have been made since the PDR, including rationale on why the changes are made and an assessment of the impact of these changes on the development plan.
2.8.25Description of the intra-HCI landscape.
2.8.26An overview of the HCI's configuration.
2.8.27Identification of HCIS.
2.8.28Where, within the architecture, development and reuse components will be located.
2.8.29How reused HCIs will meet IA requirements.
2.8.30Where industry and government standards are applied.
2.8.31Description of the test plans and procedures that will be applied to the HCI.
2.8.32Test approaches planned for the HCI.
2.8.33FQT descriptions.
2.8.34Lower-level tests to be performed on the HCI components, modules and subsystems.
2.8.35Maturity of the functional/subsystem design.
2.8.36Performance requirements of the HCI.
2.8.37Metrics appropriate to the particular development.
2.8.38Summary of the risk database items identified that impact successful completion of the HCI.
2.9Section 9 – Software Critical Design Review (SCDR).The SCDR section of the DRIP shall contain the following:
2.9.1Description of the system architecture.
2.9.2Overview of the total system requirements.
2.9.3Allocation of system requirements to SCIs.
2.9.4User interfaces, including displays.
2.9.5Growth of requirements for each system build including any training required.
2.9.6Interfaces between the SCIs, broken out into builds.
2.9.7Layers of the architecture (if layers have been defined).
2.9.8Locations of new and reused software, including COTS, NDI, legacy, and GFI.
2.9.9Plans for how reused software will meet IA requirements.
2.9.10Organizational description of operators and maintainers associated with the system.
2.9.11An overview of the SCI requirements.
2.9.12Where the SCI fits into the system architecture and system build plan.
2.9.13Description of how the system requirements are allocated to the various CIs.
2.9.14A breakdown of how the requirements are allocated across builds.
2.9.15Documentation defining which SRS requirements is allocated to which builds.
2.9.16Requirements changes made since PDR.
2.9.17Safety critical requirements.
2.9.18Quality requirements (including reliability, availability and maintainability).
2.9.19Requirements supporting test and analysis.
2.9.20How the build plan for the SCI/firmware is consistent with the overall system build plan.
2.9.21Dates when technical agreements are needed on the content of the various requirements and design documentation.
2.9.22Software development process/methods being followed and tools to be used, as documented in the SDP.
2.9.23Detailed explanation of any process and tool changes that have been made since the PDR, including rationale on why the changes are made and an assessment of the impact of these changes on the development plan.
2.9.24Description of the intra-SCI landscape.
2.9.25An overview of the SCI's architecture.
2.9.26Identification of all CSCs.
2.9.27Changes made since the PDR.
2.9.28Documentation defining the SCI's architecture.
2.9.29Where, within the architecture, new and reuse components will be located.
2.9.30How reused components will meet IA requirements.
2.9.31Where industry and government standards are applied.
2.9.32Description of the performance requirements.
2.9.33SCI SW metrics.
2.9.34Risk items for the SCI that will impact successful completion of the SCI.
2.9.35Test approaches planned for the SCI-level.
2.9.36FQT descriptions.
2.9.37Lower-level tests to be performed on the SCI components, from unit level to top-level component level.
2.10Section 10 – Test Readiness Review (TRR).The TRR section of the DRIP shall contain the following:
2.10.1Description of the system architecture.
2.10.2An overview of the total system requirements.
2.10.3Organizational description of operators and maintainers associated with the system.
2.10.4Allocation of system requirements to the CI.
2.10.5User interfaces, including displays.
2.10.6Connectivity among system CIs as defined in the IDSs.
2.10.7Identification of all NDIs, GFE, and legacy equipment.
2.10.8An overview the CI functional and performance requirements.
2.10.9Associated SCI and firmware documentation.
2.10.10How the test and evaluation management plan are allocated to the various CIs.
2.10.11Requirements changes made since the CDR
2.10.12Security requirements.
2.10.13Environmental requirements.
2.10.14Safety critical requirements.
2.10.15Quality requirements (including reliability, availability and maintainability).
2.10.16Requirements supporting test and analysis.
2.10.17Summary of risk items and mitigation plans that impact successful completion of the system.
2.10.18Test approaches planned for the system.
2.11Section 11 – Functional Configuration Audit (FCA).The FCA section of the DRIP shall contain the following:
2.11.1Description of the system architecture.
2.11.2Description of the system production process/methods and tools to be used.
2.11.3Explanation of process and tool changes since the SDP was released, why the changes were made, and an assessment of the impact of these changes.
2.11.4Test approaches planned for the system.
2.11.5A summary of the risk items and mitigation plans that will impact successful completion of the system mission.
2.12Section 12 – Physical Configuration Audit (PCA).The PCA section of the DRIP shall contain the following:
2.12.1Description of the system architecture.
2.12.2An overview of the total system requirements.
2.12.3Allocation of system requirements to each of the CIs comprising the system.
2.12.4User interfaces, including displays.
2.12.5Connectivity among system CIs as defined in the in IDSs.
2.12.6Identification of all NDIs, GFE, and legacy equipment.
2.12.7Description of the system production and deployment process/methods and tools to be used, as documented in the SDP.
2.12.8Explanation of process and tool changes that have been made since the SDP was released, why the changes were made, and an assessment of the impact of these changes on the SDP.
2.12.9Description of the processes to be used in developing HMI and its usability.
2.12.10An overview of the CI's functional and performance requirements.
2.12.11Specifications of interfaces and protocols.
2.12.12Additions and changes made to COTS equipment, including market research and upgrade strategy.
2.12.13Where the CI fits into the system and system production and deployment schedules.
2.12.14How the equipment and SCI/firmware build plans for the CI are consistent with the overall system production plan.
2.12.15Dates when technical agreements are needed on the content of the various requirements and design documentation.
2.12.16Summary of the risk items and mitigation plans that impact successful completion of the SCI.
2.12.17Test approaches planned for the system.

References

—
Schema v3.0Community-maintained · Verify against ASSIST
Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer