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