硬件开发中的需求工程

说实话：很少有人会对需求感到兴奋。然而，每个硬件团队都曾切身体会过需求不清带来的代价：要么是在后期才暴露出的返工，要么是最终做出来的产品并不符合利益相关方真正提出的要求。 

需求工程（RE）是一门通过结构化流程来定义、记录和管理需求的学科，其目标是确保最终产品解决的是正确的问题。若运用得当，它能够尽早发现错误、让团队保持一致，并让所有人都对最终交付的内容确实是大家已达成一致要构建的东西充满信心。

不过，这个术语常常让人感到混淆，因为它同时源自软件工程和硬件产品的系统工程。 

在本文中，你将获得对需求工程的清晰定义，以及它在硬件产品开发中的作用。我们既会介绍理论层面的概览，也会说明它在硬件项目中如何落地应用的实践框架，并结合真实世界示例、最常见的陷阱以及避免这些陷阱的方法。

关键要点

• 需求工程帮助硬件团队将设计意图转化为清晰的需求，并让团队中的每个人保持一致。
• 需求贯穿项目始终，从早期规划和设计一直延伸到测试、变更和最终文档。
• 良好的需求流程能够帮助开发团队尽早发现问题，避免代价高昂的重新设计，并确保最终产品符合事先约定的内容。

什么是需求工程？

需求工程是一种在硬件产品开发过程中用于定义、记录和管理需求的系统化、规范化方法。

它帮助团队理解需要解决的问题，澄清并分析利益相关方的需求，解决冲突与权衡，记录产品必须实现的目标，并在产品演进过程中持续更新这些理解。

在实践中，需求会在利益相关方与工程团队之间建立一种共同理解：要构建什么、为什么要构建，以及团队将如何判断最终产品是否符合设计意图。

需求工程的益处

当 RE 执行得当时，它有助于防止误解和代价高昂的错误，让团队保持一致，并帮助确保最终产品满足其需求。

RE 的主要益处包括：

• 共同愿景： 让利益相关方、管理者和工程团队围绕“正在构建什么”形成一致理解。
• 清晰的范围： 明确哪些内容属于项目范围，哪些不属于，从而帮助防止被称为“范围蔓延”的失控新增需求。
• 减少代价高昂的错误：帮助尽早发现需求中的问题，避免它们演变成昂贵的设计返工、新的原型制作或重复测试。
• 改进规划与排期： 让团队更清楚需要构建什么，从而更容易估算工作量并制定现实可行的时间表。
• 提升产品质量： 帮助确保最终产品实现约定的功能，并满足所要求的质量标准。

需求工程学科的演进

需求工程同时扎根于系统工程和软件工程。这两条发展脉络形成于不同的工程背景中，因此根据来源不同，这个术语的涵盖范围至今仍可能略有差异。

在软件工程语境中，重点主要放在软件开发需求上：软件应完成什么功能、应如何表现，以及应满足哪些质量属性。软件工程师通常会把功能性需求和非功能性需求记录为用户故事、用例和验收标准。而在系统工程语境中，范围则更广。需求指的是整个系统，包括硬件、软件、人员、流程、接口、运行条件以及其他系统特性。系统工程师讨论的是系统级需求如何向下分配到硬件、机械、电气、固件和安全因素中，并将其记录为正式的需求陈述和需求可追溯性矩阵。

在硬件开发中，RE 将这两种视角结合在一起。它一方面融合了系统工程的严谨性和跨学科范围，以应对物料清单（BOM）成本、热约束和制造限制；另一方面也结合了软件工程中的生命周期可追溯性，使需求在整个开发过程中保持可测试并彼此关联。

与需求工程相关的学科

需求工程与其他产品开发学科密切相关，尤其是系统工程和产品管理。

系统工程

系统工程将产品视为一个完整系统。系统工程师会确保硬件、软件、机械部件和测试等不同部分能够正确协同工作，且彼此之间不会发生冲突。

这与 RE 密切相关，因为需求为所有这些团队提供了一个共同参考，用来明确产品需要实现什么。

如果你喜欢类比，可以把它想象成建造一栋房子。不同的专业人员分别负责地基、电力、给排水和供暖，但仍然需要有人确保所有这些部分最终能够真正组合成一个完整结构。系统工程在产品开发中扮演的正是这个角色。

产品管理

产品管理帮助决定要做什么，以及为什么要做。产品经理会与客户沟通、研究市场、分析竞争对手，并与业务部门合作，以决定哪些问题值得解决、哪些功能最为重要。

这同样与 RE 有关，因为这些高层级的客户需求和业务目标会成为定义产品需求的起点。

需求工程流程的阶段

RE 流程可以根据应用领域、参与人员和组织方式的不同而采用不同形式。在某些项目中，各项活动大多按先后顺序进行；而在另一些项目中，随着团队获得更多认知，这些活动会被反复执行和重新审视。

正如发表于 Requirements Engineering 期刊的一篇文章所述，一种常见的教材式方法将 RE 流程划分为四项核心活动（阶段）：

• 需求获取： 从利益相关方及其他来源收集需求，以理解系统必须完成什么，以及它必须在什么条件下运行。
• 需求分析与规格说明：审查所收集的内容，解决不明确或相互冲突的信息，并将其转化为工程团队可使用的清晰需求。
• 需求验证：检查需求是否正确、完整，并且是否准确描述了系统预期要实现的目标。
• 需求管理： 随时间跟踪需求及其变更，包括为什么发生变更，以及哪些其他需求、设计工作或测试可能受到影响。

流程中涉及哪些角色

RE 框架中涉及若干关键角色，他们共同协作来定义产品应具备的功能：

• 需求负责人： 负责将模糊的利益相关方需求转化为工程团队可实际用于产品开发的一组需求的工程师。他们会提出正确的问题，并进行必要的澄清。这个角色通常由系统工程师、首席工程师或具有类似职责的人担任。
• 技术产品领导： 负责与利益相关方/业务侧沟通、理解其需求，并将这些请求转化为明确产品目标的人。这可能包括产品经理、项目经理或类似角色。
• 实施工程师： 使用已定义需求来设计和构建产品的工程师。这可能包括电子工程师、机械工程师、软件工程师或固件工程师。
• 验证负责人：负责决定如何测试需求，并确保必要的评审与测试得到完成的人。这可能包括验证工程师、测试工程师或 QA 工程师。

面向硬件开发的实用需求工程框架

虽然上述四项活动定义了 RE 流程的核心，但硬件团队还需要一种实用的方法，以便在整个项目中落实这些活动。

下面将从实践角度介绍适用于硬件开发的需求工程框架，说明需求如何融入各个阶段。

项目启动：捕获意图

在项目开始时，技术负责人通常会收到一些模糊输入，例如客户请求、招标书（RFP）、业务目标，或关于成本、尺寸、进度的约束。例如，客户可能会要求一个更小的设备，并支持某个特定用例。

技术负责人会与需求负责人一起澄清实际需要的内容，并将这些输入转化为描述产品应实现什么的高层级需求。

需求工程：定义需求

来自项目启动阶段的高层级需求对于详细设计来说仍然过于宽泛。在这一阶段，需求负责人会定义整个系统，将其拆分为不同部分和子系统，并把这些高层级需求转化为各部分更具体的需求。

他们还会检查需求之间是否存在冲突、是否遗漏了重要内容，以及每项需求是否清晰且可测试。最终结果是一组达成一致的需求，工程团队可以将其作为产品设计的起点。

实施：开发设计

实施工程师使用已达成一致的需求来设计和构建自己负责的产品部分，无论这意味着创建原理图、建立 3D 零件模型，还是编写软件或固件。随着设计推进，他们会将每项需求与满足该需求的设计特性关联起来。这些关联构成了项目的可追溯性，也帮助需求负责人了解各项需求是如何被实现的。

验证与确认：测试与核验

需求还定义了在评审和测试中需要检查什么。验证工程师会定义如何检查每项需求，并与实施工程师合作执行必要的评审、测量或测试，并记录结果。这将产品“被要求实现什么”与“它是否真正实现了这些要求”的证据连接起来。

变更管理：修订与迭代

在开发过程中，需求和产品设计经常会发生变化。某项需求可能被证明无法满足，某个元器件可能在市场上无法再获得，或者出现了新的约束条件。发生这种情况时，需求负责人会跟踪发生了什么变化、为什么变化，以及哪些需求、设计部分或测试会受到影响。

文档与交接：交付项目

在项目结束时，需求负责人会与验证工程师及团队其他成员合作，完成需求、设计评审和验证活动的收尾工作。最终文档应提供一份可追溯记录，说明需要实现什么、实际构建了什么，以及如何对其进行了验证。客户、制造商、审计人员，或后续继续推进该产品的团队，日后都会需要这些信息。

需求工程示例

医疗器械中的需求工程

需求工程广泛应用于医疗和护理技术产品。需求会伴随产品整个开发周期。团队会将利益相关方的需求转化为结构化的系统需求，在规范发生变化时保持这些需求之间的关联，并利用它们规划验证工作和记录测试结果。

医疗器械还增加了监管合规这一层要求。团队需要在可追溯性、验证，以及文档和纸面记录方面投入更多精力。这有助于满足美国 FDA 21 CFR Part 820以及欧盟和其他市场 ISO 13485:2016等法规框架下的监管审批要求。

HitIQ 护齿器是医疗可穿戴设备的一个例子，其中安全需求决定了每一项技术规格。了解其实现方式，请参阅完整的客户成功案例。

消费电子与工业电子中的需求工程

消费电子和工业电子中的核心需求工程流程是相似的，但产品构建所处的条件不同。智能家居设备或可穿戴设备等消费类产品通常面向大批量销售，并且上市节奏快。可编程逻辑控制器（PLC）或电机驱动器等工业产品，则必须在严苛环境下稳定运行多年。

无论哪种情况，团队都会明确写下产品必须实现的功能，将每项需求与设计关联起来，在发生变化时更新需求，并依据这些需求进行测试。

不同之处在于团队将额外精力投入到哪里。在消费电子中，重点在于跟上快速变化，因为一个被误解的需求就可能导致电路板重新设计。在工业电子中，重点在于验证，因为产品在出货前必须经过长期寿命和严苛环境测试。

要构建符合安全法规的可靠硬件，关键在于保持需求与设计变更之间的关联。了解 MakeSafe Tools 如何做到这一点，请阅读完整成功案例。

如何避免常见的需求工程陷阱

需求工程会伴随一些常见挑战。了解哪些环节可能出错，有助于在早期发现问题，并在硬件产品开发过程中加以避免。

以下是一些最常见的陷阱以及避免方法：

需求工程的软件工具

管理少量需求相对简单。随着项目规模扩大，要让所有内容保持有序并及时更新，就需要投入更多精力。到了这个阶段，采用何种方式管理需求就变得更加重要。

在实践中，团队通常会采用以下几种方式之一：

• 电子表格和文档： 大家都熟悉，且易于上手，因此适合较小型项目。然而，随着项目增长，维护它们会需要更多手动工作。
• 专用需求管理（RM）工具： 随着项目变得更复杂，这类工具能提供更多结构化管理和控制。其权衡在于，有些工具也会引入超出小型团队实际需要的流程。

目标是在满足项目需要的前提下，采用足够的结构化管理，而不是让需求管理变得比实际需要更复杂。

对于已经超出电子表格管理能力、但又不需要大型企业级 RM 工作流的小型硬件团队来说， Requirements Portal是一个值得考虑的实用选项。它旨在为小型团队提供一种更结构化的需求管理方式，同时避免传统企业系统带来的额外负担。

结论与后续步骤

到这里，你应该已经清楚理解了需求工程的主要概念，以及它们在实践中的应用方式。

如果你想继续学习需求工程，以下资源是很好的起点：

• ISO/IEC/IEEE 29148:2018提供了需求工程流程与实践的国际标准。它会进一步指导你如何编写、组织、记录和管理需求。
• NASA Systems Engineering Handbook提供了关于在系统开发过程中如何创建、编写、检查和使用需求的实用指导。
• Guide to the Systems Engineering Body of Knowledge (SEBoK)解释了需求如何融入更大的系统工程流程，以及系统的不同部分如何协同开发。
• Requirements Engineering journal发表更深入的研究、行业案例以及需求工程的不同方法。

如果你已经准备好从理论走向实践，不妨试用 Requirements Portal，立即在真实硬件项目中开始使用结构化需求，免费且无需任何设置。

常见问题

为什么需求工程很重要？

需求工程之所以重要，是因为它帮助团队在设计和开发推进过深之前，先清晰理解利益相关方的需求，从而构建出正确的产品。

需求工程师的角色是什么？

需求工程师会将利益相关方的需求转化为工程团队可用的清晰需求，并在项目变化过程中持续有序地管理这些需求。他们充当客户与开发团队之间的桥梁。 

需求工程与需求管理有什么区别？

需求工程是一个完整过程，涵盖了最初识别、理解并写明系统需要做什么的全部工作。需求管理则是其中更具体的一部分，负责在需求写出后对其进行组织管理，并跟踪后续任何变化。