37
需求跟踪可以为管理者带来什么？
• 对项目或产品更明确的整体把握 • 流程化处理需求问题，简化管理 • 很容易的了解当前每个需求问题的进展， 不再需要去询问和催办 • 很容易的了解每个成员的工作负荷，进行 有效的调整和均衡 • 很容易了解每个成员的工作能力，进行评 估和考核
38
需求跟踪可以为成员带来什么？
28
无法对需求问题进行统计分析
• 管理人员无法对出现的需求问题进行统计 和分析，无法了解需求问题的分布情况和 出现原因，并采取有效的应对措施 • 无法对需求问题的处理过程进行统计分析 ，难以了解需求问题的处理效率，难以区 分团队成员在需求问题处理过程中的作用
29
用Word和Excel方式记录需求问 题？
98
4
2.从需求回溯项目目标
• 从需求回溯相应的项目目标,确认每个软件 需求的源头。 • 如果用使用实例的形式来描述项目目标,就 是使用实例和功能性需求乊间的跟踪情况。
98
5
3. 从需求追溯产品
• 由于开发过程中系统需求转变为软件需求、 设计、代码等,所以通过定义单个需求和特 定的产品元素乊间的联系链可从需求向前 追溯. • 这种联系链使你知道每个需求对应的产品 部件,从而确保产品部件满足每个需求。
26
需求问题处理不规范
• 需求问题的处理没有一定的流程，导致需 求问题处理的过程随意化，无法保证需求 问题处理的速度和质量； • 即便有一些纸质上的流程，由于没有一定 的工具支撑，导致流程不能被实施； • 无法控制需求问题处理的时限要求，导致 需求问题处理效率低下；
27
知识无法积累
• 需求问题处理过程中的有价值信息被丢失 ，无法积累和共享 • 已处理过的需求问题重复出现，却已忘记 解决办法，或者当时解决需求问题的人已 经离开了公司 • 团队新成员无法了解现有需求问题的现状 和历史 • 无法对出现的需求问题进行总结和分析， 发掘深层次的原因
有效的需求追踪方案
需求跟踪的用途
• 助力项目管理 • 维系一条线索 • 实现追溯与追踪
四类需求跟踪能力链
项目目标 1.追溯到需求 需求 3. 从需求追溯 下游工作 产品
98 3
2.从需求回溯
4.回溯到需求
1.从项目目标追溯到需求
• 从项目目标可追溯到需求,这样就能区分出 开发过程中或开发结束后由于需求变更受 到影晌的需求。 • 这也确保了需求规格说明书包括所有项目 目标。
用例1
特性1 特性2 特性n 特性m X
用例2
X X
用例n
用例m
X
X X
98 13
跟踪矩阵：特性与补充需求
补充需求1 特性1 X 补充需求2 补充需求n 补充需求m X
特性2
特性n 特性m
X
X X X
98
14
跟踪矩阵：从用例到场景
场景 用例1 场景1 场景2 场景3 用例2
主事件流
√ √ √
备选事件流1
– 客户、市场、工程等人员提交需求 – 产品经理或系统分析人员审核需求，并给出处 理方案，对于不实现的需求给出原因，关闭需 求并反馈给需求提交人 – 将需求提交给开发人员 – 开发人员完成后，提交给测试人员进行测试 40 – 测试通过后关闭需求
知识库
• 知识库是团队知识积累不可缺少的部分。 它为团队成员以及您的客户提供在线联机的
备选事件流2
98
15
从用例跟踪到用例实现
用例 用例 顺序 类 描述 图 图 图 用例1 用例2 用例3 用例4 状态图 代码 测试元 help文 素 档
98
16
需求状态的跟踪
• 一旦确立使用实例基准,就准备在矩阵中添 加每个使用实例演化成的功能性需求。随 着软件设计、构造、测试开发的进展不断 更新矩阵。 • 例如,在实现某一功能需求后,你可以更新它 在矩阵中的设计和代码单元,将需求状态设 置为"已完成"。
◦ ◦ ◦ ◦ ◦ ◦ 产品的缺陷、bug 后称后期，客户提出的意见、建议、投诉、服务请求 产品开发中遇到的技术需求问题 软件运维中的事件、需求问题、变更管理 部门之间的业务交互 工作任务的分配
24
缺乏对需求问题的记录
• 很多发现的需求问题被忽略或遗忘，最后不了了之，任由 需求问题慢慢发展，导致成危机事件而不可收拾（温水煮 青蛙现象） • 很多需要解决的需求问题，只是通过口头传达或纸质上的 简单描述，导致不少需求问题没有真正解决或解决得不到 位。而且事后没有跟踪的记录。 • 由于需求问题没有被记录下来，导致团队成员不自觉地对 待需求问题视而不见，或掩耳盗铃，自欺欺人，以为需求 问题自己没看见就不存在（鸵鸟政策） • 被动地解决需求问题，头痛医头、脚痛医脚，导致需求问 题越来越多 • 客户提出来的需求问题没有得到跟踪解决，造成客户抱怨 和流失
您可能遇到的困扰
23
缺乏对需求跟踪的管理
任何软件组织、任何软件企业每天都要产生许多需求相 关的需求问题，只是产生需求问题的多少、大小不同罢 了。软件企业能否正常推进项目，其根本的区别在于它 能否及时发现项目中的需求问题、解决需求问题甚至举 一反三、进而避免需求问题的产生。然而恰恰相反的是 ，许多企业没有建立对需求的跟踪管理机制。 常见与需求有关的需求问题类型：
R1 R2 R3 R4 R5 R6 R1 R2 R3 R4 * * * * * * *
R5
R6
98
*
10
可跟踪性列表
• 可跟踪性列表是可跟踪性 表格的一个简化形式，对 每一个需求描述来说，可 以维护一个或者多个相关 需求的标识符的列表。 • 可跟踪性列表比可跟踪性 表格更加简洁，并且当需 求数量很大时不会达到不 能管理的地步。它们比可 跟踪性的表格产生更少错 误。 需求 R1 R2 R3 R4 依赖 R3,R4 R5,R6 R4,R5 R2
98
17
需求状态的跟踪
状态 创建 需求 用例描述 用例图
罗燕京
2005.8.15
评审
批准
实施
测试
删除
交付
顺序图
类图
98
18
原始需求软件需求
用例 功能需求 FR-1 FR-2 FR-3 UC-1 UC-2 UC-3 UC-4
软件需求设计元素
• 建议：先复制一份基线软件需求规格说明 ，只保留功能性需求标签，其他全删除。 然后建立一张如下所示的表格，但只填写 功能性需求这一列。团队成员在开发过程 用户需求 功能需求 设计元素 代码模块 测试用例 中，逐渐填充其他空白单元。
• 选择要定义的联系链、要使用的跟踪矩阵的类 型 • 确定对产品的哪些部分维护跟踪信息 • 修改开发过程和检查列表定义使用什么样的标 记约定可以惟一地标识系统元素，这样就可以 将这些元素联系在一起 • 确定负责提供每类联系链信息的人员，和负责 协商跟踪活动并管理这些数据的人员 • 为项目团队提供培训 • 要定期审核跟踪信息，以确保信息最新。
25
沟通不畅
• 发现的需求问题无法及时让相关人员获知和处理 • 客户服务部跟研发部不在一个办公室，客服接到 客户的需求问题，无法即时传达。客服无法了解 客户提出需求问题的解决状态和解决结果。 • 需求处理状态很不透明，相关人员需要了解处理 状态时，需要人工去询问，或者是人工催办处理 需求，无法及时了解需求的处理状态。 • 团队成员不清楚自己需要做的事情，以及这些事 情的优先级 • 使用Email、电话等方式沟通，无法让相关人员对 需求问题的信息、历史都了解清楚
98
6
4. 从产品回溯到需求
• 从产品部件回溯到需求,使你知道每个部件存在的 原因。 • 绝大多数项目不包括与用户需求直接相关的代码, 但对于开发者却要知道为什么写这一行代码。 • 如果不能把设计元素、代码段或测试回溯到一个 需求,你可能有一个“画蛇添足的程序”。 • 然而,若这些孤立的元素表明了一个正当的功能,则 说明需求规格说明书漏掉了一项需求。
UC-28 UC-29 catalog.query.sort catalog.query.import catalog类 catalog类 catalog.sort() catalog.import() catalog.validate() search.7 search.8 search.12 search.13 search.14
帮助信息和速查手册。 • 知识库的增加和更新：
– 将典型的需求问题信息、处理方法加入知识库 – 直接将文章、文档等信息加入知识库 – 通过知识库管理界面编辑更新知识库内容
41
谢谢！
• 为什么实施需求跟踪？ • 怎样实施需求跟踪？
42
98
8
通用跟踪模型的跟踪矩阵
• • • • • • • 1.用户需要与特性 2.跟踪矩阵：特性与用例 3.特性与补充需求 4.从用例跟踪到用例实现 5.从用例到场景 6.跟踪到测试用例 7.从用例到测试用例
98
9
需求依赖性的可跟踪性表格
• 表格中的每一行显示 了依赖性,如果R4发生 变更，则顺着R4所在 的列读下去，发现需 求Rl和R3依赖于R4的 需求。因此应该可以 评估R4的变更给Rl和 R3带来的影响。
…
…跟踪
• 非功能需求并不总能直接跟踪到代码。 • 可以将相应的业务需求：公司 安全策略 功能性需求向 与用户身份验证有 后回溯到其父 关的集成质量属性 级非功能性需 密码的功能性需求 求，也可以向前跟踪 密码管理器 到下游可交付产品。
模块的设计
实现密码特性的代 码
需求跟踪过程 1
34
积累知识
• 积累需求问题信息和处理过程中的知识 • 使用知识库进行知识的积累和共享
35
统计分析
• 统计需求问题的各种分布情况 • 了解需求问题的变化趋势
36
需求跟踪可以为团队带来什么？