需求跟踪矩阵编号规则

【PMP考试通】需求文件和需求跟踪矩阵收集需求过程是PMBOK中相对比较重要的一个过程，该过程的ITTO（“输入、工具、输出”的英文单词缩写）都非常重要，所以这是在授课时着重去讲的过程。

今天我们主要来讨论一下该过程的输出—需求文件和需求跟踪矩阵。

经常会有学员会有疑问，不太理解需求文件和需求跟踪矩阵的区别，我们先来看一下PMBOK对于这两项文件的描述：需求文件描述各种单一需求将如何满足与项目相关的业务需求。

一开始,可能只有高层级的需求,然后随着有关需求信息的增加而逐步细化。

只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要干系人愿意认可的需求,才能作为基准。

需求文件的格式多种多样,既可以是一份按干系人和优先级分类列出全部需求的简单文件,也可以是一份包括内容提要、细节描述和附件等的详细文件。

需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。

使用需求跟踪矩阵,把每个需求与业务目标或项目目标联系起来,有助于确保每个需求都具有商业价值。

需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法,有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。

最后,需求跟踪矩阵还为管理产品范围变更提供了框架。

我们把以上内容简化一下：需求文件，可以理解为是对已经收集到的各种需求的记录文件，为了使需求文件看起来更加正式正轨，我们可以对已经记录的需求进行分类，例如业务需求、干系人需求、解决方案需求、项目需求等；而需求跟踪矩阵，就是将与需求关联的一系列属性通过表格的形式记录，这样根据需求的编号可以向前或向后追踪，向前可以追踪到原始需求，向后可以追踪到可交付成果等，目的是为了保证成果是符合干系人需求并且满足商业利益和价值。

所以我们总结一下，需求文件的关键词在于“记录”，需求跟踪矩阵的关键词在于“追踪”。

那么如果在项目中出现了需求的“增删改”，那么我们就可能要进行需求文件的更新，而需求跟踪矩阵就能够告诉我们更改的需求对项目的目的目标是否有影响。

简练⽹软考知识点整理-项⽬需求跟踪及需求跟踪矩阵1.需求跟踪需求跟踪包括编制每个需求同系统元素之间的联系⽂档。

这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助⽂件、⽂档等。

跟踪能⼒信息使变更影响分析⼗分便利，有利于确认和评估实现某个建议的需求变更所必须的⼯作。

2.需求跟踪⽬的需求跟踪提供了⼀个表明与合同或说明⼀致的⽅法，需求跟踪可以改善产品质量，降低维护成本，⽽且很容易实现重⽤。

需求跟踪是个要求⼿⼯操作且劳动强度很⼤的任务，要求组织提供⽀持。

随着系统开发的进⾏和维护的执⾏，要保持关联链信息与实际⼀致。

跟踪能⼒信息⼀旦过时，可能再也不会重建它了。

由于这些原因，应该正确使⽤需求跟踪能⼒。

下⾯是在项⽬中使⽤需求跟踪能⼒的⼀些好处：（1）审核跟踪能⼒信息可以帮助审核确保所有需求被应⽤。

（2）变更影响分析跟踪能⼒信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。

（3）维护可靠的跟踪能⼒信息使得维护时能正确、完整地实施变更，从⽽提⾼⽣产率。

要是⼀下⼦不能为整个系统建⽴跟踪能⼒信息，⼀次可以只建⽴⼀部分，再逐渐增加。

从系统的⼀部分着⼿建⽴，先列表需求，然后记录跟踪能⼒链，再逐渐拓展。

（4）项⽬跟踪在开发中，认真记录跟踪能⼒数据，就可以获得计划功能当前实现状态的记录。

还未出现的联系链意味着没有相应的产品部件。

（5）再设计（重新建造）你可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。

通过定义跟踪能⼒信息链提供⼀种⽅法收集从⼀个现成系统的反向⼯程中所学到的⽅法。

（6）重复利⽤跟踪信息可以帮助你在新系统中对相同的功能利⽤旧系统相关资源。

例如：功能设计、相关需求、代码、测试等。

（7）减⼩风险使部件互连关系⽂档化可减少由于⼀名关键成员离开项⽬带来的风险。

（8）测试测试模块、需求、代码段之间的联系链可以在测试出错时指出最可能有问题的代码段。

以上所述许多是长期利益，减少了整个产品⽣存期费⽤，但同时要注意到由于积累和管理跟踪能⼒信息增加了开发成本。

需求跟踪矩阵（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编码规则修订历史记录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 需求跟踪矩阵（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的工作量还是比较大、比较烦琐。

需求跟踪矩阵维护规程文档编号：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维护阶段需求变更.................................................... 错误！未定义书签。