玻尔百科构建任何复杂系统，无论是医院的IT网络还是自动驾驶汽车的 software，都不是从代码开始，而是从对话开始。将抽象的人类需求转化为具体、明确且可测试的蓝图，这正是需求工程的精髓。这是一门至关重要却又常常默默无聞的学科，它弥合了意图与执行之间的鸿沟，确保我们构建的系统不仅技术上可靠，而且有用、易用且安全。在这一早期阶段的失败是项目失败的最大原因，会导致系统充满错误、效率低下甚至危险。
本文旨在揭开这一关键领域的神秘面纱。在接下来的章节中，我们将从该学科的核心原则出发，探究其在现实世界中的影响。首先，在“原则与机制”一章中，我们将探讨验证和确认的基础概念、逻辑精确性在定义需求中的力量，以及管控安全关键型开发的结构化流程。随后，在“应用与跨学科联系”一章中，我们将看到这些原则的实际应用，考察它们在医疗器械、汽车安全和复杂人机交互这些高风险领域中所扮演的重要角色。
想象一下，你想建造一个复杂的东西——不只是后院的棚屋，而是一家医院。你不会只带一堆木材到场就开始敲敲打打。你会从一场对话开始，深入探究其目的。这家医院是为了什么？谁会使用它？我们如何确保它是一个治愈之地，而非伤害之所？这场对话，这种将抽象需求转化为具体、可构建计划的行为，正是需求工程的灵魂所在。这是一门决定、定义和记录系统应做什么的学科。
虽然这听起来可能只是文书工作，但这个过程是一场引人入胜的智力之旅，融合了逻辑、心理学和伦理学。它关乎提出正确的问题，达到深刻的清晰度，并最终在人类意图与技术现实之间架起一座桥梁。
整个工作的核心是两个基本且常常被混淆的问题：“我们构建了正确的东西吗？”和“我们把东西构建正确了吗？” 这并非哲学谜题，而是质量的基石，在形式上分别被称为确认（validation）和验证（verification）。
确认（Validation）是检查你是否构建了正确的东西的过程。它旨在探究最终产品是否真正满足用户的真实需求。对于我们的医院而言，这就好比去询问医生、护士和病人，布局是否合理，房间功能是否齐全，是否真正支持了护理流程。这是一个面向外部的问题，关注的是现实世界中的有效性。
验证（Verification），则是检查你是否把东西构建正确的过程。它旨在探究产品是否符合其设计和规格——即它的蓝图。我们是否使用了指定等级的钢材？电气系统是否按照图纸布线？这是一个面向内部的问题，关注的是与计划的一致性。
在采购一个复杂软件系统（如医院的新医嘱系统）时，一个常见场景能让这种区别变得非常清晰。医院可能会规定数百条需求——关于所需能力的可验证陈述。例如，一条关键需求可能是：“系统必须阻止医生为已知药物过敏的患者开具该药物。” 验证将涉及运行特定的、脚本化的测试，以确认此功能完全按规定构建。但确认则需要让真正的医生和药剂师在模拟环境中使用该系统，看它在他们混乱的真实工作流程中是否直观、快速和安全。你完全可以验证一个完全无法使用的系统——一个技术上满足所有需求，却在最终的确认测试中失败的系统。目标是在两者上都取得成功。
为了把东西构建正确，我们的蓝图必须是明确无误的。在日常语言中，我们可以含糊其辞。如果你让朋友“把音乐关小点”，他们可以根据上下文理解你的意思。但计算机不能。它会逐字逐句地理解一切。需求中的模糊性是项目失败的最大原因，会导致系统充满错误、不安全或根本无法工作。
这就是为什么需求工程与形式逻辑有很深的联系。考虑一个看似简单的 software 应用规则：“当且仅当所有自动化单元测试都通过时，该应用程序才被视为处于稳定状态。”。那么，违反这条规则，精确地讲，意味着什么？
让我们将“应用程序处于稳定状态”表示为命题 ，将“所有自动化单元测试都已通过”表示为 。这条规则是逻辑双条件句，。违反规则即为该陈述的否定，。逻辑定律告诉我们，这等价于 。这个枯燥的公式揭示了一个关键点：系统存在两种截然不同的失败方式，而不仅仅一种。
没有这种逻辑上的精确性，工程团队可能只会检查其中一种情况，从而留下一个未被发现的关键故障路径。这不是卖弄学问，而是防止灾难发生的严谨思维。为了在实践中实现这种清晰度，工程师通常使用像SMART需求这样的框架，确保每一条需求都是Specific（具体的）、Measurable（可衡量的）、Achievable（可实现的）、Relevant（相关的）和Time-bound（有时限的）。
当赌注很高时——如在医疗、航空或金融领域——这种对精确性的需求就被写入一个正式的、受监管的流程中。这个流程并非为了扼杀创造力；它是一支精心编排的舞蹈，旨在确保所构建之物安全有效。这支舞通常遵循“V模型”，我们从高级需求下降到详细规格，然后通过测试和集成再回升。
这支舞中的关键步骤，特别是对于像“作为医疗器械的软件”（SaMD）这样的产品，都有细致的定义：
设计输入：过程始于捕获所有用户需求、设备的预期用途，以及从中衍生的所有精确、可衡量的需求。这构成了整个项目的基础。
设计输出：这是蓝图的创建过程。对于 software 而言，这包括 software 架构、详细算法、编码标准以及实际编写代码所需的一切。
设计验证：在创建设计输出的同时，我们不断地将其与输入进行核对。这是我们“把东西构建正确”的第一个循环。它包括代码审查、静态分析和单元测试等活动，即在隔离环境中测试单个组件。
设计确认：一旦系统完全构建和集成，最终的测试便开始了。我们将成品设备交给预期用户，在真实场景中确认它是否满足其原始需求。对于医疗器械，这涉及严格的可用性测试，并通常需要进行全面的临床评估，以产生其安全性及临床获益的客观证据。
将这支舞蹈维系在一起的“金线”是可追溯性矩阵。想象一个巨大的电子表格，它将每一个用户需求链接到一个或多个设计输入，这些设计输入又链接到特定的设计输出，然后这些设计输出再链接到检查它们的验证测试和确认它们的确认场景。这个矩阵提供了工作已正确完成的“明确证据”。如果利益相关者问：“我们如何知道该设备用于计算药物剂量是安全的？”，可追溯性矩阵可以让你直接从安全需求指向风险分析、具体算法、已通过的验证测试以及已确认它的临床确认。
如果需求工程只关乎逻辑和流程，那将是一件枯燥乏味的事情。它真正的丰富性来自于认识到我们正在为一个复杂的、充满人性的世界内部构建系统。
医院的电子健康记录（EHR）不仅仅是一个软件；它是一个社会技术系统，将技术与临床工作流程、职业责任和患者生命交织在一起。决定其需求是一种政治和组织行为。谁有最终决定权？。
在一个运营良好的组织中，决策权被仔细划分。首席医疗信息官（CMIO）代表临床方，必须在任何涉及临床工作流程和患者安全的事情上拥有最终决定权。首席信息官（CIO）代表技术方，必须在基础设施、安全和预算上拥有最终决定权。临床信息学家通常扮演着这两个世界之间关键翻译者的角色。一个由CIO决定临床工作流程的系统是危险的。一个由CMIO决定服务器架构的系统是行不通的。需求过程必须是一次结构化的协作，是这些权威人士之间的对话，以平衡医学需求与技术限制。
当利益相关者对系统应该做什么存在根本分歧时，会发生什么？一个构建用于临床决策支持的全球性AI项目将面临不同的伦理环境。有些文化可能将个体患者的自主权置于一切之上，而另一些文化则可能优先考虑集体利益或行善原则。可能没有一套普适的“正确”价值观可以被编码。
这就是价值多元主义的挑战。在这种背景下，最先进的需求方法不是像捡石头一样去“收集”需求，而是进行参与式设计。这种方法将利益相关者——患者、临床医生、社区领袖——视为共同发现过程中的合作研究者。其目标不是强行就一套单一的价值权重（）达成共識，而是描绘出有争议的价值观图景（），理解在不同背景下如何进行权衡。这是一种谦逊、包容的方法，它承认“正确的事”往往是一个经协商的、情境化的、多元的概念。
由于时间和资源有限，我们无法以同等强度测试和验证所有内容。我们必须将精力集中在最重要的地方。这里的指导原则是风险。
在受监管的行业中，software 通常会根据其故障可能导致的最严重后果被分配一个安全等级。例如，根据 IEC 62304 标准，其故障可能导致死亡或严重伤害的 software 被视为C级。这种分类会产生深远的影响。一个C级组件要求最高级别的严谨性——更多的文档、更多的测试，以及至关重要的独立验证。
这种基于严重性的优先级排序通常必须覆盖更简单的风险计算。一个故障概率高但危害严重性低的模块（例如，导致用户烦恼的界面小问题），其数值上的“风险评分”（）可能高于一个故障概率极低但危害是灾难性的模块（例如，药物剂量计算错误）。医学伦理原则，尤其是不伤害原则（“首先，不造成伤害”），要求我们将最深入的审查集中在那些可能造成最大损害的组件上，无论其故障的可能性如何。这种基于风险的方法确保我们将有限的工程精力用于防范最坏的可能结果。
在崇尚速度和适应性的世界里，上述正式的、舞蹈般的流程可能显得僵化。这些原则在现代敏捷（Agile）开发中如何存续？完美的答案是：原则依旧，但实践在演变。敏捷团队可能不会创建庞大、独立的规格说明文档，而是在其待办事项列表（backlog）中的用户故事的验收标准里捕获需求。验证测试可能是一个随每次代码更改都会运行的全自动脚本。可追溯性矩阵不再是独立文档，而是团队 software 工具内部一个实时更新的链接网络。目标是建立一个“单一事实来源”，在这里，合规性和质量不是你进入的某个阶段，而是你持续维持的一种状态。
而对于那些绝不容许失败的系统——比如飞机的飞行控制系统或自动驾驶汽车的制动逻辑——我们可以将精确性推向极致。使用像线性时序逻辑（LTL）这样的形式化方法，我们可以用数学的确定性来描述所需的行为。我们可以正式区分安全性（safety）属性（例如，，即坏事永不发生）和活性（liveness）属性（例如，G(\text{button_pressed} \rightarrow F(\text{elevator_arrives}))，即好事终将发生）。然后，这些数学陈述可以用来证明一个系统的设计是正确的，从而提供最高级别的保证。
从关于需求的简单对话到正确性的数学证明，需求工程领域是在复杂世界中追求清晰度的探索。这是一门确保我们构建的东西不仅巧妙，而且有用、易用且安全的基本的、且常常默默无闻的艺术与科学。
在体验了需求工程的原则和机制之后，我们可能会留下这样一种印象：这是一个有些形式化，甚至可能有些官僚化的流程。一套要遵循的规则，一些要勾选的方框。但这样看待它，就如同将宏伟教堂的建筑蓝图仅仅看作纸上的一些线条。当我们看到它付诸实践，见证这些结构化原则如何成为我们健康、安全以及我们对所居住的复杂技术世界信任的无形守护者时，这门学科的真正美丽与力量才会显现。
需求工程是预见性的艺术。它是一种实践，即想象一个系统可能失败的所有方式，尤其是在与混乱、不可预测的真实世界交互时，然后有条不紊地构建一个由逻辑和证据组成的堡垒来防止这种失败。现在让我们来探索一些将这门艺术实践到极致的领域。
没有哪个领域的风险比医学更高。当 software 不仅仅是在服务器上运行，而是积极参与诊断和治疗时，它就不再仅仅是代码——它变成了医疗器械。这种“作为医疗器械的软件”（SaMD）是一个前沿领域，在这里，需求工程不仅仅是一种良好实践；更是一项深刻的伦理和法规义务。
想象一个精密的人工智能，它被设计用于分析 CT 扫描并标记可能为恶性的肺结节。我们如何确保它的安全有效？这个过程不是从代码开始，而是从问题开始。我们要解决的临床问题是什么？谁会使用这个工具——放射科医生，还是技师？在什么环境下使用——安静的阅片室，还是繁忙的急诊室？这些问题定义了用户需求。
从这些需求中，我们提炼出一套精确、可测试的设计输入。这是抽象变得具体的地方。一个“准确”设备的用户需求被转化为一个可衡量的工程需求：例如，该算法必须在一个特定的、预定义的数据集上达到至少 的受试者工作特征曲线下面积（AUC）。一个“快速”工具的需求变成了一个要求，即风险评分必须在收到数据后 秒内呈现。至关重要的是，我们也要在这里加入安全和公平性的需求，例如，规定其性能在不同人群之间不应存在显著差距。
由此产生的 software 架构、源代码、训练好的人工智能模型以及用户手册——这些都是设计输出。现在到了关键时刻，这个时刻被巧妙地分为两个不同的检查。首先是验证（verification）：我们根据输入来测试输出。代码是否在 秒内运行？它在我们的测试平台上是否达到了 的 AUC 目标？我们回答的问题是：“我们把设备构建正确了吗？”
但这还不够。第二个，也可以说是更重要的检查是确认（validation）。在这里，我们拿着成品设备，对照原始用户需求进行测试。我们在模拟环境中与真正的放射科医生进行研究，看这个设备是否真的帮助了他们，而没有误导他们。我们回答的问题是：“我们构建了正确的设备吗？”。验证和确认之间的这种微妙区别是构建值得信赖的医疗技术的基石。
现代 software，尤其是 AI，的复杂性带来了独特的挑战。对于一款 MRI 重建 software，一个微小的错误可能会产生图像伪影，它既可能模拟肿瘤，也可能隐藏肿瘤。潜在的危害是严重的。为了管理这一点，像 IEC 62304 这样的标准迫使我们根据故障可能导致的最严重的可信危害对 software 进行分类。A级适用于不会造成伤害的 software，B级适用于非严重伤害，C级适用于死亡或严重伤害。一个 MRI 分析工具最初可能被视为C级。然而，如果存在强大的外部风险控制措施——比如训练有素的放射科医生总是在结合多个其他扫描的背景下解读图像——那么也许可以证明B级分类是合理的。关键的洞见是，所需的严谨性、文档和测试水平与潜在危害成正比。
当人工智能模型被用于在临床试验中提出建议时，例如选择药物剂量，这种相称严谨性的原则就更加突出了。在这里，监管环境要求一个近乎完美的证据链。为确保可复现性和完整性，我们必须把人工智能模型的创建过程当作一条高科技生产线来对待。每一个“成分”都必须被记录和版本控制：源代码的精确版本、训练数据的特定快照（附有加密校验和以证明其未被更改）、配置文件，甚至包括训练中使用的随机种子。整个过程必须由一个安全的、带时间戳的审计追踪来管理，记录下谁在何时、为何做了什么，关键变更通常还需要电子签名。这就是良好机器学习规范（GMLP）的精髓，确保在 GxP（良好规范）监管环境下，来自 AI 的建议像瓶子里的药片一样可追溯和可靠。
需求工程最引人入胜的前沿或许在于人与机器的交界面。一个“完美”的算法如果其用户界面设计不佳，也可能变得无用甚至危险。考虑一个推荐抗生素的人工智能。如果临床医生开始盲目相信它的输出——一种被称为“自动化偏见”的现象——他们可能不会运用自己的临床判断，从而导致错误。
在 IEC 62366 等标准的指导下，可用性工程不是为了让 software 更漂亮；而是为了系统地识别和减轻这些与使用相关的风险。其指导原则是“控制层级”。控制风险的最佳方法是将其完全从设计中剔除。如果做不到，就增加一个保护措施（如警报）。只有作为最后手段，才应依赖“安全信息”，例如用户手册中的警告或培训，因为这些是效果最差的控制措施。
这引出了一些引人入胜的设计问题。对于一个在 ICU 中推荐启动维持生命的血管加压药的系统，人类应该拥有多大的控制权？在人在回路（HITL）模型中，临床医生必须在系统行动前明确批准建议。在人在环路（HOTL）模型中，系统可能自动行动，但临床医生有一个时间窗口可以干预并否决。
哪种更安全？我们不靠猜测，而是靠测试。我们在混乱 ICU 的高保真模拟中，与代表性用户（医生、住院医师、护士）一起进行详细的确认研究。我们定义严格的、基于风险的验收标准：对于 HITL 任务，用户错误批准不良建议的概率必须小于 。对于 HOTL 任务，即使在高工作负荷下，否决一个错误自动指令的平均时间也必须少于 秒。通过测量这些结果，我们收集客观证据来确定哪种界面设计是可接受的安全的。
在医疗器械设计的熔炉中锻造出的原则是普适的。思考一下你车里的防抱死制动系统。这是一个信息物理系统，software 命令物理执行器，不容許失败。汽车行业使用一个名为 ISO 26262 的标准，它定义了汽车安全完整性等级（ASIL），范围从 ASIL A（低风险）到 ASIL D（最高风险，如用于制动或转向）。
对于一个被评为 ASIL C 或 D 级的系统，开发者不能简单地声明他们的 software 能用。他们必须构建一个安全案例——一个结构化的、正式的论证，由大量证据支持，证明系统是可接受安全的。这些证据包括严格的 software 开发计划、证明关键与非关键组件之间无干扰的架构设计、详尽的验证测试报告（通常使用数字孪生进行模拟），以及所有开发中使用的 software 工具本身都符合任务要求的证明。这深刻地表明，对于我们以生命为赌注的技术，“它能用”并非一个充分的答案。我们必须能够用可审计的证据来证明我们如何知道它能用，以及为何它是安全的。
当这种谨慎的预见过程崩溃时会发生什么？想象一个输液泵，其 software 界面在剂量单位应为微克时默认显示为毫克。一位忙碌的护士在压力下接受了默认设置，导致了1000倍的过量给药。制造商可能会辩称护士犯了错。但法律呼应了人因工程的原则，对此有不同的看法。
在过失和产品责任法中，一个关键概念是风险-效用测试，通常用著名的 Learned Hand 公式表达：如果预防措施的成本（）小于伤害的概率（）乘以该伤害的严重性（），那么就需要采取该预防措施。在我们的情景中，如果一项能够发现此设计缺陷的适当可用性研究所需成本为 B = \100,000PL = $200,000$，那么未能进行该研究就构成了失职。这种“人为错误”并非一个打破因果链的不可预见事件；它是一个糟糕设计的可预测、可预见的后果。遵守像 IEC 62366 这样的标准并非免除责任的自动护盾，但在风险高且预防成本合理的情况下不遵守这些标准，则是不利的铁证。
正如我们所见，现代需求工程是一首深度跨学科的交响曲。它汇集了系统工程、风险管理、人因心理学、网络安全甚至法律。不断扩展的所需文档清单——风险管理文件、可用性工程文件、software 物料清单、网络安全威胁模型——并非官僚主义的演练。它是这首交响曲的乐谱。它是客观证据，是可审计的追踪记录，证明了一个设备不仅仅是拼凑而成，而是经过精心、有远见地创作，并对依赖它的人们的安全怀有深切的敬意。在一个奔向更强大、更自主技术的世界里，这种深思熟虑、严谨且充满人性的提问“如果……会怎样？”的过程，比以往任何时候都更加美丽和重要。