其他工具和信息资源

可以帮助小组理解和确定设计要求的其他工具和资源可包括：

● 图表，图纸等

● 材料清单（BOM）

● 内部关系矩阵图

● 界面矩阵图；

● 质量功能展开（QFD）

● 质量和可靠性历史

这些工具的使用，以及工程师经验和历史信息的支持，可以帮助确定一套综合的要求和功能。

在考虑这些要求以后，开始填写表格（以下表Ⅲ.1）。

FMEA 编号（A）

输入数字列以便识别FMEA 文件。这用于文件控制。

系统、子系统或零部件名称及编号（B）

输入需要分析的系统、子系统或零部件的名称及编号。（见确定范围部分）

设计责任（C）

填入负有设计责任的OEM、组织和部门或小组。适当时，也输入供方名称。

车型年度/项目（D）

填入将使用和/或受所分析设计影响的预期车型年度/项目（如果知道的话）。

关键日期（E）

填入FMEA 初次预定完成日期，该日期不应超过计划的量产设计发布的日期。

FMEA 日期（F）

填入FMEA 原始稿完成日期，和最新的修改日期。

核心小组（G）

填入负责开发DFMEA 小组成员。联系信息（如：名字、组织、电话号码和email）可附在补充文件中。

编制者（H）

填入负责编制DFMEA 工作的工程师姓名、电话和所在公司的名称。

DFMEA 表的具体内容（a-n 栏）

FMEA 的具体内容包括对潜在失效相关的风险分析和所采取的改进措施。3

项目/功能/要求（a）

项目/功能可以分成2 栏（或更多）或合并成一栏来表述，桥梁栏将包含这些要素。界面（作为分析的“项目”）可以合并或独立。零部件可以在项目/功能栏列出来，也可以附加一栏来描述项目的功能或要求。对“项目”、“功能”和“要求”的描述如下：

项目（a1）输入通过方块图、P 图，图表和其他图纸以及由小组进行的其他分析所识别的项目、界面或零件。

所使用的术语应该与顾客要求、使用在其他设计开发文件和分析中的一致，以确保可追溯性。

功能（a1）填入根据顾客要求和小组讨论必须符合设计目的的那些需要进行分析的项目的功能或界面。如果项目或界面在不同的潜在失效模式下的功能超过一个以上，高度建议单独列出每一个功能和相关的失效模式。

如果项目和功能分开的话，则功能变为 a2.

要求(a2)在附加栏中，“要求”的增加可以使失效模式的分析更加精练。填入需要分析的每一个功能的要求（基于顾客的要求和小组的讨论：见第二章,章节：必要条件）.如果在不同的失效模式下，功能有一个以上的要求，高度建议单独列出每一项要求和功能。如果项目和功能分开成单独的栏的话，要求变成 a3，如a1 和a2.

潜在失效模式 （b）

潜在失效模式按照零部件、子系统或系统潜在不能符合或不能交付项目栏中描述的预期功能的方式来定义。

识别与功能/要求相关的潜在失效模式。潜在失效模式应用专业性的术语来描述，而不同于顾客所见的现象。

每一种功能可能有多种失效模式。单一的一种功能被识别出大量的失效模式可能表示要求没有得到很好的定义。

假设要发生的失效模式，但不一定会发生，因此使用措辞“潜在”。

潜在失效模式仅仅在与确定的操作条件（如 热、冷、干、干燥、灰尘等）和使用条件（如超过平均里程、不平的路段、仅在城市行驶等）一致的情况下发生。

在确定所有的失效模式后，可通过对以往运行不良的研究、关注点、问题报告以及小组的“头脑风暴”的来对分析的完整性进行确认。

失效模式也可以是更该一级子系统或系统的要因，或低一级零部件的后果。

失效模式例子，与相关的不同的要求一样,，如表Ⅲ.3 所示。

潜在失效后果（C）

失效的潜在后果应按顾客所察觉的功能的失效模式的后果进行规定。

要根据顾客可能发现或经历的情况来描述失效的后果，要记住顾客可能是内部顾客，也可能是外部的最终顾客。应清晰阐述失效模式是否影响安全或法律法规不符。后果应根据指定的所分析的系统、子系统或部件来阐述。要记住部件、子系统和系统级别之间存在的等级关系4。例如：一个领件的破裂，可能使装配震动，导致间隙性系统运作。间隙性运作会导致性能的降级和最终导致顾客不满意。目的是以小组的知识水准预防潜在失效后果。

定性的失效后果应根据产品或系统性能来阐述。表