4. 融合工程的需求分析与场景建模

隐私计算与数据治理融合工程的需求分析，不能从“选哪套隐私计算框架”开始，而应从四个约束源同时出发：业务目标决定系统要产出什么价值，合规约束决定哪些数据可以以何种方式被处理，数据对象决定技术路线的可行边界，参与方角色决定权限、信任与责任如何分配。四者共同收敛，才能得到一份可验证、可落地、可审计的需求规格。本节围绕这一收敛过程展开，并给出可直接参考的场景建模与需求定义方法。

一、四个约束源及其相互牵制关系

业务目标通常以可度量的方式表述，例如“将小微企业信贷审批中的外部数据核验时间从3天压缩到4小时”“在不转移原始数据的前提下完成跨机构联合风控建模”。合规约束来自《个人信息保护法》《数据安全法》以及行业监管细则，核心是处理目的限定、最小必要、单独同意、跨境限制与留存期限。数据对象需要刻画类型（身份标识、交易流水、医疗记录、位置轨迹）、敏感级别、规模、分布形态（横向/纵向/混合）以及是否含直接标识符。参与方角色则包括数据提供方、数据使用方、计算节点运营方、审计方与监管方，各自承担不同的权利与义务。

这四个约束源并非独立，而是相互牵制。例如业务目标要求“实时联合评分”，但合规约束要求“原始数据不出域”，数据对象又是纵向分布（各方持有不同特征维度），那么技术路线就被压缩到纵向联邦学习或安全多方计算中的特定协议；若参与方中存在互不信任的两方，则还需引入可信执行环境或密码学审计机制。需求分析的本质，就是把这些牵制关系显式化，而不是留到开发阶段再被动应对。

二、场景建模：把业务语言翻译成工程语言

场景建模的目标是把“我们要做联合风控”这类模糊表述，拆解为可被工程实现的结构化描述。推荐使用“场景卡”方式，每张卡包含六个字段：场景名称、参与方与角色、数据对象清单、业务动作、合规红线、成功判据。以小微企业信贷联合风控为例：参与方为银行A（数据使用方）、税务机构B（数据提供方）、隐私计算平台C（运营方）；数据对象为B持有的纳税评级与开票流水（敏感级别中高，纵向分布），A持有的贷款申请与历史违约标签；业务动作为“对申请企业进行联合信用评分，输出0-100分及风险等级”；合规红线为“B的原始明细不得离开B的域，A不得反推B的个体记录”；成功判据为“评分AUC不低于0.78，单次评分延迟不超过800ms，全流程可审计”。

场景卡完成后，需要做一次“可行性三角校验”：业务目标是否在合规红线内可达？数据对象的分布形态是否支持所选技术路线？参与方的信任关系是否允许该路线成立？若三者中任一不成立，就要回到场景卡调整，而不是硬推技术方案。例如，若B与A之间不存在任何可信第三方，且B要求“连加密后的中间结果也不可被A观察”，那么安全多方计算中的某些协议可能不适用，需要改用同态加密或可信执行环境，并相应调整延迟指标。

三、功能需求与非功能需求的区分与定义

功能需求描述“系统必须做什么”，应逐条对应场景卡中的业务动作与合规动作。以联合风控场景为例，功能需求可包括：FR-01 支持纵向联邦特征对齐，且对齐过程不暴露双方ID交集以外的信息；FR-02 支持联邦逻辑回归与联邦XGBoost两种模型；FR-03 支持评分结果的授权查询，仅申请企业本人与A的授权审批人可查看明细；FR-04 支持同意书的版本管理与撤回，撤回后24小时内停止该主体的数据参与计算；FR-05 支持全链路审计日志，记录每次计算的参与方、数据范围、模型版本与时间戳。

非功能需求描述“系统必须做到什么程度”，通常以可测量的指标表达。性能方面：单次联合评分P95延迟≤800ms，批量评分1000条≤5分钟；可扩展性方面：支持参与方从3方扩展到10方而不改变接口协议；安全方面：传输层使用TLS 1.3，计算层支持半诚实模型下的安全保证，隐私预算ε在联邦训练中累计不超过8；可审计方面：审计日志不可篡改，保留期不少于3年；可移植方面：模型与协议描述采用标准化格式，支持跨平台迁移。非功能需求必须带阈值和测量条件，否则无法验收。

四、需求优先级与冲突消解

四类约束源之间经常冲突。例如业务目标要求“实时”，合规约束要求“单独同意”，而同意获取本身需要时间；数据对象要求“不出域”，参与方又要求“可审计”。此时应使用“约束—需求—冲突”三列对照表，逐条标注冲突类型与消解策略。常见消解策略有四种：一是调整业务目标（如将实时改为准实时，允许分钟级延迟）；二是增强技术手段（如引入可信执行环境满足不出域与可审计的双重要求）；三是缩小数据范围（如仅使用聚合后的纳税评级而非明细流水）；四是增加参与方角色（如引入独立审计方，解决互不信任问题）。

优先级排序建议采用“合规一票否决、业务价值排序、技术成本参考”的原则：任何违反合规红线的需求直接否决，不进入排序；在合规通过的需求中，按业务价值与实现成本之比排序；技术成本仅作为参考，不作为否决依据。这样可避免“技术可行但业务无价值”或“业务有价值但合规不可行”的需求混入开发队列。

五、需求规格说明书的交付要点

最终交付的需求规格说明书应包含：场景卡集合、功能需求清单（含编号、描述、验收判据、优先级）、非功能需求清单（含指标、阈值、测量方法）、约束源对照表、冲突消解记录、以及需求追溯矩阵（需求编号→场景卡→测试用例）。其中需求追溯矩阵是后续验证与审计的关键，它保证每一条需求都能追溯到具体场景，也能被具体测试用例覆盖。对于隐私计算与数据治理融合工程，建议额外增加“合规映射表”，将每条功能需求映射到具体的合规条款，便于监管审查时快速举证。

需求分析不是一次性活动。当参与方增减、数据对象范围变化或合规细则更新时，应触发需求复审，重新执行四约束源收敛与冲突消解。把这一复审机制写入工程流程，才能让融合工程在长期运行中保持合规与业务的双重有效性。