需求跟踪矩阵编号规则
【PMP考试通】需求文件和需求跟踪矩阵
【PMP考试通】需求文件和需求跟踪矩阵收集需求过程是PMBOK中相对比较重要的一个过程，该过程的ITTO（“输入、工具、输出”的英文单词缩写）都非常重要，所以这是在授课时着重去讲的过程。
今天我们主要来讨论一下该过程的输出—需求文件和需求跟踪矩阵。
经常会有学员会有疑问，不太理解需求文件和需求跟踪矩阵的区别，我们先来看一下PMBOK对于这两项文件的描述：需求文件描述各种单一需求将如何满足与项目相关的业务需求。
一开始,可能只有高层级的需求,然后随着有关需求信息的增加而逐步细化。
只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要干系人愿意认可的需求,才能作为基准。
需求文件的格式多种多样,既可以是一份按干系人和优先级分类列出全部需求的简单文件,也可以是一份包括内容提要、细节描述和附件等的详细文件。
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。
使用需求跟踪矩阵,把每个需求与业务目标或项目目标联系起来,有助于确保每个需求都具有商业价值。
需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法,有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。
最后,需求跟踪矩阵还为管理产品范围变更提供了框架。
我们把以上内容简化一下：需求文件，可以理解为是对已经收集到的各种需求的记录文件，为了使需求文件看起来更加正式正轨，我们可以对已经记录的需求进行分类，例如业务需求、干系人需求、解决方案需求、项目需求等；而需求跟踪矩阵，就是将与需求关联的一系列属性通过表格的形式记录，这样根据需求的编号可以向前或向后追踪，向前可以追踪到原始需求，向后可以追踪到可交付成果等，目的是为了保证成果是符合干系人需求并且满足商业利益和价值。
所以我们总结一下，需求文件的关键词在于“记录”，需求跟踪矩阵的关键词在于“追踪”。
那么如果在项目中出现了需求的“增删改”，那么我们就可能要进行需求文件的更新，而需求跟踪矩阵就能够告诉我们更改的需求对项目的目的目标是否有影响。
简练网软考知识点整理-项目需求跟踪及需求跟踪矩阵
简练⽹软考知识点整理-项⽬需求跟踪及需求跟踪矩阵1.需求跟踪需求跟踪包括编制每个需求同系统元素之间的联系⽂档。
这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助⽂件、⽂档等。
跟踪能⼒信息使变更影响分析⼗分便利，有利于确认和评估实现某个建议的需求变更所必须的⼯作。
2.需求跟踪⽬的需求跟踪提供了⼀个表明与合同或说明⼀致的⽅法，需求跟踪可以改善产品质量，降低维护成本，⽽且很容易实现重⽤。
需求跟踪是个要求⼿⼯操作且劳动强度很⼤的任务，要求组织提供⽀持。
随着系统开发的进⾏和维护的执⾏，要保持关联链信息与实际⼀致。
跟踪能⼒信息⼀旦过时，可能再也不会重建它了。
由于这些原因，应该正确使⽤需求跟踪能⼒。
下⾯是在项⽬中使⽤需求跟踪能⼒的⼀些好处：（1）审核跟踪能⼒信息可以帮助审核确保所有需求被应⽤。
（2）变更影响分析跟踪能⼒信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。
（3）维护可靠的跟踪能⼒信息使得维护时能正确、完整地实施变更，从⽽提⾼⽣产率。
要是⼀下⼦不能为整个系统建⽴跟踪能⼒信息，⼀次可以只建⽴⼀部分，再逐渐增加。
从系统的⼀部分着⼿建⽴，先列表需求，然后记录跟踪能⼒链，再逐渐拓展。
（4）项⽬跟踪在开发中，认真记录跟踪能⼒数据，就可以获得计划功能当前实现状态的记录。
还未出现的联系链意味着没有相应的产品部件。
（5）再设计（重新建造）你可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。
通过定义跟踪能⼒信息链提供⼀种⽅法收集从⼀个现成系统的反向⼯程中所学到的⽅法。
（6）重复利⽤跟踪信息可以帮助你在新系统中对相同的功能利⽤旧系统相关资源。
例如：功能设计、相关需求、代码、测试等。
（7）减⼩风险使部件互连关系⽂档化可减少由于⼀名关键成员离开项⽬带来的风险。
（8）测试测试模块、需求、代码段之间的联系链可以在测试出错时指出最可能有问题的代码段。
以上所述许多是长期利益，减少了整个产品⽣存期费⽤，但同时要注意到由于积累和管理跟踪能⼒信息增加了开发成本。
需求跟踪矩阵(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 的工作量还是比较大、比较烦琐。
编写需求跟踪矩阵指南
编写需求跟踪矩阵指南山东中创软件工程股份有限公司二ОО七年三月文件变更记录*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 列值说明关于优先级的说明：优先级表示的是某项内容相对于同类的其他内容的优先级顺序，其取值范围为：高、中、低。
如果某几项内容的优先级相同则将其优先级设为相同的值。
《用户需求说明书》需求编号：《用户需求说明书》中描述软件需求的唯一代号（或标识）。
责任人：相关需求的责任人。
《软件需求规格说明书》需求编号：《软件需求规格说明书》中每项需求的编号（如：章节号）。
责任人：相关需求的责任人。
优先级：相对于其他需求，实现该需求的优先级顺序。
《系统测试方案》系统测试用例编号：《系统测试方案》中用例的编号（如：章节号）。
责任人：相关测试的责任人。
优先级：相对于其他测试用例，实施该用例测试活动的优先级顺序。
《概要设计说明书》概要设计编号：《概要设计说明书》中每条设计的编号（如：章节号）。
《需求ID编码规则》
《需求ID编码规则》需求ID编码规则修订历史记录A - 增加M - 修订D - 删除⽬录1. ⽬的 (4)2. 需求ID编码指南 (4)2.1. 需求说明书类型 (4)2.2. 需求类型 (4)2.3. 需求ID编码规则 (4)2.3.1. ⽤户需求编码的格式如下： (4)2.3.2. 软件需求编码的格式如下： (5)2.4. 编码说明 (8)1.⽬的为了做好需求跟踪，我们⾸先需要对所有的需求进⾏编号。
2.需求ID编码指南2.1.需求说明书类型1） URS（User Requirement Specification）：⽤户需求说明书。
2） SRS(Software Requirement Specification)：软件需求规格说明书。
3) NF(Non-Function)：⾮功能。
2.2.需求类型需求类型可以是：(1)功能性需求 F=功能需求（Function）； H=操作需求(Handle)； I=输⼊需求(Input)； O=输出需求(Output)； W=界⾯需求(Window)； R=⾓⾊及权限(Role)。
(2)⾮功能性需求 NF=⾮功能需求（Non-Function）；安全性（Security）；标准性（Standard）；可⽤性（Usability）；⾼效性(Efficiency)；稳定性（Stability）；灵活性（Agility）；可靠性（Reliability）；兼容性（Compatibility）；精度（Precision）；⼀致性(Conherence)；可扩展性（Expansibility）；易⽤性（Convenience）；清晰性（Clarity）；可移植性（Transplantation）；软硬件环境（Environment）；时间（Time）;(3)接⼝需求 I=接⼝(Interface)2.3.功能需求ID编码规则2.3.1.⽤户需求编码的格式如下：URS_ Function A_SF01_Xnn例如：URS_Function A_Login_I01 表⽰⽤户需求说明书中⼦功能A下的注册功能的输⼊需求。
信息系统项目管理师 需求跟踪矩阵内容口诀
信息系统项目管理师需求跟踪矩阵内容口诀以下是十个关于信息系统项目管理师需求跟踪矩阵内容的口诀：口诀一：需求跟踪矩阵初看同学们呀听我言，需求跟踪不犯难。
一先把那源头找，就像树根扎得牢。
需求来源是首要，用户期望这里挑。
二看需求啥内容，好比菜单列菜名。
功能性能和约束，详细列出才清楚。
这就像是搭积木，每块需求有定处。
先有框架再添补，需求矩阵不迷糊。
从始到终有条理，跟踪起来很容易，就像沿着小路走，每个站点都有数。
口诀二：需求分类与编号一要分类分得清，就像把书放柜中。
功能需求归一类，如同玩具放一堆。
非功能的单独放，好比文具另有箱。
二是编号不能忘，编号就像身份证。
每个需求一个号，独一无二错不了。
方便查找和管理，就像给娃贴个名。
顺着编号来跟踪，需求状态心里明。
从一到二按顺序，矩阵内容好整理。
口诀三：需求来源的明确一找需求哪里来，好比溯源找河海。
用户提出是大头，就像顾客点菜喽。
市场调研也重要，如同寻宝到处跑。
二把来源写清楚，不能马虎和糊涂。
是从访谈得的呢，还是问卷统计出。
就像记录小日记，详细记载才可以。
需求来源若不明，跟踪起来像乱风，搞清楚了再前进，矩阵内容才精准。
口诀四：需求描述要具体一要描述需求事，详细具体是大事。
不能含混说大概，就像画画要细致。
功能怎样去运作，像讲故事说透彻。
二是描述有条理，先说整体后局部。
比如描述小房子，先讲外形再内部。
需求描述不做好，矩阵就像乱麻包。
具体清晰是关键，就像钥匙开锁链。
按照这个来跟踪，需求变化能把控。
口诀五：需求的优先级排一先排好优先级，就像排队分前后。
紧急重要放前面，如同赛跑抢在前。
用户急需先处理，好像救火不容缓。
二把理由写清楚，为啥这个先照顾。
是对系统影响大，还是市场在催它。
就像解释为什么，有理有据才没错。
优先级排好了，跟踪起来有目标，矩阵里面排排坐，需求管理乐陶陶。
口诀六：需求状态的标记一标需求啥状态，就像标记花色彩。
未开始是一种色，好比种子没发芽。
进行中换个颜色，如同花朵正长大。
需求跟踪矩阵的内容
需求跟踪矩阵的内容1. 介绍需求跟踪矩阵需求跟踪矩阵是一个用于追踪软件项目需求的工具。
它能够帮助团队有效地管理和掌控需求变更，确保项目在开发过程中的各个阶段能够满足用户的需求。
该矩阵记录了项目的需求以及与之相关的信息，如需求的来源、状态、优先级等，从而为开发团队提供了一个清晰的需求全貌。
2. 需求跟踪矩阵的结构需求跟踪矩阵通常由表格组成，其中包含了多个字段用于描述需求的各个方面。
常见的字段包括需求编号、需求描述、需求来源、需求状态、所属模块、开发优先级、验收标准等。
这些字段能够帮助团队跟踪和管理需求的生命周期，并确保参与项目的各方都对需求有一个共同的理解。
2.1 需求编号需求编号是每个需求的唯一标识符，用于在矩阵中区分不同的需求。
编号可以采用自定义的规则，比如简单的序号、项目缩写+序号等。
2.2 需求描述需求描述是对需求的详细说明，包括需求的背景、目标、功能要求等信息。
一个清晰、准确的需求描述能够帮助开发团队准确理解用户的期望。
2.3 需求来源需求来源是指提出该需求的人或团队。
需求可以来自于不同的渠道，比如用户反馈、市场调研、相关部门等。
记录需求来源能够帮助团队了解需求的背景和动机。
2.4 需求状态需求状态标识了需求所处的状态，比如已提出、待评审、开发中、已完成等。
需求状态的变更能够帮助团队了解需求的进展情况，并及时处理需求相关的事务。
2.5 所属模块所属模块指明了需求所属的功能模块或系统模块。
将需求按模块分类能够帮助团队更好地组织和安排开发工作，并便于后续的维护和升级。
2.6 开发优先级开发优先级用于确定需求的重要性和紧急程度。
通过给需求设置优先级，团队可以合理安排开发资源，确保高优先级需求得到及时处理。
2.7 验收标准验收标准是对需求实现的一组判断规则。
它描述了需求完成后应满足的条件和表现，便于项目验收和用户验收的进行。
3. 如何使用需求跟踪矩阵需求跟踪矩阵在项目的不同阶段都扮演着重要的角色。
需求跟踪矩阵模板
地图显示项目点位。 ①地图放大、缩小；②回到
当前定位。 切换地图底图。 ①地名地址搜索；②持项目
名称搜素。 地图显示项目点位。 ①地图放大、缩小；②回到
当前定位。 切换地图底图。 ①地名地址搜索；②持项目
名称搜素。 地图显示项目点位。 ①地图放大、缩小；②回到
当前定位。 切换地图底图。 ①地名地址搜索；②持项目
件测试/验收交付
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
对应概要设 详细设计状 对应详细设
计章节
态
计章节
单元测试 集成测试用 系统测试
用例
例
用例
对应代码
示例：6.1.1 示例：修订 示例：6.1.1 示例：E1 示例：E5 示例：T3.1 示例：
一、项目信息（主要指项目基本信息）
项目名称 项目编号 客户名称 项目经理 项目发起人 编制人
日期
二、需求跟踪矩阵（把产品需求连接到可交付成果，把每个需求与业务目标或项目目标联系起来，有助于确保每
需求追踪矩阵
关于需求跟踪矩阵的6个问题1 需求跟踪矩阵（RTM）有什么作用？（1）在需求变更、设计变更、代码变更、测试用例变更时，需求跟踪矩阵是目前经过实践检验的进行变更波及范围影响分析的最有效的工具，如果不借助RTM，则发生上述变更时，往往会遗漏某些连锁变化。
（2）RTM也是验证需求是否得到了实现的有效工具，借助RTM，可以跟踪每个需求的状态：是否设计了，是否实现了，是否测试了。
2 需求跟踪矩阵分为哪几类？（1）纵向跟踪矩阵，包括如下的3种：需求之间的派生关系，客户需求到产品需求实现与验证关系：需求到设计，需求到测试用例等需求的责任分配关系；需求由谁来实现（2）横向跟踪矩阵：需求之间的接口关系3 在实践中，如何把握该建立哪些RTM？（1）在SEI的调查中达成的基本共识是：纵向跟踪是必须的，如果没有，则REQM SP1.4无法通过。
横向跟踪如果不作，则是大部分实施。
（2）对于纵向跟踪矩阵：必需的：客户需求与产品需求的跟踪⌝产品需求与测试用例的跟踪⌝100%的接口需求需要建立客户需求-产品需求-设计-编码-测试用例的跟踪矩阵⌝⌝全局性需求要建立跟踪矩阵,包括：客户需求-产品需求-设计-编码-测试用例的跟踪矩阵核心需求要建立跟踪矩阵⌝并非必需的：⌝性能需求可以不建立跟踪矩阵不影响系统架构的功能需求⌝4 需求跟踪矩阵由谁来建立？有多个角色参与建立RTM。
需求开发人员负责客户需求到产品需求的RTM建立，测试用例的编写人员负责需求到测试用例的RTM建立，设计人员负责需求到设计的RTM的建立等等。
PP QA负责检查是否建立了RTM，是否所有的需求都被覆盖了。
5 RTM是否纳入基线管理？RTM要纳入基线管理。
纳入基线后，每次变更都要申请，RTM的变更一般是和其他配置项的变更一起申请，很少单独申请变更RTM，除非RTM有错误。
6 如何简化RTM的工作？由于在RTM中，需求可能有很多项，设计、测试用例、代码等都有多项，所以建立和维护RT M的工作量还是比较大、比较烦琐。
CMMI5文档之需求跟踪矩阵维护规程
需求跟踪矩阵维护规程文档编号：FHI_CMMI_RM_PRD_FV A文档信息：需求跟踪矩阵维护规程文档名称：需求跟踪矩阵维护规程文档类别：CMMI规程密级：内部秘密版本信息：1.0建立日期：2016-1-5创建人：EPG批准人：李庆林批准日期：2016.2.25存放位置：集成公司组织资产库/组织标准过程编辑软件：Microsoft Office 2003 中文版文档修订记录目录1简介 (4)1.1文档目的 (4)1.2适用范围 (4)1.3术语表 (4)1.4参考资料 (4)2需求跟踪矩阵建立 (4)2.1《需求跟踪矩阵》概述 (4)2.2需求跟踪矩阵建立流程 (4)2.2.1创建《需求跟踪矩阵》 (6)2.2.2需求定义和需求分析阶段《需求跟踪矩阵》的填写 (6)2.2.3设计阶段《需求跟踪矩阵》的填写 (7)2.2.4编码阶段《需求跟踪矩阵》的填写 (7)2.2.5测试阶段《需求跟踪矩阵》的填写 (7)3需求跟踪矩阵变更 (8)3.1需求跟踪矩阵变更概述 (8)3.2需求跟踪矩阵变更流程................................................... 错误！未定义书签。
3.2.1设计阶段需求变更.................................................... 错误！未定义书签。
3.2.2编码阶段需求变更.................................................... 错误！未定义书签。
3.2.3测试阶段需求变更.................................................... 错误！未定义书签。
3.2.4维护阶段需求变更.................................................... 错误！未定义书签。
需求跟踪矩阵
需求跟踪矩阵1. 简介需求跟踪矩阵是一种用于追踪软件开发项目中的需求和实现之间的关系的工具。
通过创建一个需求跟踪矩阵，开发团队可以清楚地了解每个需求是否已经得到满足，并且可以在项目的不同阶段进行跟踪和评估。
本文将介绍需求跟踪矩阵的定义、作用以及如何使用Markdown文本格式输出。
2. 定义需求跟踪矩阵是一个表格，其中列表示项目的需求，行表示项目的实现。
通过填充矩阵中对应的单元格，可以追踪每个需求的实现状态。
需求跟踪矩阵通常包括以下列：•需求ID：对需求进行唯一标识的编号。
•需求描述：对需求进行详细描述，包括其背景、目的和功能要求等。
•需求状态：表示需求的实现状态，如“已实现”、“未实现”、“正在实现”等。
•需求优先级：表示需求的优先级，如“高”、“中”、“低”等。
•实现说明：对需求的实现进行详细说明，包括具体的实现方式、开发进度等。
3. 作用需求跟踪矩阵可以帮助开发团队在整个项目开发周期中跟踪和评估每个需求的实现情况。
它具有以下主要作用：•需求管理：通过列出和描述每个需求，需求跟踪矩阵帮助团队清晰地了解项目的需求，并确保所有需求都得到满足。
•进度追踪：通过填充矩阵中的需求状态和实现说明，团队可以追踪每个需求的实现进度，并及时发现和解决可能存在的问题。
•问题发现：通过对比需求跟踪矩阵中实现状态与实际开发情况，可以及时发现需求是否被遗漏或实现是否存在问题，并及时进行调整和改进。
•优先级管理：通过列出需求的优先级，可以帮助团队合理安排项目开发的顺序，并确保重要的需求得到优先满足。
4. 如何使用Markdown文本格式输出使用Markdown文本格式可以简洁清晰地输出需求跟踪矩阵。
以下是一个示例：需求ID 需求描述需求状态需求优先级实现说明RQ01用户登录已实现高使用用户名和密码进行身份验证，并显示用户个人信息。
RQ02用户注册正在实现中用户通过填写注册表单进行账号注册，并发送验证邮件。
RQ03数据导出未实现低提供导出数据为CSV格式的功能。
需求跟踪矩阵
知识创造未来
需求跟踪矩阵
需求跟踪矩阵是一种项目管理中常用的工具，用于跟踪需求与项目的关联关系。
它有助于确保项目中的所有需求得到满足，并提供了一种追踪需求变更和确认的方法。
需求跟踪矩阵通常由一个二维表格组成，其中列代表项目中的需求，行代表项目中的各个阶段或工作包。
每个单元格中的标记表示该需求在对应阶段或工作包中的状态。
以下是一个示例需求跟踪矩阵：
阶段/工作包 | 需求1 | 需求2 | 需求3
项目规划| √ | |
需求分析| | √ | √
系统设计| √ | √ |
编码| | √ |
测试| √ | | √
验收| √ | √ |
在这个例子中，我们可以看到每个需求在项目的每个阶段或工作包中的状态。
例如，需求1在项目规划、系统设计、测试和验收阶段都得到了满足，而需求2只在需求分析、系统设计和编码阶段得到了满足。
需求跟踪矩阵可以帮助项目团队了解需求的状态，及时发现并解决与需求相关的问题，并确保项目按照预期进行。
1。
需求跟踪矩阵编号规则
需求跟踪矩阵编号规则作用：“需求跟踪矩阵”主要用于记录和跟踪需求的分析、设计、实现、验证的过程。
注：客户需求与产品需求、测试用例、设计、代码之间为多对多的关系。
关于“需求跟踪矩阵”编号，建议编号规则如下:A.规则一:（1）用户需求编号(UR_001_001_001),其中UR是代表用户需求,001_001_001代表一级模块_二级模块_功能点（2）软件需求编号(SR_001_001_001),其中SR是代表软件需求,001_001_001代表一级模块_二级模块_功能点（3）概要设计编号(PSD_001_001_001),其中PSD是代表概要设计,001_001_001代表一级模块_二级模块_功能点（4）详细设计编号(DSD_001_001_001),其中DSD是代表详细设计,001_001_001代表一级模块_二级模块_功能点（5）代码编号(CODE_001_001_001),其中CODE是代表代码,001_001_001代表一级模块_二级模块_功能点（6）集成测试用例编号(ITC_001_001_001),其中ITC是代表集成测试用例,001_001_001代表一级模块_二级模块_功能点（7）单元测试用例编号(UTC_001_001_001),其中UTC是代表单元测试用例,001_001_001代表一级模块_二级模块_功能点（8）系统测试用例编号(STC_001_001_001),其中STC是代表系统测试用例,001_001_001代表一级模块_二级模块_功能点B.规则二:（1）用户需求编号(UR_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （2）软件需求编号(SR_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （3）概要设计编号(PSD_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)（4）详细设计编号(DSD_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （5）代码设计编号(CODE_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （6）集成测试用例编号(ITC_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （7）单元测试用例编号(UTC_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) （8）系统测试用例编号(STC_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母) 例:客户管理(一级模块),客户资料(二级模块),新建(功能点)PR_KHGL_KHZL_XJC.项目组自定义ID，或者是对应文档中的自定义编号。
需求跟踪矩阵 模板
表格编号：XY202-项目编号-两位顺序号
项目名称： 需求分析 用户需求 编号 章节编号 需求名称 首页 1 状 章节 态 编号 原 始 软件需求 子模块名 系统监视 状态 原始 修改 删除 增加 风电监控 2 修 改 需求优 先级 高 中 低 责任人 概要设计 章节编号
3
删 除
4
567源自8原始需求总数 修改需求总数 删除需求总数 增加需求总数 总需求数
3 0 0 0 3
需求跟踪矩阵
项目经理PM： 系统设计 概要设计 名称 是否完成 责任人 详细设计 章节编号 名称 是否完成 责任人 代码单元 编码实现 是否完成 责任人 √ √
项目QA： 功能测试 测试单元 是否完成 责任人 备注
教务管理系统需求跟踪矩阵
教务管理系统需求跟踪矩阵一、引言教务管理系统是现代教育管理的重要组成部分，它以信息化、网络化的手段来实现对教务工作的全面管理和高效运作。
为了确保教务管理系统能够顺利地满足教育管理的需求，需求跟踪矩阵成为了一种重要的工具。
本文将对教务管理系统需求跟踪矩阵的概念、作用以及具体的应用方法进行深入探讨。
二、教务管理系统需求跟踪矩阵的概念2.1 教务管理系统需求跟踪矩阵的定义教务管理系统需求跟踪矩阵是用于记录和跟踪教务管理系统功能需求的一种矩阵表格。
它以需求编号为基准，在矩阵中记录了需求的来源、描述、优先级、是否已实现等信息，用于追踪需求的状态和实现情况。
2.2 教务管理系统需求跟踪矩阵的作用教务管理系统需求跟踪矩阵主要有以下作用： 1. 确保需求的完整性：通过对需求进行编号和详细描述，需求跟踪矩阵能够帮助保证教务管理系统的所有功能需求都得到充分的考虑和记录。
2. 控制需求的优先级：通过在矩阵中标注需求的优先级，教务管理系统的开发与实施过程能够更加有针对性地进行，保证重要需求的及时实现。
3. 跟踪需求的实现情况：通过在矩阵中记录需求的实现状态，教务管理系统的开发团队和管理者可以清晰地了解到每个需求的进展情况，及时进行调整和改进。
4. 支持系统维护和升级：教务管理系统是一个长期运行的系统，通过需求跟踪矩阵的维护，可以为后续的系统维护和升级提供参考和依据。
三、教务管理系统需求跟踪矩阵的创建3.1 创建需求跟踪矩阵的步骤教务管理系统需求跟踪矩阵的创建包括以下步骤： 1. 确定需求编号：为每个需求分配一个唯一的编号，在矩阵中作为需求的标识。
2. 描述需求：对每个需求进行详细描述，包括需求的功能、性能、界面等方面。
3. 确定需求的来源：记录每个需求的来源，可以是用户需求调研、管理部门要求等。
4. 标注需求的优先级：根据需求的重要程度和紧急程度，为每个需求标注优先级，以指导系统的开发与实施过程。
5. 记录需求的状态：在需求得到实现后，将需求在矩阵中标注为已实现，并记录实现的日期。
PMP项目管理之需求管理
PMP项⽬管理之需求管理需求管理计划1、在项⽬策划阶段，需要明确该项⽬的基本需求。
2、在项⽬各个阶段结束时，需要“开项⽬阶段完成会议”，向*****汇报需求实现情况。
3、按照“渐进明细”原则对各个阶段实现的需求进⾏跟踪和管理。
4、在项⽬进展过程中，若需要“更改需求”必须提交****书⾯⽂档，获得批准后⽅可进⾏更改需求。
需求⽂件⼀、功能需求1.*******************************************。
需求编号：mkaq001.2.*******************************************。
需求编号：mkaq002.3.*******************************************。
需求编号：mkaq003.4.*******************************************。
需求编号：mkaq0045.*******************************************。
需求编号：mkaq0056.*******************************************。
需求编号：mkaq0067.*******************************************。
需求编号：mkaq0078.*******************************************。
需求编号：mkaq008需求跟踪矩阵需求编号收录该需求的理由所有者来源优先级别版本实现⽇期现状活跃中已取消已推迟新增加已批准Mkaq001发起⼈发起⼈0V1.0√Mkaq002发起⼈发起⼈0V1.0√Mkaq003发起⼈发起⼈0V1.0√Mkaq004发起⼈发起⼈0V1.0√Mkaq005发起⼈发起⼈1V1.0√Mkaq006发起⼈发起⼈1V1.0√Mkaq007发起⼈发起⼈1V1.0√Mkaq008发起⼈发起⼈1V1.0√备注：优先级别数字低代表优先级别⾼。
需求跟踪矩阵填写指南(共5页)
本资料仅供内部使用！需求跟踪矩阵填写指南____信息技术公司__年01月16日本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属____信息技术公司所有，受到有关产权及版权法保护。
任何个人、机构未经____信息技术公司的书面授权许可，不得以任何方式复制或引用本文件的任何片断。
修改记录目录1需求跟踪矩阵填写说明 (1)2需求跟踪矩阵的维护和使用 (1)3裁剪指南 (2)1需求跟踪矩阵填写说明【需求跟踪矩阵】用以跟踪需求到设计、设计到编码、编码的测试的映射过程。
项目组可以根据实际情况裁剪模板的格式来满足项目的要求。
需求跟踪矩阵的填写遵循以下原则：需求号：为每条需求编制唯一的识别号，通过需求号可以与需求文档中描述的需求建立一一对应关系。
建议不要使用章节号作为需求号。
如果没有在编程规范或需求跟踪矩阵中说明编号的格式，则可以按一下格式编号：●需求号＝一级功能编号.二级功能编号.三级功能编号.N级功能编号●建议最多不要超过5级；●例子：需求号表示：第一个一级功能的第二个二级功能的一个三级功能。
软件需求描述：简单描述需求内容。
这个描述看是冗余，但有简单描述可以使得跟踪矩阵更具可读性和独立性。
概要设计：描述需求在概要设计中的实现情况。
建议使用编号对应，也可以使用文字对应，建议不要使用章节号。
如果使用编号，请在编程规范中说明编号规则。
详细设计：描述概要设计在详细设计中的实现情况。
建议使用编号对应，也可以使用文字对应，建议不要使用章节号。
如果使用编号，请在编程规范中说明编号规则。
编码：描述详细设计在编码时的实现情况。
可以使用函数名称，文件名称，对象名称等。
单元测试用例：描述详细设计对应的测试用例。
集成测试用例：描述概要设计对应的测试用例。
系统测试用例：描述需求对应的测试用例。
2需求跟踪矩阵的维护和使用跟踪矩阵有助于在各个生命周期阶段跟踪所有需求，以此来确保实现所有已并入的需求，这也避免了由于遗漏需求而进行的重复劳动。
需求编号规则
用于项目需求的跟踪以及需求变更的统计。
使用时可删除掉“模版信息”工作表。
表单中此种颜色表格为自动计算，无需填写。
表单中此种颜色表格为下拉列表，请从列表中选择选项作为单元格的值。
××模块功能点列表字段定义字段定义字段定义字段定义子系统:对于所实现系统在功能上做的整体划分，可以是某个子系统；功能模块:子系统下的功能点的集合；功能点：通过用户交互触发、外部系统触发或后台程序触发来完成的一个完整的动作；功能点编号：为“需求用例编号”+“-”+“功能点流水号”。
每个功能模块下的功能点，流水号从01起编。
需求用例编号为：系统名称的拼音缩写＋功能模块序号＋需求用例流水号。
如果需求划分到需求用例级，则需求用例流水号从01起编。
例：需求用例编号为MPJ0301，对应的功能点编号则为：MPJ0301-01、MPJ0301-02等。
如果需求只划分到功能模块级，则需求用例流水号用“00”表示。
例：需求用例编号为MPJ0300，对应的功能点编号则为：MPJ0300-01、MPJ0300-02等。
注意此列不能为空注意此列不能为空注意此列不能为空注意此列不能为空；；；；从属编号：如果某个功能点在不同模块中重复出现，则再次描述时，须填写“从属编号”,即为此功能点第一次出现时分配的功能点编号；重要程度：一般与客户业务需求相关。
指产品部门对于需求要求的精细程度.项目组依据此程度制定开发策略，由高到低依次为1级、2级和3级。
通常系统的核心模块，级别最高。
注意此列不能为空注意此列不能为空注意此列不能为空注意此列不能为空；；；；需求是否明确：指相关需求第一次形成基线时，功能点描述是否准确、可行。
如准确则填“是”，反之填“否”。
根据《评审报告》填写；删除说明：需求分析阶段结束之后，后续如有删除功能时，需要在该列填写删除原因，如：产品部门要求本版不实现或研发部门暂时无法实现等。
仅当删除功能点时填写该列仅当删除功能点时填写该列仅当删除功能点时填写该列仅当删除功能点时填写该列。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
作用：“需求跟踪矩阵”主要用于记录和跟踪需求的分析、设计、实现、验证的过程。
注：客户需求与产品需求、测试用例、设计、代码之间为多对多的关系。
关于“需求跟踪矩阵”编号，建议编号规则如下:
A.规则一:
（1）用户需求编号(UR_001_001_001),其中UR是代表用户需求,001_001_001代表一级模块_二级模块_功能点
（2）软件需求编号(SR_001_001_001),其中SR是代表软件需求,001_001_001代表一级模块_二级模块_功能点
（3）概要设计编号(PSD_001_001_001),其中PSD是代表概要设计,001_001_001代表一级模块_二级模块_功能点
（4）详细设计编号(DSD_001_001_001),其中DSD是代表详细设计,001_001_001代表一级模块_二级模块_功能点
（5）代码编号(CODE_001_001_001),其中CODE是代表代码,001_001_001代表一级模块_二级模块_功能点
（6）集成测试用例编号(ITC_001_001_001),其中ITC是代表集成测试用例,001_001_001代表一级模块_二级模块_功能点
（7）单元测试用例编号(UTC_001_001_001),其中UTC是代表单元测试用例,001_001_001代表一级模块_二级模块_功能点
（8）系统测试用例编号(STC_001_001_001),其中STC是代表系统测试用例,001_001_001代表一级模块_二级模块_功能点
B.规则二:
（1）用户需求编号(UR_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)
（2）软件需求编号(SR_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)
（3）概要设计编号(PSD_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)
（4）详细设计编号(DSD_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)
（5）代码设计编号(CODE_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)
（6）集成测试用例编号(ITC_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)
（7）单元测试用例编号(UTC_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)
（8）系统测试用例编号(STC_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)
例:客户管理(一级模块),客户资料(二级模块),新建(功能点)
PR_KHGL_KHZL_XJ
C.项目组自定义ID，或者是对应文档中的自定义编号。