关于需求跟踪矩阵的6个问题
发布于 2024-10-03
1960
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
需求跟踪矩阵(RTM)摘要
1. RTM的作用:
- 在需求、设计、代码、测试用例变更时,RTM是进行变更影响分析的有效工具,减少因变更带来的连锁变化遗漏。
- RTM能有效验证需求的实现状态,包括是否设计、实现、测试。
2. RTM的分类:
- 纵向跟踪矩阵:包含需求派生、实现与验证、责任分配的关系。
- 横向跟踪矩阵:涉及需求之间的接口关系。
3. 建立RTM的实践:
- SEI调查认为纵向跟踪是必须的,横向跟踪则是大部分实施。
- 纵向跟踪必需建立的关系包括:客户需求与产品需求、产品需求与测试用例、全局性需求和核心需求的完整跟踪,而性能需求和不影响系统架构的功能需求可以不建立。
4. 负责建立RTM的角色:
- 需求开发人员、测试用例编写人员、设计人员等各自负责相应的RTM建立。
- PPQA负责检查RTM的建立和覆盖情况。
5. RTM的基线管理:
- RTM应纳入基线管理,变更需申请,一般与其他配置项的变更一起进行。
6. 简化RTM工作:
- 实践中,企业通过需求、设计、代码、测试用例的编号来简化RTM的建立和维护。
- 无法通过DOORS等需求管理工具时,通常使用EXCEL来维护RTM,但工作量大。
- 简化RTM需平衡管理投入与产出,可能会牺牲跟踪的精确度。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1025.2K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
杂谈推理逻辑的严密性
我们在日常生活中的逻辑推理可以分为两类:必然性推理、或然性推理。从前提条件推理出的结论是确定的,这就是必然性推理。比如:人都有父母。这种结论是必然的,不可否认的,所以没必要争论。从前提条件推理出的结论并非是确定的、必然的,这就是或然性推理。比如:痴情女子负心汉。女人—>痴情女;男人—>负心汉这就不是必然性推理,仅仅是部分人的经验。我们的经验大都...
如何推广单元测试
在我咨询的客户中,软件企业对于单元测试的执行情况可以划分为4类: (1)不做单元测试 (2)组织级要求了开发人员做单元测试,但是开发人员在做单元测试时,测试用例仅覆盖了程序中的正常路径,基本上是一个函数只有一个单元测试用例 (3)组织级要求了每千行代码必须有多少个单元测试用例,一般是在50个/KLOC到100个/KLOC之间。 (4)要求语句覆盖与分支覆盖必须达到100%。其中(3)、(4
我说CMMI 2.0 之 估算
EST(estimation)是CMMI2.0中新增的一个PA,从1.3版本中的PP与IPM PA中剥离了一些实践过来。 基本思想估计什么?规模、工作量、工期、成本等。估算是承诺的基础,充分沟通是估算的基础。估算可能是逐步细化的,并非在项目初期就估计一次。初期的估算与实际结果偏差比较大,因此,承诺也是多版本的,会逐渐调整承诺。估算要有方法论,要根据估计的结果与实际的偏差率不...
度量指标的数值越大越好还是越小越好?
系统测试的缺陷密度越大越好,还是越小越好呢?不同的人可能观点不一致。推而广之,每个度量指标都存在这个问题,那结论到底是啥呢?
需求变更对软件质量的影响
根据我们的经验,需求变更越多,造成的软件修改越多,bug也就会越多,事实是否如此呢?需要我们根据历史的数据进行检验。某企业采集了历史上多个项目的的需求变更次数、交付代码的规模、软件测试发现的缺陷个数,参见下表,基于这些历史数据我们分析一下,看看我们的经验结论是否成立。表一:需求变更的历史数据 ID 需求变更数 代码规模LOC 总缺陷数 测试缺陷密度bugs/KLOC
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线