需求跟踪矩阵检查单
需求跟踪矩阵
3、需求稳定度/变化率统计
初始
增加
删除
修改
未更改变更数 现有需求总数 需求稳定度
16
9
2
3
11
23
68.75%
注：
1、需求稳定度 = 未更改变更数/原始需求总数
2、需求变化率 = 需求变更总数/原始需求总数
其中：需求变更总数 = 增加的需求数+删除的需求数+修改的需求数
需求变化率 87.50%
2、需求变更在各阶段的分布
阶段
需求分析 概要设计
需求变更数 0
5
需求分布 0.00% 35.71%
详细设计 3 21.43%
编码单元测试 集成测试
2
1
14.29%
7.14%
系统测试 2 14.29%
需求变更数
5 4.5
4 3.5
3 2.5
2 1.5
1 0.5
0
需求变更数
需求分 析
0
概要设 计
5
详细设 计
2008/8/20 修改
1
阶段 需求分析 概要设计 概要设计 详细设计 详细设计 编码单元测试 编码单元测试 集成测试 系统测试 验收测试
涉众类型 客户 研发人员 客户 研发人员 客户 研发人员 客户 系统限制 客户 客户
注：每次更新需求跟踪矩阵的需求信息时，首先填写变更明细表
变更记录人
张三 李四 张三 李四 张三 李四 张三 李四 王二
3
编码单 元测试
2
集成测 试
1
系统测 试
2
验收维 护
1
注：由该图可以看出项目各阶段的需求变更数
验收维护 1
7.14%
需求跟踪矩阵
原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始
已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准 已批准
结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项
评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过
评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过
已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试
已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试 已系统测试
当前状态
概要设计状态
对应概要 设计章节
结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项
需求跟踪矩阵_产品版本标识
填写说明：
1）产品经理完成本文件的第一版，后续由软件需求、设计、测试负责人进行完善
2）本文件与产品需求、软件需求、设计文档、测试案例一同评审并基线
3）项目组如裁剪软件需求，则需完成产品需求到设计的跟踪，可删除软件需求到设计跟踪
4）项目组如不裁剪软件需求，则需完成软件需求到设计的跟踪，产品需求到设计的跟踪可删除5）测试案例如使用TD维护，应将可说明跟踪关系的截图粘贴在产品需求到测试案例跟踪一页
6）其他跟踪关系项目组可自行添加，如跟踪到架构设计、集成测试案例、单元测试案例、代码等。
需求跟踪矩阵的内容
需求跟踪矩阵的内容1. 介绍需求跟踪矩阵需求跟踪矩阵是一个用于追踪软件项目需求的工具。
它能够帮助团队有效地管理和掌控需求变更，确保项目在开发过程中的各个阶段能够满足用户的需求。
该矩阵记录了项目的需求以及与之相关的信息，如需求的来源、状态、优先级等，从而为开发团队提供了一个清晰的需求全貌。
2. 需求跟踪矩阵的结构需求跟踪矩阵通常由表格组成，其中包含了多个字段用于描述需求的各个方面。
常见的字段包括需求编号、需求描述、需求来源、需求状态、所属模块、开发优先级、验收标准等。
这些字段能够帮助团队跟踪和管理需求的生命周期，并确保参与项目的各方都对需求有一个共同的理解。
2.1 需求编号需求编号是每个需求的唯一标识符，用于在矩阵中区分不同的需求。
编号可以采用自定义的规则，比如简单的序号、项目缩写+序号等。
2.2 需求描述需求描述是对需求的详细说明，包括需求的背景、目标、功能要求等信息。
一个清晰、准确的需求描述能够帮助开发团队准确理解用户的期望。
2.3 需求来源需求来源是指提出该需求的人或团队。
需求可以来自于不同的渠道，比如用户反馈、市场调研、相关部门等。
记录需求来源能够帮助团队了解需求的背景和动机。
2.4 需求状态需求状态标识了需求所处的状态，比如已提出、待评审、开发中、已完成等。
需求状态的变更能够帮助团队了解需求的进展情况，并及时处理需求相关的事务。
2.5 所属模块所属模块指明了需求所属的功能模块或系统模块。
将需求按模块分类能够帮助团队更好地组织和安排开发工作，并便于后续的维护和升级。
2.6 开发优先级开发优先级用于确定需求的重要性和紧急程度。
通过给需求设置优先级，团队可以合理安排开发资源，确保高优先级需求得到及时处理。
2.7 验收标准验收标准是对需求实现的一组判断规则。
它描述了需求完成后应满足的条件和表现，便于项目验收和用户验收的进行。
3. 如何使用需求跟踪矩阵需求跟踪矩阵在项目的不同阶段都扮演着重要的角色。
需求跟踪表模板
需求跟踪表
项目名称：
说明：
1、此表以需求编号作为唯一，可维护一对多关系。
2、原编号填入该需求在《用户需求说明书》中的编号
2、需求编号方法：日期_4位流水号（yyyymmdd_0001）,例如20000517_0001;
3、需求类别：A、功能性需求B、非功能性需求；
4、优先等级：A、B、C、D、E五个等级；
5、需求状态：A、已提出；B、已批准；C、已拒绝；D、已变更；E、已删除；F、已关闭；
6、进度：Y表示已完成，P表示正在进行，---表示不需进入该步骤进行处理；
7、设计、编码、测试用例填写：编号+（命名），具体的编码方法是：design/code/test+4位流水号，例如，design0001
（class）；另外，设计、编码、测试用例需遵循一致的命名约定，如设计模型中名为 class 的类由实施模型中的 class 类来实现。
8、设计可以包括：模型中的对象、关系数据库中的模型、表单，或对象类；代码可以是：类中的方法、源代码的文件名、过程或
函数；测试用例是改需求所对应的测试用例；发布产品版本是该需求所对应的产品版本；
9、本表A,B,C,D,E,F,H,I,J,K栏由需求管理员进行维护；L栏由设计人员进行维护，需求管理员进行检查和跟踪；M栏由开发人员进行维护，需求管理员进行检查和跟踪；G栏由测试经理进行维护，需求管理员进行检查和跟踪。
N栏由项目经理进行维护。
10、需求基线编号填入本次需求基线的编号，对于每一次需求基线的变更都需要建立新的《需求跟踪矩阵》
11、“蓝色字”标注的内容需要及时填写，“黑体字”标注的内容可以延迟到项目验收后填写。
《需求开发与管理检查单》
说明： 1、本检查单在需求开发结束/项目结束之后由QA进行检查。 2、工作产品中空白的sheet必须删除。 3、 不需填写 需要填写 自动计算出的结果 4、检查“结果”栏的内容有三种：“是”、“否”，“免”。“是”表示符合，“否”表示不符合，“免”表示 不适用或不需检查。
单
0 0
备注
”表示符合，“否”表示不符合，“免”表示
需求开发与管理检查单
项目名称 项目编号 项目级别 项目经理 检 查人 检查日期 说 明 序号 1 2 3 4 5 6 8 9 10 11 12 13 14 15 16 17 18 24 25 检查大类 检查项 总项数 符合项数 不符合项数 NA项数 符合度
结果
Байду номын сангаас
是否已制订需求开发阶段计划？ 通过沟通了解项目组是否明确了需求获取的信息 内容、来源与渠道？ 需求获取 项目组是否采用了至少一种需求获取技术获取相 关的需求？是否形成了相关的资料与记录？ 是否根据需求获取的结果编制了《用户需求说明 书》？ 项目经理是否组织进行了软件需求分析工作？ 需求分析是否采取了相关的分析方法？ 需求分析与 需求分析师是否为每一个软件需求分配了一个需 定义 求编号？且该编号是唯一的。 是否根据规定的标准确定了需求的优先级？ 是否编制形成了《软件需求规格说明书》？ 是否提出了需求技术评审会议申请 评审通过后，是否采用了适当的方式获得了客户 与关联项目组的需求确认？ 需求确认 是否在需求评审通过后建立了需求跟踪矩阵？ 项目经理是否指定人员对需求跟踪矩阵进行了个 人复查？ 需求的变更是否提出了申请？ 发生需求变更后，是否同步更新了需求文档？ 需求变更与 每次需求变更完成后，是否对需求跟踪矩阵进行 跟踪 了修改？ 在项目的每个阶段产品完成后，是否由项目的相 关人员补充填写了需求跟踪矩阵的相应内容？ 完整性、规 是否遵循标准的软件需求规格说明书模板 范性 是否遵循需求开发与管理的其他模板
(项目简称)-RDM-需求跟踪矩阵
软件需求功能标题
软件需求变更标识
需求等所有需求项； 明书》通过评审和确认后开始跟踪； 格说明书》通过评审后开始跟踪；
阶段《需求跟踪矩阵》的填写和维护； 和计算百分比； 中的需求情况的度量数据收集到《数据度量及分析表》的“项目需求管理”页中。
用户需求标题
用户需求变更标识
填பைடு நூலகம்说明：
1、需求跟踪的内容包含功能需求和非功能需求等所有需求项； 2、定制类项目跟踪的源头从《业务需求说明书》通过评审和确认后开始跟踪； 3、研发类项目跟踪的源头从《软件需求规格说明书》通过评审后开始跟踪；
4、第一张表格由项目组成员负责各自开发阶段《需求跟踪矩阵》的填写和维护； 5、第二张表格不需要填写，已经自动统计和计算百分比； 6、项目经理在各阶段里程碑点将第二张表中的需求情况的度量数据收集到《数据度量及分析表》的“项目需求管理”
软件问题报告问题跟踪矩阵(全)
低
已建议
57
组织机构形成树形维护，提供统一查询维护的管理界面
中
已建议
58
企业信息管理 名称与客户协商
中
已建议
59
“设置配送企业”审核不通过状态是可以删除的
中
已建议
60
增加修改药品状态可以停止采购该药品配送企业设置”药品过期状态有两个“GMP过期”“注册批件过期” 中
已建议
62
中
已建议
39
编辑不限不竞表，最小单位要可以选，不能填
中
已建议
40
新增医院不限不竞目录，不可编辑区域灰掉与可编辑区域区分
高
已建议
41
“采购计划管理”“采购计划初审”“采购计划复审”如果未发送时间列为
空，不显示“1970-01-01”
高
已建议
42
编辑采购单，保存不了之前编辑的采购数量
高
已建议
43
“退货管理”，退货数量不能高于发货数量，新建的退货列表不能删除
低
已分析
3
查看采购单，不应该有“勾选”框，系统所有涉及此类查询都需要修改
高
已实现
4
要加医院评价，增加医院对药品和配送企业的评价等，这个只能给药招采购
中心看
低
已分析
5
交易明细记录查询，条件还不灵活，要增加 “生产企业”等选择。要了解
客户需求
低
已分析
6
可以双击点击进去的，变成手指头
中
已分析
7
查看采购单，审批的时候不要发送人：初审查询界面，增加审核通过和不通
2011/9/10 2011/9/10
2011/9/10 2011/9/10 2011/9/10 2011/9/10 2011/9/10
需求跟踪矩阵 模板
表格编号：XY202-项目编号-两位顺序号
项目名称： 需求分析 用户需求 编号 章节编号 需求名称 首页 1 状 章节 态 编号 原 始 软件需求 子模块名 系统监视 状态 原始 修改 删除 增加 风电监控 2 修 改 需求优 先级 高 中 低 责任人 概要设计 章节编号
3
删 除
4
567源自8原始需求总数 修改需求总数 删除需求总数 增加需求总数 总需求数
3 0 0 0 3
需求跟踪矩阵
项目经理PM： 系统设计 概要设计 名称 是否完成 责任人 详细设计 章节编号 名称 是否完成 责任人 代码单元 编码实现 是否完成 责任人 √ √
项目QA： 功能测试 测试单元 是否完成 责任人 备注
FTCS需求跟踪矩阵表技术评审报告
《FTCS用户需求说明书（系统）》
《FTCS软件需求跟踪矩阵表单》
产品批准人
（审核人）
意见
同意评审
由XX担任评审负责人，按技术评审流程开展评审工作。
评审方式： 正式技术评审（会议评审）
□非正式技术评审（□Email会签□走查□其他：）
评审级别：□部门级□子部门级□项目组内
xxx
日 期
2007年10月9日下表）
序号
缺陷内容
修正措施
实施结果
实施人、日期
1
在《软件需求跟踪矩阵表单》的SRS列表中没有填写’需求分级’
在需求跟踪矩阵中对SRS列表进行需求分级。
完成
ZZ
2007-10-9
2
其它具体参见文档缺陷见《缺陷管理表》
其它具体参见文档缺陷见《缺陷管理表》
评审
人员签名
XX,YY,ZZ,…
其他参与
人员签名
ZZ
评审意见
汇总
一、缺陷识别
序号
缺陷描述
严重性
建议缺陷解决方案
1
在《软件需求跟踪矩阵表单》的SRS列表中没有填写’需求分级’
严重
补充详细
2
其它文档缺陷见《缺陷管理表》
一般
修改文档
二、总体评价及建议
需求分析比较透彻、完善，而且能够将客户需求与产品需求、高层设计、单元测试、集成测试和系统测试等统一起来管理，工作进行的比较认真。
XXX项目
需求跟踪矩阵表技术评审报告
项目名称
XXX系统
项目级别
□公司级 部门级□子部门级
项目经理
XX
要求评审的工作产品的名称
《FTCS产品需求规格说明书》
需求跟踪矩阵编写指南(共7页)
需求跟踪矩阵编写指南工程股份公司__年三月文件变更记录目录1目的 (1)2角色和职责 (1)3格式 (1)4表格说明 (1)4.1项目基本信息 (1)4.1.1 角色等基本信息 (1)4.2需求跟踪矩阵（纵向） (1)4.2.1 基线标识 (1)4.2.2 列值说明 (1)4.2.3 注意事项 (3)4.3 需求跟踪矩阵（横向） (4)4.3.1 列值说明 (4)5需求跟踪矩阵的不断完善 (4)1目的需求跟踪是需求管理的一项重要内容。
需求跟踪的主要意义在于获得需求目前的实现状态，确保用户所有的需求都得到满足。
它的主要目标是: 维护软件工作产品间的一致性。
2角色和职责3格式需求跟踪矩阵采用E_CEL电子表格形式制作。
具体格式请参考《需求跟踪矩阵模板》。
4表格说明4.1项目基本信息角色等基本信息填写项目名称、项目经理、项目小组责任人、更新次数、最后更新日期、更新需求跟踪矩阵的工作量（多次更新累加）以及版本号（此为需求跟踪矩阵的版本号）等信息。
4.2需求跟踪矩阵（纵向）4.2.1 基线标识列出该需求跟踪矩阵中用到的各个工作产品的基线标识号。
4.2.2 列值说明关于优先级的说明：优先级表示的是某项内容相对于同类的其他内容的优先级顺序，其取值范围为：高、中、低。
如果某几项内容的优先级相同则将其优先级设为相同的值。
《用户需求说明书》需求编号：《用户需求说明书》中描述软件需求的唯一代号（或标识）。
责任人：相关需求的责任人。
《软件需求规格说明书》需求编号：《软件需求规格说明书》中每项需求的编号（如：章节号）。
责任人：相关需求的责任人。
优先级：相对于其他需求，实现该需求的优先级顺序。
《系统测试方案》系统测试用例编号：《系统测试方案》中用例的编号（如：章节号）。
责任人：相关测试的责任人。
优先级：相对于其他测试用例，实施该用例测试活动的优先级顺序。
《概要设计说明书》概要设计编号：《概要设计说明书》中每条设计的编号（如：章节号）。
南中心95598供电服务中心需求跟踪矩阵
模块 01业务分册
一级模块名称
软电话
来电信息
来电前次服务
客户识别
客户资料查询
模板导入
服务评价
座席工作台业务受理辅助 转IVR
服务异常回呼
地址定位
停电信息查询
待办事宜提醒
最新故障工单
对内公告信息
KPI指标
咨询受理
业务咨询
咨询回复 咨询归档
咨询查询
信息查询
查询受理 查询归档
故障报修受理
故障报修
故障报修回访 故障报修归档
停电信息管理
03系统运行监 测分册
信息发布管理
工单终止 运营总览
服务指标
流程监测 业务统计 视频监测 平台监测 气象监测 蜂拥监测
信息发布管理
工单终止 运营总览 话务接入监测 服务队列监测 服务水平监测 座席工作监测 流程监测 业务统计 视频监测 平台监测 气象监测 蜂拥监测
话务类
手机号首归属地对照表维护信息列表 固话号首归属地对照表维护信息列表 短信发送 待回访工单解锁
告警指标管理 告警用户管理 告警策略管理 告警项管理
工单挂起申请 工单挂起审核 工单挂起列表
供电服务突发事件信息 企业简介 事务公告 电力法律法规 服务指南 供电服务承诺 营业收费 曝光信息 文件颁布信息 停电信息收集 停电信息审核 停电信息发布 发布申请 信息审核 信息发布 工单终止
运营总览 话务接入监测 服务队列监测 服务水平监测 座席工作监测 流程监测 业务统计 视频监测 平台监测 气象监测 蜂拥监测 电话服务综合分析表 IVR业务统计表 接听、放弃、呼损统计表 业务平均处理时长统计表 座席小时话务数据统计
业扩类
05质检管理功 能分册
CMMI-3需求跟踪矩阵同行评审检查单
项目名称 检查人 检查目的
当前阶段 检查日期
责任人
序号 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
1 2 3 4
检查项 每个需求都标识了明确的来源? 每个派生的需求可以追溯到来源吗? 每个需求与其他需求的关联是否标识出? 每个客户需求是否与一个或多个软件需求对应? 每个需求是否对应一个或多个概要设计吗? 每个概要设计是否对应正反向一个或多个详细设计? 每个详细设计是否对应一个或多个模块(编码单元)吗? 每个模块是否对应模块/单元测试用例? 每个概要设计是否对应一个或多个集成测试用例? 客户需求是否对应系统测试用例? 对于性能需求是否有对应的测试用例？ 需求变更后需求跟踪矩阵是否与变更后的文档内容对应 每个需求是否被唯一标识，并保持唯一标识 ？ 每个需求与其他需求的关联变更后是否重新进行了标识 ? 当前的需求是否与项目计划保持一致 ？ 当前的需求是否都得到项目相关人员的承诺 ？（变更后再承 诺） 需求库控制的需求粒度与需求跟踪矩阵列出的粒度是否保持一致 当需求的变化没有引起需求跟踪矩阵的变化时是否说明理由
检查结果 本次检查是否可以通过 发现的问题是否登记在项目的《问题跟踪表》中 是否已经落实了解决问题的责任人、检查人 新修改的需求跟踪矩阵是否按照配置管理的要求进行了管理
是/否 是 是 是 是 是
是 是 是 是
最终关闭问题 日期： 负责人签字：
说明
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
6 所有的概要设计是否都为之设计了集成测试用例。
7 工作产品变更后，需求跟踪矩阵（RTM）是否也保持一致。
8 检查需求跟踪矩阵是否与项目计划一致？
9
10
11
12
13
14
151617 Nhomakorabea20
owner责任人
花费时间：
不一致个数(自动统
结果
备注
Y
N NA 无关
0 评审发现
负责人
状态
需求跟踪矩阵检查单
项目名称：
审核日期：
审核人：
编号
审查点
1 项目的功能需求是否在需求跟踪矩阵（RTM）存在对应。
2 项目的性能、安全等其他需求是否也写入需求跟踪矩阵（RTM）。
3 每条需求是否都可以方便的通过一条或多条测试用例进行测试。
4 需求跟踪矩阵（RTM）是否根据项目的情况进行了裁剪。
5 所有的详细设计是否都为之设计了单元测试用例。