需求跟踪矩阵模板(RTM Template)
需求跟踪矩阵(RTM)
需求跟踪矩阵（RTM）有什么作用？（1）在需求变更、设计变更、代码变更、测试用例变更时，需求跟踪矩阵是目前经过实践检验的变更波及范围、影响分析的最有效的工具，如果不借助RTM，则发生上述变更时，往往会遗漏某些连锁变化。
（2）RTM也是验证需求是否得到了实现的有效工具，借助RTM，可以跟踪每个需求的状态：是否设计了，是否实现了，是否测试了。
2 需求跟踪矩阵分为哪几类？（1）纵向跟踪矩阵，包括如下的3种：需求之间的派生关系，客户需求到产品需求实现与验证关系：需求到设计，需求到测试用例等需求的责任分配关系；需求由谁来实现（2）横向跟踪矩阵：需求之间的接口关系3 在实践中，如何把握该建立哪些RTM？（1）在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则REQM SP1.4无法通过。
横向跟踪如果不作，则是大部分实施。
（2）对于纵向跟踪矩阵：必需的：客户需求与产品需求的跟踪，产品需求与测试用例的跟踪。
100%的接口需求需要建立客户需求-产品需求-设计-编码-测试用例的跟踪矩阵。
全局性需求要建立跟踪矩阵，包括：客户需求-产品需求-设计-编码-测试用例的跟踪矩阵。
核心需求要建立跟踪矩阵并非必需的：性能需求可以不建立跟踪矩阵不影响系统架构的功能需求4 需求跟踪矩阵由谁来建立？有多个角色参与建立RTM。
需求开发人员负责客户需求到产品需求的RTM建立，设计人员负责需求到设计的RTM的建立，测试用例的编写人员负责需求到测试用例的RTM建立等等。
PPQA 负责检查是否建立了RTM，是否所有的需求都被覆盖了。
5 RTM是否纳入基线管理？RTM要纳入基线管理。
纳入基线后，每次变更都要申请，RTM的变更一般是和其他配置项的变更一起申请，很少单独申请变更RTM，除非RTM有错误。
6 如何简化RTM的工作？由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所以建立和维护RTM 的工作量还是比较大、比较烦琐。
需求跟踪矩阵填写指南
本资料仅供内部使用！需求跟踪矩阵填写指南xxxx信息技术有限公司2016年01月16日本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属xxxx信息技术有限公司所有，受到有关产权及版权法保护。
任何个人、机构未经xxxx信息技术有限公司的书面授权许可，不得以任何方式复制或引用本文件的任何片断。
需求跟踪矩阵仅供内部使用修改记录目录1需求跟踪矩阵填写说明 (1)2需求跟踪矩阵的维护和使用 (1)3裁剪指南 (2)1需求跟踪矩阵填写说明【需求跟踪矩阵】用以跟踪需求到设计、设计到编码、编码的测试的映射过程。
项目组可以根据实际情况裁剪模板的格式来满足项目的要求。
需求跟踪矩阵的填写遵循以下原则：需求号：为每条需求编制唯一的识别号，通过需求号可以与需求文档中描述的需求建立一一对应关系。
建议不要使用章节号作为需求号。
如果没有在编程规范或需求跟踪矩阵中说明编号的格式，则可以按一下格式编号：●需求号＝一级功能编号.二级功能编号.三级功能编号.N级功能编号●建议最多不要超过5级；●例子：需求号1.2.1表示：第一个一级功能的第二个二级功能的一个三级功能。
软件需求描述：简单描述需求内容。
这个描述看是冗余，但有简单描述可以使得跟踪矩阵更具可读性和独立性。
概要设计：描述需求在概要设计中的实现情况。
建议使用编号对应，也可以使用文字对应，建议不要使用章节号。
如果使用编号，请在编程规范中说明编号规则。
详细设计：描述概要设计在详细设计中的实现情况。
建议使用编号对应，也可以使用文字对应，建议不要使用章节号。
如果使用编号，请在编程规范中说明编号规则。
编码：描述详细设计在编码时的实现情况。
可以使用函数名称，文件名称，对象名称等。
单元测试用例：描述详细设计对应的测试用例。
集成测试用例：描述概要设计对应的测试用例。
系统测试用例：描述需求对应的测试用例。
2需求跟踪矩阵的维护和使用跟踪矩阵有助于在各个生命周期阶段跟踪所有需求，以此来确保实现所有已并入的需求，这也避免了由于遗漏需求而进行的重复劳动。
需求跟踪矩阵模板
软件需求 概要设计 系统/FAT测试用例
详细设计 编码文件 集成/SIT测试用例
XX项目需求跟踪矩阵
子系统 系统管理
需求 权限管理
业务需求 需求名称
用户添加
状态
类别
优先 级
执行 状态
功能子集(FS)
软件需求 执行单元名称(EU)
做
必须 高
权限管理
用户添加
关键 程度
模块
权限管理 高
概要设计
跟踪矩阵
概要设计 组件
用户添加 用户维护 角色添加 角色维护 测试 角色权限对照
机器参数添加
详细设计 开发单元
编码文件 代码文件
SRS_XTGL_YHGL_用户添加001 SRS_XTGL_YHGL_用户添加002 SRS_XTGL_YHGL_用户添加003 SRS_XTGL_YHGL_用户添加004
完
完
完
用户维护
做
必须 高
用户维护
高
角色添加 角色维护
做
必须 高
新增 必须 高
角色添加
中
角色维护
中
权限报表
待定 必须 中
权限报表
低
角色权限对照
删除 必须 中
角色权限对照
低
参数管理
机器参数添加
必须 高
参数管理
机器参数添加
参数管理 高
电话银行
机器参数维护
必须 高
完
完
完
完完完完 完ຫໍສະໝຸດ 完请在这行之前插入行。
完完
请在这行之前插入行。
j1.java j2.jsp F_AddEmployee.sql FormConfig.xml
需求跟踪矩阵(需求管理过程)
用户需求规格说明
验收测试用例
编号
需求描述
编号
内容描述
CR01
AT01
CR02
AT02
【填表说明】1）验收测试用例对应用户需求；2）当工作产品发生变更时，要及时更新（填写）需求跟踪矩阵。
【填表说明】1）编号用于标识对应的需求描述或内容描述，编号命名方式由项目组自行定义，编号必须唯一，而且统一，可以使用数字、中文、英文；2）当工作产品发生变更时，要及时更新（填写）需求跟踪矩阵。
2需求跟踪矩阵—单元测试阶段
软件设计说明
单元测试用例
编号
内容描述
编号
内容描述
SD01
dd
UT1
SD02
ee
UT2
需求跟踪矩阵
1需求跟踪矩阵—单元测试前阶段
用户需求规格说明
软件需求规格说明
软件设计说明书
程序代码
编号
需求描述
编号
内容描述
编号
内容描述
编号
内容描述
CR01
dd
SR01
通用查询
SD01
CI1
通用查询模块
SR02
用户信息修改
SD02
SR03
用户信息添加
SD03
CR02
ee
SR04
SD04
CI2
用户信息维护
【填表说明】
1）单元测试用例对应软件设计；2）当工作产品发生变更时，要及时更新（填写）需求跟踪矩阵。
3需求跟踪矩阵--系统测试阶段
软件需求规格说明
系统测试用例
编号
内容描述
编号
内容描述
SR01
通用查询
电子地图管理系统_RTM
需求跟踪矩阵（RTM）
担当:张效群、侯冲冲、张晓文、盖玉杰
详细功能点说明 本次変 对应种类 担当者 更后
对应种类说明: ●新增/Δ 修改/×删除/◎保留/－无
读取文件并开始播放音乐/停止播放音乐并退出
●
陈畏龙
可在任意位置暂停播放音乐并且再次开始播放
●
陈畏龙
日方叫法
新规 流用 削除 再利用
增/Δ 修改/×删除/◎保留/－无 责任者
需求跟踪矩阵（RTM）
项目名称： 电子地图管理系统
Ｎｏ. 大分類 （模块） 中分類 （子模块）
PM:赵志愚
小分類 （功能点）
播放/停止
开始播放/停止播放
1
播放功能
暂停/开始
暂停播放音乐/重新开始播放
对应种类说明： 对应种类 新增 修改 删除 保留
说明 新增的模块或机能 部分重用，有变更 删除的模块或机能 完全重用，无变更
陈畏龙陈畏龙Fra bibliotek
需求跟踪矩阵
单元测试计划子表
编号
Exe2
程序设计人员*Βιβλιοθήκη **测试人员*****
测试目的
输出当前日期的后天日期
测试内容描述
输出当前日期显示后天日期
输入期望
你当前日期
功能处理期望描述
平年合理处理
输出期望
你当前日期的后天日期
单元测试结果
实际输入数据
2011-2-28
实际处理情况描述
程序在输入日期时，天数加2，若month=2时，程序判断year是否为闰年，若day=29或者30时，month加1，若month=12时，year加1，month-11，day-31
程序在输入日期1时，天数加2，若month=2时，程序判断year是否为闰年，若day=29或者28时，month+1，day-29
实际输出
2008-3-2
测试结论
正常
单元测试计划子表
编号
Exe4
程序设计人员
****
测试人员
*******
测试目的
输出当前日期的后天日期
测试内容描述
输出当前日期显示后天日期
实际输出
2011-3-2
测试结论
正常
单元测试计划子表
编号
Exe3
程序设计人员
*****
测试人员
*****
测试目的
输出当前日期的后天日期
测试内容描述
输出当前日期显示后天日期
输入期望
你当前日期
功能处理期望描述
闰年合理处理
输出期望
你当前日期的后天日期
单元测试结果
实际输入数据
2008-2-29
实际处理情况描述
CMMI-REQM-T-04 需求跟踪矩阵表模板
×——此项不适合
已完成进行中但未完工空白未开展此项不适合序号功能模块一级功能二级功能需求类型设计阶段编码及集成阶段测试阶段
XXX项目——需求跟踪矩阵表
序号 功能模块 一级功能 二级功能 需求类型 状态 需求阶段 需求规格 设计阶段 状态 体系结构 状态 编码及集成阶段 产品代码 集成测试 测试阶段 状态 系统测试 状态 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 状态说明： √——已完成 注：此处注明特殊情况。 此处说明需求文档，设计文档的版本等相关情况。 实施阶段 验收测试 测 试
需求跟踪矩阵(RTM)事例
版本：1.1.0-1.1.0 第1页
需求进度管理表Biblioteka ○：完成（通过评审或测试） NO. 1 2 3 4 5 6 7 8 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 移动蛇身 31 游戏升级 32 35 36 游戏结束 游戏开始/暂停 移动情况检测 GamePlay 游戏任务 游戏初始化 游戏结束界面 地图初始化 贪吃蛇初始化 显示信息初始化 启动定时器 撞墙 咬到自己 吃到食物 没吃到食物 未升级 升级 通关 增加蛇身 游戏界面显示 TaskInfo 显示信息 游戏信息显示 Start/Pause键 游戏时间 游戏积分 游戏等级 游戏欢迎界面 游戏过程界面 大分类 main 系统管理 中分类 模块调用 任务管理 Keyprocess 按键任务 按键检测 按键处理 △：进行中 小分类 调用系统初始化 调用游戏初始化 游戏运行任务 游戏信息任务 按钮检测任务 检测按键键值 方向键 N/A：不适用（没有此项活动） 完成情况跟踪 详细说明 SD PD DD COD UT ○ ○ ○ ○ 初始化游戏系统 ○ ○ ○ ○ 调用游戏初始化模块 ○ ○ ○ ○ 根据蛇速度设置定时 ○ ○ ○ ○ 调用显示信息模块 ○ ○ ○ ○ 调用按键任务模块 把键值返回给按键处 ○ ○ ○ ○ 理模块 当按键为方向键时， ○ ○ ○ ○ 判断方向，然后调用 移动情况检测模块 ○ ○ ○ ○ 调用游戏开始/暂停模 在字符显示屏上显示 ○ ○ ○ ○ 游戏时间 在字符显示屏上显示 ○ ○ ○ ○ 游戏积分 在字符显示屏上显示 ○ ○ ○ ○ 游戏等级 显示欢迎图案，2s后 ○ ○ ○ ○ 开始游戏 在图形显示屏上显示 ○ ○ ○ ○ 当前地图、障碍物、 贪吃蛇和食物 ○ ○ ○ ○ 显示"Game Over"字样 根据游戏级别初始化 ○ ○ ○ ○ 游戏地图、食物、障 根据游戏级别初始化 ○ ○ ○ ○ 贪吃蛇身体、方向、 初始化游戏时间、分 ○ ○ ○ ○ 数、级别 启动定时器、游戏开 ○ ○ ○ ○ 始 调用游戏结束模块 ○ ○ ○ ○ ○ ○ ○ ○ 调用游戏结束模块 ○ ○ ○ ○ 调用升级检测模块 ○ ○ ○ ○ 调用移动蛇身模块 ○ ○ ○ ○ 调用增加蛇身模块 调用游戏升级模块 ○ ○ ○ ○ 调用游戏结束模块 ○ ○ ○ ○ 增加积分、根据方向 增加蛇身长度1、创建 ○ ○ ○ ○ 新的食物、调用显示 信息模块 清除蛇尾、建立新的 ○ ○ ○ ○ 蛇身、根据方向创建 新蛇头，调用显示信 游戏等级+1、调用地 图初始化模块、调用 ○ ○ ○ ○ 贪吃蛇初始化模块， 调用显示信息模块 清除定时器，调用显 ○ ○ ○ ○ 示信息模块 若未设置定时器则调 ○ ○ ○ ○ 用游戏初始化模块， 若已设置定时器则暂 ×：未着手 IT ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ST
需求跟踪矩阵(RTM)
5. 快进键
需求跟踪矩阵
版本：1.1.0-1.2.0 第2页
Ｎｏ.
大分類 模块）
中分類 （子模块）
6. 快退键
小分類 （功能点）
详细说明
1. 点击后播放进度减少指定时间，若当前 文件播放时间小于该时间，则重新播放该文
完成情况跟踪 SD PD DD COD UT IT ST
担当者
责任者
7. 音量加键 8. 音量减键 9. 静音键
10.时间轴
默认为 00 ： 00 | 00 ：00 ，当播放音乐是前 边时间表示当前音乐的播放时间，后者时间 表示该歌曲的总时长。
点击后将播放器音量加一，若当前音量 已为最大时，则不执行该操作。 点击后将播放器音量减一，若当前音量 已为静音时，则不执行该操作。 点击后播放器音量置为0
沈阳东软软件股份有限公司
沈阳东软软件股份有限公司
完成情况跟踪 SD PD DD COD UT IT ST
担当者
责任者
1
主界面
设置模块 列表模块 图片模 块 播放模块
歌曲信息 删除模块 本地歌曲
添加模块
歌曲 歌曲名
2
列表模块
需求跟踪矩阵
1．目的和范围
本文件用于项目的需求跟踪，以确保该项目需求在需求分析、设计实现、测试等环节得到完整的管理一般情况下需求跟踪包括以下环节内容（详见需求跟踪矩阵）：
追溯输入需求：即建立项目需求与其来源需求的追溯；
跟踪此需求的分解和实现的过程；
跟踪需求的设计实现和相关验证过程情况。
2、填表说明
1）“需求来源”：需说明需求的出处，如：业务/产品自身完善/运维/客户等
1）需求部分，在项目立项后，需求确认阶段填写，由项目经理或指派人员填写；
2）设计部分，在项目实现阶段填写，由项目经理或指派人员填写；
3）测试部分，在项目测试阶段填写，由项目测试负责人填写；
4）完成状态，在测试结束后，由项目经理填写。
的管理和控制，保证一致性。
软件测试基础回顾（十六）--如何创建需求可跟踪性矩阵（RTM）
软件测试基础回顾（⼗六）--如何创建需求可跟踪性矩阵（RTM）什么是可追溯性矩阵？（TM）可追踪性矩阵是⼀个⽂档，它将需要多对多关系的任何两个基线⽂档联合起来，以检查关系的完整性。
它⽤于跟踪需求并检查当前项⽬要求是否得到满⾜。
什么是RTM（需求可追溯性矩阵）？需求可跟踪性矩阵或RTM捕获客户端或软件开发团队提出的所有要求及其在⽣命周期结束时提供的单个⽂档中的可跟踪性。
换句话说，它是⼀个⽤测试⽤例映射和跟踪⽤户需求的⽂档。
需求可跟踪性矩阵的主要⽬的是确保涵盖所有测试⽤例，以便在进⾏软件测试时不会错过任何功能。
需求可追溯性矩阵 - 参数包括要求ID风险要求类型和描述追溯设计规范单元测试⽤例集成测试⽤例系统测试⽤例⽤户验收测试⽤例跟踪测试脚本可追溯性测试矩阵的类型前向可追溯性：该矩阵⽤于检查项⽬是否按期望的⽅向和正确的产品进展。
它确保每项要求都适⽤于产品，并且每项要求都经过彻底测试。
它将需求映射到测试⽤例。
向后或向后可追溯性：⽤于确保当前产品是否保持在正确的轨道上。
这种可追溯性背后的⽬的是通过添加代码，设计元素，测试或其他未在需求中指定的⼯作来验证我们不扩展项⽬的范围。
它将测试⽤例映射到需求。
双向可追溯性（前向+后向）：此可追溯性矩阵确保测试⽤例涵盖所有要求。
它分析了受⼯作产品中的影响的需求变化的影响，反之亦然。
如何创建需求可跟踪性矩阵让我们通过Guru99银⾏项⽬了解需求可追溯性矩阵的概念。
在业务需求⽂档（BRD）和技术需求⽂档（TRD）的基础上，测试⼈员开始编写测试⽤例。
让假设，下表是我们的业务需求⽂档或的Guru99银⾏项⽬。
这⾥的情况是客户应该能够使⽤正确的密码和⽤户#id登录Guru99银⾏⽹站，⽽经理应该能够通过客户登录页⾯登录⽹站。
下表是我们的技术要求⽂件（TRD）。
注意： QA团队不记录BRD和TRD。
此外，⼀些公司使⽤与技术要求⽂档类似的功能需求⽂档（FRD），但创建可跟踪性矩阵的过程保持不变。
需求跟踪矩阵 模板
表格编号：XY202-项目编号-两位顺序号
项目名称： 需求分析 用户需求 编号 章节编号 需求名称 首页 1 状 章节 态 编号 原 始 软件需求 子模块名 系统监视 状态 原始 修改 删除 增加 风电监控 2 修 改 需求优 先级 高 中 低 责任人 概要设计 章节编号
3
删 除
4
567源自8原始需求总数 修改需求总数 删除需求总数 增加需求总数 总需求数
3 0 0 0 3
需求跟踪矩阵
项目经理PM： 系统设计 概要设计 名称 是否完成 责任人 详细设计 章节编号 名称 是否完成 责任人 代码单元 编码实现 是否完成 责任人 √ √
项目QA： 功能测试 测试单元 是否完成 责任人 备注