需求的定义
• 解决用户问题或达到用户目标所需的条件或能力。
• 为遵循合同、标准、规格或其他要求的正式文档，系统必须满足或拥有的条件或能力。
• 按文档化表现（1）和（2）中的条件或能力，就是SRS强调做什么（What）而不是如何做（How）
案例分析
小学生阿东在家庭晚宴上，对他的母亲、奶奶、姑姑说：他的裤子左
腿长了2厘米，他的姑姑在晚饭后把阿东的裤子左腿剪短2厘米，他
的母亲在睡前也把阿东的裤子左腿剪短2厘米，他的奶奶在第二天的
早上把阿东的裤子右裤脚续了两厘米。
第二天，阿东穿着这条裤子上学了
案例启示
• 软件需求要基线化，要管理起来，否则需求的实现是盲目的，不受控的
• 软件需求的实现要跟踪、要记录、要标识
• 要测量软件需求
• 要验证软件需求
软件需求工程介绍
软件需求变更流程
软件需求跟踪介绍
软件需求跟踪流程介绍
需求跟踪矩阵
• 确保需求被设计
• 确保需求被实现
• 确保需求被验证
• 了解需求变更影响的范围
软件需求跟踪规程
• PM负责需求跟踪。需求跟踪的目的是确保所有的分配需求均被实现，被验证，后续的工作产品与分配需求一致。
• 需求跟踪过程的主要活动是对RTM的维护，通过建立如下跟踪关系，达到需求跟踪的目的：
– 分配给项目的需求－项目的软件需求规格－概要设计－详细设计－代码
– (开发需求跟踪矩阵)
– 项目的软件需求规格－系统测试项－系统测试子项－系统测试用例
– （系统测试需求跟踪矩阵）
– 概要设计－集成测试项－集成测试子项－集成测试用例
– （集成测试需求跟踪矩阵）
– 详细设计－单元测试项－单元测试子项－单元测试用例
– （单元测试需求跟踪矩阵）
• 需求跟踪表介绍
软件需求跟踪规程
• RTM初次准备的时间是在SRS review之前，PM必须维护分配需求和软件需求清单。 完成RTM中分配需求与SRS的 跟踪关系, 并确定全套跟踪编号规则（包括需求、设计、测试用例、代码等）。
• 初始的RTM以验证SRS与分配需求一致。在SRS review后，RTM和SRS一起进行基线化必须作为SRS review的输入。
• 在后续的开发过程中，当完成相应的工作产品（ 系统测试、集成测试、单元测试的计划、方案、用例，HLD、LLD，CODE ）后，项目经理要确保RTM在工作产品review前得到了及时更新，完成前面所说的四种跟踪关系；更新后的RTM必须作为工作产品review 的输入以验证工作产品与分配需求一致。在工作产品review后，RTM和相应的配置项一起进行基线化。
• 在完成测试执行之后，PM要确保测试用例及其执行状态的跟踪。
• 当相应的工作产品发生变更时，如果涉及到需求跟踪关系的变化，需要及时更新RTM。
需求跟踪的输出
• RTM需求跟踪表
需求变更引起的需求跟踪
（1）需求分析阶段
需求分析----系统测试计划
（2）概要设计阶段
需求分析----系统测试计划-系统测试方案
（3）详细设计阶段
需求分析----系统测试计划----系统测试方案----系统测试用例
（4）编码及后期测试执行阶段
需求分析----系统测试计划----系统测试方案----系统测试用例
软件需求管理工具
ALM实战 禅道 等
