Exhibit_B_DIDs_Portfolio_for_A001_to_A042.pdf

For the best experience, open this PDF portfolio in

Acrobat X or Adobe Reader X, or later.

Get Adobe Reader Now!

http://www.adobe.com/go/reader

DATA ITEM DESCRIPTION

TITLE: COUNTERFEIT PREVENTION PLAN

Number: DI-MISC-81832 Approval Date: 20110121 AMSC Number: 9181 Limitation:

DTIC Applicable: No GIDEP Applicable: No Office of Primary Responsibility: NRO Applicable Forms: N/A

Use/Relationship: The Counterfeit Prevention Plan will be used by the procurement activity to determine and evaluate the effectiveness of the contractor’s counterfeit protection plan and award fee.

a. This Data Item Description contains the format and content preparation instructions for the data product generated by the specific and discrete task requirements delineated in the statement of work.

b. This DID is related to Parts, Materials and Processes Selection List (PMPSL).

c. This DID is related to “As Designed” and “As Built” Parts List.

d. The Counterfeit Prevention Plan will be updated as counterfeiting methods evolve to include any new indicators, as well as new prevention processes needed (either discovered directly or provided by the Government).

Requirements:

1. The Counterfeit Prevention Plan shall be in contractor format and shall include the following, as a minimum:

a. Procurement practices and procedures to include procurement of all parts and materials from original qualified parts/materials equipment manufacturer (OEM) or it franchised/authorized distributor.

b. Procurement practices and internal processes used for exceptions to buying from

OEM or OEM franchised distributors in cases where items are no longer available including a process to qualify/certify non-OEM parts & materials.

c. Monitoring procedures to include the delivery of test results from random sampling and supply chains surveillance that does not assume any source is safe to identify possible penetration of OEM supply chain.

d. Training/certification program for receiving inspectors.

e. Process to verify counterfeit.

Source: https://assist.dla.mil -- Downloaded: 2016-11-04T21:12Z Check the source to verify that this is the current version before use.

DI-MISC-81832

- 2 -

f. Processes to identify, store, and report counterfeit parts.

g. Process to ensure subcontracts contain the following requirements (As a minimum):

(1) Requirements to procure only from Original Equipment Manufacturer

(OEM) or OEM franchised distributors

(2) Procurement practices and internal processes used for exceptions to buying from OEM or OEM franchised distributors including a process to qualify/certify non-OEM parts & materials obtained

(3) Requirements to monitor supply (including delivery of test results from random sampling and supply chain surveillance that does not assume any source is safe) to identify possible penetration of OEM supply chain

(4) Training/certification program for receiving inspectors

(5) Process to verify counterfeit

(6) Processes to identify, store, and report counterfeit parts.

(7) Notification procedure (tailored to specific sub-contractor based on following Notification Procedure)

h. Self-audit of internal processes.

i. Monitor processes at all subcontractor levels processes and verify compliance through on-site audits.

j. Notification Procedure:

(1) Step 1: The contractor shall quarantine all suspect products pending further direction. The contractor shall provide a statement, with problem description, justifying why this is considered suspect and how it was detected. The contractor shall NOT notify the supplier that the items are suspected as being counterfeit items. However, consultation with the OEM is authorized. Make certain the parts and all members of the lot procured for use on this contract are stored in correct environmental controls. These parts need to be protected as evidence.

(2) Step 2: Contractors that identify suspect items shall immediately notify their customer that is the next link toward the prime contractor.

Notification shall be passed up the customer chain until reaching the prime contractor. The prime contractor shall immediately notify the cognizant Contracting Officer (CO) and Contracting Office Technical Representative (COTR) of all suspect items identified.

DI-MISC-81832

- 3 -

(3) Step 3: The contractor shall make certain that the original documentation is secured as evidence and maintain any and all documentation associated with the part to include:

a. Part information such as part identifying number, lot date code, manufacturer information and originator/point of contact information

b. Any information reflecting part procurement/acquisition traceability which should include a copy of the purchase order, any and all correspondence between the buyer and the supplier to include: e-mails, records of phone conversations and paper letters of correspondence

c. Part documentation from the purported original manufacturer, distributors and suppliers (certificate of compliance and certificate of conformance)

d. All visual examination and physical analysis/testing results and the technical data package showing that the parts passed the required screening and qualification tests

e. List of company products affected

(4) Step 4: Determine that the part is or is not counterfeit (Usually accomplished as part of root cause analysis of non-conforming parts and/or materials)

(5) Step 5: If the parts are found to be counterfeit, they shall be isolated and controlled pending direction from law enforcement.

(6) Step 6: The contractor shall provide any additional required information to the government’s investigation team

END OF DI-MISC-81832

Title: NUCLEAR CERTIFICATION IMPACT STATEMENT (NCIS)

Number: DI-NUOR-81888A Approval Date: 20130213

AMSC Number: F9332 Limitation:

DTIC Applicable: N/A GIDEP Applicable:

Office of Primary Responsibility: 27 (AFNWC)

Applicable Forms: N/A

Use/Relationship: The NCIS is required for the development of new nuclear certifiable items (procedures, equipment, software/firmware, facilities, systems, subsystems or components having a nuclear mission), and also required for the modification to pre-existing nuclear certified items in order to determine if the modification could affect nuclear certification. When it is determined that an item requires nuclear certification or will change the status of a previously certified item, the Air Force Nuclear Weapons Center (AFNWC)/NCS shall be formally notified by submission of the NCIS. The NCIS is a prerequisite before initiation of the nuclear certification process and therefore must be submitted prior to the release of a request for proposal or an equivalent program milestone.

a. There are two different NCIS forms that are provided by the AFNWC/NCS, the NCIS Short Form and the NCIS Long Form (for use with Detailed NCIS). The NCIS short form is intended for a proposed change to a nuclear certifiable item that will result in minor nuclear certification impact. The Detailed NCIS is intended for nuclear certification actions that require a more comprehensive nuclear certification impact description. Items requiring a Detailed NCIS are nuclear certifiable items that have not previously been nuclear certified (i.e., a new/or current weapon system that is tasked to support nuclear missions).

b. This Data Item Description (DID) is related to DI-NUOR-81409, Certification Requirements Plan, Air Force Instruction (AFI) 63-125, Nuclear Certification Program, and AFI 91-107, Design, Evaluation, Troubleshooting, and Maintenance Criteria for Nuclear Weapon Systems, AFI 91- 103, Air Force Nuclear Safety Design Certification Program, Air Force Manual (AFMAN) 91-118, Safety Design and Evaluation Criteria for Nuclear Weapon Systems, AFMAN 91–119, Safety Design and Evaluation Criteria for Nuclear Weapon Systems Software and NCIS Coordination Form V7.

(Copies of AF Instructions and Manuals are available online at http://www.e-publishing.af.mil/.

Copies of the NCIS Coordination Form can be obtained from: AFNWC/NCS, OPR: Richard Burton, 8601 Frost Ave., Bldg 20203, Kirtland AFB, NM 87117-5624 or e-mail Richard.Burton@Kirtland.af.mil.)

1. Reference documents. The applicable issue of the documents cited herein, including their approval dates and dates of any applicable amendments, notices and revisions, shall be as specified in the solicitation or contract.

2. Format. Contractor must use either the Short or Long Forms provided by the AFNWC/NCS.

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

Source: https://assist.dla.mil -- Downloaded: 2016-11-07T14:39Z http://www.e-publishing.af.mil/

DI-NUOR-81888

3. Content. The NCIS shall provide the evaluation of the potential for a nuclear certification impact and also provide the data necessary for the AFNWC/NCS to define the basic certification requirements. The NCIS short form shall be included for a proposed change to a nuclear certifiable item that will result in minor nuclear certification impact. The detailed NCIS shall be included for nuclear certification actions that require a more comprehensive nuclear certification impact description.

3.1 NCIS Short Form Template. The NCIS Short Form template is provided by the AFNWC/NCS as guidance. To aid with the understanding of the nuclear certification impact, supplementary information can be attached to the NCIS Short Form. If the AFNWC determines that the NCIS is insufficient the process can be delayed.

3.1.1 The NCIS Short Form template provides sections for and shall include the following information:

a. Certification Components Impacted:

Block a. Design certification.

Block b. Operational certification.

Block c. Proposed release case

b. Scope of Impact:

Block a. Systems that will be affected.

Block b. Miscellaneous (Project is, Project requires, Project affects, Project result of).

Block c. Equipment/software affected.

Block d. Tech Orders affected.

c. Signature Block:

Block a. Submitter’s name.

Block b. NCM’s name.

Block c. SPM’s name.

d. Description (a functional description of potential nuclear certification impact).

e. Nuclear Certification Recommendation.

3.2 Detailed NCIS. A detailed NCIS shall be derived from the NCIS Long Form template which is provided as guidance and shall be tailored as needed to adequately describe the certification impact. Nuclear certifiable items requiring a Detailed NCIS are items that have never been nuclear certified (i.e., a new/or current weapon system that is tasked to support nuclear missions).

3.2.1 The NCIS Long Form Template. The NCIS Long Form template provides sections for and shall include the following information:

a. Certification Components Impacted:

Block a. Design certification.

Block b. Operational certification.

Block c. Proposed release case.

DI-NUOR-81888

b. Scope of Impact:

Block a. Systems that will be affected.

Block b. Miscellaneous (Project is, Project requires, Project affects, Project result of).

Block c. Equipment/software affected.

Block d. Tech Orders affected.

c. Signature Block:

Block a. submitter’s name.

Block b. NCM’s name.

Block c. SPM’s name.

d. Table of Contents.

e. List of Figures – specific drawings, changes and actual depiction of proposed modifications.

f. Background:

(1) Introduction.

(2) Purpose.

(3) Scope.

(4) Description.

(5) Schedule.

g. Design Certification:

(1) Compatibility Certification.

(2) Nuclear Safety Design Certification.

(3) Rules Development.

(4) Technical Order Certification.

h. Operational Certification:

(1) Qualification Training.

(2) Personnel Reliability Program (PRP).

(3) Nuclear Surety Training.

(4) Initial Nuclear Surety Inspection (INSI).

i. Conclusion

j. Recommendation

k. References

l. Attachments – include any additional information deemed appropriate.

4. End of DI-NUOR-81888.

Title: Briefing Material

Number: DI-MGMT-81605 Approval Date: 15 February 2001 AMSC Number: G7425 Limitation: N/A DTIC Applicable: N/A GIDEP Applicable: No

Office of Primary Responsibility: G/TS-ALS

Applicable Forms: None

Use/relationship:

The Briefing Material shall provide the Government with the necessary briefing materials to conduct a formal or informal briefing.

l. Contract. This data item is generated by the contract which contains a specific and discrete work task to develop this data product.

2. Content. The content of the briefing material shall address those areas of the contractual effort identified by the Government on the DD Form 1423, Contract Data Requirements List (CDRL).

3. Format. The format for the briefing material shall be in contractors format unless otherwise specified by the DD 1423, or the COR.

End of DI-MGMT-81605

Source: https://assist.dla.mil -- Downloaded: 2016-11-07T14:50Z

Title: Management Plan

Number: DI-MGMT-80004A Approval Date: 30 OCT 2006 AMSC Number: 7621 Limitation: N/A DTIC Applicable: No GIDEP Applicable: No Office of Primary Responsibility: NS/DA02 Applicable Forms: N/A

Use/relationship: The management plan describes the contractor’s organization, assignment of functions, duties, and responsibilities, management procedures and policies, and reporting requirements for the conduct of contractually-imposed tasks, projects, or programs.

This Data Item Description (DID) contains format and content preparation instructions for the data product generated by the specific and discrete task requirement as delineated in the contract.

This DID may be applied in any contract or program phase where the contract management is under the direction and control of the contractor.

Requirements:

1. Reference documents. None.

2. Format. The plan shall be in a format that the contractor devises and conforms to the following:

a. Identification. The plan shall be identified with the preparing office or contractors title, the identifying numbers or designation of the Contract/Procurement Request, the identify and/or nomenclature of the system/component/program/project, the security classification and the Government activity issuing the controlling contract.

b. Descriptive material. As may be needed to clarify or explain matters in the text, the plan may include descriptive material, sketches, drawings, photographs, tables, forms, graphs, worksheets, charts, etc.

c. Page size. The plan may be typewritten or printed on standard size paper, e.g., 8 ½ x 11 inches or metric A4. The pages shall be sequentially numbered and security bound together. As necessary, graphic material may be one-way fold-outs. All attachments shall be identified and referenced in the text. Each section and paragraph shall be numbered.

d. Table of contents and index. Plans of more than 30 pages in length shall contain a

Source: https://assist.dla.mil -- Downloaded: 2016-11-09T21:30Z

h. delivery procedures

DI-MGMT-80004A

table of contents. Plans more than 120 pages in length shall also include an Index.

e. Legibility. The document shall be legible and reproducible.

3.1 General. The Management Plan shall consist of the organizational structure, the assignment of functions, duties, and responsibilities, the procedures and policies and the reporting requirements that are established for the initiation, monitoring, control, completion, test and verification, and reporting of contractual tasks, projects, and programs.

3.2 Specific contents. The Management Plan shall cover the organizational structure, program management methodology, personnel, security, and the reports as described herein. Other subjects to be included are as follows:

a. design control

b. reliability

c. configuration control

d. standardization

e. quality assurance

f. provisioning

g. control of Government property

i. tests

j. certifications

k. packaging

l. shipping

m. other

3.3 Organizational structure. The plan shall present an organizational chart and supporting narrative portraying the contractor’s business (corporate) structure. It shall describe the functional relationships and responsibilities among the organizational elements that will participate in the accomplishment of the contractual commitments.

3.4 Program management. The plan shall present an organizational chart and supporting narrative describing the management office the contractor establishes to manage the contractual commitments. The plan shall define the direct lines of control, responsibilities, functional relationships, and authority between the management office and the contractor’s other organizational elements. The plan shall also describe all interfaces between the contractor and the Government and between the contractor and other contractors which are necessary and pertinent to the accomplishment of contractual tasks, projects and programs.

3.5 Methodology.

a. The plan include a narrative description of the technical approach or methods the contractor will employ to accomplish contractual tasks, projects, and programs, including, as applicable, development, tests, manufacture, construction, formulation, installation, logistics support, training, maintenance documentation, and configuration controls.

b. The plan shall include a milestone chart graphically depicting the schedule of events associated with accomplishing each contractual commitment.

3.6 Personnel.

a. The plan shall list the personnel staffing of the contractor’s management office that directs the contractual tasks, projects, and programs and assist in completing the contract. The listing shall include the education, training, skills, experience, and security clearance that personnel require to fill each such position and shall state the identity, background, and work experience of the personnel assigned to fill these positions.

b. The plan shall also describe the staffing required for proper accomplishment of each contractual task by skill type, skill level, number of personnel, and security clearance. When submitted as part of a proposal, the plan shall state how many such personnel are currently available and how many new hires are required to staff fully to accomplish each task as scheduled.

3.7 Security.

a. Provide a Standard Practice Procedure (SPP) which fully describes the security program, safeguards emergency procedures to be established to the protection of Government-furnished and contractor-developed classified materials prepared In conjunction with the project. The SPP shall be prepared in accordance with guidelines contained in the Industrial Security Manual, Purchase Description, and such additional requirements as may be stipulated by the cognizant security compliance organization. The SPP shall require approval by the Government.

b. Develop a comprehensive security accreditation plan to demonstrate how the computer security requirements stipulated in the PD, as applicable, have been accounted for in the system design, and how satisfaction of each requirement will be explicitly demonstrated in the test program. This plan shall also identify any specific support equipment or software to be provided for demonstration of design compliance and/or system compliance with the planned security requirements. The plan shall require approval by the Government prior to implementation.

c. Reports. The plan shall describe the management methods the contractor will employ to ensure meeting all preparations, format, and submittal requirements established by the CDRL (DD Form 1423) for data to be delivered to the Government.

4. END OF DI-MGMT-80004A

DATA ITEM DESCRIPTION

Requirements:

Title: CONFERENCE AGENDA

Number: DI-ADMN-81249B Approved Date: 20160524

AMSC Number: F9658 Limitation:

DTIC Applicable: GIDEP Applicable:

Preparing Activity: 11 (AFLCMC/EZSC) Project Number: ADMN-2015-002

Applicable Forms: None

Use/Relationship: The Conference Agenda provides information concerning purpose, location, and schedule of conferences required to manage the acquisition of systems equipment, related items, and services.

a. This Data Item Description (DID) contains the format and content preparation instructions for the data product generated by the specific and discrete task requirement as delineated in the contract.

b. This DID supersedes DI-ADMN-81249A.

1. Reference documents. None.

2. Format. Contractor format is acceptable.

3. Content. The agenda shall include the following, where applicable:

a. The purpose and objective of the conference.

b. The conference location, date, and duration.

c. A daily chronological listing of each major topic or subtopic to be discussed and the time to be devoted to each topic.

d. A list of activities to be represented and identification of their responsibilities.

e. A list of subcommittees to be established during the conference and the proposed activity representation for each subcommittee.

f. Reference to and brief description of the results of previous meetings, when relevant.

g. Location, schedule, and purpose or subject area to be covered by each subcommittee, when applicable.

h. Names of the conference chairperson, co-chair, and subcommittee chairs, when applicable.

i. Information on billeting, messing, transportation, and administrative services available to conference attendees.

j. Complete list of all documentation to be available for review.

DISTRIBUTION STATEMENT A. Approved for public release; distribution is unlimited.

Source: https://assist.dla.mil -- Downloaded: 2018-02-21T19:29Z

DI-ADMN-81249B

k. Brief description of progress on actions or problems identified at previous meetings, when applicable.

l. Other pertinent information such as Forms to be used, identification of any deviations or waivers, security classification, and clearance requirements.

End of DI- ADMN-81249B

Source: https://assist.dla.mil -- Downloaded: 2018-02-21T19:29Z

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.

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: 2017-06-26T19:33Z

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

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.

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

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

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

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

GFI.

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

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

aa. Identification of all CSCs.

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

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.

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

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

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

d. Allocation of system requirements to the CI.

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.

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

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

Source: https://assist.dla.mil -- Downloaded: 2016-11-09T14:11Z

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.

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

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.

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

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

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

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.

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.

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

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

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

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

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

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.

x. Description of the equipment development…