1

Project NameSystem Critical Design Review

Class Number – TitleDate

Location

Insert project logo

This Critical Design Review assumes that the design team will be following a formalized design process. This design process is assumed to follow the following major steps:1 – Formulation2 – Conceptual Design3 – Configuration Design4 – Detailed DesignThe Critical Design Review builds on the content found in the Preliminary Design Review , updates the information found in the Design Formulation,Conceptual Design, and Configuration Design phases for information learned since then, and summarizes the design development from the Detailed Design phase. For all of the pages that are repeats of the Preliminary Design Review, ensure that all of the information, diagrams, and requirements track to the current design state. Revise the information as needed.

On this slide, you will need to enter the project name, class number (e.g. EE 498 – Capstone Design I), date, and location. It is also recommended that the project develop an interesting logo and attach it here as well. The logo can also be carried on the subsequent slides as well.

2

Date Project PDR 2

Topics

• Project Overview• System Overview • System Element 1• System Element 2• System Element 3• Management Overview• Supplemental Slides

This is the suggested content and order of presentation for the review. Sponsor may request a different order or additional topics. Modify as required. Be sure to go to the Headers/Footers tool and update the Date and Project name in the footer.The System Element 1, 2, and 3 sections are place holders for the actual number of system elements in the design. The same general format is used in each section description. The actual number of system elements will depend upon the nature of the system design.

3

Date Project PDR 3

Project Overview

• Project Mission Statement– One paragraph statement of the overall goal

(general attributes) of the project. This is a high-level summary statement (few specific details).

• Project Technology Demonstration– What are the key technologies to be demonstrated

in the project• Project Objectives

– List objectives (specific attributes) to define the mission statement. These are lower-level and more specific than the Mission Statement.

The “Mission Statement” is the problem statement from the Formulation stage of the design. The Technology Demonstration section is an optional listing of interesting technologies that the project may be attempting. Basically this is the first of several marketing sections to highlight interesting features of the design.The Project Objectives section is to expand on the mission statement. Again, this is to better explain the project to others.Note: If needed, expand this page out to multiple pages so that the print does not become too small.

4

Date Project PDR 4

Project Overview

• Project Success Criteria– What will be the minimum set of testable

outcomes to declare the project a success• Relevance to Sponsor

– What are the reasons that the sponsor should support the project (what will it do for the sponsor?)

The Success Criteria should be tied to the system integration and test plan. These criteria are the ones that represent a “buy-off” on a successful completion of the design.The Relevance to the Sponsor section is marketing back to the sponsor to tell the sponsor why this project fulfills a critical need for that sponsor.

5

Date Project PDR 5

Project Overview

• Project-level Requirements– Project success and other programmatic criteria turned into

a set of specific, testable statements. If programmatic criteria come from a specification document that must be met, reference the document. List these requirements in a table.

MSTestable project-level requirement

P1

SourceRequirementID

These are the system-level requirements developed in the system design Formulation stage. These requirements should also be in the first section of the Requirements Verification matrix. Generally, the project-level (total system level) requirements will track to the overall mission statement.

6

Date Project PDR 6

System Overview

• Itemize the major system elements and a brief statement of their function

System Block Diagram/Graphic

This slide begins the Conceptual Design for the entire system. The block diagram is intended to be the Conceptual Design Diagram from the conceptual design phase of the design process. This diagram will show the major system elements that will be refined further via the more detailed design stages. The Conceptual Design should show the major system information flow and power distribution, as necessary.The list of major system elements and functions will be summary statements. We will expand these more later in the presentation.

7

Date Project PDR 7

System Overview

Graphic to illustrate system operational phases

This is intended to be a graphical summary of the system operations concept. It should be more than just On/Off. It should show major operational phases and/or timing.

8

Date Project PDR 8

G = low risk Y = medium risk R = high risk NA = N/A

Facilities

NAOverall System Element Assessment

Manpower

Testing

RSafety

GCost

GSchedule

YPerformanceO

verall Program

Assessm

ent

System

Elem

ent N

………………

System

Elem

ent 2S

ystem

Element 1

Project System Element Risk Assessment

Assess the risk status of the overall project based on the assessment made of each of the system elements. Take the “system element” columns from the last column of the matching chart for the system element summary.Use the Red/Yellow/Green color coding:• Green – no issues with this portion of the design; all relevant technologies are known, components/software tested; everything works as it should.• Yellow – there are design issues still to be resolved, parts may not yet be fully tested so there are unknowns, etc. There are issues that can be identified as posing a problem but nothing that is believed to be ready to cause a major setback.• Red – many unknowns in the design of hardware or software that could prevent proper operation or completion of the project; parts with long lead times or critical operating conditions may be considered to be “red” until they are in hand or the operations are fully understood.Generally, the project-level “risk to completion” should be the “worst case”risk of any of its system elements for a given category.

9

Date Project PDR 9

System Element 1

• System Element Description– For each major system element, give a

detailed description of the main function it is to perform.

• System Element Success Criteria– For each major system element, give a

detailed listing of success criteria

RISK

R

This is the beginning of the Conceptual Design description for the first major system element. Additional system elements in the overall system design will follow this same format with appropriate modifications.The system description section is really the Problem Statement from the Formulation step of the design process for this system element. Similarly,the system element success criteria should relate back to the system element test plan.Assess the “risk to completion” for this system element.

10

Date Project PDR 10

System Element 1

• System Element Requirements– Testable requirements tied to project-level

requirements for the 1st system element

PxTestable project-level requirementS1-j

SourceRequirementID

These are the system element requirements developed in the Formulationphase of the design for this system element. These requirements should also appear as the first ones in the System Element section of the Requirements Verification matrix. Most of these requirements should track to project-level requirements. However, they may also track to the mission-level (project-level) requirements as well.

11

Date Project PDR 11

System Element 1

• Subsystem Listing– For each major system

element, list the subsystems to comprise that system element. Use WBS numbering to identify them.

– Include a block diagram showing the relative relationship between the subsystems and any signals that can be defined

Graphic capturing the Conceptual Design Diagram for the system element

This is to capture the functional decomposition for the system element that was developed during the Conceptual Design for the system element.The graphic should be the Conceptual Design Diagram from the Conceptual Design phase for this system element. For clarity, this diagram can be move to a full page.

12

Date Project PDR 12

System Element 1

• Subsystem Definition– Describe the function(s)

to be performed by the ithsubsystem of system element 1

– Describe any operational phases or timings relevant to the subsystem

– Subsystem I/O (power and/or signals)

Subsystem block diagram/graphic

RISK

R

This is the description for each of the subsystems identified in the Functional Decomposition in this system element.

For each subsystem, indicate it’s current risk status.

Repeat this slide for each of the subsystems in this system element.

13

Date Project PDR 13

System Element 1

• Subsystem Requirements– Testable requirements tied to system element

requirements for the ith subsystem of system element 1

S.1-xTestable project-level requirement

S1.i-j

SourceRequirementID

These are the subsystem element requirements developed in the Formulation phase of the design for this subsystem belonging to the system element. These requirements should also appear as the second level ones in the System Element section of the Requirements Verification matrix. Most of these requirements should track to system element-level requirements. However, they may also track to the mission-level (project-level) requirements as well.

14

Date Project PDR 14

System Element 1

Insert a graphic showing the Part Configuration for this subsystem.

This is the Part Configuration diagram from the Configuration Design phase. Be sure to include interfaces, information, power, and control signal flow in some manner. This should be updated from the PDR slides.

15

Date Project PDR 15

System Element 1

Insert the data from the Parametric Design.

These are the design variables from the Parametric Design in the Configuration Design phase. This is probably best entered as a spreadsheet. This should be updated from the PDR slides.

16

Date Project PDR 16

System Element 1Detailed schematics/drawings/flow charts, etc.

This shows the actual configuration drawing to move to subsystem “build.”

17

Date Project PDR 17

System Element 1

• Support Analysis/Data– Power needs (nominal, worst case)– Mass budget, form factor restrictions– Thermal considerations/mitigation– Safety factors (vibration, mass, wire gauge,

fasteners, etc.)– Regulatory issues (code specifications, regulatory

specifications, etc.) that must be met; status of any relevant applications, licenses, or reviews

This is all of the major analysis to back up selections made in the parametric design table. This may extend to several pages, depending upon the state and complexity of the design. This should be updated from the PDR slides.

18

Date Project PDR 18

System Element 1

• Hardware/software status– If any hardware/software has been

developed to test design concepts, show results here

– Indicate any potential design delays (long lead items, etc.) here.

Optional slide to cover actual hardware/software status if known at this time. If there is a specific reason why a design element is still “high risk,” this would be the place to explain the status.

19

Date Project PDR 19

G = low risk Y = medium risk R = high risk NA = N/A

Facilities

NAOverall Subsystem Assessment

Manpower

Testing

RSafety

GCost

GSchedule

YPerformance

Overall

System

Elem

ent Assessm

ent

Subsystem N

………………

Subsystem 2

Subsystem 1

System Element Subsystem Risk Assessment

Assess the risk status for this system element. Use the same red/yellow/green criteria as before. Copy the last column results to the appropriate column in the program-level table.

20

Date Project PDR 20

Management Overview

• Organizational Chart• WBS• Schedule• I&T Summary• Budget• Detailed Risk Assessment and

Mitigation

These are the main management issues at this point in the design process. If the sponsor requires others, add them as needed.

21

Date Project PDR 21

Organizational Chart

Show an organizational chart with lines of reporting for team members. Also indicate advisors/helpers

Enter an organizational chart for the whole project.

22

Date Project PDR 22

WBS

• WBS– Project Work breakdown Structure

Develop a system Work Breakdown Structure (WBS) for the system.

23

Date Project PDR 23

Schedule

• Schedule– Show expected time line for the project

(can be done as a Gantt chart)– Use the WBS from the preceding slide

This is the high-level project schedule as best can be determined at this point. Typically a Gantt chart is used. A similar chart in a spreadsheet can also be used. It should be organized via WBS.

24

Date Project PDR 24

I & T Summary

• I&T Overview– Describe the approach to how I&T will be

accomplished• I&T Flow

– Describe the flow of the I&T from unit level to final acceptance testing

At this point, the integration and test concepts should be being developed. How will all of the system elements be integrated and tested?

25

Date Project PDR 25

Budget

• Budget– Personnel and resources budget for

developing the project

There are several budgets important in the design:1 – financial2 – personnel3 – required resources.These can be done as a series of spreadsheets with one per page.

26

Date Project PDR 26

Detailed Risk Assessment and Mitigation

How will the risk be minimized and/or contained by the design

Describe the risk and other systems/subsystems that could be impacted

Element or subsystem that has major risk potential

Proposed MitigationDescriptionRisk Element

For the “big risk” items, how will that risk be mitigated?

27

Date Project PDR 27

Documentation

• The following documents are suggested to be ready at the time of the Critical Design Review:– Finalized Parts List and Materials List.– Finalized Operations Concept Document– Finalized Interface Control Document– Finalized Integration and Test Plan– Finalized budgets: power, mass, size,

communications links, etc.– Finalized Requirements Matrix and Requirements

Document