ISO9001 System Document Package (52) | Design and Development Record Form Templates: Design Task Book, Review Record, Verification and Validation Report, and Change Request Form

Document Description: This document is a set of "design and development" record form templates, which are part of the fourth-level documents. It serves all sub-clauses of ISO 9001:2015 Clause 8.3 (Design and Development of Products and Services) — 8.3.1 General, 8.3.2 Design and Development Planning, 8.3.3 Design and Development Inputs, 8.3.4 Design and Development Controls, 8.3.5 Design and Development Outputs, 8.3.6 Design and Development Changes — and extends to post-production engineering changes through 8.5.6 (Control of Changes) and 6.3 (Planning of Changes). The control requirements for records themselves are governed by 7.5.3 (Control of Documented Information). The second-level document, "Design and Development Control Procedure," specifies "who does what at what stage and when a review must be conducted." The third-level document, "Design and Development Stage Work Instruction," specifies "how each action is performed and what criteria must be met to pass." This document translates these requirements into printable or directly copyable tables, criteria, and conclusion columns for use in Excel and project management tools, detailing what to fill in, who fills it, when to fill it, and what conclusions allow progression to the next stage. It is applicable to organizations in mechanical equipment, electronics, automotive parts, tooling and molds, packaging and printing, customized software, and engineering services that are establishing or revising their ISO 9001 system. It is also suitable for organizations that already have certification but whose design records exist only on local engineer computers, where reviews are conducted verbally and changes are notified via email. Once approved, these forms become controlled records and must be registered with a number and retention period in the record list. Departments using the forms are not allowed to delete review elements, cancel verification items, or simplify the approval process.

1. Purpose

To standardize the headers, fields, criteria, and archiving requirements for design and development records, ensuring:

a) Planning Traceability: Each design project clearly defines phase divisions, responsible persons, time nodes, review/verification/validation activities, and interface personnel at the start, avoiding "doing and changing simultaneously, wherever it ends up";

b) Verifiable Inputs: Functionality, performance, regulations, reliability, manufacturability, maintainability, packaging and transportation, and customer special requirements are listed item by item, with each input having a source and review conclusion. In case of disputes, it can be traced back to "what was initially required";

c) Substantive Reviews: Reviews are not just "everyone looks over it and has no objections," but involve asking questions, recording opinions, and assigning responsibilities and closure deadlines for each item. Items not closed cannot proceed to the next stage;

d) Separation of Verification and Validation: Verification answers "whether the design output meets the design input," while validation answers "whether the product can be accepted under real-use conditions." These two types of records, criteria, and signatories are separate to avoid using a single test report as evidence for both;

e) Controlled Changes: Any changes affecting approved design outputs must go through six stages: application, impact analysis, graded approval, implementation, verification, and document update. There must be clear conclusions on the impact on work-in-progress, inventory, delivered products, and customer commitments;

f) Traceable Outputs: The design output list, version status, number of distributed and recalled copies, and controlled identification are clear. The versions of drawings, specifications, and work instructions used on-site are consistent, avoiding "two sets of drawings circulating in the workshop."

2. Scope of Application

2.1 This set of templates includes the following 6 record forms, covering the main evidence chain from "project initiation → planning → input → output → verification → validation → change":

2.2 Applicable Scenarios:

a) Organizations establishing a system for the first time, building design and development process record carriers from scratch, and completing the five types of evidence required by Clause 8.3 (planning, input, output, control, and change) in one go;

b) Routine design projects of certified organizations: new product development, product modification, platform derivatives, non-standard customization, and customer委托 design (the party responsible for design in ODM/OEM);

c) Process design projects: design of tooling and fixtures, specialized equipment, automated workstations, and packaging solutions, which also use this set of forms, but with "process characteristics" instead of "product characteristics";

d) As a unified design evidence base during customer second-party audits, customer special requirement checks, and pre-regulatory type testing reviews.

2.3 Boundaries with Other Documents: This document only provides table formats, field definitions, and criteria. The division and gate control of design stages, role permissions, principles of solution selection, and references to reliability testing standards are specified in the "Design and Development Control Procedure." Specific calculations, simulations, and test operation steps are covered by third-level work instructions and test standards. If there is a conflict between this form and the procedure document, the procedure document takes precedence, and the using department should submit a form revision request to the system office.

2.4 Not Applicable: Records for daily process parameter adjustments in production are covered in the "Production Process Control Procedure" (Article 17 of the package) and the "Change Management Procedure" (Article 29 of the package). Inspection records for incoming materials and finished products are covered in the "Production Inspection Record Form Templates" (Article 53 of the package). Nonconforming product handling is covered in the "Nonconforming Product Review and Disposition Work Instruction" (Article 37 of the package).

3. Responsibilities

3.1 General Manager (Top Management): Approves new product initiation and design and development resource allocation; adjudicates design solutions involving product positioning, major costs, or market commitments; approves Class I (major) design changes; reviews the achievement rate of design projects and change performance in management reviews.

3.2 Management Representative (System Responsible Person): Confirms that the design process meets ISO 9001 clause requirements; spot-checks the effectiveness and closure of review records; initiates corrective actions for inconsistencies between design records and actual on-site conditions.

3.3 R&D Department (Technical Department): Manages the QR-DR series forms; prepares the design and development task book and phase plans; organizes reviews at each stage; implements verification and issues verification records; compiles validation evidence; accepts change requests and organizes impact analysis; maintains the design output document list and version status.

3.4 Project Leader: Is responsible for the progress, quality, and completeness of records for a single project; convenes reviews, implements opinion closure, and determines whether the phase gate is passed; escalates unresolved opinions in a timely manner.

3.5 Quality Department: Participates in the review of design inputs (regulatory and quality requirements completeness), witnesses or retests verification and validation; confirms that inspection specifications, control plans, and design outputs are consistent; signs off on whether nonconformities in verification/validation have been closed.

3.6 Process/Production Department: Proposes manufacturability, tooling feasibility, and constraints on rhythm and capacity during the design input stage; confirms that process documents, tooling, and work instructions have been updated synchronously during the design output stage; assesses the impact of changes on work-in-progress and in-transit orders.

3.7 Purchasing Department: Evaluates the availability, lead time, and cost impact of new materials and suppliers; confirms the approval status of substitute materials when changes involve material substitution.

3.8 Sales/Marketing Department: Converts customer explicit requirements, implicit needs, and delivery commitments into design input clauses; handles customer communication and written confirmation when changes involve delivered products.

3.9 Service/After-sales: Provides on-site failure and maintainability feedback as a source of design input; participates in the assessment of usage conditions during the validation stage.

4. Form Templates and Filling Instructions

4.0 General Filling Rules (Applicable to all forms in this set):

a) Fill out using blue-black ink or approved electronic forms; electronic forms must have modification tracking and approval permissions, and multiple people sharing one account for signing is prohibited;

b) Correct errors by drawing a single line through the mistake and signing the name and date next to it, keeping the original text legible; do not scribble, cover, or tear pages to re-fill;

c) Slash or fill in "/" for empty fields; do not leave entire fields blank to avoid being questioned about post-filling during audits;

d) Data fields must specify the data source (test number, inspection report number, calculation book number); records that only state conclusions without providing evidence are weak;

e) Time fields should be precise to the day, and to the hour if necessary; signing fields must be signed by the individual, and review and approval must not be completed by the same person.

4.1 Design and Development Task Book (QR-DR-01)

Field List

Example Row

Filling Instructions:

a) The project initiation basis must be verifiable. Writing "customer requirement" without the document number and date makes it impossible to prove the authenticity of the requirement during audits and to clarify responsibilities when requirements change;

b) Function and performance requirements should be numbered item by item (e.g., F-01, P-01). Subsequent design input lists, verification items, and validation items should use the same numbers to form a traceable chain;

c) Phase division should specify "which gate must be passed by which day." Writing only "concept—design—trial production—mass production" without specifying review arrangements typically degrades into no reviews in actual execution;

d) The task book becomes the project baseline upon approval. Any modifications must follow the change process in 4.5, and direct changes to the original document without traceability are not allowed.

4.2 Design and Development Review Record (QR-DR-02)

Field List

Review Elements for Each Stage (excerpt, can be added or deleted based on product type)

a) Concept Stage: Whether the technical approach covers all functional and performance requirements; whether key indicators are achievable; whether cost and schedule are realistic; whether regulatory and certification paths are clear; whether single-source and patent risks are identified;

b) Input Stage: Adequacy, suitability, and consistency of inputs; whether customer and regulatory requirements are fully converted; whether differences from the previous generation or similar products are clearly defined; whether previous project failures are included;

c) Output Stage: Whether the output meets each input requirement; whether tolerances, materials, surface treatments, and heat treatments are clearly defined in drawings; whether key characteristics and special characteristics are marked; whether inspection specifications provide criteria and sampling plans; whether packaging and transportation requirements are specified; whether user training and manual requirements are covered; whether the output is sufficient to guide procurement and production;

d) Process Review (Prototype/Small Batch Stage): Whether issues identified in verification are closed; whether process capability and rhythm meet standards; whether tooling and fixtures meet consistency requirements; whether rework and repair plans are verified;

e) Type Approval Review: Whether all verification and validation items are passed; whether unresolved items are controllable and have deadlines; whether production conditions (suppliers, equipment, personnel, inspection) are in place; whether documents are fully archived.

Example Row

Filling Instructions:

a) The value of review records lies in "opposing opinions being written down." Review records with all opinions marked as "none" will be questioned during audits: whether the design is already perfect or whether the review did not occur;

b) Each opinion must have a responsible person and deadline, assigned on the spot before the meeting ends to avoid "project team following up after the meeting" leading to long-term unresolved opinions;

c) When the conclusion is "conditional pass," the list of unresolved items must be a mandatory input for the next stage review, and the previous review number must be referenced to form a closed loop;

d) Review basis documents must specify the version number. If disputes arise later, it can be confirmed which version of the design the opinion was directed at.

4.3 Design Verification Record (QR-DR-03)

Field List

Example Row

Filling Instructions:

a) Verification must cover all design input items. A common pitfall is "verifying performance but not regulations, packaging, and transportability," leading to issues discovered during validation and increased rework costs;

b) Criteria must be determined before verification. Conducting tests and then retroactively determining "this is also qualified" is a typical scenario for verification failure during audits;

c) Extreme conditions must be verified. Normal operating conditions being qualified does not mean extreme conditions are qualified. High temperature, low temperature, low voltage, overload, misuse, and short power outages should be listed as verification items in the task book stage;

d) Failures cannot be resolved by simply "noting in the remarks." The record should lead to a design change request or additional verification plan, and unresolved items should be checked in the next review.

4.4 Design Validation Report (QR-DR-04)

Field List

Example Row

Filling Instructions:

a) Verification answers "whether it meets the input," while validation answers "whether it meets the expected use." The evidence sources are different: the former relies on tests and calculations, the latter on customer use or equivalent simulation. The same data cannot be used to substitute for both;

b) Validation should be completed before delivery. If it cannot be completed before delivery, the reason must be specified in the record, along with the post-delivery validation plan and responsible department, and corresponding control measures for delivered products;

c) When customers participate in validation, the record must include verifiable traces: sign-in, acceptance forms, email numbers, or stamped returns. Internal meeting minutes labeled "customer confirmation" are difficult to verify during second-party audits;

d) Customer opinions during validation, even if they are suggestions, should be numbered and registered. The project team should determine whether to adopt them and provide reasons to avoid similar opinions in the next project.

4.5 Design Change Request Form (QR-DR-05)

Field List

Impact Analysis Dimensions (fill in "affected/unaffected" and reasons for each dimension)

a) Product performance and safety; b) Regulations and certification (whether re-certification or type testing is triggered); c) Customer requirements and customer approval agreements; d) Drawings and BOM; e) Process routes, tooling and fixtures, and equipment; f) Inspection specifications and control plan; g) Supplier and material availability; h) Work-in-progress, inventory, in-transit, and delivered products; i) Cost and delivery schedule; j) Consistency of records and document versions.

Example Row

Filling Instructions:

a) The change category determines the approval level; all changes cannot be approved by "supervisor's signature." Classification standards are written into the procedure document to avoid repeated debates on "whether this is a major change";

b) Impact analysis is the soul of this form. Documents that only state "agree to change" without item-by-item analysis are typically judged as change control failures during audits;

c) Document updates must be done in groups. Changing only the drawing without updating the inspection specification, or changing only the BOM without notifying the warehouse, can lead to two sets of standards on-site, which is the most common starting point for batch quality incidents;

d) After the change is implemented, verify on-site: whether the new version of the drawing has been issued to the workstation, whether the old version has been recovered and invalidated, whether the warehouse is issuing materials according to the new BOM, and whether inspections are being conducted according to the new criteria. Completing these four steps ensures the change is truly closed;

e) Class III textual changes must not be made casually. Any changes to controlled documents must be recorded with a number, otherwise the version traceability chain is broken.

4.6 Design Output Document List and Distribution Record (QR-DR-06)

Field List

Example Row

Filling Instructions:

a) The number of distributed and recovered copies must match. If 7 copies are distributed and 6 are recovered, specify the destination and handling method of the remaining 1 copy, which is a common point of deduction in "document control";

b) Electronic control must be effective. Drawings in a shared folder that anyone can modify are not considered controlled; there should be version locking, modification tracking, and download records, or at least be converted to a non-editable format and distributed with encryption;

c) The output list should be checked against the input. Confirm that each design input has a corresponding output, which can help identify omissions such as missing packaging and transportation requirements or missing user training materials;

d) Historical versions should not be deleted. Retaining each version facilitates failure traceability and responsibility definition; historical versions should be marked as "invalid" to prevent misuse.

5. Form Flow and Related Documents

5.1 Form Flow Chain: Task Book (QR-DR-01) establishes the baseline → Stage Review Record (QR-DR-02) controls at the gate → Output List and Distribution Record (QR-DR-06) completes controlled transfer → Verification Record (QR-DR-03) proves compliance with input → Validation Report (QR-DR-04) proves satisfaction of use → Change Request Form (QR-DR-05) corrects and closes back to the task book baseline.

5.2 Gate Rules Suggestion: Do not proceed to the next stage if all review items are not closed; do not proceed to validation if all input items are not covered; do not proceed to mass production if validation is not passed; do not declare closure if the change is not completed with document synchronization and on-site verification. These four rules should be written into the procedure document, which is more effective than repeatedly emphasizing "quality importance."

5.3 Related Documents (see "Design and Development Control Procedure," "Change Management Procedure," "Document Control Procedure," "Record Control Procedure," and work instructions for each stage); related records include the 6 forms in this set and their attachments (calculation books, test reports, third-party inspection reports, customer confirmation documents).

6. Usage Instructions

6.1 Adapt to Actual Corporate Conditions

a) Organizational Structure Adaptation: For companies without an independent R&D department, the technical department or process department can take on the responsibilities of preparing QR-DR-01 and organizing QR-DR-02; in small organizations, the approval levels can be merged into "preparation—review—approval" three levels, but the designer cannot be the approver;

b) Product Type Adaptation: Hardware products retain fields for drawings, BOM, prototype verification, and type testing; customized software replaces "drawing version" with "requirement specification and version number," and "prototype verification" with "unit test/integration test/user acceptance test" records; engineering services replace verification with "scheme review and simulation exercises," and validation with "customer evaluation after use";

c) Project Scale Adaptation: For single-piece small batches or non-standard customization projects, the task book and review record can be combined into a single "design and review form," but the three elements of functional and performance item numbers, verification correspondence, and change impact analysis must not be reduced; for large-scale or platform projects, add phase plan tables and configuration management lists;

d) Retention Principle: Forms can be simplified, but elements cannot. Remove duplicate and inapplicable fields, but retain the "input—output—verification—validation—change" number correspondence.

6.2 Audit Focus Points

1. Whether there is evidence of design planning, and whether the phase division, review points, and responsible persons match actual execution;

2. Whether design inputs have sources for customer and regulatory requirements, and whether they are fully converted with review records;

3. Whether verification items cover all input items, and whether there are cases of "verifying performance but missing regulations and packaging and transportation";

4. Whether criteria are determined before verification, and whether data is reproducible (complete test conditions, equipment, and sample numbers);

5. Whether verification and validation are separated, and whether validation has verifiable traces of customer participation;

6. Whether review opinions have responsible persons, deadlines, and closure evidence, and whether unresolved items from the previous review are re-verified in the next review;

7. Whether design changes have classification, impact analysis, graded approval, and implementation verification, and whether they cover assessments of delivered products;

8. Whether drawings, BOM, inspection specifications, process documents, and control plans are updated synchronously after changes, and whether only one valid version is used on-site;

9. Whether the number of design output lists and distribution/recovery records match, and whether electronic control is truly effective;

10. Whether records are filled out properly: no pencils, no corrections, no entire fields left blank, signatures completed by the individual, and retention periods consistent with the record list.

6.3 Common Errors

1. Drawings without Records: All design is complete, but only the final drawings are available, with planning, input, and review fields all blank, making Clause 8.3 only verbally applicable;

2. Formalistic Review Records: A form with "review opinions: none" but signed by a dozen participants, directly contradicting subsequent exposed design defects;

3. Mixed Verification and Validation: Using a single customer on-site test report as both verification and validation, unable to answer "which data corresponds to each design input item";

4. Post-facto Criteria Setting: Data is produced first, then "qualified" is written, or criteria are stated as "meets requirements" without quantifiable metrics;

5. Missing Sample Numbers: Prototype and trial batch numbers in verification records cannot be matched with physical items, breaking the traceability chain at the first step;

6. Oral Changes Only: Multiple handwritten versions of a drawing appear, and the workshop produces according to different versions, making it impossible to determine from which batch the deviation started;

7. Missing Impact Analysis: Only evaluating "performance unaffected" without considering work-in-progress, inventory, tooling, inspection specifications, and customer agreements, leading to the warehouse still issuing materials according to the old BOM a week after the change;

8. Asynchronous Document Updates: Drawings are upgraded but inspection specifications remain old, leading to inspectors judging according to old criteria while customers judge according to new requirements, resulting in conflicting opinions;

9. Old Versions Not Recovered: More copies are distributed than recovered, leaving old drawings on workstations as a potential source of misuse;

10. Undefined Record Retention Period: Design records are scattered on individual engineer computers and in others' emails, leading to evidence loss when personnel leave and inability to provide evidence during second-party audits.

By linking the six forms in the order of "baseline—gate—verification—validation—change—control," design and development is no longer a product of individual engineer experience but a verifiable process that anyone can review: the task book answers "what to do and to what extent," the review record answers "who approved each stage," the verification record answers "whether data supports the conclusion," the validation report answers "whether the user can accept it," the change request form answers "the legal basis for changes and whether all impacts are handled," and the output list answers "whether the on-site version is the only valid one." During audits, randomly selecting a project and tracing each decision from initiation to mass production by number and date can make the design and development clause virtually unassailable.

Six forms link the traceability chain for design and changes

Knowledge code: 2.3.1

Version: v20260809

Author: QTank QTank is dedicated to providing systematic knowledge, methodologies, and practical tools for quality management professionals to help enterprises continuously improve their quality capabilities.