Design Reviews (DRs)

Introduction

Design reviews serve to evaluate the project’s progress throughout its development process. Members of the Design Review Committee will be present at each DR presentation to identify issues and provide technical feedback. DRs are expected to last 60–90 minutes each. They are by default public, allowing all TURTLE members to attend.

  1. Project leads must submit their deliverables beforehand (2~3 days before).

  2. Project leads may submit a list of topics they may specifically want detailed feedback on.

  3. Project leads may choose to do one or two DRs per semester. They are by default Continuing DRs.

    1. 1 DR: One Saturday in the midterm of the semester.

    2. 2 DRs: Two Saturdays in the thirds of the semester. Transition DRs (PDR/CDR) will be done at the second third of the semester.

  4. Project subteam leads are expected to attend to present and explain their decisions and design choices. It is encouraged that project members are involved in making the design review deliverables.

  5. Project leads may choose to close their DR from the public.

Continuing Design Reviews

Definition

A design review to evaluate the project’s progress during its respective phase. Each semester, project leads may replace one of their Continuing Design Reviews with a transition Design Review (PDR or CDR).

Deliverables

  1. Project Objectives (if not in Research Phase)

    1. A list of objectives that the project intends to meet at the end of its development. These define the specific milestones the project needs to achieve.

    2. Number them as PO-1, PO-2, etc.

  2. System requirements and design choices (if not in Research Phase)

    1. Functional and performance requirements and their rationale to meet the Project Objectives.

    2. Start with high-level requirements and number them as R-1, R-2, etc.

    3. All design choices must be traced back to a system requirement, supported by the level of detail appropriate to the current development phase.

  3. Bill of Materials (BOM)

    1. A list of materials, components, and the quantities of each needed to progress in the current phase.

    2. The BOM must list all purchases necessary until the next Design Review.

  4. Gantt Chart

    1. The project schedule until the next Design Review in the following semester.

    2. The chart must contain all necessary project tasks and identify who is responsible for each task.

Preliminary Design Review (PDR)

Definition

A transition Design Review to progress from the Research Phase to the Prototyping Phase.

Deliverables

  1. Project Objectives

    1. A list of objectives that the project intends to meet at the end of its development.

    2. Number them as PO-1, PO-2, etc.

  2. System requirements and design choices

    1. Functional and performance requirements and their rationale to meet the Project Objectives.

    2. Start with high-level requirements and number them as R-1, R-2, etc.

    c. All system requirements must be traced back to a Project Objective. c. All design choices must be traced back to a system requirement and must be supported by documentation from the project, including but not limited to:

    1. Basic electronics diagrams

    2. High-level pseudocode (all code must be uploaded onto the project’s GitHub repository)

    3. Rough CAD drawings or design sketches

    4. Any other relevant pictures of the project’s progress

  3. Bill of Materials (BOM)

    1. A list of materials, components, and quantities needed to progress into the Prototyping Phase.

    2. The BOM must list all purchases necessary until the next Design Review.

  4. Gantt Chart

    1. The project schedule until the next Design Review in the following semester.

    2. The chart must contain all necessary project tasks and identify who is responsible for each task.

Critical Design Review (CDR)

Definition

A transition Design Review to progress from the Prototyping Phase to the Production Phase.

Deliverables

  1. Project Objectives

    1. A list of objectives that the project intends to meet at the end of its development.

    2. Number them as PO-1, PO-2, etc.

  2. Finalized system requirements and design choices

    1. Functional and performance requirements and their rationale to meet the Project Objectives.

    2. Start with high-level requirements and number them as R-1, R-2, etc.

    3. All design choices must be traced back to a system requirement and must be supported by documentation from the project, including but not limited to:

      1. Trade studies

      2. Functional code (all code must be uploaded onto the project’s GitHub repository)

      3. Detailed CAD drawings and assemblies

      4. Detailed CAD drawings and assemblies

      5. Simulations

      6. Test Data

      7. Any other relevant pictures of the project’s progress

  3. Final Bill of Materials (BOM)

    1. A final list of materials, components, and quantities required to progress into the Production Phase.

  4. Gantt Chart

    1. The project schedule through the end of the development process.

    2. The chart must contain all necessary project tasks and identify who is responsible for each task.