Day24-03｜5.2.3 需求追踪：让每项需求都能找到设计、实现、验证和责任

本文对应《系统架构设计师教程（第2版）》第5章“软件工程基础知识”5.2.3“需求追踪”。需求追踪是建立和维护需求与业务目标、架构决策、设计元素、代码、测试用例、缺陷、发布版本和运行指标之间关联的活动。它使团队能够回答“需求为什么存在、由什么实现、如何验证、变更影响什么、是否已经交付”，是高级系统架构设计中控制复杂度和变更风险的重要手段。

一、学习目标与考试定位

完成本节后，应能够解释需求追踪的目的、对象和基本关系；理解前向追踪、后向追踪和双向追踪；能够设计需求追踪矩阵和追踪标识；能够利用追踪关系进行变更影响分析、测试覆盖分析、验收和审计；能够识别“孤儿需求”“无来源功能”“无测试需求”和“过期链接”等问题；能够在案例题和论文中说明追踪如何支撑架构治理和质量保证。

考试题目常描述需求变更后遗漏测试、开发人员实现了未批准功能、客户质疑某功能来源、架构文档与代码不一致，要求找出原因并提出办法。高分答案不能只写“建立需求跟踪表”，还要说明追踪粒度、责任人、维护时机、工具集成、双向验证和异常处理。

二、什么是需求追踪

需求追踪是对需求及其相关产物之间关系进行识别、记录、维护和查询的过程。相关产物包括业务目标、利益相关者需求、系统需求、质量属性、约束、用例、架构决策、模块、接口、数据库、代码提交、测试用例、缺陷、部署版本、用户手册和监控指标。

追踪不是简单复制需求文本，而是记录“哪个对象实现或验证哪个需求”“对象发生变化会影响哪些需求”。追踪关系可以是一对一、一对多、多对一或多对多。一个安全需求可能由身份、授权、审计和密钥多个组件共同实现；一个模块可能支撑多个业务需求；一个测试用例也可能验证多个相关条件。

需求追踪可以概括为：

目标 → 需求 → 架构 → 设计 → 实现 → 测试 → 发布 → 运行证据

三、前向、后向和双向追踪

前向追踪从需求出发，检查每项需求是否有设计、实现和测试，主要用于验证需求覆盖和交付完整性。后向追踪从设计、代码或测试出发，检查其是否有合法需求来源，主要用于发现未经批准的功能、范围蔓延和无依据实现。双向追踪同时建立两个方向，是更完整的治理方式。

例如需求 R-102“支持订单取消”，前向追踪应找到订单状态机、取消接口、权限规则、数据库变更、测试用例和发布版本；后向追踪检查某个“批量取消脚本”是否有对应需求和审批。只有双向追踪才能同时避免漏实现和乱实现。

四、为什么架构师需要需求追踪

架构设计处理的是跨模块、跨团队和跨生命周期的复杂关系。没有追踪，质量属性容易停留在口号，架构决策无法解释，变更影响只能依赖个人记忆，测试无法证明关键场景覆盖，系统上线后也无法判断某项运行指标对应哪个业务目标。

需求追踪可以支撑五类工作。第一，范围管理，确认做了什么、没做什么以及为什么；第二，变更影响分析，快速找到受影响的模块、接口、数据、测试和文档；第三，质量保证，检查关键需求是否有验证证据；第四，合规和审计，证明要求被落实和复核；第五，架构演化，判断替换组件、拆分服务或迁移数据会影响哪些业务能力。

五、追踪关系的设计粒度

追踪过粗，无法定位影响；追踪过细，维护成本高且容易失真。粒度应与风险、变化频率、交付规模和合规要求匹配。核心业务、架构驱动需求、安全、可靠性、数据迁移和外部接口通常需要较细粒度；低风险界面细节可以通过故事、验收条件和测试覆盖追踪，不必为每个像素建立独立关系。

每个可追踪对象应有稳定标识，例如 REQ-001、ARCH-003、API-017、TC-045 和 DEF-208。标识不要包含容易变化的标题或位置，标题修改不应导致关系全部失效。需求正文、状态、版本、优先级、来源、责任人、验收标准和关联对象应由工具管理，避免靠复制粘贴维持多个“最终版”。

六、追踪矩阵与覆盖分析

需求追踪矩阵是展示需求与其他产物关联关系的表格或工具视图。基础矩阵可以列出需求编号、业务目标、设计模块、代码提交、测试用例、缺陷和发布版本；高级矩阵还可以加入风险、质量场景、数据分类、权限、监控指标和恢复目标。

矩阵可以发现三类异常。第一，需求没有设计、代码或测试，说明可能漏实现；第二，代码或测试没有需求来源，说明可能有范围蔓延、重复或临时实现；第三，关键需求关联多个未关闭缺陷或没有有效测试结果，说明交付风险高。覆盖率指标有帮助，但“每项需求都有一个测试用例”不等于测试充分，还要看场景、边界、异常、权限和质量属性。

七、需求追踪与架构驱动需求

架构驱动需求通常跨越多个产物，追踪尤其重要。以“核心交易在单节点故障时自动恢复”为例，需求需要关联可用性场景、冗余架构、健康检查、故障转移、数据复制、部署配置、演练脚本和恢复测试；以“敏感数据只能由授权角色访问”为例，需求需要关联数据分级、身份认证、授权策略、数据库权限、审计日志、脱敏规则和安全测试。

架构师应在需求分析阶段为质量属性和约束建立专门标识，不要把它们埋在长段落中。架构评审时检查每项架构驱动需求是否有决策和验证证据；架构变更时通过追踪关系定位受影响需求和测试；运行阶段将监控指标回连到质量目标，形成设计到运行的闭环。

八、需求追踪与变更影响分析

发生变更时，先定位变更的需求编号和版本，再沿追踪关系查询受影响的业务流程、质量属性、架构决策、模块、接口、数据库、测试、文档、部署和培训。对于多团队系统，还要查外部系统、合同、数据共享和运维预案。影响分析结果应记录哪些对象必须修改、哪些无需修改以及判断理由。

追踪关系不是自动等于影响关系。一个需求与模块关联，并不代表任何修改都必须影响模块全部代码；还需要结合变更内容、调用方向、数据依赖和配置。工具可以提供候选影响集合，最终判断仍需架构、开发、测试和业务共同确认。

九、工具和流程落地

追踪可以由需求管理、项目管理、版本控制、持续集成、测试管理、缺陷管理和配置管理工具共同实现。需求提交代码时引用需求编号，合并请求关联变更，构建产物保留提交和版本信息，测试结果关联需求和环境，发布记录包含需求范围和回滚版本。

自动化检查可以阻止没有需求编号的高风险提交，检查需求是否有验收标准、关键需求是否有测试、发布是否包含未关闭高危缺陷、接口变更是否通知消费者。自动化不能替代人工治理，链接可能存在但内容已过期，必须通过评审、抽查和运行反馈维护质量。

追踪过程的责任要明确。产品或业务维护需求来源和验收；架构师维护架构驱动需求、决策和影响关系；开发维护实现关联；测试维护验证关系和结果；配置管理维护版本与基线；项目管理关注范围和变更；运维补充部署、监控和事故关联。

十、案例分析：需求追踪缺失导致漏测

某保险系统新增“按地区计算差异化费率”。开发团队修改了费率服务和数据库字段，但没有通知报表、批量导入和对账团队。上线后，在线报价正确，批量出单仍使用旧规则，财务对账出现差异。项目组发现原需求文档中没有明确数据来源、受影响接口和验收场景。

问题在于需求没有拆成可追踪的业务规则和质量条件，架构、数据、接口和测试之间没有建立关联；团队依赖口头沟通，后向追踪也无法识别报表和批量流程是同一需求的消费者。

改进时先建立需求编号和完整场景，明确地区、时间、生效版本、历史保单和异常规则；再将需求关联费率领域模型、计算服务、批量接口、报表、对账、数据库迁移和部署配置；为在线、批量、历史重算、权限、审计和对账分别建立测试；发布前检查所有关联对象的版本和结果，灰度期间对新旧结果进行比对；上线后监控费率差异、对账差异和失败率，并将事故关联回需求和架构决策。

十一、常见误区

第一，追踪矩阵只在验收前临时填写。这样容易遗漏且无法反映真实过程，应从需求建立时持续维护。第二，追踪就是一张 Excel 表。小项目可以使用表格，但复杂系统需要与版本、测试、变更和发布工具集成。第三，有链接就代表追踪有效。还要检查对象版本、内容一致性和验证结果。第四，只做需求到测试的追踪。架构师还要覆盖业务、架构、实现、部署和运行。第五，追踪越细越好。应按风险和变化程度选择合理粒度。

十二、课后练习

练习一：单项选择

从代码和测试反向检查是否存在合法需求来源，属于（ ）。

A. 前向追踪；B. 后向追踪；C. 性能测试；D. 配置打包。

答案：B。后向追踪从实现或验证产物回到需求，能够发现无依据实现和范围蔓延。

练习二：简答题

请说明需求追踪如何帮助进行变更影响分析。

参考答案：通过需求编号定位变更对象和版本，沿追踪关系查询相关业务流程、质量属性、架构决策、设计模块、接口、数据、代码、测试、文档、部署和外部依赖；由相关责任人确认实际影响、工作量、风险、回滚和验收范围；依据结果更新计划、基线和追踪关系，实施后通过回归测试和发布验证关闭变更。

练习三：案例分析

某项目测试覆盖率达到 100%，但上线后仍发生核心权限越权。请分析为什么追踪和覆盖率可能仍然失效。

参考答案：测试覆盖率可能只表示每项功能有测试，不表示覆盖了角色、租户、边界、异常和权限组合；权限需求可能没有作为独立、可追踪的架构驱动需求；测试环境与生产配置、账号和数据不一致；代码、测试和需求链接存在但版本过期。应拆分身份、授权、数据范围和审计需求，关联角色矩阵、权限组件、接口、数据库策略和安全测试；覆盖正常、越权、跨租户、失效凭据和管理员场景；在生产前核对配置和权限基线，保留测试证据，并将安全事件回溯到需求和架构改进。

十三、论文素材

论文可写：为了控制系统复杂度和变更风险，我建立了从业务目标到运行验证的双向需求追踪。每项需求具有稳定编号、来源、优先级和验收标准，并分别关联架构决策、模块接口、数据模型、代码提交、测试用例、缺陷和发布版本。发生变更时，团队沿追踪关系分析对业务、质量属性、数据库、外部接口、测试和运维的影响；通过持续集成、测试管理和发布记录自动校验关键需求覆盖，结合架构评审和运行指标维护追踪有效性。这样既减少漏实现和漏测，也为审计、回滚和架构演化提供了证据。

十四、今日复盘

需求追踪的价值是让需求、架构、设计、实现、测试、发布和运行形成可查询的关系。前向追踪检查需求是否被实现和验证，后向追踪检查代码和测试是否有合法来源，双向追踪更完整；追踪应服务于变更影响、质量覆盖、审计和架构演化，并按风险选择合理粒度。下一阶段进入 5.3.1 结构化方法。