需求跟踪矩阵编写指南

需求跟踪矩阵填写指南本资料仅供内部使⽤！需求跟踪矩阵填写指南XXXXXXXXXXXXX公司20XX年XX⽉XX⽇修改记录⽬录1需求跟踪矩阵填写说明 (1)2需求跟踪矩阵的维护和使⽤ (1)3裁剪指南 (2)1需求跟踪矩阵填写说明【需求跟踪矩阵】⽤以跟踪需求到设计、设计到编码、编码的测试的映射过程。

项⽬组可以根据实际情况裁剪模板的格式来满⾜项⽬的要求。

需求跟踪矩阵的填写遵循以下原则：需求号：为每条需求编制唯⼀的识别号，通过需求号可以与需求⽂档中描述的需求建⽴⼀⼀对应关系。

建议不要使⽤章节号作为需求号。

如果没有在编程规范或需求跟踪矩阵中说明编号的格式，则可以按⼀下格式编号：●需求号＝⼀级功能编号.⼆级功能编号.三级功能编号.N级功能编号●建议最多不要超过5级；●例⼦：需求号1.2.1表⽰：第⼀个⼀级功能的第⼆个⼆级功能的⼀个三级功能。

软件需求描述：简单描述需求内容。

这个描述看是冗余，但有简单描述可以使得跟踪矩阵更具可读性和独⽴性。

概要设计：描述需求在概要设计中的实现情况。

建议使⽤编号对应，也可以使⽤⽂字对应，建议不要使⽤章节号。

如果使⽤编号，请在编程规范中说明编号规则。

详细设计：描述概要设计在详细设计中的实现情况。

建议使⽤编号对应，也可以使⽤⽂字对应，建议不要使⽤章节号。

如果使⽤编号，请在编程规范中说明编号规则。

编码：描述详细设计在编码时的实现情况。

可以使⽤函数名称，⽂件名称，对象名称等。

单元测试⽤例：描述详细设计对应的测试⽤例。

集成测试⽤例：描述概要设计对应的测试⽤例。

业务测试⽤例：描述需求对应的测试⽤例。

2需求跟踪矩阵的维护和使⽤跟踪矩阵有助于在各个⽣命周期阶段跟踪所有需求，以此来确保实现所有已并⼊的需求，这也避免了由于遗漏需求⽽进⾏的重复劳动。

通过为评审专家提供⼀套机制，矩阵有助于评审，使得很容易检验是否已处理所有的需求。

当需求变更时，矩阵中包含的信息可⽤于分析变更带来的影响。

它也有助于向顾客验证所开发的软件满⾜所有需求⽽且已经得到了充分的测试。

需求跟踪矩阵（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 的工作量还是比较大、比较烦琐。

编写需求跟踪矩阵指南山东中创软件工程股份有限公司二ОО七年三月文件变更记录*A–增加M–修改D–删节目录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格式需求跟踪矩阵采用EXCEL电子表格形式制作。

具体格式请参考《需求跟踪矩阵模板》。

4表格说明4.1项目基本信息4.1.1 角色等基本信息填写项目名称、项目经理、项目小组责任人、更新次数、最后更新日期、更新需求跟踪矩阵的工作量（多次更新累加）以及版本号（此为需求跟踪矩阵的版本号）等信息。

4.2需求跟踪矩阵（纵向）4.2.1 基线标识列出该需求跟踪矩阵中用到的各个工作产品的基线标识号。

4.2.2 列值说明关于优先级的说明：优先级表示的是某项内容相对于同类的其他内容的优先级顺序，其取值范围为：高、中、低。

如果某几项内容的优先级相同则将其优先级设为相同的值。

《用户需求说明书》需求编号：《用户需求说明书》中描述软件需求的唯一代号（或标识）。

责任人：相关需求的责任人。

《软件需求规格说明书》需求编号：《软件需求规格说明书》中每项需求的编号（如：章节号）。

责任人：相关需求的责任人。

优先级：相对于其他需求，实现该需求的优先级顺序。

《系统测试方案》系统测试用例编号：《系统测试方案》中用例的编号（如：章节号）。

责任人：相关测试的责任人。

优先级：相对于其他测试用例，实施该用例测试活动的优先级顺序。

《概要设计说明书》概要设计编号：《概要设计说明书》中每条设计的编号（如：章节号）。

需求跟踪矩阵维护指南*C A——M——D——文档审批信息目录1简介 (1)1.1文档目的 (1)1.2适用范围 (1)1.3术语表 (1)1.4参考资料 (1)2需求模块功能矩阵建立 (1)2.1《需求模块功能矩阵》概述 (1)2.2需求模块功能矩阵建立流程 (1)2.2.1创建《需求模块功能矩阵》 (1)2.2.2需求定义和需求分析阶段《需求模块功能矩阵》的填写 (2)2.2.3设计阶段《需求模块功能矩阵》的填写 (2)2.2.4编码阶段《需求模块功能矩阵》的填写 (3)2.2.5测试阶段《需求模块功能矩阵》的填写 (3)3需求模块功能矩阵变更 (3)3.1需求模块功能矩阵变更概述 (3)3.2需求模块功能矩阵变更流程 (3)3.2.1设计阶段需求变更 (4)3.2.2编码阶段需求变更 (4)3.2.3测试阶段需求变更 ........................................... .43.2.4维护阶段需求变更 (5)4需求功能编号的编写规则 (5)1简介1.1文档目的本规程的目的是为了定义在软件生命周期内维护《需求模块功能矩阵》的时机，并规定软件生命周期各阶段维护《需求模块功能矩阵》的主要内容、入口、出口和人员等。

1.2适用范围本规程适用于公司的所有软件项目。

1.3术语表无1.4参考资料1.《软件需求管理过程》2.《软件需求》，Karl E. Wiegers著，陆丽娜、王忠民、王志敏等译，机械工业出版社，2000年7月2需求模块功能矩阵建立2.1 《需求模块功能矩阵》概述需求追溯贯穿项目的整个生命周期，即在项目的各个阶段均要进行软件需求的追溯，通过不同阶段填写《需求模块功能矩阵》，建立软件需求与开发过程的追溯关系，这样可以根据软件需求追溯到开发工作产品，从而确保每个工作产品满足每个需求。

2.2 需求模块功能矩阵建立流程2.2.1创建《需求模块功能矩阵》创建人：项目经理前提：项目经理指定了项目成员角色，包括需求人员（填写《需求模块功能矩阵》的需求项），设计人员（填写设计项），开发人员（填写实现项），测试负责人（填写测试项）。

用户需源自代号需求获取 用户需求项名称
用户需求功能描述
软件需求代号
软件需求项名称
需求分析 软件需求功能描述 原型 文件名
需求间关系 受影响的软件需求代号 受影响的软件需求名称
模块（构件） 模块（构件）名称
模块设计 文件名/章节 文件名 章节
概要设计 接口设计 文件名/章节 文件名 章节
数据表设计 数据表名称
其它设计元 素 文件名/章节 文件名 章节
详细设计 文件名/章节 文件名 章节
代码实现 文件名
单元测试 测试用例 文件名/用例编号 文件名 用例编号
集成测试 测试用例 文件名/用例编号 文件名 用例编号

填写说明：
1）产品经理完成本文件的第一版，后续由软件需求、设计、测试负责人进行完善
2）本文件与产品需求、软件需求、设计文档、测试案例一同评审并基线
3）项目组如裁剪软件需求，则需完成产品需求到设计的跟踪，可删除软件需求到设计跟踪
4）项目组如不裁剪软件需求，则需完成软件需求到设计的跟踪，产品需求到设计的跟踪可删除5）测试案例如使用TD维护，应将可说明跟踪关系的截图粘贴在产品需求到测试案例跟踪一页
6）其他跟踪关系项目组可自行添加，如跟踪到架构设计、集成测试案例、单元测试案例、代码等。

2005.XX.XX： 项目需求文档V2.0
NF_1 NF_2 NF_3
注意事项： 注意事项： 文档命名： 1 需求文档/概要设计文档/测试用例文档等命名遵循命名格式：XX项目＋文档类型名称 需求 版本保持一致. 需求功能点编号： 1、功能点编号与需求文档中需求点保持一致，如有新增或变更等,不改动此表中原功能点信息 点。 2 例如，客户申请更改F_1功能点,工程师需在需求文档的功能点列表中增加 填写必要说明信息，如："Cancel或变更"。之后重新跟踪变更后的功能点 命名为V2.0。 2、注意后续的设计、测试用例等文件均需做出对应的变动并更新版本， 3 4 5 6 7 8 9 10
识别信息 项目编号： 项目名称： 需求规格书最新基线版本： 需求文档 版本、日期） （版本、日期） 2005.07.25： XX项目需求文档V1.0 F_1 F_2 F_3 F_4 F_5 F_6 2005.XX.XX： 项目需求文档V1.1
需求功能点编号
客户关键程度
实现复杂度
CR_1 CR_2 CR_3 CR_4 CR_5 CR_6
客户关键程度（需求重要程度）：A（非常重要）、B（重要）、C（一般 实现复杂度：复杂、一般、简单。 设计模块：可填写设计文档名及设计文档中与需求点对应的几个设计模块的编号及名称 代码文件名：对应需求点的代码文件名，可由工程师提供。也可提供代码实现对应需求的版本及 Comment：在此栏说明需求对应关系链的变更情况，如close/open/变更/ CR－Change Request；NF－New Feature（新功能） 目前需求跟踪矩阵只在需求功能点编号中体现变更或新增，后续的设计等文档编号中并没有体现 需求跟踪累计总工时：统计每个需求点跟踪工时累计的总和。

编号 类型
一级菜单
模块名称
1 界面需求
全局
全局
2 功能需求 3 功能需求 4 功能需求 5 功能需求 6 功能需求 7 功能需求 8 功能需求 9 功能需求 10 功能需求 11 功能需求 12 功能需求 13 功能需求 14 功能需求
全局 用户管理 用户管理 用户功能 用户功能 用户功能 用户功能 用户功能 用自定义。
单位设置 账户权限过滤 账户登录 对用户进行分组管理 按管理层级查询（及操作）用户权限台帐明细 修改用户组信息 删除用户组 添加新用户 不同角色查看不同的页面 按部门管理不同的用户 访问时间、ip范围等 不同角色配置不同的节点查看操作权限 不同角色配置不同的数据查看操作权限
全局 全局/用户管理 用户权限管理 用户权限台帐 用户权限台帐 用户权限台帐 用户权限台帐 用户权限台帐 用户权限管理 用户组管理 访问配置 用户权限管理 用户权限管理
需求编号
IR001
BR001 BR002 BR003 BR004 BR005 BR006 BR007 BR008 BR009 BR010 BR011 BR012 BR013
优先 所属阶段 级 低 第2阶段
中 第2阶段 中 第2阶段 中 第1阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第3阶段 高 第2阶段 高 第2阶段
对应功能
上传Logo图片和输入 项目名称 修改各参数的单位标 签 权限过滤 登录 新建用户组 用户（组）节点树 编辑用户组 删除用户组 添加新用户 权限过滤
数据表
接口
../auth/v1/login
自测用例
系统测试用例 完成情况
R
R R R R S S S S S S S S S

需求跟踪矩阵编写指南工程股份公司__年三月文件变更记录目录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 列值说明关于优先级的说明：优先级表示的是某项内容相对于同类的其他内容的优先级顺序，其取值范围为：高、中、低。

如果某几项内容的优先级相同则将其优先级设为相同的值。

《用户需求说明书》需求编号：《用户需求说明书》中描述软件需求的唯一代号（或标识）。

责任人：相关需求的责任人。

《软件需求规格说明书》需求编号：《软件需求规格说明书》中每项需求的编号（如：章节号）。

责任人：相关需求的责任人。

优先级：相对于其他需求，实现该需求的优先级顺序。

《系统测试方案》系统测试用例编号：《系统测试方案》中用例的编号（如：章节号）。

责任人：相关测试的责任人。

优先级：相对于其他测试用例，实施该用例测试活动的优先级顺序。

《概要设计说明书》概要设计编号：《概要设计说明书》中每条设计的编号（如：章节号）。

软件需求跟踪矩阵范本软件开发过程中，需求跟踪是一个至关重要的环节，它有助于保证项目顺利进行，并满足用户的需求。

而软件需求跟踪矩阵作为一种工具，可以有效追踪需求的实现情况、与测试案例的对应关系等信息，为项目管理和测试提供了便利。

本文将以一个范例的形式，介绍软件需求跟踪矩阵的基本构建和使用方法。

一、需求跟踪矩阵的构建需求跟踪矩阵可以根据项目的实际情况进行定制，以下是一个基本的范本，包含了一些常见的列及其含义：1. 需求ID：每个需求在需求文档中应有唯一的标识，需求ID可以用来追踪和引用特定的需求。

2. 需求描述：清晰、准确地描述需求的内容和目的。

3. 设计文档中的需求ID：如果需求在设计文档中有进一步细化，可以记录其对应的设计文档中的ID。

4. 测试案例ID：为每个需求编写相应的测试案例，并在此列记录其唯一标识。

5. 实现情况：记录需求的开发和实现进度，例如"已实现"、"待实现"、"已废弃"等状态。

6. 测试结果：记录对每个测试案例的执行结果，例如"通过"、"失败"等。

7. 备注：可以记录一些额外的信息，如需求的变更历史、实现细节等。

这只是一个基本的模板，根据项目的具体需求，可以增加或调整更多的列。

当然，在构建需求跟踪矩阵时，也需要考虑到团队成员的实际情况，并根据项目管理的要求进行个性化的修改。

二、需求跟踪矩阵的使用方法需求跟踪矩阵的目标是将需求与其对应的设计、实现和测试环节联系起来，以确保开发过程中的每个环节都能按照需求文档的要求进行。

下面是一些使用需求跟踪矩阵的常见方法：1. 需求的分解与整理：将项目的需求文档梳理完善后，将每个需求在矩阵中进行记录，并填写相应的需求描述。

2. 设计与开发过程：与开发团队紧密合作，将需求在设计文档中进行细化，并在矩阵中填写对应的设计文档ID。

3. 编写测试案例：根据每个需求编写对应的测试案例，并在矩阵中记录其唯一标识。

软件需求功能标题
软件需求变更标识
需求等所有需求项； 明书》通过评审和确认后开始跟踪； 格说明书》通过评审后开始跟踪；
阶段《需求跟踪矩阵》的填写和维护； 和计算百分比； 中的需求情况的度量数据收集到《数据度量及分析表》的“项目需求管理”页中。
用户需求标题
用户需求变更标识
填பைடு நூலகம்说明：
1、需求跟踪的内容包含功能需求和非功能需求等所有需求项； 2、定制类项目跟踪的源头从《业务需求说明书》通过评审和确认后开始跟踪； 3、研发类项目跟踪的源头从《软件需求规格说明书》通过评审后开始跟踪；
4、第一张表格由项目组成员负责各自开发阶段《需求跟踪矩阵》的填写和维护； 5、第二张表格不需要填写，已经自动统计和计算百分比； 6、项目经理在各阶段里程碑点将第二张表中的需求情况的度量数据收集到《数据度量及分析表》的“项目需求管理”

姓名 文本框 必填项，支持20个字符，支持汉字、字母、数字、下划线，特殊字符等
姓名 文本框 必填项，支持20个字符，支持汉字、字母、数字、特殊字符等
教师用户名 文本框 必填项，支持２０个字符，支持汉字、字母、数字、特
殊字符等
教师用户名 文本框 必填项，支持２０个字符，支持汉字、字母、数字、特殊字符等
发.测试
要求必须输入yyyy-mm-dd格式
1.搜索功能能用，且按钮存在
2.可以根据教师姓名,教授方向,隶属角色,入职日期等内容进行单项查询或组合查询，并都支持模糊查询
3.确定搜索文本框可用，并支持信息输入
4.搜索文本框支持20个字符（一个汉字占两个字符），支持汉字、字母、数字、特殊字符等
5.搜索文本框要支持yyyy-mm-dd
格式,且不能晚于系统时间
教师管理模块-编辑模块：
1.隶属角色-下拉列表-根据班级管理中的角色进行选择；
2.姓名-文本框-必填项，支持20个字符，支持汉字、字母、数字、特殊字符等；（一个汉字占两个字符）
3.教师用户名-文本框-必填项，支持20个字符，支持汉字、字母、数字、特殊字符等；（一个汉字占两个字符）
4.密码-文本框-支持10位字符，支
字符，支持汉字、字母、数字、特殊字符等；（一个汉字占两个字符）
3.教师用户名-文本框-必填项，支持20个字符，支持汉字、字母、数
字、特殊字符等；（一个汉字占两个字符）
4.密码-文本框-支持10位字符，支持数字,字母，特殊符号（字母区分大小写）；
5.教授方向-单选-备选开发和测试；
6.入职时间-文本框-要求必须输入yyyy-mm-dd格式。

入职时间。

添加所需播放的歌曲点击界面列表名单击右键选择添加选项选择文件所处位置进行选择文件打开文件添加成功在界面查询空白框输入歌曲名点击查询按钮然后跳到列表中歌曲的位置在界面查询空白框输入歌手点击查询按钮然后跳到列表中歌曲的位置点击列表然后右键选择列表循环列表存在歌曲信息记录但本地文件不存在则跳到下一个文件播放列表最后一个文件结束后则跳到列表第一个文件点击列表中该首歌曲的歌曲名然后右键选择单曲循环正在播放单曲循环歌曲时点击下一个则下一个歌曲单曲循环下一个歌曲为列表最后一个歌曲时则跳到列表第一个歌曲循环
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）完成状态，在测试结束后，由项目经理填写。

的管理和控制，保证一致性。

需求跟
表格编号：XY202-项目编号-两位顺序号
项目名称： 需求分析 用户需求 编号 章节编号 需求名称 首页 1 状 章节 态 编号 原 始 软件需求 子模块名 系统监视 状态 原始 修改 删除 增加 风电监控 2 修 改 需求优 先级 高 中 低 责任人 概要设计 章节编号
3
删 除
4
567源自8原始需求总数 修改需求总数 删除需求总数 增加需求总数 总需求数
3 0 0 0 3
需求跟踪矩阵
项目经理PM： 系统设计 概要设计 名称 是否完成 责任人 详细设计 章节编号 名称 是否完成 责任人 代码单元 编码实现 是否完成 责任人 √ √
项目QA： 功能测试 测试单元 是否完成 责任人 备注

概要
状态
系统 系统编 对应概要 详细设 对应详细 单元测 集成测 测试用 对应代码 码状态 设计章节 计状态 设计章节 试用例 试用例 例 4.1.2.3 4.1.2.4 4.1.2.5 评审通 6.1.2 过 评审通 6.1.3 过 评审通 6.1.4 过 E1 E2 E3 E5 E6 E7 T3.1 T3.2 T3.3 emis导出 业务代码 emis导出 业务代码 emis导出 业务代码 已单元 测试 已单元 测试 已单元 测试
3 6 0 0 3 9 6
备注说明
评审通 6.1.5 过
E4 E5 E6 E8
E8 E9 E10 E12
T3.4 T3.5 T3.6 T3.8
emis导出 已单元 业务代码 测试 emis导出 业务代码 emis导出 业务代码 emis导出 业务代码 已单元 测试 已单元 测试 已单元 测试
FR002
合同综 合查询
原始
3.3.2 3.3.4
增加 增加 增加 增加 增加 增加 原始 原始 原始
已批准 已批准 已批准 已批准 未批准 已批准 已批准 已批准 已批准
需求开发 结项 结项 编写
通过 评审 系统设计 通过
结项 结项 结项 结项
评审 通过 评审 通过 评审 通过 评审 通过
4.1.2.6 4.1.2.7
评审通 6.1.6 过 评审通 4.1.2.8 6.1.7 过 评审通 4.1.2.10 6.1.9 过
原始的需求： 原始的需求： 增加的需求： 增加的需求： 修改的需求： 修改的需求： 删除的需求： 删除的需求： 未变更需求数： 未变更需求数： 现有需求总数： 现有需求总数： 需求变更总数： 需求变更总数：
XXXX项目需求跟踪矩阵 XXXX项目需求跟踪矩阵

已建议该需求已被有权提出需求的人建议
已批准该需求已被分析，估计了其对项目余下部分的影响（包括成本和对项目其余部分的干扰），已用一个确定的产已实现已实现需求代码的设计、编写和单元测试
已验证使用所选择的方法已验证了实现的需求，例如测试和检测，审查该需求跟踪与测试用例相符。

该需求现在被认已删除计划的需求已从基线中删除，但包括一个原因说明和做出删除决定的人员
用一个确定的产品版本号或创建编号分配到相关的基线中，软件开发团队已同意实现该项需求例相符。

该需求现在被认为完成。