在医疗设备软件中应用需求管理

在 过去10 年中，医疗设备软件开发的技术发展水平经历了巨大的变化。从过去 10-15 年间的医疗软件规格说明书中，FDA 已经意识到，规格说明书还有待于大幅度地改进。实际上，FDA 发现，这期间大约 44% 导致厂家自愿召回产品的质量问题，归因于特殊医疗设备的设计错误或设计不足，而不是因为制造阶段的错误。而且，似乎可以通过充分的设计控制来避免这些错 误。

医疗设备软件的规格说明书

在过去10 年中，医疗设备软件开发的技术发展水平经历了巨大的变化。从过去 10-15 年间的医疗软件规格说明书中，FDA 已经意识到，规格说明书还有待于大幅度地改进。实际上，FDA 发现，这期间大约 44% 导致厂家自愿召回产品的质量问题，归因于特殊医疗设备的设计错误或设计不足，而不是因为制造阶段的错误。而且，似乎可以通过充分的设计控制来避免这些错误。

为了能够随着全球市场的不断演进来规范化美国的标准，并且为了改进医疗设备开发的规格说明书，1990 年美国通过了启用立法，来赋予 FDA 必要的职权范围以管理医疗设备软件的开发。启用立法包含在 1990 年安全医疗设备法（SMDA）中，是 FDA 大幅度修订其对医疗设备涉用软件开发设计监督不足的动力。

安全医疗设备法的通过，对以前的 GMP 规范起到了大幅度的修订作用。新的 GMP 规范刚刚通过批准，并且对医疗设备软件产生巨大影响。简而言之，新的 GMP 规范（现在也称作 Quality System Regulation（QSM））在 1997 年 6 月到 1998 年 6 月期间的过渡时期生效。在过渡期结束前，所有的第二类（Class II）和第三类（Class III）医疗设备及其软件开发，必须与 QSM 中规定的开发过程标准保持一致。

QSM 对建立现代软件开发实践起到了优秀的指导作用，这是个好消息。实际上，这些规定的实践是通过 QSM 中的规章，经过细致工作而作出的，以便与您所熟悉的标准相一致。QSM 是为了遵从 IEEE 软件工程标准或 ISO 9001、IEC 601 或 EN 46001中的全球化标准而特别编制的。还有一个更好消息，QSM 中没有绝对要求的标准。因此，您可以根据现有的标准来塑造自己的开发过程，并且能够调整过程模型使其满足您特有的开发需要。

下面第 1 部分概述了医疗设备软件开发过程要求的结构和文档编制。在第 2 部分中，我们将探讨一个医疗设备开发计划实例，并且考查一下 RequisitePro 工具所提供的功能，以及该工具所提供的对设备需求自动化和管理的支持。

第1部分 制定可以接受的开发计划

从1997年中开始，Quality System Regulation（QSR）规定，应该建立可广泛使用的、良构型计划，用于依赖于软件而工作的医疗设备软件开发。尽管 QSR 规定了要建立计划，但并未规定这样的计划或过程（通过该过程开发软件）的内容。为了能得到这方面的深入见解，有必要熟悉另一个 Office for Device Evaluation （ODE）组织公布的新的 FDA 指导文档：”用于医疗设备涉用软件上市前提交内容的 ODE 指导方针”（草案）。该文档是一个指导性文档，不具备规章效力。但是，该文档包含大量关于如何制定计划的实用建议，我们将这个文档称作”ODE Guidance”文档（OG）。

OG 的附录 A 定义了许多软件开发生命周期中截然不同的阶段。附录 A 定义了以下主要的生命周期域：

• 需求分析和规格说明书
• 结构分析和规格说明书
• 设计和开发
• 验证
• 确认
• 配置管理与变更控制
• 独立验证与确认

在本白皮书中，将讨论每个域的要点，从而建立过程和每个阶段所需文档的概要。在本白皮书第 2 部分中，将使用 RequisitePro 工具箱来自动处理用于支持这些阶段的需求管理活动，并为这些需求管理活动提供支持。

需求分析和规格说明书

OG 的 A. 2 部分指出了确定和分析终端用户的产品功能性需求和性能需求的重要性。Rational软件的需求管理团队是这方面的业内领袖，并且他们已经公布了一些文章 和教程，为收集和分析需求信息的至关重要性提供支持4。为了组织和管理这项工作，许多医疗设备项目，都通过定义和使用这三种不同类型的文档，获取良好的服 务，来收集和管理需求：产品需求文档（PRD）、软件需求规格说明书（SRS），以及危害分析（HA）。这些文档形成了实现文件结构的顶层，其最初出现的 形式如图 1 所示。

设计与开发

OG 附录 A.4 讨论了软件需求由 SRS 转化成源码的过程。为了标准化这个实现过程，OG 推荐采用格式指南、编码标准等。在该活动中，还推荐了走查测试和基准测试。通常，围绕某类实现单元来组织软件，例如代码模块、子例程、对象类等。因此，明 确地，或隐含地建立了另一个文档集，即实现单元集。

随着实现文档的逐渐可用，应该将其加到图 3 所示的实现文档编制的结构中、

OG 推荐，在实现单元和规格说明与该实现过程的 HA 之间，开发人员应严格坚持审计跟踪。在第 2 部分讨论可跟踪性时，我们将讨论如何完成这项工作

OG 推荐，在验证活动和产品规格说明书与该实现过程的 HA 之间，开发人员应严格坚持审计跟踪。在第 2 部分讨论可跟踪性时，我们会探讨这个问题。

确认

同样，OG 附录 A.6 推荐了多种确认活动。IEEE 这样定义”确认”：

“它是开发过程中间或结束时对某一系统或某一组件进行评价的过程，以确定它是否满足规定的需求”

换句话说，您需要确认已经实现的组件实际上按照规格说明书进行工作。通常，用测试来完成这项任务。再一次强调，确认计划是必需的。按照惯例，确认计划是前面讨论过的 V 和 V 计划（VVP）的一部分，

确认活动与测试同步进行。但是，好的测试计划是什么样的呢运的是，IEEE 回答了这个问题。IEEE 829-1983, IEEE Standard for Software Test Documentation 提供了广泛的内容，包括如何建立测试方法、进行测试、 告测试结果，以及如何解决异常问题。

注 意进行软件测试时，应从两个角度确定被测部件的正确性：1）被测部件是否满足实现单元规格说明书，并且 2）被测部件是否满足其控制需求。也就是说，不仅要通过测试来确认部件能够正确运行，而且要确认被测部件满足原始规格说明书。测试文档是实现文档中的一部 分。考虑到测试文档，实现文档树应如图 5 所示。

注意 RequisitePro 工具允许通过双下划线或以用户定义的样式，来自动强调某些需求。强调方式是我们推荐的一种有力的可视辅助形式，用来帮助阅读者快速定位特定行为问题、性能问题和安全问题等。

在标识产品需求时，RequisitePro 为每项产品需求分配唯一标识符（PR4, PR5等）；从而遵照第 1 部分中提到的 FDA 指南。

RequisitePro 还应该用来分配和维护属性集和 PRD 中每项 PR 值。

现在，我们将使用 Attribute 功能，在逐项功能分析法基础上，对关注级别（LOC）进行归类。随着每项功能被定义，可以插入属性值，即我们为 PR 定义的 Concern 属性。可以用 RequisitePro 定义属性并定义可选值清单。然后，随着功能被定义，您可以评估 LOC，并用 Concern 属性来记录评估结果。RequisitePro 提供了易于使用的选择和排序功能，使您过后可以只选择具有精选的 LOC 的那些功能，或选择团队感兴趣的其他属性和属性值组合。

在项目的任意位置，都可以用 RequisitePro 来打印文档，或显示数据视图，从而提供所有定义的 PR 的当前清单。可以根据不同属性，以特有角度，对该视图进行过滤或排序。表 1 显示了一个这类视图的一个样例。

在 PRD 例中，我们已经强调过软件需求（SR）。如前，标识软件需求时，RequisitePro 为每项需求分配唯一标识符（SR1、 SR2等），从而遵照第 1 部分中提到的 FDA 指南。

RequisitePro 还应用于分配和维护属性集和 SRS 中每项需求属性值。注意可以为每类需求独立地分配属性和属性值。注意我们已经通过与 PRD 中所用的相同属性概念实现了关注级别问题，但我们还定义了与 PRD 不同的属性。表 2 显示了一个 SR 视图样例和它们的一些属性。

每个文档中的单个元素，应与另一文档中的适当元素链接。也就是说，SRS 中每个 SR 项要与 PRD 中控制它的 PR 项关联起来。反之，将每个 PR 项和它控制的 SR 项进行匹配。注意这项匹配可以是一对多，多对一，或多对多。

同样，HA 项也要进行对应的关系链接。RequisitePro 未要求严格的关系分级结构。因此，允许所有的垂直关系（如 PR-to-SR）和所有的平行关系（如 HA -to-SR）。非分级结构关系是大多数开发项目的常见部分，并且不暗含特殊特征。

无论是何种关系，将相关项链接起来都非常重要。该链接过程称作可跟踪性。

可跟踪性

优质软件实现过程中一个重要因素是，跟踪能力要贯穿整个实现过程，包括规格说明阶段、构架阶段、设计阶段、实现阶段，以及 V&V 阶段。实际上，跟踪关系的能力，并将这些关系与变更管理问题关联起来，成为贯穿新的 OG 的关键线程。另外，CGMP 的 Design Controls 部分，即 CGMP 的 Subpart C 再次重申在产品开发生命周期范围内，在不同工作产品之间建立关系跟踪能力的重要性。IEEE 提供了两种可跟踪性的工作定义：

1）”在两种或多种开发过程的产品之间建立关系的程度，特别是相互之间具有前后关系或主从关系的产品；例如，给定软件组件的需求与设计之间的匹配程度”。

2）”某一软件开发产品的元素存在原因的程度；例如，一个泡式图的元素为需求提供参考的程度”。

可 跟踪性的一个要素是，对某一”可跟踪性关系”意味着什么作出的定义。使用 RequisitePro 工具，可以按照简单的”traced-to”和”traced-from”模型，方便地定义某种关系。例如，我们很容易设想，在系统中建立一个或多个软件 需求（SR），来支持产品需求（PR）中指定的某一给定功能。从而可以说，从一个或多个 PR，对 SR 进行跟踪。在已建立的需求类型的环境中，可以赋予关系另外的意义。例如，如果从一个 SR 跟踪到测试用例需求型，可以推出该软件需求是”通过测试用例进行测试”，也就是”traced-to”型。从一个 SR 需求来跟踪类描述，意味着需求是通过该类来实现的。使用 RequisitePro 工具，对可定义的需求类型没有数量限制和类型限制。另外，给定类型的需求可以在任意文档范围内出现。例如，不必只有 SR 类型需求才能驻留在用于描述软件需求的文档中。

RequisitePro 提供了一个简单的 user-guided 过程，通过可能存在于生命周期中两个元素之间的关系，来”指向并点击”（point and click）。在定义了 PR 和 SR 之间的关系后，RequisitePro 可以显示 PR 和 SR 之间关系的矩阵图，如图 9 所示。

图 9 中可跟踪性矩阵是直接实现的。例如，可以考虑 PR8（远程数据通信）和 SR1（调制解调器端口）的相交部分。在相交部分的 格中，” “箭头表明，从 PR8 跟踪到 SR1，可以得到某种关系。也就是说，SR1 来自 PR8 定义的某种功能，或者 SR1 以某种方式满足 PR8 定义的功能。

RequisitePro 还提供了显示项目中全部可跟踪性关系集的功能。图 11 显示了这样一个”树”视图。注意树视图（或部分树视图）允许同时查看项目所有关系。您应该利用树视图来帮助充分理解项目的总体关系。

例如，图 11 的树视图表明，PR3（一个产品需求或功能）链接到 SR1（一个软件需求），SR1 又链接到 TST4（一个测试规格说明）。

元 素之间建立了链接之后，RequisitePro 将用于保持这些链接。利用 RequisitePro 的强大功能，可以任您所需地来检查项目元素之间的关系。一项关键的需求管理活动为您提供了一种常规的检查功能，那就是利用可跟踪性关系来检查项目中建议的 变更、和已经实现的变更带来的影响，该类活动在 OG 和 QSR 中称为变更管理。

随着项目的进展，您会发现，项目的很多方面都有变更提议。这些变更可能发生在项目的任何地方，从高级 PRD 一直到规格说明、实现过程和测试。无论变更何时发生，RequisitePro 都将自动插入可疑链接标记来提醒您可能受到变更影响的关系。当检查交互作用时，您可能发现受到影响的元素可能发生变更，也可能不发生变更。变更管理活动通常包含以下两个步骤之一：

1、如果受到影响的链接不会发生改变（例如，PR8 的变更不会影响到 SR1），那么只需用 RequisitePro 来清除可疑链接即可。请注意，过后的 PR8 变更可能在某一时刻再次将其标为可疑链接。

RequisitePro 实际上提供了所有级别可跟踪性关系的变更管理功能。也就是说，改变 PRD 中 PR 项可能对 SRS 中若干项 SR 产生影响，这些影响随后又会对某些实现单元产生影响，而实现单元受到的影响随后又会对一个或多个测试计划产生影响。RequisitePro 还对可跟踪性链接进行双向跟踪。例如，测试计划规格说明书的变更可能需要回头来检查实现单元（IU）以确定是否对其产生影响。随后，改变 IU 可能要求您复查受到影响的 SR，甚至要求复查高级 PR，这些 PR 都是通过已建立的可跟踪性关系而最终进行链接的。

在所有情况下，RequisitePro 的跟踪活动贯穿了可跟踪性链接，并且在适当的地方插入可疑链接标记。这项强大功能为您提供了一个简单的方法，来跟踪项目中变更带来的影响。

变更历史记录的审计跟踪

RequisitePro 提供了一项强大功能，用来保持变更的审计跟踪。这项功能的最大用途在于，对单个需求发生的变更自动进行跟踪。RequisitePro 独立管理每项需求，尽管需求包含在文档中。这样，RequisitePro 能够自动捕获每项需求发生的变更，并且您可以过后检查和评审这些变更。

通过变更的历史记录来捕获当前的需求说明，包括当前的所有需求属性值。通过捕获所有当前的需求参数，可以将历史记录用作查看所有需求参数的简洁方法。这项功能类似于 RequisitePro 其他功能所提供的常用属性查看方法。

变更的历史记录还使您能够查看较早的需求变更的历史记录（这些记录是按时间顺序排列的），包括他们的属性。RequisitePro 能够自动捕获某项需求所有的文本变更和需求属性值的变更。

无论 RequisitePro 何时检测到一项变更，它可以自动捕获该项变更的背景情况。另外，RequisitePro 还可以自动捕获某项变更的创建者（例如，用 RequisitePro 进行变更的人）和该项变更的日期和时间。然后，在过后的任何时间，按时间顺序排列的变更和变更创建者可以作为历史记录的一部分来查看。

另 外，RequisitePro 允许输入一项变更描述来记录该项变更。通常，用一两句话来解释为什么要进行变更，建立关于变更的项目备忘录参考资料，等等。将变更记录下来，可以得到令人 满意的基本的变更理由和相互参照，从而在后面做历史记录检查时，可以充分地回想起某项变更的动机。在 FDA 评审那些影响到设备的临床要求、效率和安全性的变更时，这是一项关键要素。

图 13 显示了部分 SRS 需求历史记录（SR7）样例。注意变更的历史记录是按反向时间顺序排列的，并且记录了文本变更（#1.0006对 #1.0005）和所选属性值（#1.0005）的变更。变更可能是非常细小的，例如 1.0005 和 1.0006 的文本变更，仅仅是改变了”cpu”的字母大小写。即使如此，极小的变更也要作为一项变更，通过 RequisitePro 正确地记录下来。

(rest of history truncated for this example)

配置管理与变更管理

在使用 RequisitePro 工具进行管理的项目中，强大的变更历史记录功能有三个级别：

1. 在最好的细节级别上，变更历史记录对项目中每项单个的需求的所有变更进行记录。图 13 显示了该细节级别。

2. 在中等细节级别上，RequisitePro 用于与常见的行业配置管理工具（包括 PVCS 和 Visual Source Safe）集成，从而自动保持每个已知项目文档的类似的变更历史记录。

3. 在最普通的细节级别上，RequisitePro 用于与配置管理工具进行链接，从而自动保持整个项目的勒死的变更历史记录。在这种模式中，RequisitePro 还提供了安全访问，来防止关键项目文档的非授权变更。RequisitePro 还用于保持项目级的内置的项目存档功能，从而允许您为处于特定开发形态中的项目进行”快照”。

借助于这些功能，RequisitePro 实现了与公共应用程序的自动且无缝集成，在配置管理任务中起到辅助作用，这些配置管理任务对于管理高可信度软件项目至关重要。

结束语

随着最新的 FDA 规范的出台，医疗设备制造商正在面临着更加严格的医疗设备开发过程和医疗设备软件开发过程的管理方针。预计这种趋势将不断加深。不良的设计控制不仅意味着产品不能通过 FDA 评审，而且也无法满足客户的期望，还可能导致项目超过日程计划一半，以及相关的成本超支，而且最严重的后果将导致项目终止。

同时，我们正在开发复杂性不断增加的系统，要求对项目组成组件有更好的了解。不断出现的用户要求，促使形成了一个系统的设计控制的方法，该方法是完全有必要的。了解需求管理过程，并且将其用于开发医疗设备，是实现成功的项目设计、测试和管理的根本所在。

通过以原有形式输入需求文档和对其进行评审这两个功能的结合，并且链接到中心库（库内容包括需求、规格说明、属性和它们之间的可跟踪性链接），可以建立一个可以控制的机制，用以确保一致性和设计质量。通过使用 RequisitePro，使项目团队能够管理设备的设计过程，改进团队之间的交流，更清楚地定义项目基线，以及更高效地管理资源。另外，RequisitePro 提供了需求可跟踪性和变更管理的自动支持功能，从而降低了开发成本，并且通过消除许多人工活动易范的错误，而提高了产品质量。

将 RequisitePro 整合到医疗设备团队的设计控制过程中，可以提供一个更加自动化的方法，来开发能够按期交付的、预算内的产品，从而满足客户的真正需要，并且确保病人的安全。

建议阅读

Software Requirements – Objects, Functions, & States, Davis, Alan M., Englewood Cliffs, NJ: Prentice Hall, 1993.

Exploring Requirements – Quality Before Design, Gause, Donald C., and G. Weinberg, New York, NY Dorset House Publishing, 1989

如需订购这些书目，或加入 上论坛来讨论需求管理问题，请与 Rational 软件集团公司联系，4900 Pearl East Circle, Suite 106, Boulder, CO 80301，电话：(303)-444-3464，传真：(303)-444-3413，电子邮件：information@rational.com

缩写词汇表

510(k) 关于上市的医疗设备（与市面上已有的医疗设备相似）方面控制立法的组织的简写。用法类似于用来指联邦管理下的公司储蓄计划时的”401(k)”。

CDRH Center for Devices and Radiological Health
CGMP Current Good Manufacturing Practices
CMP Configuration Management Plan
FDA Food & Drug Administration
EU European Union
GMP Good Manufacturing Practices
HA Hazard Analysis
HRS Hardware Requirement Specification
IEC International Electrotechnical Commission
IU Implementation Unit
IEEE Institute of Electrical and Electronic Engineers
ISO International Standards Organization
LOC Level Of Concern
MDA Medical Device Amendments
ODE Office of Device Evaluation
OG “Office of Device Evaluation Guidance for the Content of Premarket Submission for Medical Devices Containing Software (draft document)”
PRD Product Requirements Document
QSR Quality System Regulation
SMDA Safe Medical Device Act
SRS Software Requirement Specification
V&V Verification and Validation
VVP Verification and Validation Plan

参考资料

• Davis, Alan M. Software Requirements – Objects, Functions, & States. Englewood Cliffs, NJ: Prentice Hall, 1993.
• Davis, Alan M. 201 Principles of Software Development. New York, NY: McGraw-Hill, Inc., 1995.
• FDA. Medical Devices; Current Good Manufacturing Practice (CGMP) Final Rule; Quality System Regulation.
• Washington, DC: GPO, 1997.
• FDA/ODE. ODE Guidance for the Content of Premarket Submission for Medical Devices Containing Software.
• Washington, DC: GPO, (draft 1.3, 12 Aug 1996).
• Gause, Donald C., and G. Weinberg. Exploring Requirements – Quality Before Design. New York, NY: Dorset House Publishing, 1989.
• IEEE. IEEE Standards Collection, Software Engineering. IEEE: New York, NY. 1994.
• Leffingwell, D., and A. Davis, Using Requirements Management to Speed Delivery of Higher Quality Applications.
• Rational Software TR0001, 06/96.
• Wood, Bill J, and Julia W Ermes. “Applying Hazard Analysis to Medical Devices”, Medical Device & Diagnostic Industry magazine, 01/93.