【系统分析师】11.7 软件需求管理

📋 一、概述：需求生命周期的"持续护航"

软件需求管理是指在软件项目开发过程中，对需求的变更、跟踪、版本控制和状态维护进行系统性管理的一系列活动。它的目标是确保需求的完整性、一致性、可追溯性，并在需求发生变化时，能够有效评估影响、控制变更、维护基线，从而保证项目始终在可控范围内交付正确的产品。

如果把需求获取、分析、文档化比作"建房"，那么需求管理就是"房屋交付后的维护和改造管理"------确保房子在长期使用中，任何改动都有记录、有审批、不影响整体结构。

需求管理在需求工程中的位置：

```

需求获取\] → \[需求分析\] → \[需求文档化\] → \[需求确认和验证\] → \[需求管理

↑ │

└──────────────────── [变更驱动] ←──────────────────┘

```

需求管理的核心活动：

· 需求基线管理

· 需求变更控制

· 需求跟踪

· 需求状态维护

· 需求版本控制

· 需求沟通与报告

🏗️ 二、详细讲解：需求管理的六大核心活动

1️⃣ 需求基线管理

需求基线是指经过正式评审和批准的需求规格说明，作为后续开发工作的基础。它定义了项目范围的"冻结点"。

基线的建立：

· 在需求确认和验证通过后，将SRS文档正式纳入配置管理

· 建立基线标识（如V1.0），并通知所有干系人

· 基线后的任何变更必须通过正式变更控制流程

基线的类型：

基线类型时机作用

初始基线需求阶段结束作为设计和开发的基准

迭代基线每次迭代开始敏捷开发中定义本次迭代的范围

发布基线版本发布前作为验收和测试的基准

基线管理原则：

· 基线前自由，基线后受控：基线前可以灵活调整，基线后必须经过变更控制

· 基线标识唯一：每个基线应有唯一标识（如版本号、日期）

· 基线存储安全：基线文档应纳入配置库，受版本控制

📌 速记口诀："基线是冻结点，评审批准后建立；基线前灵活，基线后受控"。

2️⃣ 需求变更控制

需求变更是不可避免的。有效的变更控制是需求管理的核心。

变更的来源：

· 业务环境变化（政策、市场、竞争）

· 用户需求深化或调整

· 技术限制或突破

· 项目范围蔓延

· 错误或遗漏的修正

变更控制流程：

```

变更请求\] → \[变更分析\] → \[变更决策\] → \[变更实施\] → \[变更验证\] → \[变更关闭

↑ │

└────────────────── [通知干系人] ←──────────────────────┘

```

步骤活动描述责任角色

变更请求提交书面变更申请，描述变更内容、理由、紧急程度任何干系人

变更分析评估变更对范围、进度、成本、质量的影响，提出建议 CCB、系统分析师

变更决策决策是否批准变更 CCB

变更实施如果批准，更新需求文档、设计、代码等开发团队

变更验证验证变更已正确实施，需求已满足测试团队、系统分析师

变更关闭更新需求状态，通知干系人，归档记录项目经理

变更控制委员会（CCB）：

· 由项目经理、系统分析师、客户代表、技术负责人等组成

· 负责评估变更影响，做出批准/拒绝决策

· 定期召开会议，处理积压变更

变更影响分析要点：

· 范围影响：变更涉及哪些需求模块？是否引发连锁变更？

· 进度影响：变更需要多少工作量？是否影响关键路径？

· 成本影响：变更带来多少额外成本？

· 质量影响：变更是否引入新风险？是否需要额外测试？

· 技术影响：变更技术可行性如何？是否与现有架构冲突？

变更控制的原则：

· 任何变更必须书面化，避免口头变更

· 变更必须经过评估，不能随意插入

· 变更影响透明化，让所有干系人了解后果

· 变更实施后更新所有相关文档，保持一致性

📌 速口口诀："变更请求书面提，CCB评估做决策；影响范围进度成本，批准实施再验证"。

3️⃣ 需求跟踪

需求跟踪是指建立并维护需求与后续开发制品（设计、代码、测试用例）之间的关联关系，实现需求的双向追溯。

需求跟踪矩阵是需求跟踪的核心工具。

业务需求用户需求系统需求设计元素代码模块测试用例

BR-001 UR-001 FR-001 模块A 类A.java TC-001

UR-002 FR-002 模块B 类B.java TC-002

BR-002 UR-003 NFR-001 架构设计 - 性能测试

... ... ... ... ... ...

双向跟踪的含义：

· 正向跟踪：从需求出发，跟踪到设计、代码、测试用例，确保所有需求都被实现和验证

· 反向跟踪：从设计、代码、测试用例出发，回溯到需求，确保没有"镀金"（无需求对应的实现）

需求跟踪的价值：

· 影响分析：需求变更时，快速定位受影响的设计、代码、测试

· 完整性验证：检查是否有需求未被实现

· 合规性证明：向客户或审计方证明所有需求都被覆盖

· 回归测试范围确定：变更后确定需要重新测试的范围

维护跟踪矩阵的注意事项：

· 跟踪关系要及时更新，避免脱节

· 跟踪粒度要适中，太细维护成本高，太粗失去价值

· 可使用工具（如DOORS、Jira、Excel）辅助管理

📌 速记口诀："跟踪矩阵建关联，正向确保都实现，反向杜绝镀金件，变更影响秒发现"。

4️⃣ 需求状态维护

在整个项目生命周期中，每个需求都经历一系列状态。状态维护帮助团队实时了解需求的进展情况。

典型的需求状态：

状态含义阶段

已提议需求被提出，但尚未分析获取

已分析需求已完成分析，进入文档化分析

已批准需求通过确认和验证，纳入基线确认/验证

已设计需求已完成设计设计

已实现需求已完成编码编码

已测试需求已通过测试验证测试

已交付需求包含在发布版本中发布

已拒绝需求被否决任何阶段

已变更需求发生变更，需重新处理变更管理

状态维护的作用：

· 进度可视：实时了解需求完成情况

· 风险预警：长时间停留在某状态的需求可能有问题

· 决策支持：为版本规划提供依据

状态迁移图：可以用状态图描述需求状态的合法转换路径。

📌 速记口诀："提分准设实测验，交付拒绝变更添；状态流转可视管，进度风险一目然"。

5️⃣ 需求版本控制

需求文档和需求项本身需要像代码一样进行版本控制。

版本控制的对象：

· 需求规格说明书（SRS）整体

· 每个需求项（特别是独立管理的需求库）

版本控制的原则：

· 每次变更都产生新版本，保留历史记录

· 版本号规则统一，如V1.0、V1.1、V2.0

· 基线版本固化，不可修改，只能新建后续版本

· 版本差异可追溯，清楚了解每次变更的内容

版本控制工具：Git、SVN、配置管理工具、需求管理工具（如Jira、Polarion）。

📌 速记口诀："版本控制像代码，每次变更新版本；基线固化不可改，历史记录要留存"。

6️⃣ 需求沟通与报告

需求管理的成果需要及时、有效地传递给所有干系人。

沟通内容：

· 需求基线：当前批准的需求集合

· 变更情况：近期变更汇总、变更状态

· 需求状态：各需求的完成进度

· 跟踪报告：需求实现情况、覆盖情况

· 风险预警：需求相关的风险

沟通形式：

· 定期会议：变更控制会议、状态同步会

· 报告：需求状态报告、变更汇总报告

· 看板：需求看板、燃尽图

· 邮件通知：变更结果通知、基线发布通知

沟通原则：

· 及时性：变更一旦决策，立即通知相关方

· 针对性：不同角色关注不同信息

· 可理解性：用业务语言沟通，避免技术术语

📌 速记口诀："基线变更和状态，跟踪风险要通报；会议报告看板邮件，及时针对可理解"。

📝 三、重点总结与速记方法

✅ 核心重点

需求管理的定义：在项目生命周期中，对需求的变更、跟踪、版本控制、状态维护进行系统性管理。
六大核心活动：基线管理、变更控制、需求跟踪、状态维护、版本控制、沟通报告。
基线管理：基线是冻结点，基线前自由，基线后受控。
变更控制流程：请求→分析→决策→实施→验证→关闭，CCB是决策机构。
需求跟踪矩阵：实现双向追溯，用于影响分析、完整性验证。
需求状态：提议→分析→批准→设计→实现→测试→交付，以及变更、拒绝。
版本控制：每个变更产生新版本，基线固化。
沟通报告：及时、针对、可理解。

⚡ 速记口诀

1️⃣ 六大活动"六字诀"

"基、变、跟、状、版、通"（基线、变更、跟踪、状态、版本、沟通）

2️⃣ 变更控制"五步走"口诀

"请求分析批实验，变更五步走闭环"

3️⃣ 需求跟踪"双向"口诀

"正向跟踪保实现，反向追溯证无余"

4️⃣ 需求状态"九态"口诀

"提分准设实测验，交付拒绝变更管"

5️⃣ 版本控制"三要"口诀

"变更要版本，基线要固化，历史要留存"

6️⃣ 需求管理"三问"自查

"基线建了吗？变更控了吗？跟踪做了吗？"

7️⃣ 一句话总纲

软件需求管理 = （基线 + 变更 + 跟踪 + 状态 + 版本 + 沟通），是需求生命周期的"持续护航"，确保需求在变化中依然可控、可追、可交付。