4. 密码敏捷性需求工程

密码敏捷性不是等到算法被攻破才临时抱佛脚的能力，而是一项需要在系统设计早期就被“写进需求”的工程属性。需求工程的任务，就是把“将来要能快速换算法、换协议、换密钥体系”这一模糊愿望，翻译成可验证、可分配、可验收的规格条目。本节从合规、业务连续性和风险三个视角出发，说明如何提取敏捷性需求并形成规格说明。

一、三个视角各自“逼”出什么需求

合规视角关注的是“必须满足的外部约束”。例如等保、密评、行业监管或跨境数据规则，往往规定了算法清单、密钥长度、证书有效期上限、密码模块资质等。这类要求会直接转化为硬性需求：系统必须支持国密 SM2/SM3/SM4 与 RSA/AES 的并存或切换，必须记录密码使用审计日志，必须在证书到期前完成轮换。合规需求的特点是“不可协商”，但它的实现方式可以敏捷——例如把算法标识做成配置项而非硬编码。

业务连续性视角关注的是“切换过程中业务不能断”。密码变更如果导致交易中断、批量任务失败或用户无法登录，敏捷性就失去了意义。因此需要提取：双算法并行运行能力、灰度切换能力、会话不中断的密钥更新能力、回滚能力。典型指标包括切换窗口时长、允许的最大不可用时间、回滚点恢复时间。

风险视角关注的是“哪些密码资产最可能先出问题”。这需要先做密码资产盘点：哪些系统用了什么算法、密钥多长、证书何时到期、依赖哪些密码库。然后按“暴露面×失效影响×迁移难度”排序，把有限资源投向高风险项。风险视角产出的不是“全部都要敏捷”，而是“哪些必须先敏捷、敏捷到什么程度”。

二、从需求到规格：字段怎么定

规格说明不是把需求写成一句话就结束。为了让后续设计、开发和验收有据可依，每条敏捷性需求至少应包含以下字段：需求标识、来源（合规/业务/风险）、能力描述、验收标准、约束条件、优先级、验证方法、责任方、当前状态。下面给出一份可直接参考的规格条目示例，参数为教学假设值，实际项目需按自身资产和监管要求调整。

REQ-AGL-001
来源：合规（密评）+ 风险（高暴露面）
能力描述：核心支付网关须支持 SM2 与 RSA-2048 双算法并行，
          并可在不中断交易的前提下按租户灰度切换签名算法。
验收标准：
  1) 同一交易链路中，SM2 与 RSA 签名可同时被验证通过；
  2) 灰度切换期间，交易成功率不低于 99.95%；
  3) 切换后 5 分钟内可一键回滚至原算法。
约束条件：切换窗口 ≤ 30 分钟；密钥材料不得落盘明文。
优先级：P0
验证方法：双算法并行演练 + 回滚测试 + 审计日志抽查
责任方：密码平台组（实现）/ 支付应用组（接入）
当前状态：部分实现（RSA 已就绪，SM2 待接入）

这份规格的价值在于：它把“要敏捷”变成了“双算法并行、灰度切换、30 分钟窗口、5 分钟回滚、99.95% 成功率”。开发和测试拿到它，就知道该做什么、做到什么程度算通过。

三、需求优先级：不是所有系统都要一步到位

敏捷性改造需要成本，因此必须排序。一个实用的排序方法是按“失效紧迫性×业务影响×迁移难度”打分。例如：

• 高紧迫、高影响、低难度：优先做。如对外 TLS 证书的自动化轮换，通常有成熟工具支持。
• 高紧迫、高影响、高难度：必须立项攻坚。如核心交易链路的国密改造，涉及硬件密码模块和应用改造。
• 低紧迫、低影响：可延后，但要在资产台账中登记，避免“不知道它存在”。

排序结果应直接反映到规格说明的优先级字段中，并与项目排期对齐。没有优先级的敏捷性需求清单，最终往往变成一份无人执行的愿望清单。

四、把需求写成可验证的验收条件

敏捷性需求最容易犯的错误是写成“系统应具备密码敏捷性”这类无法验证的表述。正确的做法是把它拆成可观察、可测量的验收条件。例如“支持算法切换”应细化为：

1. 算法标识可从配置中心读取，修改后无需重新编译应用；
2. 切换过程中，新旧算法可并行运行至少一个完整业务周期；
3. 切换操作有审计记录，包含操作人、时间、原算法、目标算法、影响范围；
4. 回滚操作可在规定时间内完成，且回滚后业务指标恢复正常。

这些条件可以直接转化为测试用例。测试人员不需要理解密码学细节，也能按条目执行并给出通过/不通过结论。

五、需求基线的维护

密码敏捷性需求不是一次性的。算法威胁在变、监管要求在变、业务架构也在变，因此需求基线需要定期复审。建议至少每季度做一次“密码资产—需求—状态”三方对账：资产台账中新增的系统是否已纳入需求？已实现的需求是否仍然满足当前合规要求？风险排序是否因为新的漏洞披露而需要调整？对账结果更新到规格说明的状态字段中，形成可追踪的演进记录。

至此，敏捷性需求工程完成了从“三个视角提取”到“规格化表达”再到“优先级排序与验收定义”的闭环。下一阶段的设计与实现，都将以这份需求基线为输入。