如何制定一份有效需求跟踪矩阵表

冰封伯爵

以下是我目前准备重新制定需求跟踪矩阵设计的时候分析:
说明：需求阶段，我们的输出产物为：业务需求说明书、用户需求说明书、功能设计说明书
1、相关涉众：项目经理、需求分析师、设计师、软件工程师、测试工程师、客户
2、用例统计：需求总数、模块总数、变更总数、用例总数
3、需求变更类型：新增、遗漏、修改
4、需求跟踪矩阵表中的设计元素：（以对应角色关注点列出，有部分共同关注点没有单独列出）
项目经理：返工量评估、评估变更风险、质量影响、纠正措施、跟踪结果、跟踪人
需求分析师：需求用例ID、用户需求说明书、需求稳定性、需求优先级、变更相关涉众（一般指客户）、关联模块、需求维护人（具体需求分析师，针对变更）、需求 变更类型、验收标准
设计师：功能设计ID、功能设计说明书、技术难度（评估）、设计维护人
开发工程师：工作量反馈、修改人、单元测试用例ID（链接）
测试工程师：测试用例ID（链接）、测试用例说明书、用例维护人
以上字段是我打算设计使用的字段，请大家帮忙指点，看是否有遗漏或不妥之处。
此次交流期望：想得到一份比较简单但执行效率高的需求跟踪矩阵。
备注：文中附件是我之前很早设计的需求跟踪矩阵，考虑到执行的有效率不高的情况，想进一步优化，请大家帮忙指点，如有成功的跟踪表和案例，请分享，谢谢。

[ 本帖最后由 冰封伯爵 于 2008-5-28 16:42 编辑 ]


上一篇：在CMMI4评估过程中需要注意哪些问题，请高手、老手、新手指点？
下一篇：如何组建一支优秀的EPG团队？

JP-TEMP-RM-001_需求跟踪表模板.xls

ivan_d

先下来看看,学习一下!

cecilia

目前存在一个大问题就是，规范、流程和模板都有了，可是执行力不高。
当然需求跟踪不单单由某一人负责，比如项目经理，亦或是需求分析员等。因为开发人员可能在编写程序的时候可能会出现与需求不符的情况，如以目前的技术无法实现这个需求，不符合操作习惯等。说到这又与《需求管理》有关了。

先下载看看，再进一步讨论。

iamredeye

想办法自动化吧。否则：
1。项目太小，这张表没存在价值
2。项目比较大，这张表手工维护成本太高，里面没有及时更新导致的错误肯定比较多。如果准确性有问题，那么张表也起不到作用。

此外很多元素是没有一对一的映射关系的，甚至requirements和architecture可能没有对应关系。所以我觉得实施遇到的问题一方面是你说到的，另外可能更重要的是执行成本和实用性。

cecilia

可怎么样做到自动化呢？
在这整个表中都是需要人工来维护的，一旦事情一多忘记了，那这个需求可能就不能在需求规格说明书中体现了，并且表中涉及的人员多，人一多执行起来就不方便了。而且也不能保证每个人都会将关联模块中需求的改变进行记录，并汇报，很有可能是在编码实现之后，到测试的过程才发现与当初评审通过的需求不符。
需求状态分为：已批准、已实现、待确认和已变更，我觉得挺好的，这样的话待项目办结时，需求规格说明书就是完整的了，而不致出现最后开发出来的产品与需求不符的现象了。

xixiaojing666

原帖由 iamredeye 于 2008-5-28 20:44 发表
想办法自动化吧。否则：
1。项目太小，这张表没存在价值
2。项目比较大，这张表手工维护成本太高，里面没有及时更新导致的错误肯定比较多。如果准确性有问题，那么张表也起不到作用。

此外很多元素是没有一对一 ...

说的真对，项目太小，这个表就填的感觉繁复。项目大，维护成本又高，而且非一对一的映射关系也难以对应。
所以我们现在的状况是根本上就不使用这个表了。

能作到自动化最好，不知道目前有免费的工具吗？

iamredeye

no idea

我这里其实是在做QA，能指出问题；但我也不知道怎么解决；甚至我不知道你们的项目是不是真需要解决这个问题:loveliness:

冰封伯爵

原帖由 iamredeye 于 2008-5-29 15:33 发表
no idea

我这里其实是在做QA，能指出问题；但我也不知道怎么解决；甚至我不知道你们的项目是不是真需要解决这个问题:loveliness:

我们的最终目的是想解决需求跟踪难的事,降低管理成本\时间.

iamredeye

如果这个表实际上不能起很大作用甚至还增加了管理的成本\时间，那么也许要考虑换个思路，而不是优化这张表。

比如，能否增加use case ，test case和其它artifact的review effort/quality；增加沟通，提高变更管理的有效性。。。

冰封伯爵

原帖由 iamredeye 于 2008-5-29 21:11 发表
如果这个表实际上不能起很大作用甚至还增加了管理的成本\时间，那么也许要考虑换个思路，而不是优化这张表。

比如，能否增加use case ，test case和其它artifact的review effort/quality；增加沟通，提高变更管理 ...

不知楼上有什么好的需求管理思路,如果可能的话,大家一起探讨下;之前我也借鉴了不少需求跟踪矩阵模版,当是我也在想,我是不是被误导了,或是没有创新的思想,或是该换换角度,从需求管理的重点,需求变更下手,后来又想到,与需求变更的相关涉众,及涉众所关心的信息着手,也就是我之前列出的几类角色,那只是我分析思路,还未付出实践,我也不知道我分析的这些对不对,实不实用,对需求跟踪矩阵的优化是否有帮助.借这次探机会,希望大家一起讨论,必竟在整个软件生命周期里,需求这块是最难做的,也是最难控制的,如果我们做的话,可以大大减少软件的开发成本和周期;据我调查和所知,90%的IT企业都不能做好需求管理这块,目前需求这块是我们过程改进中最薄弱的地方(很多通过CMMI5的企业也没什么可行的好办法)

cecilia

原帖由 冰封伯爵 于 2008-5-29 22:26 发表

借这次探机会,希望大家一起讨论,必竟在整个软件生命周期里,需求这块是最难做的,也是最难控制的,如果我们做的话,可以大大减少软件的开发成本和周期;据我调查和所知,90%的IT企业都不能做好需求管理这块,目前需求这块是我们过程改进中最薄弱的地方(很多通过CMMI5的企业也没什么可行的好办法)

是的，我们现在需求这一块也不知道应该怎么来管理，需求涉及的人员多，只要一个相关的人员没有将更改的需求记录下来，那整个需求管理也是没到位的。希望大家能一起讨论，看有没有更好的解决办法。

iamredeye

我对requirement mgmt也没有深入的理解。楼上的提到requirement change，我相信这个如果是root cause的话，主动的解决方案是加强change mgmt，这个traceability matrix反而是个被动、事后的处理方案。如果很多公司都做不好的话，不妨先把注意力转移到change mgmt上。

总之，change mgmt做不好的话我相信这个traceability matrix能起到的作用非常有限，或者说overhead非常大，project team执行起来也有很大问题。

不知道这样的思路是不是适合你们公司。:loveliness:

inst

在建立需求跟踪矩阵时，花费大量时间，实际又不在实际中应用它，白劳啊

chinahci

挺有用的，不错 挺有用的，不错 挺有用的，不错 挺有用的，不错

solo

太好了 ，正好为这事头痛呢，原来我们的需求跟踪矩阵模板非常简单去描述各阶段的工作产品的关系。

因为过于简单，实现和维护上反而不好实施，怎么做都难达到效果。

现下载下来看看 多谢~ 希望能有效，~！