STAR CL-8.

1: STAR Critical Design Review Review Check List

Version History Summary
Version

1.0

Description
New Check List adapted from CMMI
guidelines and Raytheon Systems
Engineering practices by Ken Jensen
(Raytheon Information Solutions). Initial
version named T-11.1.

Revised Sheets

N/A

2.0

Revised by Ken Jensen (Raytheon

Information Solutions) for version 2.
Renamed CL-11.1

Added "Approval" and "Version History"

sheets. Document renamed CL-11.1.
Risks and Actions sections combined. Exit
and entry criteria moved to Section 2.
Some revisions to Check List Items.

3.0

Revised by Ken Jensen (Raytheon

Information Solutions) for version 3.
Renamed CL-8.1.

"Approval" sheet deleted. "CDR Check

List" sheet revised.

Check List

Date

December 29, 2006

April 11, 2007

October 1, 2009

STAR Critical Design Review Check List

The check list in the following "CDR Check List" sheet is the STAR standard checklist for a Critical Design
Review (CDR).
The CDR reviewers should use this as the basis for their review checklist, but may tailor their checklist by
adding, deleting, or modifying items (rows). The columns may NOT be modified.
The columns are:
A

CLI # - Check List Item ID number

Check List Item (CLI) - Check List Item Description

Disposition (Pass) - Fill in an "X" if the item receives a "Pass" disposition.

Disposition (Conditional Pass) - Fill in an "X" if the item receives a "Conditional Pass" disposition.

Disposition (Defer) - Fill in an "X" if the item receives a "Defer" disposition.

Disposition (Waive) - Fill in an "X" if the item receives a "Waive" disposition.

Disposition (N/A) - Fill in an "X" if the item receives a "Not Applicable" disposition.

Risk - Provide a risk evaluation. Standard evaluations are comprised of four levels (High, Medium, Low,
None). It is recommended that the cells be filled in with (Red, Yellow, Green, Blue) fill color corresponding
to the risk level.

Action (Y/N) - Fill in "Y" if there is at least one open action associated with this item; if no actions, fill in "N".
An item with a risk evaluation of Medium or worse should generate at least one action. Low risk items may
also generate actions, at the discretion of the reviewers.

Comments - Include any explanatory comments (e.g. rationales for the disposition of the item, rationales
for the risk evaluation, description of open actions, identification of the review that should address the
actions).
Each item should have an "X" filled in for one, and only one, of columns C, D, E, F or G
Detailed instructions for filling in the checklist can be found in the STAR EPL Process Asset "Critical
Design Review Peer Review Guidelines" (PRG-8.1)

Disposition
CLI #

Check List Item (CLI)

1.0

Introduction

1.1.1

The Critical Design Document (CDD) provides a pointer to the

Development Project Plan (DPP)

1.2.1

Project objectives are consistently identified in the CDD and DPP.

1.3.1

Project stakeholder roles have been identified in the CDD and

DPP.

1.3.2

Project stakeholder personnel have been identified in the CDD

and DPP.

1.3.3

Project stakeholder tasks have been adequately described in the

DPP.

1.4.1

Project milestones have been identified in the CDD and DPP.

1.4.2

A project timeline has been included in the CDD and DPP.

1.5.1

Modifications to the project plan since the Preliminary Design

Review (PDR) are clearly explained, including the rationale and
documentation of management concurrence.

1.6.1

Stakeholders are involved in the project as expected.

1.7.1

The Critical Design Document (CDD) provides pointers to the

CDR Peer Review Guidelines (PRG-8.1) and CDR Check List (CL8.1).

1.8.1

The CDD provides a pointer to the CDR Report Guidelines (DG8.3).

1.9.1

The CDR review objectives are satisfactory.

2.0

PDR Report

2.1.1

The CDD provides a pointer to the Preliminary Design Review

Report (PDRR)

2.2.1

CDR entry criteria are listed completely and correctly in the CDD

2.2.2

The CDD provides a satisfactory description of tailored CDR entry

criteria

2.2.3

The CDD provides a satisfactory description of waived CDR entry

criteria

2.2.4

Deviations from CDR entry criteria that were established at the

PDR are approved and documented in the Critical Design Review
Report (CDRR).

2.2.5

Entry # 1 - A Preliminary Design Review Report (PDRR) has been

written. The CDR reviewers have access to the current baseline
version of the PDRR.

2.2.6

Entry # 2 - A Development Project Plan (DPP) has been written.

The CDR reviewers have access to the current baseline version of
the DPP.

Pass

Conditional
Pass

Defer

Waive

N/A

Risk

Action
(Y/N)

2.2.7

Entry # 3 - An Operations Concept Document (OCD) has been

written. The CDR reviewers have access to the current baseline
version of the OCD.

2.2.8

Entry # 4 - A Requirements Allocation Document (RAD) has been

written. The CDR reviewers have access to the current baseline
version of the RAD.

2.2.9

Entry # 5 - An Algorithm Theoretical Basis Document (ATBD) has

been written. The CDR reviewers have access to the current
baseline version of the ATBD.

2.2.10

2.2.11

2.2.12

Entry # 6 - A Software Architecture Document (SWA) has been

written. The CDR reviewers have access to the current baseline
version of the SWA.
Entry # 7 - A Detailed Design Document (DDD) has been written
for each software unit in the software architecture. The CDR
reviewers have access to the current baseline version of each
DDD.
Entry # 8 - A Verification and Validation Plan (VVP) has been
written. The CDR reviewers have access to the current baseline
version of the VVP.

2.2.13

Entry # 9 - A Critical Design Document (CDD) has been written.

CDR review objectives are clearly stated in the CDD.

2.2.14

Entry # 10 - A Project Baseline Report (PBR) has been written.

The CDR reviewers have access to the current baseline version of
the PBR.

2.3.1

CDR exit criteria are listed completely and correctly in the CDD

2.3.2

The CDD provides a satisfactory description of tailored CDR exit

criteria

2.3.3

The CDD provides a satisfactory description of waived CDR exit

criteria

2.3.4

Deviations from CDR exit criteria that were established at the PDR
are approved and documented in the CDRR.

3.0

Operations Concept

3.1.1

The CDD has explained the link between the concept of

operations and requirements development.

3.1.2

The CDD introduces the Operations Concept Document (OCD)

and provides a pointer to the project OCD.

3.2.1

The CDD and OCD satisfactorily explain why the products are
being produced.

3.3.1

The CDD and OCD satisfactorily explain how the products will be
used.

3.4.1

The CDD and OCD satisfactorily explain how the products should
be produced. Production and delivery scenarios have been
described, consistent with the level of detail in the customer's
concept of operations and the production environment constraints.

4.0

Requirements

4.1.1

The CDD illustrates the iterative development of requirements

during the Design Development phase of the STAR EPL process.

4.2.1

The PRD introduces the Requirements Allocation Document

(RAD) and provides a pointer to the RAD.

4.3.1

The CDD describes each new requirement since PDR in sufficient

detail.

4.3.2

The CDD explains the rationale for each new requirement since
PDR, notes the potential effects on the project plan, documents
the agreement of affected stakeholders, notes new or modified
risks that result from the new requirement and notes any
recommended actions that result from the new requirement

4.4.1

The CDD describes each changed requirement since PDR in

sufficient detail.

4.4.2

The CDD explains the rationale for each changed requirement

since PDR, notes the potential effects on the project plan,
documents the agreement of affected stakeholders, notes new or
modified risks that result from the new requirement and notes any
recommended actions that result from the new requirement

5.0

Algorithm Theoretical Basis

5.1.1

The CDD introduces the Algorithm Theoretical Basis Document

(ATBD) and provides a pointer to the project ATBD.

5.2.1

The CDD describes the objectives of the algorithm consistent with

the ATBD.

5.2.2

The algorithm objectives are derived from and consistent with the
operations concept

5.3.1

The attributes of the sensing system(s) used to supply data for the
algorithm are described in the CDD and ATBD.

5.3.2

The CDD provides pointers to appropriate Sensor Specifications

and sensor review documents.

5.3.3

The sensor attributes documented in the ATBD and CDD are

consistent with the appropriate Sensor Specification and/or sensor
reviews.

5.4.1

The attributes of all input data used by the algorithm, including

ancillary data, forward models and look-up tables, are
documented in the ATBD and CDD.

5.5.1

The fundamental approach for retrieval, as documented in the

ATBD and CDD, is satisfactory.

5.6.1

The description of the algorithm process flow is clear and

consistent with the software architecture documentation.

5.7.1

The adopted approach is satisfactory, given the project

requirements and the available algorithm technology

5.7.2

The physical description of the algorithm is correct and consistent

with the adopted approach.

5.8.1

The mathematical description of the algorithm is correct and

consistent with the physical description.

5.9.1

The algorithm output descriptions in the CDD and ATBD are

consistent with the software architecture and with requirements.

5.10.1

The ATBD and CDD describe the predicted algorithm

performance and quality of the products derived from analysis and
tests with simulated and/or proxy test data.

5.10.2

Verification methods and assumptions are noted in the ATBD and

CDD, with references to the project's Verification and Validation
Plan (VVP).

5.10.3

Results from performance testing, as documented in the ATBD

and CDD, provide a convincing demonstration that the selected
solution will meet requirements.

5.10.4

The documentation of performance testing in the ATBD and CDD

is sufficient to identify performance risks.

5.11.1

The CDD and ATBD adequately address the practical

considerations specific to this algorithm.

6.0

Software Architecture and Interfaces

6.1.1

The CDD explains the concept of software architecture

6.1.2

The CDD introduces the Software Architecture Document (SWA)

and provides a pointer to the project SWA.

6.1.3

The CDD illustrates the four layers of data flows.

6.2.1

The CDD explains the Context-Layer of the software architecture

6.2.2

The required criteria for external interfaces are listed in the CDD.
Deviations from the STAR standard criteria are noted and
explained.

6.2.3

The external interfaces in the software architecture meet the

required criteria

6.2.4

The CDD description of the Context-Layer software architecture is

consistent with the SWA.

6.2.5

The CDD introduces the Interface Control Document (ICD) and

provides a pointer to the project ICD.

6.3.1

The CDD explains the System-Layer of the software architecture

6.3.2
6.4.1
6.5.1

The System-Layer data flows are consistently and satisfactorily

described in the SWA and CDD.
The Unit-Layer data flows are consistently and satisfactorily
described in the SWA and CDD.
The Sub-Unit-Layer data flows are consistently and satisfactorily
described in the SWA and CDD.

7.0

Detailed Design Description

7.1.1

The CDD explains the concept of detailed design

7.2.1

The CDD explains the concept of software detailed design

7.2.2

The CDD introduces the Detailed Design Document (DDD) and

provides a pointer to the project DDDs.

7.3.1

The detailed design for each unit fully defines the structure and
capabilities of the software product components at the Unit-Layer

7.3.2

The detailed design for each unit, fully defines the structure and
capabilities of the software product components at the Sub-UnitLayer

7.4.1

The detailed design for each unit, fully describes each Look Up
Table (LUT) in the algorithm design

7.5.1

The detailed design for each unit, fully describes all parameter
files, system control files, input/intermediate/output data files, and
ancillary data files in the algorithm design

7.4.1

The detailed design for each unit, fully describes each Look Up
Table (LUT) in the algorithm design

7.5.1

The detailed design for each unit, fully describes all parameter
files, system control files, input/intermediate/output data files, and
ancillary data files in the algorithm design

8.0

Quality Assurance

8.1.1

The CDD explains the distinction between PROCESS QA and

PRODUCT QA

8.2.1

The CM/DM stakeholders for the project are identified.

8.2.2

The CM/DM stakeholders for the project are committed to the

project plan.

8.2.3

The CDD describes the CM/DM tools that are in use for the project

8.2.4

The CDD introduces the Project Baseline Report (PBR) and

provides a pointer to the project PBR.

8.3.1

The PDD explains the concepts of verification and validation

8.3.2

The PDD introduces the Verification and Validation Plan (VVP)

and provides a pointer to the project VVP.

8.4.1

The CDD, VVP and DPP consistently identify the work products to
be verified and the requirements to be satisfied by each work
product selected for verification.

8.4.2

The verification methods documented in the CDD and VVP are

satisfactory.

8.4.3

Verification activities documented in the VVP and CDD are

consistent with the project plan.

8.5.1
8.5.2

8.5.3

The CDD and VVP identify user-driven requirements on the

product or products to be validated
The CDD and VVP satisfactorily describe the scope of the
validation, distinguishing between pre-launch and post-launch
plans
The CDD and VVP identify operator needs (operations and
maintenance, or O&M) to be validated

8.5.4

The CDD and VVP identify the tools and training available for
Operations and Maintenance (O&M).

8.5.5

The CDD and VVP describe the scope of the validation for each
operator need.

8.5.6

The CDD and VVP identify user needs (training, support, use of
products) to be validated.

8.5.7

The CDD and VVP identify the tools, training, and support
services available to the user, and the procedure for delivering
these to the intended users.

8.5.8

The CDD and VVP describe the scope of the validation for each
user need.

9.0

Requirements Allocation

9.1.1

The CDD illustrates the iterative development of the requirements

allocation during the Design Development phase of the STAR
EPL process.

9.2.1

The RAD correctly documents each requirements allocation

change since PDR.

9.2.2

The CDD provides the information needed for CDR reviewers to

dispose of each unapproved requirements allocation change since
PDR.

9.2.3

All unapproved requirements allocation changes since PDR have

been properly disposed of.

10.0

Risks and Actions

10.1.1

The CDD correctly reports, in sufficient detail, the status of each

risk identified at the PDR and documented in the PDRR.

10.1.2

The CDD reports the status of all PDR actions with sufficient detail
to allow the CDR reviewers to assess the current status of the
actions and their associated risks.

10.2.1

The CDD reports, in sufficient detail, the status of each risk that
has been identified since PDR.

10.2.2

The CDD reports the status of all new actions with sufficient detail
to allow the CDR reviewers to assess the current status of the
actions and their associated risks.

10.3.1

The CDD provides a list of risks that can be closed

10.3.2

The CDD provides a list of outstanding risks, in priority order.

10.3.3

The CDR reviewers' assessment of outstanding risks and actions

is documented in the CDR Report

11.0

Summary and Conclusions

11.1.1

All review objectives have been addressed.

11.2.1
11.3.1

The CDD lists all outstanding issues, actions and risks that require
attention.
The CDD lists the recommendations of the development team for
the next steps after the CDR.

Comments