AI总结
笔记总结与重点分析
笔记总结
本笔记系统阐述了软件需求管理的核心内容，重点包含需求基线、需求跟踪和需求变更控制三大模块。其中需求基线明确定义了经批准的稳定需求集合及其包含的要素；需求跟踪解释了前向/后向跟踪机制及其对项目各角色的价值；变更控制则详细说明了变更流程、CCB组成及应对策略。实践调查部分揭示了行业现状，指出变更处理、跟踪依赖关系及工具应用等方面存在的挑战。
重点/易考点分析 (名词解释)
什么是需求基线？
已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制过程才能修改它。被明确和固定下来的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求的集合。
变更控制委员会（CCB）由哪些部门的人员组成？
项目或程序管理部门；产品管理或者需求分析部门；开发部门；测试或者质量保障部门；市场或客户代表；编写用户文档的部门；技术支持或帮助部门；配置管理部门。
需求跟踪包括哪些类型？
前向跟踪是指被定义到软件需求规格说明文档之前的需求演化过程，包含：向前跟踪到需求（说明涉众需要和目标产生的软件需求）、从需求向后回溯（说明软件需求来源）。后向跟踪是指被定义到软件需求规格说明文档之后的需求演化过程，包含：从需求向前跟踪（说明需求如何被后续开发物件支持）、回溯到需求的跟踪（说明开发物件产生原因）。
需求基线包含哪些核心内容？
标识符（ID）、当前版本号（Version）、源头（Source）、理由（Rational）、优先级（Priority）、状态（Status）、成本/工作量/风险/可变性（Cost/Effort/Risk/Volatility），以及需求创建日期、相关人员、子系统、版本号、验收标准等补充信息。
什么是需求交互作用管理？
用于发现、管理和部署（disposition）需求之间关键联系的活动。其特殊性在于需求依赖关系难以发现、建立和维护，大多数需求在复杂机制中互相影响。
需求管理
需求管理概述
意图
- 需求的影响力
- 整个后续的产品生命周期 VS 需求开发阶段
- 需求规格说明文档
- 后续的开发工作都应该以软件需求规格说明文档的内容为标准和目标来进行
- 需求管理
- 在需求开发之后的产品生命周期当中保证需求作用的有效发挥
作用
- 增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解
- 增强了项目涉众对需求（尤其是复杂需求）的掌握。
- 增进了项目涉众之间的交流
- 减少了可能的误解和交流偏差。
- 减少了工作量的浪费，提高了生产力
- 需求管理能够更加有效的处理需求的变更
- 准确反映项目的状态，帮助进行更好的项目决策
- 需求跟踪信息能够更加准确的反映项目的进展情况
- 改变项目文化，使得需求的作用得到重视和有效发挥
- 使得项目涉众认识到需求在项目工作中的重要性
任务
- 交流涉众需要什么；
- 将需求应用、实施到解决方案；
- 驱动设计和实现工作；
- 控制变更；
- 将需求分配到子系统；
- 测试和验证最终产品；
- 控制迭代式开发中的变化；
- 辅助项目管理
活动
维护需求基线
交流涉众需要什么 驱动设计和实现工作 测试和验证最终产品 辅助项目管理
实现需求跟踪
将需求应用到解决方案 将需求分配到子系统
控制变更
控制变更 控制迭代式开发中的变化
需求基线
已经通过正式评审和批准的规格说明或产品，它可以作为进一步开发的基础，并且只有通过正式的变更控制过程才能修改它 定义：是被明确和固定下来的需求集合，是项目团队需要在某一特定产品版本中实现的特征和需求的集合
需求基线的内容
- 标识符（ID），为后续的项目工作提供一个共同的交流参照。
- 当前版本号（Version），保证项目的各项工作都建立在最新的一致需求基础之上。
- 源头（Source），在需要进一步深入理解或者改变需求时，可以回溯到需求的源头。
- 理由（Rational），提供需求产生的背景知识。
- 优先级（Priority），后续的项目工作可以参照优先级进行安排和调度。
- 状态（Status），交流和具体需求相关的项目工作状况。
- 成本、工作量、风险、可变性（Cost、Effort、Risk、Volatility），为需求的设 计和实现提供参考信息，驱动设计和实现工作。
- 需求创建的日期；
- 和需求相关的项目工作人员，包括需求的作者、设计者、实现者、测试者等；
- 需求涉及的子系统；
- 需求涉及的产品版本号；
- 需求的验收和验证标准；
维护活动：配置管理
维护活动：状态维护
需求跟踪
- 避免在开发过程或者演化过程中与需求基线不一致或者偏离的风险
- 前向跟踪是指被定义到软件需求规格说明文档之前的需求演化过程
- 向前跟踪到需求：说明涉众的需要和目标产生了哪些软件需求
- 从需求向后回溯：说明软件需求来源于哪些涉众的需要和目标
- 后向跟踪是指被定义到软件需求规格说明文档之后的需求演化过程
- 从需求向前跟踪：说明软件需求是如何被后续的开发物件支持和实现的
- 回溯到需求的跟踪：说明各种系统开发的物件是因为什么原因（软件需求）被开发出来的
作用
- 需求的后向跟踪可以帮助项目管理者：
- 评估需求变更的影响；
- 尽早发现需求之间的冲突，避免未预料的产品延期；
- 可以收集没有被实现的需求，并估算这些需求需要的工作量；
- 发现可以复用的已有组件，从而降低新系统开发的时间和精力；
- 明确需求的实现进度，跟踪项目的状态。
- 需求的后向跟踪可以帮助客户和用户：
- 评价针对用户需求的产品的质量；
- 可以确认成本上没有浪费；
- 确认验收测试的有效性；
- 确信开发者的关注点始终保持在需求的实现上。
- 需求跟踪中针对具体需求的设计方案选择、设计假设条件以及设计结果等信息可以帮助设计人员：
- 验证设计方案正确的满足了需求；
- 评估需求变更对设计的影响；
- 在设计完成很久之后仍然可以理解设计的原始思路；
- 评估技术变化带来的影响；
- 实现系统组件的复用；
- 需求跟踪信息还可以帮助维护人员：
- 评估某一个需求变化时对其他需求的影响；
- 评估需求变化时对实现的影响；
- 评估未变化需求对实现变更的允许度。
内容
- 最低层次：低端用户
- 捕获各个系统组件之间的关系
- 更高层次：高端用户
- 捕获组件之间的联系
- 捕捉各个组件的工作背景
- 例如实现的理由、实现方案的选择、实现技术的假设、决策依据、变化历程等等
- 最高层次：高端用户
- 捕获更高层次信息
- 捕获项目的组织过程
- 例如负责人、时间安排、资源消耗、最终成果等
实现方法
- 矩阵、实体关系模型和交叉引用
需求依赖
- 大多数的需求并不是完全独立的，它们在一种复杂的机制中互相影响
- 需求依赖联系的特殊性并不在于它的重要性，而在于它是难以发现、建立和维护的
- 需求交互作用管理
- 用于发现、管理和部署（disposition）需求之间关键联系的活动
需求变更控制
- 需求的变化是正当和不可避免的
- 问题发生了改变
- 环境发生了改变
- 需求基线存在缺陷
- 用户变动
- 用户对软件的认识变化
- 相关产品的出现
过程
- 以可控、一致的方式进行需求基线中需求的变更处理，包括对变化的评估、协调、批准或拒绝、实现和验证
变更控制委员会
- 变更控制委员会（CCB）
- 评价需求的变更，做出批准或者拒绝变化的确定，并确保已批准变化的实现
- 变更控制委员会可能由来自下列部门的人员组成
- 项目或程序管理部门；
- 产品管理或者需求分析部门；
- 开发部门；
- 测试或者质量保障部门；
- 市场或客户代表；
- 编写用户文档的部门；
- 技术支持或帮助部门；
- 配置管理部门。
注意事项
- 认识到变更的必要性，并为之制定计划
- 定义明确的变更控制过程，建立变更控制的有效渠道
- 所有提交的需求变更请求都要进行仔细的评估
- 是否进行变更的决定应该由变更控制委员会统一做出
- 必须对变更的实现结果进行验证
- 需求的变化情况要及时的通知到所有会受到影响的项目涉众
- 维护需求基线，审计变更记录
- 管理范围蔓延
- 根据业务目标、产品前景和项目范围，评估每一项提议的新增需求和特性
- 灵活应对变更请求
- 推迟产品的交付时间。
- 要求增派人手：在有限的情况下有效
- 要求员工加班工作：只能适度的使用。
- 推迟或者去除尚未实现的优先级较低的需求
- 容许产品质量的降低：尽量不使用
- 使用辅助工具
- 工具应该具有以下几个特性，以支持需求变更
- 可用定义变更请求中的数据项。
- 可用辅助项目涉众完成变更控制过程中的协作。
- 可以帮助维护需求基线，审计变更记录。
- 能够将变更情况及时的通知到相关人员。
- 可以生成标准的和定制的报告和图表。
- 工具应该具有以下几个特性，以支持需求变更
需求管理的实践调查
- 有效处理变更非常重要
- 新增（Added）需求影响最大
- 缺陷修复最为频繁
- 范围蔓延常见
- 需求可变性很高
- 变更控制还需要继续完善
需求跟踪
- 重视和关注了对后向跟踪联系的处理
- 忽视了对前向跟踪联系的处理
- 最低层次需求跟踪策略存在广泛
- 高端用户的需求跟踪实现仍需努力
- 需求之间的依赖关系困难和复杂
- 只有大概20％的需求是完全独立的
- 20％左右的需求产生了所有依赖关系的75％。
需求管理工具
- 非常需要需求管理工具
- 通用的文本处理器（Word Processor）和电子表格（Spreadsheet）使用最为广泛
- 部分组织自己开发了专用需求管理工具
- 很少有组织使用专用的商业需求管理工具
- 无法和软件的开发过程以及其他辅助工具进行有效的集成