如何编写工程需求文档

工程需求文档 (ERD) 是描述新组件的目标和用途的声明。与产品需求文档 (PRD) 不同，产品需求文档 (PRD) 告诉工程师他们需要构建什么，ERD 指定了构建零件的原因以及其设计如何为其目的提供动力。通过遵循 ERD 中概述的工程要求，工程师可以确保他们制造的零件能够满足客户的需求。使用 ERD 还有助于以各种方式简化生产：

• ERD 使用明确且一致的沟通来促进协作、减少沟通不畅并让每个人都保持一致。
• ERD 有助于将大型项目分解为更小的任务，从而更容易委派或外包。
• 可以对照 PRD 检查 ERD，以确保正确实施所有设计意图并实现所有产品目标。

编写良好的 ERD 允许工程师和制造商回答有关零件设计和用途的关键问题，而无需来回走动。这会带来更快、更高效的构建过程，从而节省您的时间和金钱。以下是编写清晰有效的工程需求文档所需了解的一切。

工程需求文档的标准标准

首先，所有有效的工程需求文档都具有以下六个共同点：

清晰度

所有工程要求都应该清晰、简短、明确，以避免混淆。少即是多——通常，一句话描述就足够了。

必要性

为避免混淆或矛盾，请仅在您的 ERD 中提出绝对必要的要求。确定每个需求的最坏情况，如果没有任何后果，则无需将其包含在您的 ERD 中。

协调

在整个产品设计过程中，工程要求应该是正确的。 ERD 应该描述所有的产品需求、目标、条件和能力。尽可能以最精确的数字方式解释产品的作用。

可测试性

每当您编写新的工程需求时，您必须能够验证成功的实施。有许多不同类型的测试方法来确保可验证性，包括检查、用户测试、软件测试和系统集成测试。选择对您的项目最有意义的测试方法。

可行性

保持在技术上可以实现的范围内，以及法律上、组织上和财务上可能实现的范围内。保持理性和诚实，因为创建不可行的要求会导致并发症。如果无法达到可行性，您可以将设计细节声明为目标而不是要求。

可追溯性

任何查看您的 ERD 的工程师都应该能够将每个需求追溯到原始产品的用途。将实现与产品目标联系起来有助于解释为什么一个元素很重要、它的来源以及它对整体部件设计的意义。

编写良好的工程需求文档的技巧

一旦您确定已考虑到标准标准，您就可以实施最佳实践，将您的工程需求文档提升到一个新的水平。以下是编写一流工程需求文档的五个技巧。

使用工程需求模板

通过使用工程需求文档模板，您可以在新项目开始时节省时间和精力。 ERD 模板可确保您的 ERD 始终具有正确的结构。工程需求文档模板至少应该有封面、章节标题和其他称为“样板”的标准化章节。使用样板来涵盖 ERD 主题，例如动词使用、缩写、关键字、格式标准和其他理解 ERD 所需的指南。

避免编写操作和实现

您的工程要求应说明目标，而不是如何实现目标。如果您解释完成目标的步骤而不是目标本身，那么您实际上并不是在编写 ERD，而是在编写操作和实施指南。如果您错误地编写了操作和实施指南，制造商可能会误解您的意图，您的项目目标可能无法实现。

为了确保您的需求确实是需求，问问自己为什么这个需求是您的工程需求文档的必要部分。相信系统设计人员和制造商将决定如何实现目标，并且他们会以最有效的方式实现。

评估您的 ERD

这将有助于验证所有工程要求是否符合您的既定目标和公司愿望。为了进行全面的评估，最好组建一个多元化的团队。这包括将所有种族、民族和性别的人聚集在一起以评估您的工程需求文档，还包括将各种角色带到评估中。包括尽可能多的角色 - 设计师、开发人员、测试人员、最终用户代表、负责维护和管理的人员，当然还有客户团队 - 为您的 ERD 评估带来大量有价值的见解。

使用正确的语言

在编写工程需求文档时，您应该始终遵循一些语言规则。三大 ERD 特定术语是应该、将和应该。 “Shall”代表要求，“will”代表事实，“should”代表目标。

一个经常被误用的特定 ERD 术语是支持。在 ERD 术语中，“支撑”是指结构保持或承受重量的能力，而不是它会支撑或完成某些能力。

一般来说，在工程需求本身中远离诸如 are、is 和 was 之类的术语。您可以在描述性部分或引入需求中使用它们，但在您的需求本身中避免使用它们以提高特异性。您还应该避免使用模糊的术语，例如：

• 但不限于或等 — 这些术语涵盖了未知数，您的 ERD 不应有任何未知或不可预测的情况。
• 和/或 — 这为解释和错误留下了太多选择，因为承包商在两种不同的情况下都是正确的（如果他们选择 AND 或如果他们选择 OR）。
• 弱词 没有数量意义的。这包括“强大”和“高效”等形容词以及“增强”或“加强”等动词。此外，请尽量避免比较（例如，快或慢、大多数或少数）和其他非量化语言。

在编写 ERD 时，您还应该避免负面陈述，并关注需求元素或能力的存在。唯一可以接受使用负面规格的情况是在强调潜在的危险情况时。即使在这些情况下，也要确保说明安全案例。

不要过于具体

尽管在编写工程需求文档时要遵循许多语言规则，但请保持简单。清晰是 ERD 的关键，因此只关注您需求的必要目标、目的和约束。提出要求总是有理由的——太多的要求会混淆你的 ERD 并使读者感到困惑。如果您觉得您的需求变得太长和太复杂，请使用项目符号来拆分其元素。
拥有精心编写的工程需求文档 (ERD) 将帮助工程师、产品团队和其他合作者更好地了解您的设计意图。通过清楚地将组件的设计与其特定目标和整体零件用途联系起来，ERD 可确保以满足客户需求的方式构建产品。

最重要的是，优秀的 ERD 可以促进整个设计和制造过程中的协作、沟通和清晰。这将确保每个部分功能齐全，并完成其预期目标。除了确保零件之间的一致性外，ERD 还可以促进更快的生产运行和更低的成本。

无论您是在编写第一个工程需求文档还是经过良好实践，Fast Radius 都可以在开发和生产过程的每个阶段提供帮助。我们的专家设计师、工程师和制造商团队在这里确保您的零件实现其所有目标。立即联系我们。

有关产品开发的更多资源，请访问 Fast Radius 学习中心。

准备好使用 Fast Radius 制作零件了吗？