对于快速发展的医疗设备行业的管理者，开发人员，质量保证人员和其他人来说，设备技术的复杂性似乎几乎呈指数级增长。今天，医疗器械可以利用专业分析仪来评估化学试剂，生物试剂或两者的作用;它们可能包含复杂的机电和机器人装置;或者它们可能包括与任何现代计算机一样复杂的电子子系统。运行这样的系统需要数千行软件如此复杂，以至于它们在五年前就不可想象了。

然而，这种复杂性的核心是一个基本问题：这种系统的真正要求是什么？毕竟，如果系统的预期行为未被完全理解，那么它的标签声称如何确保其有效性和安全性呢？如何设计系统？如何确定系统的目的或测量其质量？公司如何预测开发和生产系统需要多大的努力？

部件管理过程和部件工程学科，需求管理是一种可以有效地用于管理这种日益增加的复杂性的技术。

需求管理

设计和开发是一项艰巨的任务。机械公差规定在几千分之一英寸之内，电气时间以纳秒为单位，软件特定于包含数千行代码的应用中的每个位。尽管存在这种精确性，但很多项目都存在着不确定性：这件事到底应该做些什么？

需求管理被定义为一种系统方法，用于引出，组织，记录和管理系统的初始需求和不断变化的需求。这项工作的主要成果是开发了一个或多个需求规范，这些规范定义并记录了要构建的系统的完整外部行为。

一个良好实施的需求管理程序创建了一个中央信息库，其中包括需求，需求属性，需求相关状态信息以及与公司环境相关的其他管理信息。该存储库不仅是项目成功的关键环节，也是宝贵的企业资产。需求及其相关属性可以发展，调整，并可以重用于后续开发项目，从而降低成本。该存储库不仅定义了系统将执行的操作的细节，还帮助管理层确定系统开发活动的相对优先级并评估程序的状态。

一些项目工程师认为需求管理是一项不必要的练习。他们更愿意直接进行实施。但是，我们的经验表明，有效的需求管理可以提供产品开发过程中可能缺少的各种好处。其中包括：

*更好地定义和管理标签声明。对需求管理的前期投资可以为制造商最终为设备做出的功效和安全性声明提供更强有力的基础。

*更好地控制开发项目。在失控项目中，需求蔓延和对系统预期行为的充分了解是常见的。需求管理可以使开发团队更清楚地了解要交付的内容，以及何时以及为何。

*提高质量和最终用户满意度。质量的基本衡量标准是，设备是否按预期执行？只有当最终用户，开发人员和测试人员对必须构建和测试的内容有共同的理解时，才能获得更高的质量。

*降低项目成本和延迟。研究表明，需求错误是最普遍且最昂贵的错误。在开发周期的早期减少这些错误的数量可以减少错误总数并降低项目成本和上市时间。

*改善团队沟通。需求管理鼓励客户参与，以便设备满足他们的需求。中央存储库为用户社区，管理，分析人员，开发人员和测试人员提供项目需求和承诺的通用知识库。

*更容易遵守法规。 FDA对需求管理问题有着敏锐的理解。最新修订的良好生产规范（GMP）规则，其建议纳入设计控制，为该机构提供了审核需求管理流程的坚实基础。

需求错误导致的高成本

有力的证据表明，有效的需求管理可以节省整体项目成本。例如，在测试或部署之前仍未检测到的需求错误通常比其他错误的修复成本高出10倍以上。需求错误通常也占软件项目总错误的40％以上。通过避免返工和调度延迟，这种错误数量的少量减少可以节省资金。

很少公布的数据可以量化医疗设备中的需求错误成本，但软件行业已经积累了一段时间内这种成本的证据。这些数据应直接适用于医疗设备软件开发，这是设备开发中最耗费人力的部分之一。

在GTE，TRW和IBM进行的研究测量了在项目生命周期的各个阶段发生的错误的成本.尽管这些研究是相互独立进行的，但它们都得出了大致相同的结论：检测并修复错误。需求阶段的成本比编码阶段的成本低5到10倍，比维护阶段的成本低20倍。在生命周期的后期发现错误，修复费用更有可能包括纠正违规错误的成本和纠正产品开发后期错误中所产生的额外投资的成本。典型的投资包括重新设计和更换代码，重写文档以及在现场返工或更换软件的成本。

在Raytheon进行的一项研究中，据报道，平均而言，大约40％的项目预算用于返工其他研究证实，对于大多数公司而言，返工相当于项目总成本的3040％。由于需求误差的频率和乘数效应，找到并修复它们会占平均项目总返工成本的7085％。像Raytheon这样的组织已经证明，改进他们的开发流程可以将他们的返工成本降低多达60％。虽然并非所有公司都会经历如此显着的改进，但即使是少量减少需求错误也可以节省大量成本。

但是，尽管它们很高，但这些对需求错误的硬成本的估计只能说明故事的一部分。无形成本包括如果项目资源未用于返工，可能已经交付的功能，不利事件的可能性增加，市场份额损失，以及相关的收入和利润损失。这些成本的总和表明公司不能忽视改进的需求管理的好处。

FDA的观点

根据现行法规，FDA的预生产质量保证指南对其对需求管理的看法提供了最清晰的见解.该文件指出，“在设计活动之前，设计概念应根据其特点明确表达......一旦商定了这些特征......它们应该被翻译成书面设计规范。“根据这些指导原则，检查员和审查员今天不仅要求需求文件存在，而且要求准确，完整和明确。当它在今年晚些时候发布时，FDA修订的GMP法规将对医疗设备制造商产生重大影响，因为它将把与设计相关的活动纳入监管范围。这些活动统称为设计控制，是用于记录用于实现设备标签声明的设计活动的过程和程序。一旦修订后的法规到位，FDA似乎将在审查和评估公司的需求管理活动方面发挥非常积极的作用。

刺激需求

收集和引出新设备，系统或应用程序的需求的过程是设备开发中最激动人心和最重要的阶段之一。此阶段的目标是收集设备的所有要求。要取得成功，这些要求不仅应反映公司内部的共识，还应反映潜在客户和用户的共识。

在此过程中有许多可以有效使用的潜在来源，包括公司现有的类似或先前设备的文档，510（k）来自其他公司或竞争对手营销类似设备的提交，来自公司内部或外部的专家了解应用领域，公司的营销和销售部门以及潜在用户。一旦确定了这些来源，目标就是建立一个系统的过程，从中收集数据，合成和整理数据，然后合理化和减少数据。需要最后一步来消除冲突或冗余的需求，并根据当前技术，成本限制或市场因素消除或注释那些不切实际的需求。

为了引出要求，设备制造商可以单独或组合使用多种技术：

*结构良好的访谈可以非常有效地收集专家，销售和营销部门以及潜在用户的要求。

*头脑风暴是一种结构化但富有创意的技术，用于引出想法，捕捉想法，然后使其符合客观的评估标准。

*将使用设备的域可以是丰富的系统要求来源。将工程师和设计师置于这种环境中即使是一天也是一种快速的方式来教育他们潜在的问题和问题。

*由训练有素的协调人管理的结构化研讨会也是获取意见的有效方式。

定义要求

通常情况下，要求从一个抽象开始，就像“我们觉得患者需要低成本的动态输液泵”。随着过程的继续，需求变得更加具体，分散，以新的方式重新组合，并最终成为一套详细的要求，例如“泵重量不到12盎司”或“泵将能够使用一节9 V电池可以运行长达24小时。“随着它们变得更加详细，要求也变得不那么模糊。

当达到最终要求时，包含它们的文档称为需求规范。该规范是设计的基础，向设计人员和测试人员解释系统应该做什么。它还必须与所有相关方沟通并达成一致。

良好的要求规范具有以下共同属性：

*清晰。如果需求有多种解释，则生成的产品可能无法满足用户的需求。

*完整性。可能无法了解系统的所有未来要求，但应指定所有已知要求。

*一致性。如果两个要求发生冲突，则无法构建满足所有要求的系统。

*可追溯性。应确定每项要求的来源。该要求可以表示对另一个更抽象的要求的改进，或者它可以来自与目标用户的会议的输入。

只要需求解决外部行为 - 如用户或其他接口系统所看到的那样 - 那么它们仍然是需求，无论其详细程度如何。然而，一旦它试图指定特定子组件或其算法的存在，则需求变为设计信息。

大多数需求规范包括辅助信息，根据定义，辅助信息不是必需的。此类信息可能包括介绍性文本，摘要声明，表格和术语表。因此，应通过唯一字体或其他标识符突出显示实际要求。

危害分析的作用

危害分析在确保医疗器械的安全性和有效性方面发挥着独特的作用。作为一种技术，它考虑了可以减轻或消除对患者的危害的设计相关元素，以及产生必须在其他地方减轻的危害的设计元素。当简化为产品文档时，危害分析所传达的理解与纯粹的需求文档在质量上有所不同。由于需求文档侧重于产品应该做什么，而不是应该如何完成，因此它们不应包含与设计相关的信息。另一方面，危害分析旨在将良好设计实践的知识应用于减轻潜在危害。在这样做时，它必然会创建新的系统需求，因此应该将包含这些需求的文档视为文档层次结构的最高级别（参见图1）。通过这种方式，通过危害分析开发的新要求可以追溯到实施和测试，其方式与其他产品要求相同。

组织文件

在引出对需求的反馈之后，下一步是将需求组织到文档层次结构中，这将支持后续的开发和维护阶段。没有严格的规则来定义管理产品发展所必需的文档的数量和类型;它将部分取决于项目团队的复杂程度，子系统的数量，设备的重要程度，要求的总数以及其他因素.

在许多情况下，不超过三个级别的文档层次结构就足够了。在图1所示的层次结构中，根据产品的体系结构分解，文档树被划分为三个主要分支：软件，硬件，试剂和消耗品。这个三方部门为每个领域的工作组提供了具体的需求文件，他们可以围绕这些文件集中他们的开发工作。在此层次结构中，三个分支源自产品需求文档，该文档是所有系统需求的来源。这通常是定义设备声明的最高级别文档，以及510（k）或上市前批准所依据的文档。在层次结构的最低级别，文档被进一步划分为实现文档，以及要在子系统级别应用的单个测试文档和特定测试协议。

软件要求规范

其中一个更重要的需求文档是软件需求规范，这是软件开发人员主要关心的问题。该文档不仅定义了要构建的软件系统的完整外部行为，还定义了其非行为要求。许多标准和指南可用于帮助制造商创建需求规范.标准绝不是万灵药，但它们确实提供了要解决的事项清单，可以帮助缩短新需求编写者和其他人的学习曲线。项目团队成员。选择的标准应确保准确性，鼓励一致性，并促进短暂的学习曲线。然后，根据使用情况，可以根据需要修改标准并使公司特定。

文档编写者应将标签附加到文本，图形或声音对象的那些部分，这些部分必须在实现后进行测试。理想情况下，实际要求将保留在原位而不是存储在多个地方。这样，即使将它们作为单独的要求选择，也可以在项目文档中对它们进行编辑和维护。这样可以在需求发生变化时更轻松地更新项目文档。

属性分配

所有系统要求都具有属性。它们提供丰富的管理信息来源，以帮助计划，沟通和记录项目在其生命周期中的活动。由于每个项目的需求都是唯一的，因此应相应地选择其属性。例如，具体要求将对疗效和患者安全性产生不同的影响。对于输液泵，要求“通过冗余安全系统防止过度输注”的要求比指出“壳体应涂成灰色”的要求更为重要。

因此，公司必须确定优先事项并进行权衡，特别是在安排和预算限制方面。通过与客户和管理层交谈，开发人员可以通过按重要性排序需求来改进他们的决策。应创建状态字段以记录关键决策和进度。在定义项目基线时，建议，批准和合并的术语非常有用。随着项目进入开发阶段，正在进行，实施和验证可用于描述重要的里程碑。

另一个重要属性是所有权;也就是说，谁负责确保满足特定要求？为理由创建一个领域也很重要;也就是说，为什么存在特定要求？该字段可以直接解释原理或在其他地方引用解释。例如，参考可以是产品需求规范的页面和行号，也可以是重要客户访谈的录像带。并且还应记录创建或更改要求的日期。

需求之间可以存在许多关系。例如，属性字段可以记录：

*一个更抽象的要求，从中提出了当前的要求。

*根据现有要求提出的更详细的要求。

*当前要求是子集的要求。

*要求是当前要求的子集。

除了上面列出的属性之外，其他常见属性包括难度，稳定性，风险，安全性，版本和功能区域。无论用于跟踪它们的方法如何，都应该可以轻松定制属性，以适应每个开发团队和每个应用程序的独特需求。制造商应特别注意保持要求与由此产生的所有产品之间的联系。这些链接有助于确定任何更改的影响以及它们的开发状态，这些更改可以记录为这些下游实体的属性。

需求的可追溯性

首次从客户或用户引出时，要求就开始存在。一旦捕获它们，链接必须向后保持其更抽象的前辈，并转发到更详细的后继要求。保持跟踪这些变化路径的能力是质量保证和健全需求管理的先决条件。使用需求可追溯性使产品开发团队能够达到一定程度的项目控制，质量保证和产品安全性，这是通过任何其他方式难以实现的。

可追溯性应该是项目管理中的关键工具，只是因为如果没有某种形式的需求可追溯性，确保完全需求测试覆盖率几乎是不可能的。 FDA的“计算机控制医疗设备审查指南正在进行510（k）审查”指出“测试要求应该可追溯到系统/软件要求和设计。”拟议修订的GMP法规更进一步，指出“制造商必须建立一个记录程序，以确保设计要求得到适当建立，验证并转化为设计规范，并且发布到生产的设计符合批准的设计规范。

最简单的说，需求跟踪表明系统完成了它应该做的事情。该过程的主要好处包括：

*验证所有用户需求已经实施并经过充分测试。

*验证没有无法跟踪用户要求的系统行为。

*更好地了解不断变化的要求的影响。

图表形式的文档层次结构可以是管理需求可跟踪性的有用工具。这样的图表以图形方式显示项目文档之间存在的相互关系，因此也显示了这些文档中表达的要求。例如，产品需求文档（所有产品需求的来源）与软件需求规范之间存在直接关系。因此，所有与软件相关的产品要求应该由一个或多个软件要求来满足，相反，任何软件要求可以帮助满足一个或多个产品要求。在此示例中，不满足任何没有相应软件，硬件或试剂和消耗品要求的产品要求。出于同样的原因，没有相关产品要求的软件或其他要求是无关紧要的，应予以消除。文档层次结构使项目团队成员能够可视化并检查产品文档的所有级别中包含的需求的完整性。

除了使用文档层次结构之外，制造商还应该使用一些系统来使他们能够持续识别层次结构中的项目之间的关系。这可以通过在文档中嵌入唯一标识符和电子链接，或通过使用管理文档外部链接的单独电子表格或数据库来完成。最新一代的需求管理工具可自动维护可追溯性链接。

需求变更

需求可跟踪性提供了一个有条理的受控流程，用于管理在开发和部署到现场时不可避免地发生的变更。如果没有可追溯性，每次更改都需要项目团队成员临时审核所有文档，以确定项目的其他元素（如果有）需要更新。由于这样的过程将难以确定是否所有受影响的组件随着时间的推移而被识别，因此系统的改变将倾向于降低其可靠性和安全性。

通过可跟踪性，可以通过文档层次结构遵循产品需求和规范的关系，以有序的方式管理更改。当用户需要更改时，开发人员可以快速识别可能需要更改的元素，测试人员可以查明可能需要修改的测试协议，管理人员可以更好地确定实施更改的潜在成本和难度。

需求报告

需求存储库为管理员提供了一个强大的工具来跟踪和报告项目状态。 可以更容易地识别关键里程碑，更好地量化调度问题，并保持优先级和所有权可见。查询存储库可以帮助管理人员快速检索关键信息，例如为其设备确定了多少要求，这些信息中有多少可能影响患者安全，是否已识别和减轻所有危害，将需求纳入其中的当前状态和时间表原型，以及建议更改的估计成本。

从需求库中提取的高级报告也可以帮助管理产品功能评估。 需求可以根据客户需求，用户安全考虑因素或其难度或成本来确定优先级。这些专业报告可以帮助管理人员将注意力集中在关键项目问题上来分配资源。

结论

许多设备制造商从未达到预期的项目中获取伤痕。 项目通常将他们的日程安排超过一半，交付少于最初的承诺，或在发布前取消。为了跟上不断增加的复杂性和用户需求的增长，公司必须在开发，测试和管理项目方面变得更加复杂。 改进的需求管理为此提供了第一步。

需求管理存储库包含产品的需求，规格和属性 - 以及它们之间的链接 - 可以帮助制造商准确确定产品应该执行的操作。 它可用于管理和控制设备开发过程，改善团队沟通，提高质量，并最终确保最终产品完全满足客户的需求。