Java Web空气质量监测系统源码详解：从环境配置到二次开发
2026/9/24 18:27:56
【软考高级·系统分析师全链路通关实战】第 31 篇：需求管理——基线、变更控制与双向跟踪
本系列定位：面向有开发经验、从零备考软考高级「系统分析师」的工程师，以《系统分析师教程（第 2 版）》为主线，按「综合知识 → 案例分析 → 论文」三科组织，需求工程与 UML 建模深拆，60 篇带你从考试小白到三科同过。
本篇你将学到
- 需求基线：版本冻结的确切含义（冻结的是变更入口，不是文档本身）
- 变更控制流程五步：提出→评估影响→CCB 决策→实施→验证（案例高频流程题）
- 需求跟踪矩阵 RTM：正向/反向跟踪的含义与矩阵画法（案例可考画表）
- 需求变更的两大风险：范围蔓延与镀金
- 云诊通实战：监管新规引发处方需求变更的全过程——从变更请求到 RTM 更新与回归验证的完整闭环
学完本篇，需求工程五活动的最后一环（管理）补齐；案例题「补全变更控制流程 / 指出变更管理的问题 / 画跟踪矩阵」三类设问你都有标准答案结构。
考点热力表
|| 知识点 | 综合知识 | 案例分析 | 论文 |
|--------|:—😐:—😐:—😐
| 需求基线与版本冻结 | ★★★ | ★ | ★★ |
| 变更控制流程与 CCB | ★★★ | ★★★ | ★★★ |
| 需求跟踪矩阵 RTM | ★★ | ★★★ | ★★ |
| 范围蔓延与镀金 | ★★ | ★★ | ★ |
| 变更影响评估 | ★★ | ★★★ | ★★ |
一、需求基线：冻结的是什么
1.1 基线的定义
需求基线（baseline）是经过正式评审并达成一致的需求集合的快照版本，通常对应一版签字通过的 SRS（第 30 篇评审通过的时点即基线建立的时点）。基线一经建立，任何修改都必须通过变更控制流程，不允许再「顺手改一条」。
冻结的确切含义（易错点）：冻结的是变更入口与随意修改的自由，不是文档永恒不变——基线后需求仍然可以变，但只能走受控流程，且每次变化都有记录、有版本、有影响评估。把基线理解成「需求再也不改」是综合知识常见的错误选项。
1.2 为什么需要基线
没有基线的项目场景人人熟悉：开发按上周的说法做，测试按上上周的文档测，业主验收时说「我当初不是这个意思」。基线解决的就是多方引用同一版本的问题：设计、编码、测试、验收全部指向编号明确的基线版本（如 SRS v2.0），版本间差异通过变更记录可查。它同时是项目管理的范围基准——进度、成本、质量度量都以基线需求为分母（衔接第 20 篇范围管理）。
二、变更控制：五步流程与 CCB
2.1 五步流程（案例必背）
变更控制的标准流程：
- 提出变更请求：任何干系人可提，用统一模板写明变更内容、理由、提出人——口头变更不受理是纪律
- 评估影响：分析师评估该变更影响哪些需求条目（RTM 反向查询）、波及的设计与代码模块、测试用例、进度与成本增量、风险
- CCB 决策：变更控制委员会（Change Control Board）由业主方、开发方、关键干系人代表组成，依据影响评估做出批准/拒绝/延后决策
- 实施变更：按决策更新需求文档（升版本）、同步修改设计与代码、更新 RTM
- 验证变更：验证实施结果符合变更要求并回归相关功能，关闭变更单
2.2 CCB 的定位
CCB 不是一个人（也不是必须很庞大的委员会），而是一个决策机制：小项目可以是 3 人小组，大项目是分层的（项目级 CCB + 公司级 CCB，重大变更上浮）。关键在于变更决策权与执行权分离——分析师可以评估并建议，但批准权在 CCB；这防止了「谁嗓门大听谁的」。
2.3 范围蔓延与镀金
变更管理失守的两种典型病症（综合知识概念辨析高频）：
| 症状 | 定义 | 云诊通典型 |
|---|---|---|
| 范围蔓延（scope creep） | 未经正式变更评估的小改动不断累积，范围悄悄膨胀 | 「顺便加个」式的报表字段、页面小调整，零打碎敲吃掉工期 |
| 镀金（gold plating） | 开发方未经需求方要求，自行添加「更好」的功能 | 开发顺手给问诊界面加了自认为炫的动效，增加测试负担却无业务价值 |
两者共同的解药就是变更控制：任何范围变化无论多小都走流程，让累积效应在每次评估中显形。
三、需求跟踪矩阵 RTM
3.1 为什么跟踪
需求跟踪回答两个方向的问题：
- 正向跟踪：每条需求是否都有后续承接——对应哪些设计元素、哪些代码模块、哪些测试用例（防「需求没人做」）
- 反向跟踪：每个设计/代码/测试元素是否都能追溯到某条需求（防「没人要的东西被做出来」——镀金的检测手段）
没有 RTM 的项目，变更影响评估只能靠拍脑袋猜波及面；有 RTM，一次反向查询就能列出全部受影响条目——这正是变更控制第二步的执行基础。
3.2 矩阵画法（案例可考画表）
RTM 以需求编号为主键，向两侧延伸列：来源（原始需求条目/干系人）→ 需求编号 → 用例/设计元素 → 代码模块 → 测试用例 → 验证结果。云诊通问诊域节选：
| 原始条目 | 需求编号 | 用例 | 设计元素 | 代码模块 | 测试用例 | 状态 |
|---|---|---|---|---|---|---|
| ORD-031 | REQ-IVC-001 | UC-04 提交图文问诊 | 问诊服务资格校验组件 | ivc-qualify | TC-IVC-001~003 | 已验证 |
| ORD-034 | REQ-IVC-002 | UC-04/UC-06 | 留痕日志组件 | ivc-audit | TC-IVC-011~014 | 已验证 |
| ORD-011+052 | REQ-IVC-003 | UC-05 会话消息 | 消息通道+异步落痕 | ivc-msg | TC-IVC-021~025 | 已验证 |
| ORD-078 | REQ-RCP-006 | UC-09 开立处方 | 处方服务上报组件 | rcp-report | TC-RCP-031~036 | 变更中 |
画表要点：主键唯一、每行两端都有值（左空=无来源要追问，右空=无承接要立查）、状态列支撑变更期间的口径管理。案例题给一组需求与设计/测试元素让你「补充完整矩阵」时，按业务域语义配对并保持编号对应即可。
四、云诊通实战：监管新规引发的处方需求变更
4.1 变更背景
迭代开发第 7 个月（处方域已实现、正在联调），省监管平台发布新规：处方上报须增加「开方医师电子签名值」与「审方药师工号」两个字段，且上报时限从「当日」收紧为「开具后 30 分钟内」。新规直接影响基线中的 REQ-RCP-006（处方上报）与 REQ-INT-003（监管上报接口）。
4.2 五步流程实录
第一步·提出：监管联络员（第 27 篇合规清单的维护人）当天提交变更请求 CR-2025-014，附新规文件编号与生效日期，变更理由为「法规强制」——合规类变更的特权是优先级自动置顶，但不豁免流程。
第二步·评估：分析师用 RTM 反向查询：REQ-RCP-006 关联 rcp-report 代码模块与 6 个测试用例、REQ-INT-003 关联接口适配层。影响清单：①数据模型——上报报文增加 2 字段（处方表与报文映射各改 1 处）；②医师端——开方流程须接入电子签名组件（新购服务，约 2 万元/年，医生端新增一次签名操作）；③时限逻辑——上报触发器从批处理改为开方事件即时触发（与第 28 篇 T+0 结论一致，架构上已预留同步通道，改造量可控）；④测试——12 个既有用例更新 + 4 个新用例；⑤进度——合计约 9 人日，可用缓冲吸收，不需要顺延上线。
第三步·CCB 决策：项目级 CCB（业主医务处代表、牵头开发方、分析师）开会审议，结论批准，同时决议两条：电子签名组件采购走应急通道；30 分钟时限列为上线前必测项。
第四步·实施：SRS 相关条目更新并升版 v2.1（REQ-RCP-006、REQ-INT-003 修订 + 新增 REQ-RCP-014 电子签名要求），设计文档、代码、测试用例按影响清单同步修改，RTM 相应行更新为「变更中→已实施」。
第五步·验证：测试对 16 个用例执行回归（12 改 + 4 新），30 分钟时限实测 P95 为 4 分钟，验证通过，CR 关闭，v2.1 成为新基线。
4.3 复盘要点（论文素材）
这次变更的平稳落地依赖三个前置投资：合规清单（新规当天就被识别为变更而非上线前惊喜）、RTM（影响评估 2 小时完成而非 2 天猜）、架构预留（同步上报通道使时限收紧不必重构）。论「需求管理」的论文里，这段「前置投资在变更时刻兑现」的因果叙事远比罗列流程步骤有说服力。
真题风格自测题
1. 需求基线「版本冻结」的确切含义是（ ）。
A. 需求从此永不修改 B. 冻结随意修改的入口，后续变化须经变更控制 C. 文档加密存档 D. 禁止任何人阅读
2. 变更控制流程的正确顺序是（ ）。
A. 提出→评估影响→CCB 决策→实施→验证 B. 评估→提出→实施→验证→决策 C. 决策→提出→实施→评估→验证 D. 提出→实施→评估→决策→验证
3. CCB 的中文名称与职能是（ ）。
A. 配置控制板，管代码编译 B. 变更控制委员会，对变更做批准/拒绝/延后决策 C. 成本控制部，管预算 D. 客户服务部，受理投诉
4. 「每条需求都能找到对应的设计与测试用例」属于（ ）。
A. 反向跟踪 B. 正向跟踪 C. 基线审计 D. 镀金检测
5. 「每个代码模块都能追溯到某条需求」属于（ ），它也是检测镀金的手段。
A. 正向跟踪 B. 反向跟踪 C. 版本控制 D. 影响分析
6. 未经正式变更评估的小改动不断累积导致范围悄悄膨胀，称为（ ）。
A. 镀金 B. 范围蔓延 C. 需求漂移 D. 基线退化
7. 开发人员未经需求方要求自行添加「更好」的功能，称为（ ）。
A. 镀金 B. 范围蔓延 C. 重构 D. 优化
8. 变更影响评估通常不涉及（ ）。
A. 波及的需求条目与 RTM 反查 B. 设计与代码模块 C. 测试用例与进度成本增量 D. 竞争对手产品定价
9. 云诊通 CR-2025-014 中「上报时限收紧为 30 分钟」能低成本落地，关键前置是（ ）。
A. 临时加班 B. 架构已预留同步上报通道 C. 删除留痕需求 D. 拒绝变更
10. 关于变更请求的纪律，正确的是（ ）。
A. 口头变更可先做后补记录 B. 统一模板书面提出，口头变更不受理 C. 只允许业主提出 D. 测试人员无权提出
11. RTM 中某需求行「测试用例」列为空，说明（ ）。
A. 该需求已完成 B. 该需求缺少承接，需立即补测试设计或查是否遗漏 C. 该需求应删除 D. 无实际含义
12. 变更实施后 SRS 版本从 v2 升为 v2.1，此时基线状态是（ ）。
A. 原 v2 基线永久有效 B. 验证通过后 v2.1 成为新基线，变更记录可查 C. 项目无基线 D. 两版本同时有效由开发自选
13. 简答：为什么「再小的范围变化也要走变更流程」？请用范围蔓延的机制说明。
参考答案：1.B 2.A 3.B 4.B 5.B 6.B 7.A 8.D 9.B 10.B 11.B 12.B 13. 单个小改动的时间/成本影响看似可忽略，因此常被「顺手」接受而不做评估；但范围蔓延的机制正是无数个「可忽略」的累积——每个改动都绕过影响评估，其真实成本（代码+测试+文档+回归）从未进入项目账本，累积到发现时工期与预算已被侵蚀；强制所有变化走流程，是把每个改动的真实代价显式化，让累积效应在每次 CCB 评估时可见可控。
本篇小结
| 知识点 | 核心内容 |
|---|---|
| 需求基线 | 评审签字时点建立；冻结变更入口而非文档本身 |
| 变更五步 | 提出（书面模板）→评估影响（RTM 反查）→CCB 决策→实施（升版本）→验证（回归） |
| CCB | 变更决策机制，决策权与执行权分离；可分层 |
| RTM | 需求为主键双向延伸；正向防漏做、反向查镀金 |
| 两大病症 | 范围蔓延（小改动累积）、镀金（自加无需求功能），解药=全量走流程 |
| 云诊通实录 | 监管新规 CR：合规清单即时识别→RTM 两小时评估→CCB 批准→16 用例回归→v2.1 新基线 |
下篇预告
第 32 篇：面向对象分析 OOA——用例驱动的分析方法
需求工程收官于分析方法论：三大模型（用例/分析类/分析包）、从用例到边界/控制/实体三类分析类的推导方法、OOA 与结构化分析的选型论证，以及云诊通在线问诊用例的完整类推导。
如果本篇内容对你有帮助，欢迎点赞收藏！有任何疑问，欢迎在评论区交流。