敬儿(cnitpm.com) 22:55:18
请教大家一个问题，需求跟踪矩阵里面的需求都是项目定义范围里要做的吗
敬儿(cnitpm.com) 22:55:32
还有需求评审是在什么时候做的？
Frank(cnitpm.com) 9:07:58
@敬儿 需求跟踪矩阵是范围管理里面收集需求的输出
Frank(cnitpm.com) 9:08:12
收集需求之后才是定义范围
敬儿(cnitpm.com) 9:48:25
需求跟踪矩阵不是有个跟踪能力链吗？这个正向跟踪的时候，要跟踪到产品，是不是就是说需求跟踪矩阵中的需求都是范围定义后的需求呢？
Frank(cnitpm.com) 9:50:05
需求跟踪矩阵是在定义范围之前就已经有了
敬儿(cnitpm.com) 9:50:38
说上说需求文件里面的内容都要跟踪到产品元素是不是有问题？
敬儿(cnitpm.com) 9:50:44
书上说的
Frank(cnitpm.com) 9:52:13
定义范围的输入有需求文件
Frank(cnitpm.com) 9:52:56
你觉得会有什么问题？不是很明白你的意思
敬儿(cnitpm.com) 9:53:31
需求跟踪能力链不是每个需求都要有相应的产品元素吗
敬儿(cnitpm.com) 9:54:22
如果这个需求跟踪矩阵是所有的需求，包括范围内的和范围外的话，外围外的需求就不可能跟踪到产品元素吧
Frank(cnitpm.com) 10:19:12
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪
矩阵，把每个需求与业务目标或项目目标联系起来，有助于确保每个需求都具有商业价值。需求跟
踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法，有助于确保需求文件中被批准的每项需
求在项目结束的时候都能交付。最后，需求跟踪矩阵还为管理产品范围变更提供了框架。
Frank(cnitpm.com) 10:19:42
有助于确保需求文件中被批准
敬儿(cnitpm.com) 10:20:35
明白了，也就是批准的对应产品元素
Frank(cnitpm.com) 10:20:41
注意是被批准的，只要是被批准的，最终都要转化为产品元素，肯定就是可被追溯的
敬儿(cnitpm.com) 10:20:54
玫瑰/
Frank(cnitpm.com) 10:21:01
范围外的肯定就不在批准之内了
Frank(cnitpm.com) 10:21:04
属于镀金了
敬儿(cnitpm.com) 10:21:16
恩，谢了
向前，努力奔跑！(cnitpm.com) 10:23:54
@Frank 范围也会变更，也就意味着，早先被批准的需求，在后续可能会被否定，此时，需求跟踪矩阵中难道还会剔除该条被否定的需求？
牧马人(cnitpm.com) 10:28:39
需求跟踪矩阵和范围说明书是从两个方面对需求进行的描述，前者关注产品需求，后者还包含项目需求。一般来说，需求跟踪矩阵中所列出的需求与项目范围说明书中的产品范围描述的需求是同源的
牧马人(cnitpm.com) 10:28:42


向前，努力奔跑！(cnitpm.com) 10:30:54
我觉得，被批准的需求 肯定是应该罗列在 矩阵中的，至于 之后被否定的需求，是否需要被剔除，应该是团队用法的问题吧；如此，在项目初期，所有能被考虑到的需求全（无论是否被批准）全都放在矩阵中，这又有何不可？
敬儿(cnitpm.com) 10:32:19
不做的需求应该也在需求跟踪矩阵中，因为需求跟踪矩阵有个状态
向前，努力奔跑！(cnitpm.com) 10:32:21
没有人规定，在收集需求时，非得等到该需求被批准后 才能被列入 矩阵中
向前，努力奔跑！(cnitpm.com) 10:32:35
@敬儿 
就是嘛
牧马人(cnitpm.com) 10:34:41
作用不同。二者所列出的需求是一致的（名词规范后，需求的名称都是一致的）。需求跟踪矩阵用来验收产品用。范围说明书用来分解项目工作用。项目工作的目的就是生产出符合需求文件的产品。二者的最终目的相同。用项目管理系统进行需求管理后，二者是一致的，可验证和追踪的
牧马人(cnitpm.com) 10:35:22
项目变更后，如果影响到需求的变更，范围说明书和跟踪矩阵都要做响应的变更
向前，努力奔跑！(cnitpm.com) 10:36:49
@牧马人 是的，但是，便跟的应该是状态，或者 新增需求，我个人觉得不应该删除已经罗列的需求，否则，不利于“需求跟踪”
牧马人(cnitpm.com) 10:37:26
需求评审是一个里程碑，一般在需求收集完成后召开评审会。当然重大的需求变更，召开的变更评审会一定包含对需求的评审内容
牧马人(cnitpm.com) 10:40:34

这是一个可使用的实际的需求跟踪矩阵
牧马人(cnitpm.com) 10:41:42
范围说明书最终要演化为WBS才能实用，是个中间产品
牧马人(cnitpm.com) 10:42:14
需求跟踪矩阵具有实用的价值
牧马人(cnitpm.com) 10:42:53
对，还未进行需求评审
牧马人(cnitpm.com) 10:43:38
当前状态还处于需求收集阶段。“需求开发”
敬儿(cnitpm.com) 10:44:41
在工作中我们都是写需求规格说明书，然后给用户签字确认，这样是不是不对
敬儿(cnitpm.com) 10:45:35
需求规格说明书的内容应该是范围内的需求吧
牧马人(cnitpm.com) 10:46:58
对。因为召开需求评审会的时候，让甲方参加比较难。一般是先让甲方确认需求，之后再召开需求评审会，这时甲方可不参加
牧马人(cnitpm.com) 10:47:44
范围内的需求更广，包含项目需求，比如开发用的计算机、人力、时间、资金等资源
牧马人(cnitpm.com) 10:49:52
需求跟踪矩阵只包含针对产品的需求。产品需也是范围内包含的需求之一
牧马人(cnitpm.com) 10:51:12
用项目管理系统，需求跟踪矩阵、范围说明书将自动生成
敬儿(cnitpm.com) 10:51:44
需求规格说明书所有需求都是范围内的，但是跟踪矩阵中的所有需求并不一定是范围内的，我可以这么理解吧
牧马人(cnitpm.com) 10:53:04
依据就是需求规格说明书。需求规格说明书评审通过后，就可以生成这两个文件了。当然还需要对这两个文件进行修改
敬儿(cnitpm.com) 10:54:09
需求规格说明书是收集需求的输出
老冯(cnitpm.com) 10:55:32
我们这类考试，有时题目不是很精确，知识点既要弄懂，又不要钻牛角尖。
尤其选择题，可能觉得都不对，或不只一个对的，这时候，选最对的那个。
牧马人(cnitpm.com) 10:56:31
老冯对。实际工作就需要弄清楚。干过就知道啦
梦(cnitpm.com) 10:57:26
书上的跟实际工作肯定有出入
老冯(cnitpm.com) 10:57:35
考后核对答案时，有考友觉得老师的答案好像不对就是这个问题。
梦(cnitpm.com) 10:57:39
每个公司都有自己的一套标准
牧马人(cnitpm.com) 10:57:44
系统就设计好了，自动生成，一般两个文件的需求是不是一直都不核对，应该是
牧马人(cnitpm.com) 10:58:15
对。遵循国家标准，就是一致的
梦(cnitpm.com) 10:59:06
大致流程是一致的，中间流程没有那么繁琐
牧马人(cnitpm.com) 10:59:13
谁有那个时间，对上千上万条需求一一核对呀
梦(cnitpm.com) 10:59:27
对呀