
2/15

Date

December 29, 2006

April 11, 2007

October 1, 2009

t


3/15

A

B

C

D

E

F

G

H

I

J

STAR Critical Design Review Check List

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.

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:

Detailed instructions for filling in the checklist can be found in the STAR EPL Process Asset "Critical

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.

Each item should have an "X" filled in for one, and only one, of columns C, D, E, F or G

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).

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


4/15

Pass

Conditional

Pass Defer Waive N/A

1.0 Introduction

1.1.1The 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.1Project stakeholder roles have been identified in the CDD and

DPP.

1.3.2Project stakeholder personnel have been identified in the CDD

and DPP.

1.3.3Project 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 (CL-

8.1).

1.8.1The CDD provides a pointer to the CDR Report Guidelines (DG-

8.3).

1.9.1 The CDR review objectives are satisfactory.

2.0 PDR Report

2.1.1The 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.2The CDD provides a satisfactory description of tailored CDR entry

criteria

CLI # Check List Item (CLI)Disposition


5/15

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


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

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


version of the SWA.

2.2.11

n ry - e a e es gn ocumen as een wr en

for each software unit in the software architecture. The CDR

reviewers have access to the current baseline version of each

2.2.12

Entry # 8 - A Verification and Validation Plan (VVP) has been


version of the VVP.

2.2.13Entry # 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.2The CDD provides a satisfactory description of tailored CDR exit

criteria

2.3.3The CDD provides a satisfactory description of waived CDR exit

criteria

2.3.4Deviations from CDR exit criteria that were established at the PDR

are approved and documented in the CDRR.

3.0 Operations Concept


6/15

4.0 Requirements

4.1.1The CDD illustrates the iterative development of requirementsduring the Design Development phase of the STAR EPL process.

4.2.1The PRD introduces the Requirements Allocation Document

(RAD) and provides a pointer to the RAD.

4.3.1The 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.1The 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.1The CDD introduces the Algorithm Theoretical Basis Document

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

5.2.1The CDD describes the objectives of the algorithm consistent with

the ATBD.

5.2.2The algorithm objectives are derived from and consistent with the

operations concept

5.3.1The attributes of the sensing system(s) used to supply data for the

algorithm are described in the CDD and ATBD.

5.3.2The 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


7/15

5.8.1The mathematical description of the algorithm is correct and

consistent with the physical description.

5.9.1The 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.3Results from performance testing, as documented in the ATBDand CDD, provide a convincing demonstration that the selected

solution will meet requirements.

5.10.4The documentation of performance testing in the ATBD and CDD

is sufficient to identify performance risks.

5.11.1The 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.2The 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.3The external interfaces in the software architecture meet the

required criteria

6.2.4The CDD description of the Context-Layer software architecture is

consistent with the SWA.

6.2.5The CDD introduces the Interface Control Document (ICD) and

provides a pointer to the project ICD


8/15

7.2.2The CDD introduces the Detailed Design Document (DDD) and

provides a pointer to the project DDDs.

7.3.1The 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-Unit-

Layer

7.4.1The 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, andancillary data files in the algorithm design

7.4.1The 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.2The 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.4The 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.2The 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


9/15

8.5.4The CDD and VVP identify the tools and training available for

Operations and Maintenance (O&M).

8.5.5The CDD and VVP describe the scope of the validation for each

operator need.

8.5.6The 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.8The 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.1The 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.3All unapproved requirements allocation changes since PDR havebeen properly disposed of.

10.0 Risks and Actions

10.1.1The 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/15

Comments


11/15


12/15


13/15


14/15


15/15

STAR Critical Design Review Check List v3.0

Documents

Transcript of STAR Critical Design Review Check List v3.0