E001_PA44_PETRA_Design_Review.pdf

4/4/201412

CONTRACT DATA REQUIREMENTS LIST

(1 Data Item)

Form Approved OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 110 hours per response, including the time for reviewing instructions, searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing the burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188), Washington, DC 20503. Please DO NOT RETURN your form to either of these addresses. Send completed form to the Government Issuing Contractor Officer for the Contract/PR No. Listed in Block E.

A. CONTRACT LINE ITEM NO.

B. EXHIBIT

A

C. CATEGORY:

TDP _________ TM- _________ OTHER SESS

D. SYSTEM / ITEM

PETRA

E. CONTRACT / PR NO.

TBD

F. CONTRACTOR

TBD

1. DATA ITEM NO.

E001

2. TITLE OF DATA ITEM

DESIGN REVIEW INFORMATION PACKAGE (DRIP)

3. SUBTITLE

PRELIMINARY DESIGN REVIEW

4. AUTHORITY (Data Acquisition Document No.)

DI-SESS-81757A (see BLK 16)

5. CONTRACT REFERENCE

SOW Section 3.0

6. REQUIRING OFFICER

NSWC Corona, PA44

7. DD 250 REQ.

9. DIST STATEMENT

REQUIRED

10. FREQUENCY

12. DATE OF FIRST SUBMISSION

14. DISTRIBUTION

LT 1TIME SEE BLK 16 b. COPIES

8. APP CODE C 11. AS OF DATE 13. DATE OF SUBSEQUENT

SUBMISSION

a. ADDRESSEE

Draft

Final

N/A N/A N/A Reg Repr o

16. REMARKS

Blk 4 - DELETE SECTIONS 1-4 (2.1-2.4) OF THIS DID.

THE REST OF THE SECTIONS ARE REQUIRED.

Blk 9 - Use the following: "DISTRIBUTION STATEMENT C.

Distribution authorized to U.S. Government agencies and their contractors only.

(Reason: Administrative Use). (Date: 6/15/2015). Other requests for this document shall be referred to Marine Corps Systems Command."

Blk 10, 12 - THE PRELIMINARY DESIGN REVIEW SHALL BE SUBMITTED

WITHIN 50 DAYS AFTER EFFECTIVE DATE OF ORDER. THE

CONTRACTOR SHALL PROVIDE THE REPORT AT THE POST AWARD

CONFERENCE, WHICH SHALL BE SCHEDULED WITHIN 60 DAYS AFTER

CONTRACT AWARD

Blk 14 - ELECTRONIC COPY SHALL BE BY E-MAIL IN MICROSOFT

OFFICE/WORD FORMAT

PA44 Tech

POC

15. TOTAL 1

G. PREPARED BY

//S//William Debbanah

H. DATE

I. APPROVED BY

Kimberly Brayton, PA02

J. DATE

01/11/2016

DD Form 1423–1, FEB 2001 Previous editions are obsolete Page __1__ of __1__ Pages

DATA ITEM DESCRIPTION

Title: DESIGN REVIEW INFORMATION PACKAGE (DRIP)

Number: DI-SESS-81757A Approval Date: 20100406 AMSC Number: N9129 Limitation: N/A DTIC Applicable: N/A GIPDEP Applicable: N/A Office of Primary Responsibility: SH/PEO IWS 1.0 Applicable Forms: N/A

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.

Requirements:

1.0 Format. The DRIP shall be in contractor’s format.

2.0 Content. The DRIP shall contain the following sections:

2.1 Section 1 – Alternative System Review (ASR). The ASR section of the DRIP shall contain the following:

a. System purpose.

b. Existing system shortfalls.

c. Threat/Targets.

d. Design Reference Mission (DRM).

e. Operational requirements status.

f. System architecture of each alternative concept.

g. Key technologies for each alternative concept.

h. Technology risk and abatement approaches.

i. Approach to estimating performance aspect of the system concepts and their architectures.

Source: https://assist.dla.mil -- Downloaded: 2015-12-21T17:22Z Check the source to verify that this is the current version before use.

DI-SESS-81757A (Continued)

j. Key metrics and how they were measured.

k. Estimates of performance for each system concept.

l. System and human performance estimates for the best overall system concept alternative.

m. Operational impacts to the selection of each concept alternative.

n. Key Information Assurance (IA) considerations that impact the certification and accreditation risks for concept alternatives.

o. Technical performance measures to assess Hardware (HW), Software (SW) and human performance.

p. Risk assessment measures to assess risk and the effectiveness of mitigation upon those risks.

q. Alternative selection decision approach.

r. Preferred concept selection and standing.

s. Technical review team recommendation of the preferred concept.

t. Status of the requirements documentation along with the development and approval schedule and document hierarchy scheme.

u. Key system technical and IA requirements and allocations to subsystems.

v. An overview of the proposed system development, acquisition schedule, and test and operational evaluation.

w. Detailed schedule and costs associated with the next phase of development.

x. Overall acquisition cost and plans for completion.

y. Technical review team recommendation on the system development plans.

2.2 Section 2 – System Requirements Review (SRR). The SRR section of the DRIP shall contain the following:

a. System mission.

b. Operational views and documentation of the operational requirements.

c. Scenarios, 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.

d. Description of the capability development document, system threat assessment report, and concept of operations.

e. Description of the system architecture.

f. System boundaries describing the system apart from other systems and its environment.

g. Internal 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.

h. Unique states of the system and identification of all static and dynamic modes.

i. System trades and analyses.

j. Key performance parameters, technologies, system concept, anticipated human performance requirements, and the differences between the system concept used at the SRR and the ASR.

k. Results of the system effectiveness and performance assessment.

l. Status of the development of the requirements documentation.

m. Identification of the required threat and the IA threat.

n. System capability requirements.

o. Requirements not related to mission capabilities.

p. How the system requirements will be qualified.

q. Description of the process of the allocation of requirements from the system-level to the subsystem level and major system requirements allocations to subsystems.

r. Remaining schedule of the entire system development and acquisition.

s. Near term schedule and costs plans for the next phase of development.

t. Estimation of cost and progress for the overall acquisition program.

u. Description of the approach to management of the system requirements, architecture, design, and the special configuration management requirements of security-critical elements.

2.3 Section 3 – System Functional Review (SFR). The SFR section of the DRIP shall contain the following:

a. Description of the functional architecture.

b. Performance specifications.

c. System Requirements Document (SRD).

d. Draft prime item performance and prime item detail specifications.

e. Design data defining the overall system.

f. Risk assessment results.

g. Risk mitigation plans.

h. Trade studies and analyses.

i. Technical performance measurements.

j. Draft enabling product plans, Systems Engineering Plan (SEP) and a summary of comments.

2.4 Section 4 – Software Specification Review (SSR). The SSR section of the DRIP shall

a. Description of the system architecture.

b. An overview of the system requirements.

c. Growths of requirements for each system build.

d. Allocation of system requirements to Software Configuration Items (SCIs).

e. Identification of security-critical and non-critical SCIs.

f. Interfaces between the Configuration Items (CIs), broken out into builds.

g. Layers of the architecture, if layers have been defined.

h. User interfaces, including displays and the rational for their selection.

i. Operator job descriptions, based on functions allocated to humans.

j. Planned locations for new and reused software, Commercial Off-The-Shelf (COTS), Non-Developmental Items (NDI), legacy equipment, and Government Furnished Information (GFI).

k. Plans for how reused software will meet IA requirements.

l. An overview of the SCI requirements, both functional and IA.

m. Where the SCI fits into the system architecture and the system build plan.

n. Description of how the system requirements are allocated to the various CIs.

o. A breakdown of how the requirements are allocated across builds.

p. References defining which Software Requirements Specification (SRS) requirements are allocated to which builds.

q. System requirements changes made since the SFR.

r. Safety critical requirements.

s. Quality requirements (including reliability, availability, maintainability).

t. Requirements supporting test and analysis.

u. Human Machine Interface (HMI) requirements.

v. How the build plan for the SCI is consistent with the overall system build plan.

w. Dates when technical agreements are needed on the content of the various requirements and design documentation artifacts.

x. Description of the software development processes/methods and tools that will be used, as documented in the Software Development Plan (SDP).

y. Explanation 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.

z. Processes and measures to be used in developing the HMI and evaluating its usability and impact on operator performance and workload.

aa. Progress made in SCI development compared to the plan defined in the system development landscape.

bb. Requirements and implementation constraints allocated to the SCI.

cc. Performance requirements of the SCI.

dd. Test approaches planned for qualification of the requirements

ee. Summary of the risk items and mitigation plans identified for the SCI that will impact successful completion of the SCI.

2.5 Section 5 – Hardware Preliminary Design Review (HPDR). The HPDR section of the DRIP shall contain the following:

b. An overview of the total system requirements.

c. Allocation of requirements to each of the hardware configuration items (HWCIs).

d. Allocation of requirements to any SCI hosted by the HWCI.

e. User interfaces, including displays.

f. Connectivity among system HWCIs as defined in the Interface Design Specifications (IDSs).

g. Identification of all NDIs, Government Furnished Equipment (GFE), and legacy equipment.

h. Operator and maintainer job descriptions.

i. An overview of the HWCI requirements and any associated SCI/firmware documentation.

j. Where the HWCI fits into the system architecture and system development schedule.

k. How the system requirements are allocated to the various HWCIs.

l. Requirements applicable to the production equipment, but not the Engineering Development Model (EDM).

m. A breakdown of the requirements relative to SCI/firmware builds associated with the particular HWCI.

n. Requirement changes made since the SSR.

o. Safety critical requirements.

p. Quality requirements (including reliability, availability and maintainability).

q. Requirements supporting test and analysis.

r. Design error budgets for meeting allocated requirements.

s. Ship integration requirements.

t. System security/IA requirements.

u. Environmental requirements.

v. How the equipment and SCI/firmware build plans for the HWCI are consistent with the overall SDP.

w. Dates when technical agreements are needed on the content of the various requirements and design documentation.

x. Description of the equipment development process/methods and tools that are to be used, as documented in the SDP.

y. Description of the processes and methodologies for assessing the ergonomics and operational suitability of the hardware configurations.

z. Description of the intra-HWCI landscape.

aa. Where, within the architecture, development/new and reuse components will be located, including NAVSEA Data Environment, COTS, legacy equipment and GFE.

bb. How reused components will meet IA requirements.

cc. Where industry and government standards are applied.

dd. Description of the maturity of the functional/subsystem design.

ee. Description of the HWCI’s performance requirements, including design margins.

ff. Metrics to include plan vs. specified parameters, Earned Value Metrics (EVMs), and the programs’ Work Breakdown Structure (WBS).

gg. Summary of the risk items identified for the HWCI that impact successful completion of the HWCI.

hh. Test approaches planned for the HWCI.

ii. Lower-level tests to be performed on the HWCI components, modules and subsystems.

jj. Degree of functional and environmental coverage planned for the tests.

2.6 Section 6 – Software Preliminary Design Review (SPDR). The SPDR section of the DRIP shall contain the following:

c. Allocation of system requirements to SCIs.

d. User interfaces, including displays.

e. Growths of requirements for each system build.

f. Interfaces between the CIs, broken out into builds.

g. Layers of the architecture (if layers have been defined).

h. Locations of new and reused software, including COTS, NDI, legacy, and GFI.

i. Plans for how reused CIs will meet IA requirements.

j. An overview of the SCI requirements.

k. Where the CI fits into the system architecture and system build plan.

l. How the system requirements are allocated to the various CIs.

m. A breakdown of how the requirements are allocated across builds.

n. Documentation defining which SRS requirements is allocated to which builds.

o. Requirements changes made since SSR.

p. Security critical requirements.

q. Quality requirements (including reliability, availability and maintainability).

r. Requirements supporting test and analysis.

s. Safety critical requirements.

t. How the SCI build plan is consistent with the overall system build plan.

u. Dates when technical agreements are needed on the content of the various

v. Description of the software development process/methods and tools that are to be

w. Explanation of any process and tool changes that have been made since the SSR, why

x. Description of the measures to be used in assessing human performance and operator workload (cognitive/temporal/physical).

y. Description of the intra-SCI landscape.

z. An overview of the system architecture.

aa. Identification of all Computer Software Components (CSCs).

bb. Documentation defining the SCI’s architecture.

cc. Where, within the architecture, development/new and reuse components are located, including NDI, COTS, legacy equipment and GFI.

dd. How reused components will meet IA requirements.

ee. Where industry standards are applied.

ff. Maturity of the functional/subsystem design.

gg. Description of the SCI’s performance requirements.

hh. Summary of risk items identified for the SCI that impact successful completion of the

SCI.

ii. Test approaches planned for the SCI testing.

jj. Lower-level tests to be performed on the components, from unit-level to top-level.

2.7 Section 7 – Software Design Review (SDR). The SDR section of the DRIP shall contain the following:

e. Growths of requirements for each system build.

f. Interfaces between the CIs, both HW and SW, broken out into builds.

g. Layers of the architecture, if layers have been defined.

h. Locations of new and reused software, including COTS, NDI, legacy equipment, and

GFI.

i. Plans for how reused CIs will meet IA requirements.

j. An overview of the SCI requirements.

k. Where the SCI fits into the system architecture and system build plan.

l. How the system requirements are allocated to the various CIs.

m. A breakdown of how the requirements are allocated across builds.

n. Documentation defining which SRS requirements is allocated to which builds.

o. Requirements changes made since the SSR and the previous SWDR.

p. Security critical requirements.

q. Quality requirements (including reliability, availability and maintainability).

r. Requirements supporting test and analysis.

s. Safety critical requirements.

t. How the SCI build plan is consistent with the overall system build plan.

v. Description of the software development process/methods and tools that are to be

w. Explanation of any process and tool changes that have been made since the SSR, why

x. Description of the measures to be used in assessing human performance and operator workload (cognitive/temporal/physical).

y. Description of the intra-SCI landscape.

z. An overview of the system architecture.

aa. Identification of all CSCs.

cc. Where, within the architecture, development/new and reuse components are located, including NDI, COTS, legacy equipment and GFI.

ee. Where industry standards are applied.

ff. Maturity of the functional/subsystem design.

gg. Description of the SCI’s performance requirements.

hh. Summary of risk items identified for the SCI that impact successful completion of the

SCI.

ii. Test approaches planned for the SCI testing.

jj. Lower-level tests to be performed on the SCI components, from unit-level to top-level.

kk. Formal Qualification tTest (FQT) descriptions of the SCI.

Section 8 – Hardware Critical Design Review (HCDR). The HCDR section of the DRIP shall

b. An overview of the total system requirements as defined in the system specifications.

c. Allocation of system requirements to each of the HCIs comprising the system.

e. Connectivity among system HCIs.

f. Identification of all NDIs, GFE, and legacy equipment.

g. An overview of the HCI requirements and associated SCI and firmware documentation.

h. Where the HCI fits into the system architecture and the system development schedule.

i. How the system requirements are allocated to the various HCIs.

j. Requirements applicable to the production equipment, but not the EDM.

k. A breakdown of the requirements relative to SCI/Firmware builds associated with the particular HCI.

l. Requirements changes made since PDR.

m. Safety critical requirements.

n. Quality requirements (including reliability, availability and maintainability).

o. Requirements supporting test and analysis.

p. Design error budgets for meeting allocated requirements.

q. Ship integration requirements.

r. System security/IA requirements.

s. Environmental requirements.

t. Processes for assessing the ergonomics and suitability of hardware configurations.

u. How the equipment and SCI/firmware build plans for the HCI is consistent with the overall SDP.

v. Dates when technical agreements are needed on the content of the various

w. Equipment development process/methods being followed and tools that are to be

x. Detailed 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.

y. Description of the intra-HCI landscape.

z. An overview of the HCI's configuration.

aa. Identification of HCIs.

bb. Where, within the architecture, development and reuse components will be located.

cc. How reused HCIs will meet IA requirements.

dd. Where industry and government standards are applied.

ee. Description of the test plans and procedures that will be applied to the HCI.

ff. Test approaches planned for the HCI.

gg. FQT descriptions.

hh. Lower-level tests to be performed on the HCI components, modules and subsystems.

ii. Maturity of the functional/subsystem design.

jj. Performance requirements of the HCI.

kk. Metrics appropriate to the particular development.

ll. Summary of the risk database items identified that impact successful completion of the HCI.

Section 9 – Software Critical Design Review (SCDR). The SCDR section of the DRIP shall

b. Overview of the total system requirements.

e. Growth of requirements for each system build including any training required.

f. Interfaces between the SCIs, broken out into builds.

g. Layers of the architecture (if layers have been defined).

h. Locations of new and reused software, including COTS, NDI, legacy, and GFI.

i. Plans for how reused software will meet IA requirements.

j. Organizational description of operators and maintainers associated with the system.

k. An overview of the SCI requirements.

l. Where the SCI fits into the system architecture and system build plan.

m. Description of how the system requirements are allocated to the various CIs.

n. A breakdown of how the requirements are allocated across builds.

o. Documentation defining which SRS requirements is allocated to which builds.

p. Requirements changes made since PDR.

q. Safety critical requirements.

r. Quality requirements (including reliability, availability and maintainability).

s. Requirements supporting test and analysis.

t. How the build plan for the SCI/firmware is consistent with the overall system build plan.

v. Software development process/methods being followed and tools to be used, as documented in the SDP.

w. Detailed 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.

x. Description of the intra-SCI landscape.

y. An overview of the SCI’s architecture.

z. Identification of all CSCs.

aa. Changes made since the PDR.

cc. Where, within the architecture, new and reuse components will be located.

ee. Where industry and government standards are applied.

ff. Description of the performance requirements.

gg. SCI SW metrics.

hh. Risk items for the SCI that will impact successful completion of the SCI.

ii. Test approaches planned for the SCI-level.

jj. FQT descriptions.

kk. Lower-level tests to be performed on the SCI components, from unit level to top-level component level.

2.8 Section 10 – Test Readiness Review (TRR). The TRR section of the DRIP shall contain the following:

c. Organizational description of operators and maintainers associated with the system.

d. Allocation of system requirements to the CI.

e. User interfaces, including displays.

f. Connectivity among system CIs as defined in the IDSs.

g. Identification of all NDIs, GFE, and legacy equipment.

h. An overview the CI functional and performance requirements.

i. Associated SCI and firmware documentation.

j. How the test and evaluation management plan are allocated to the various CIs.

k. Requirements changes made since the CDR

l. Security requirements.

m. Environmental requirements.

n. Safety critical requirements.

o. Quality requirements (including reliability, availability and maintainability).

p. Requirements supporting test and analysis.

q. Summary of risk items and mitigation plans that impact successful completion of the system.

r. Test approaches planned for the system.

2.9 Section 11 – Functional Configuration Audit (FCA). The FCA section of the DRIP shall

b. Description of the system production process/methods and tools to be used.

c. Explanation of process and tool changes since the SDP was released, why the changes were made, and an assessment of the impact of these changes.

d. Test approaches planned for the system.

e. A summary of the risk items and mitigation plans that will impact successful completion of the system mission.

2.10 Section 12 – Physical Configuration Audit (PCA). The PCA section of the DRIP shall

c. Allocation of system requirements to each of the CIs comprising the system.

e. Connectivity among system CIs as defined in the in IDSs.

f. Identification of all NDIs, GFE, and legacy equipment.

g. Description of the system production and deployment process/methods and tools to be used, as documented in the SDP.

h. Explanation 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.

i. Description of the processes to be used in developing HMI and its usability.

j. An overview of the CI’s functional and performance requirements.

k. Specifications of interfaces and protocols.

l. Additions and changes made to COTS equipment, including market research and upgrade strategy.

m. Where the CI fits into the system and system production and deployment schedules.

n. How the equipment and SCI/firmware build plans for the CI are consistent with the overall system production plan.

o. Dates when technical agreements are needed on the content of the various requirements and design documentation.

p. Summary of the risk items and mitigation plans that impact successful completion of the SCI.

q. Test approaches planned for the system.

3.0 End of DI-SESS-81757A