软件变化时保持需求可追溯

描述可以验证的行为

“创建现代化客户导出”没有解决重要决策。它没有定义用户、记录、字段或失败行为。智能体必须询问，或自行假设。未记录的假设以后很难审查。

使用一个边界清楚的虚构要求：通过身份验证的经理可以导出自己组织的活跃客户数据。导出包含客户 ID 和显示名称，不包含联系方式和已归档记录。没有经理角色的用户不能获得导出结果。

仍需决定格式、数据量、响应时间和失败处理。明确标记未知事项。有用的规范会显露不确定性，而不是用自信文字将其掩盖。

区分要求与实现选择

用户需要的是格式可用、且允许访问的一组记录。数据库查询、库和端点结构属于实现选择。将这些选择与要求关联，但不要把每个当前选择都当作永久业务需要。

为重要决策记录背景、备选方案和原因。例如，同步导出可能适合少量数据。更大数据量可能需要后台任务，以及单独的下载授权检查。

在可行时保持要求稳定，同时为改变的决定记录版本。这有助于审查者区分实现变化与对用户承诺的变化。

建立简短证据链

使用在审查中容易理解的标识符。本例可以用 EXPORT-01 标识组织边界。该名称仅作示例，不是规定的编号体系。

证据链必须指向真实证据。测试名称中包含要求 ID，不能证明断言检查了该要求。检查测试，以及它实际覆盖的生产代码路径。

NIST 的 SSDF 为安全开发中的要求和验证提供背景。使用可追溯性，让这些活动可以检查，而不是为了文档本身而写文档。阅读框架。

审查假设变化带来的影响

假设业务现在需要包含已归档客户。这不只是查询标志的变化。检查保留规则、授权、预期数据量、用户说明，以及现有报表的含义。

标记需要复核的文档和检查。保留之前的决定，让运维人员能够解释旧版本。不要悄悄重写历史，仿佛最新设计从一开始就是唯一选择。

智能体可以帮助查找引用并提出更新。相关负责人必须解决要求冲突，并接受改变后的行为。匹配文件列表只是起点，不是完整影响评估。

让记录足够简明，便于使用

记录影响实现、验证和运维的决定。避免在多份互不关联的文档中重复同一要求。优先链接到一份持续维护的来源。

接受修改前，检查审查者能否从其目的追踪到实际证据。运行服务前，检查服务负责人能否找到相关边界和恢复决定。这些都是检验可追溯性是否有用的实际方法。