需求跟踪矩阵填写指南

本资料仅供内部使用！

需求跟踪矩阵填写指南

XXXXXXXXXXXXX公司

20XX年XX月XX日

修改记录

目录

1需求跟踪矩阵填写说明 (1)

2需求跟踪矩阵的维护和使用 (1)

3裁剪指南 (2)

1需求跟踪矩阵填写说明

【需求跟踪矩阵】用以跟踪需求到设计、设计到编码、编码的测试的映射过程。项目组可以根据实际情况裁剪模板的格式来满足项目的要求。需求跟踪矩阵的填写遵循以下原则：需求号：为每条需求编制唯一的识别号，通过需求号可以与需求文档中描述的需求建立一一对应关系。建议不要使用章节号作为需求号。如果没有在编程规范或需求跟踪矩阵中说明编号的格式，则可以按一下格式编号：

●需求号＝一级功能编号.二级功能编号.三级功能编号.N级功能编号

●建议最多不要超过5级；

●例子：需求号1.2.1表示：第一个一级功能的第二个二级功能的一个三级功能。

软件需求描述：简单描述需求内容。这个描述看是冗余，但有简单描述可以使得跟踪矩阵更具可读性和独立性。

概要设计：描述需求在概要设计中的实现情况。建议使用编号对应，也可以使用文字对应，建议不要使用章节号。如果使用编号，请在编程规范中说明编号规则。

详细设计：描述概要设计在详细设计中的实现情况。建议使用编号对应，也可以使用文字对应，建议不要使用章节号。如果使用编号，请在编程规范中说明编号规则。

编码：描述详细设计在编码时的实现情况。可以使用函数名称，文件名称，对象名称等。

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

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

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

2需求跟踪矩阵的维护和使用

跟踪矩阵有助于在各个生命周期阶段跟踪所有需求，以此来确保实现所有已并入的需求，这也避免了由于遗漏需求而进行的重复劳动。通过为评审专家提供一套机制，矩阵有助于评审，使得很容易检验是否已处理所有的需求。当需求变更时，矩阵中包含的信息可用于分析变更带来的影响。它也有助于向顾客验证所开发的软件满足所有需求而且已经得到了充分的测试。

除非正确维护跟踪矩阵，否则它的作用是有限的。由于矩阵的设计方式，它不可能一成不变，而是在生命周期的很多点上需要更新。开始，矩阵只有需求数据。随着开发的进行，其他域的数据不断被加进来。更新矩阵最简单的方式是在相关阶段评审结束后更新它。为了对一个项目的跟踪矩阵进行维护，在工作产品的所有文档中必须使用编号机制。

在矩阵构建后以及矩阵维护期，需要执行一些完整性检查。这里列出一些需要遵循的检查和步骤。根据项目或客户的需要可以很容易地设计出其他检查。

●浏览矩阵中的需求数目和需求文档中的需求，确保矩阵中列出了所有的需求，没有遗漏。

通过对需求编号进行排序，然后对照检查需求数目是否与需求文档中的数目一致，可以很容易地达到这个目标。

●为确保在矩阵中列出的所有程序在最终的软件中都是必要的，并且没有冗余的代码，必须

在矩阵中指出每个程序、类和其他单元。

●通过确保功能需求没有空白列来检查需求的实现。对其他需求，如果设计和程序域是空白

的，需要仔细检查和验证这些需求对程序有没有直接的影响。

●对每个性能需求，都应该设计一些测试用例。使用矩阵，可以很容易地检查测试用例是否

适合检测这项性能需求。

●集成和系统测试计划可以和矩阵一起进行交叉检查，以此来保证需求的所有条件都包含在

系统测试计划中。

在需求变更的情况下维护矩阵的完整性不是一件容易的事情。将需求变更合入需求文档通常采用两种方式：更改文档中一些已经存在的需求或补充变更请求。更新需求规格文档的方法同样也可以在更新跟踪矩阵时使用。如果需求变更附加到文档中，它将作为附加需求，并在跟踪矩阵中为它增加一个表项。如果更改现有需求，需要同时确定矩阵中的相关表项是否需要更改。如果需要，则进行更改。在大多数情况下使用前一种办法。

3裁剪指南

需求管理过程

需求管理过程 本文件属深圳天源迪科信息技术股份有限公司所有， 未经书面许可，不得以任何形式复印或传播。 2008-1-31发布 2008-2-18 实施

文件建立/修改记录

目录 1 简介 (4) 1.1 目的 (4) 1.2 适用范围 (4) 1.3 背景描述 (4) 1.4 术语表 (4) 1.5 参考资料 (5) 2 总体描述 (5) 2.1 概述 (5) 2.2 职责分工 (5) 2.3 结构描述 (6) 3 活动描述 (7) 3.1 需求培训 (7) 3.2 建立需求跟踪矩阵 (8) 3.3 维护需求跟踪矩阵 (9) 3.4 检查一致性 (10) 3.5 采取更正行动 (11) 3.6 需求变更管理 (12) 4 附录 (13) 4.1 附录A－相关过程 (13) 4.2 附录B－相关规范、指南 (13) 4.3 附录C－相关模板列表 (13)

1简介 1.1目的 制定需求管理过程的目的是管理产品和组件的需求，识别需求与项目计划及工作产品之间的不一致，有效地控制需求变更、以及跟踪需求的演进，指导项目组管理需求。 1.2适用范围 本过程适用于公司所有的软件项目，贯穿项目的整个生命周期。 1.3背景描述 无。 1.4术语表 ●软件需求：用户解决某一问题或者得到某一目标所需的软件功能。 ●基线：基线是经过评审和批准的配置项的集合，其作用是明确划分项目各阶段，确定各阶 段的结束点。在项目的开发过程中，最基本的基线有需求基线、开发基线、发布基线等。 ●配置控制委员会(Configuration Control Board)：简称CCB，是确定配置基线，评估、批准 变更，并保证已批准变更的实施的组织。 ●需求变更：需求变更主要来自三个方面－客户、高层和开发人员。因此，无论哪一方面提 出需求变更的要求，都应当对变更请求进行评估。需求变更通常包括三项内容：新增需求、修改需求、删除需求。每一种变更都可能影响到其他需求的变化，因此在进行变更时需要利用需求跟踪记录。 ●需求跟踪：需求跟踪主要是跟踪需求及其实现之间的一致性，需求跟踪通过管理需求跟踪 记录来进行。在需求的阶段已经建立了需求跟踪记录，在后续的开发过程中，通过不断填写需求跟踪记录，将设计、开发和测试等阶段产品与需求进行一一对应。同时，在任何一个阶段发生变更时，都要检查需求跟踪记录是否需要进行变更。需求跟踪是分布在各个开发阶段之中的。 ●涉众:专指所有会受到项目结果重大影响的人。要有效地解决任何复杂的问题，就会涉及 到满足不同涉众的需要。涉众通常会对问题持有不同的观点，因而必须用所提供的解决方案来满足不同的需要。许多涉众都是系统的用户。其中许多涉众只是系统的间接用户，或者只受到系统所影响的业务结果的影响。还有许多涉众是系统的经济型买主或支持者。了解涉众的组成及其特定需要是开发有效解决方案的关键。典型的涉众有客户（或客户代表）、用户（或用户代表）、投资者、股东、生产经理、买方、项目经理、设计人员、测试

需求跟踪矩阵(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 的工作量还是比较大、比较烦琐。对于变化频繁的项目，更是如此。在实践中，为了简化该RTM的建立与维护工作，有的企业仅仅通过需求与设计、代码、测试用例的编号来实现跟踪，如需求为：r1,r2,……等编号，而设计的编号为：r1-d1,r1-d2,…….,测试用例的编号为：r1-t1,r1-t2等等。需要注意的是需求与它们之间是多对多的关系，仅通过编号是无法实现这种关系的。 如果不借助DOORS之类的需求管理工具，一般只能通过EXCEL来维护RTM，工作量就是比较大。要简化，就要平衡管理的投入与产出，平衡时，可以借鉴上面的问题3。 当然也可以考虑增大需求、设计、代码、测试用例的颗粒度大小，但是那样RTM的作用就打了折扣，还是一个平衡问题。

软件测试之软件测试报告编写指南

软件测试之软件测试报告编写指南 测试报告编写指南 由安博测试空间技术中心:///提供摘要 测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。本文提供测试报告模板以及如何编写的实例指南。 关键字 测试报告缺陷 正文 测试报告是测试阶段最后的文档产出物，优秀的测试经理应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。 下面以通用的测试报告模板为例，详细展开对测试报告编写的具体描述。 PARTⅠ 首页 0.1页面内容： 密级 通常，测试报告供内部测试完毕后使用，因此密级为中，如果可供用户和更多的人阅读，密级为低，高密级的测试报告适合内部研发项目以及涉及保密行业和技术版权的项目。XXXX项目/系统测试报告 报告编号 可供索引的内部编号或者用户要求分布提交时的序列号 部门经理 ______项目经理______ 开发经理______测试经理______ XXX公司 XXXX单位（此处包含用户单位以及研发此系统的公司） XXXX年XX月XX日 0.2格式要求： 标题一般采用大体字（如一号），加粗，宋体，居中排列 副标题采用大体小一号字（如二号）加粗，宋体，居中排列 其他采用四号字，宋体，居中排列 0.3版本控制： 版本作者时间变更摘要 新建/变更/审核 PARTⅡ 引言部分 1.1编写目的 本测试报告的具体编写目的，指出预期的读者范围。

实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。 提示：通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。此部分可以具体描述为什么类型的人可参考本报告XXX页XXX章节，你的报告读者越多，你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。 1.2项目背景 对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。 1.3系统简介 如果设计说明书有此部分，照抄。注意必要的框架图和网络拓扑图能吸引眼球。 1.4术语和缩写词 列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多 义词一定要注明清楚，以便阅读时不会产生歧义。 1.5参考资料 1．需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的东东。 2．测试使用的国家标准、行业指标、公司规范和质量手册等等 PARTⅢ 测试概要 测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。（其他测试经理和质量人员关注部分） 2.1测试用例设计 简要介绍测试用例的设计方法。例如：等价类划分、边界值、因果图，以及用这类方法。 提示：如果能够具体对设计进行说明，在其他开发人员、测试经理阅读的时候就容易对你的用例设计有个整体的概念，顺便说一句，在这里写上一些非常规的设计方法也是有利的，至少在没有看到测试结论之前就可以了解到测试经理的设计技术，重点测试部分一定要保证有两种以上不同的用例设计方法。 2.2测试环境与配置 简要介绍测试环境及其配置。 提示：清单如下，如果系统/项目比较大，则用表格方式列出 数据库服务器配置 CPU：

编写需求跟踪矩阵指南

编写需求跟踪矩阵指南 山东中创软件工程股份有限公司 二ОО七年三月

文件变更记录*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 列值说明 关于优先级的说明：优先级表示的是某项内容相对于同类的其他内容的优先级顺序，其取值范围为：高、中、低。如果某几项内容的优先级相同则将其优先级设为相同的值。 《用户需求说明书》 需求编号：《用户需求说明书》中描述软件需求的唯一代号（或标识）。 责任人：相关需求的责任人。 《软件需求规格说明书》

访谈问题列表 for Developer(需求,设计,编码,测试)

需求访谈 1.请说明公司怎样明确需求人员岗位职责？在哪些方面体现？ 由高层指定项目经理，由项目经理在立项会议时通知我负责这个项目的需求。这些内容都记录在《项目计划》中。 2.需求方面，公司是否有一些指导的方针？ 有的，存放在“过程改进方针.doc”中，在这里有对我的需求开发和管理的主要指导思想。这个方针是由公司高层制订的。主要内容是：需求获取，需求分析，还有根据需求做概要设计和详细设计等。 3.请你描述一下需求阶段分为几个子过程？及主要的工作是什么？ 需求阶段分为需求获取，审核和确认，需求分析，需求评审，需求管理（填写需求跟踪矩阵）等。 （1）需求获取阶段主要收集客户的需求，并整理到《用户需求说明书》，然后给客户确认，采用的方式主要是EMAIL沟通，有时会用电话，网络交流工具，面对面地访谈等； （2）《用户需求说明书》确认通过后，需求人员来填写《需求跟踪矩阵》的“用户需求”列； （3）需求分析人员根据《用户需求说明书》制定《软件需求说明书》。然后项目组人员对《软件需求说明书》进行评审。评审通过后，需求人员填写《需求跟踪矩阵》中的“软件需求”列。 4.你是如何获取项目和产品的需求？有哪些方法？ 采用的方式主要是面对面地访谈，EMAIL沟通，有时会用电话，网络交流工具等； 还有一些《问卷调查》做一些静态效果图给客户，帮助客户发现一些潜在的需求。这些都记录在用户需求说明书当中。 5.你是如何对需求分类（功能、非功能）？ 需求分为功能性需求与质量属性方面的需求。质量属性可以分为可维护性，安全性，兼容性，易用性等。 6.你是如何标识需求状态的？你采用了什么方法或工具跟踪需求的状态？ 我们在每个阶段完成时，都填写《需求跟踪矩阵》来标识需求状态； 当需求变更时，我们采用《需求跟踪矩阵》来查看每个需求的状态，了解因变更而影响的需求范围。 7.需求分析采用了哪些方法？你是如何判断这些方法符合项目要求？ 我们采用VISIO（根据实际列举所使用到的工具）工具来分析系统，并对系统进行建模，制定出系统的业务流程图和系统架构图，当《软件需求说明书》制定完成后，由项目经理组织邀请客户，开发人员，测试人员，配置人员，质量保证人员，高层参加需求评审会议，以保证需求分析是满足客户需求的，并得到大家的认可。 8.需求分析结果是否都记录?在哪里，主要内容有哪些？ 记录在《软件需求说明书》，主要的内容有系统架构图，每个功能的业务流程图及场景描述和接口需求等。 9.需求的优先级如何确定？需求程度（验证、一般），需求的稳定性？ 高——软件必须实现的功能，用户有明确的功能定义和要求； 中——软件应该实现的功能，用户的功能定义和要求可能是模糊的、不具体的、或低约束的，但是这类功能的缺少会导致用户的不满意，因此这类功能的具体需求应当由需求分析人员诱导用户产生并明确； 低——软件尽量实现的功能，并可根据开发进度进行取舍，但这类功能的实现将会增加用户的满意度。 10.你是如何与客户确定需求变更的约定？有哪些记录？ 当需求变更时，由项目经理对需求变更进行分析，主要是从需求变更所影响的范围，进度，质量和成本四个方面进行分析。 当项目经理分析后，确定这次变更的影响值，如果变更影响值小于或等于2,则由项目经理决定是否执行变更，当变更影响值大于2,则提交给CCB（变更控制委员会，由高层、客户和项目经理组成）来决定是否执行变更。 关于变更都记录在《变更申请表》、《变更控制跟踪表》等文档中。 11.需求变更的流程是如何的？ 首先填写《变更申请表》，主要内容是本次需求变更的内容，项目经理分析本次需求变更的影响值，我们这个项目影响值为“3”，由项目经理提交给CCB，高层组织我们开了一个变更决策会议，会议通过打分的方式决定变更。决策结果是执行变更。 当然，如果变更影响值为2或小于2，则可以由项目经理决定是否执行变更。

CMMI3需求访谈提纲

需求访谈提纲 一、自我介绍 1、你的姓名？ 2、你担任的角色？ 3、你来公司多长时间？ 4、你参与了哪几个项目？ 5、目前项目处于什么阶段？ 二、能力（GP2.3 资源、GP2.4分配职责、GP2.5培训、OT组织培训过程域） 1、你在公司的岗位是什么？ 答：公司有岗位职责表。在《项目组岗位职责》中明确在该项目中的职责。 2、为了胜任本岗位工作，你参加过哪些方面培训？ 答：进入公司时，参加了公司的入职培训；正式上岗之前，参加了岗位培训；需求分析，Visio2003、沟通技巧。 3、项目启动时，是否进行过培训？ 答：项目启动时，项目经理依据《员工技能一览表》查看人员的技能，组织项目团队。根据项目的实际情况和人员能力要求，项目经理会制定《项目培训计划》，参加《项目培训计划》的内容参加相应的培训。举例说明你在参加项目过程中参加了哪些培训。 4、为了更好的开展你的工作，公司为你提供了哪些资源？ 答：机器设备如电脑、办公场地、办公软件等，公司还有专门一个文件《工作环境标准》明确一些资源使用的要求。 三、制度（GP3.1组织标准过程文件和裁剪） 1、你工作时主要依据哪些方针和制度（过程文件、规范、指南、模板）？ 答：需求开发的方针是保证后阶段产物与客户的需要一致，并获取客户及相关人员承诺；需求管理的方针是需求进行良好的跟踪，保证最终产品满足客户的要求。规范指南：需求的过程文件、需求分析指南等 2、文件是如何产生和更新的？ 答：我是EPG的成员（具体按照实际情况回答），参与了这些文件的编写和评审。做为PAT（过程行动组成员），在项目试点及推广时，负责对我负责的文件跟踪，收集过程改进建议。一般会通过《过程改进建议表》提交给EPG组长，EPG组长

需求跟踪矩阵编写指南

需求跟踪矩阵编写指南 山东中创软件工程股份有限公司 二ОО七年三月

文件变更记录*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 列值说明 关于优先级的说明：优先级表示的是某项内容相对于同类的其他内容的优先级顺序，其取值范围为：高、中、低。如果某几项内容的优先级相同则将其优先级设为相同的值。 《用户需求说明书》 需求编号：《用户需求说明书》中描述软件需求的唯一代号（或标识）。 责任人：相关需求的责任人。 《软件需求规格说明书》

需求跟踪矩阵编号规则

作用：“需求跟踪矩阵”主要用于记录和跟踪需求的分析、设计、实现、验证的过程。注：客户需求与产品需求、测试用例、设计、代码之间为多对多的关系。 关于“需求跟踪矩阵”编号，建议编号规则如下: 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_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)

测试申请表

测试申请表 申请单编号： 项目编号项目名称胜东社区技术监督管理系统版本号V1.0 项目经理王鹏 开发周期人日申请日期2012年03月02日 预计提交测试日期2012年03月02日期望完成日期2012年03月10日 开发平台: Eclipse3.2、J2EE 开发语言: JA V A 软件安装、运行所需要的软、硬件环境： Windows2003、jboss-4.2.3.GA、mysql5.0 测试类型软件产品附带文档及说明 功能测试√业务需求规格说明书 （必备）需求变更记录 （必备） 软件需求规格说明书需求跟踪矩阵 （两者至少有一个）性能测试 提供业务需求规格说明书中对性能的说明（必备） 安全性测试 提供描述系统安全指标的说明（必备） 接口测试 提供描述系统接口的说明（必备） 系统概要设计说明书（必备）、系统详细设计说明书 安装/卸载测试系统安装程序（必备）系统安装手册（必备） UI测试 提供描述UI测试的相关要求（必备） 易用性测试 提供易用性测试的相关要求（必备） 兼容性测试提供测试软件在特定的硬件/软件/操作系统/网络等环境下的性能情况及兼容性要求（必备） 其他测试类型

测试部门意见： 签字：__________日期：__________特殊情况领导意见： 签字：__________日期：__________ 系统测试范围列表 系统名称（若项目存在多个子系统，请分开罗列） 功能模块开发人员状态优先级对其他模块的影响

填写说明： 1、使用范围：该表格适用于济南广域软件有限责任公司，项目组提交测试申请时必须填写的表单，作为 接收、处理任务的依据。 2、申请单编号，由测试部门填写，该编号表示为“项目名称—TR—号码”。 3、特殊情况指正常情况下不予测试，如缺少必备文档等，需领导签字后才能进入测试流程。 4、功能列表上所列出来的功能必须是可以实现的，如果不能实现，请不要列上，并且功能在用户手册上 都要有详细的描述和操作说明。 【状态】：新增，修改等。主要用于在多次测试中，本次提交的功能较之于之前版本而言的，是新增加的功能，还是在原功能上进行修改的。 【优先级】：可选项为高级、中级、低级；项目功能定义优先级后，将会对级别高的功能进行优先测试。 【影响】：状态为新增加的模块或者修改的模块，对其他功能模块的影响；简言之，即所影响到的模块。 5、运行环境：软件运行所需的最低软/硬件要求，如操作系统、数据库、其它应用软件等；使用的CPU（类 型和频率）/内存（类型和大小）/硬盘（容量和转速），网络环境等 6、开发工具：软件开发过程中使用的工具，如VB、VC等 7、需提交的材料：软件测试申请表、软件测试范围列表

2016年PMP考试试题及答案

2016年PMP考试试题及答案（1-69） 1、以下哪项基准可用于评估请求的变更或额外的工作是否包含在项目边界之内？ A、项目管理计划 B、项目范围说明书 C、项目范围管理计划 D、工作分解结构词典 2、在项目执行阶段，你发现分包商在按照不完整并且不同的范围说明进行工作。作为项目经理，你应该首先作什么？ A按照正确的范围说明书检查完成的工作 B与项目干系人一起审核工作范围 C用文档记录下管理中的不一致之处并计算不一致的成本 D在工作范围未完整之前停止工作 3、下列关于分解的说法，错误的是____。 A、工作包是工作分解结构的底层 B、分解的对象是为提交所需可交付成果而实施的工作 C、工作分解结构是以可交付成果为导向的工作层级分解 D、“工作分解结构”中的“工作”是指为完成工作付出的“努力(effort)”本身(这个是活动了) 4、以下关于产品范围和项目范围的说法，哪个是正确的？() A、项目范围服务于产品范围 B、项目范围的变化必然引起产品范围的变化 C、产品范围的变化必然引起项目范围的变化 D、产品范围服务于项目菹围 5、你是某主要合同的分包商的项目经理。总承包商曾要求你以具体详尽的方式管理工作。你首先要采取的步骤是___。 A、遵循总承包商为项目制定的工作分解结构，并利用你在建议书中确定的工作包 B、为由你公司负责的工作包制定一个子项目工作分解结构 C、设立类似于总承包商所用的编码结构，以促进对通用项目管理信息系统的利用 D、编制工作分解结构词典，以说明具体的人员分配 6、下列哪个文件详细描述了项目的可交付成果，以及为提交这些可交付成果而必须开展的工作? A、项目管理计划 B、项目章程 C、工作分解结构 D、项目范围说明书 7、项目团队通过让干系人填写问卷，从而了解于系人的需求状况，这是什么过程? A、收集需求 B、定义范围

用户需求说明书模板

用户需求说明书模板 目录 1 引言 (3) 1.1 编写目的 (3) 1.2 项目背景 (3) 1.3 术语定义 (3) 1.4 参考资料 (3) 2 综合描述 (3) 2.1 产品介绍 (3) 2.2 目标范围 (3) 2.3 用户特性 (4) 2.4 约定假设 (4) 3 用户需求（可剪裁） (4) 3.1 总体需求（可剪裁） (4) 3.2 内容需求（可剪裁） (5) 4 功能需求 (5) 4.1 数据需求（可剪裁） (5) 4.2 接口需求（可剪裁） (6) 4.3 权限控制需求（可剪裁） (6) 4.3.1 系统安全要求（软硬件） (6) 4.3.2 用户角色 (6) 4.3.3 角色权限控制 (6) 5 非功能需求 (6) 5.1 用户界面需求（可剪裁） (6)

5.2 性能需求（可剪裁） (7) 5.3 压力需求（可剪裁） (7) 5.4 主流技术应用需求（可剪裁） (7) 5.5 安全需求（可剪裁） (7) 5.6 故障处理需求（可剪裁） (7) 5.7 环境需求（可剪裁） (7) 5.8 产品质量需求 (7) 5.9 其他需求（可剪裁） (8) 6 需求优先级 (8) 7 附加说明（可剪裁） (8) 1.1. 1 引言 1.1.1. 1.1 编写目的 本节描述编写该用户需求说明书的目的，并指出预期的读者。 1.1. 2. 1.2 项目背景 本节描述用户需求说明书中所定义的产品的背景和起源，以及同其他系统或其他机构的基本相互关系等。当在已有的系统上进行特性开发时，如果新特性与已有系统的特性之间存在关系，则应在本节说明其相互之间的关系。 1.1.3. 1.3 术语定义 本节可列出本文件中用到的专门术语的定义、外文首字母组词的原词组等。 1.1.4. 1.4 参考资料 本节列举编写用户需求说明书时所参考的资料或其他资源，这可能包括用户合同、公司规范、技术书籍等。在这里应该给出详细的信息，包括资料名称、版本号、作者、日期、出版单位或资料来源，以方便读者查阅这些文献，可用以下格式表示： 资料名称版本号作者日期出版单位/资料来源备注

需求追踪矩阵

关于需求跟踪矩阵的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有错误。

需求跟踪矩阵填写指南

本资料仅供内部使用！ 需求跟踪矩阵填写指南 xxxx信息技术有限公司 2016年01月16日 本文件中出现的任何文字叙述、文档格式、插图、照片、方法、过程等内容，除另有特别注明，版权均属xxxx信息技术有限公司所有，受到有关产权及版权法保护。任何个人、机构未经xxxx信息技术有限公司的书面授权许可，不得以任何方式复制或引用本文件的任何片断。

需求跟踪矩阵 仅供内部使用修改记录

目录 1需求跟踪矩阵填写说明 (1) 2需求跟踪矩阵的维护和使用 (1) 3裁剪指南 (2)

1需求跟踪矩阵填写说明 【需求跟踪矩阵】用以跟踪需求到设计、设计到编码、编码的测试的映射过程。项目组可以根据实际情况裁剪模板的格式来满足项目的要求。需求跟踪矩阵的填写遵循以下原则：需求号：为每条需求编制唯一的识别号，通过需求号可以与需求文档中描述的需求建立一一对应关系。建议不要使用章节号作为需求号。如果没有在编程规范或需求跟踪矩阵中说明编号的格式，则可以按一下格式编号： ●需求号＝一级功能编号.二级功能编号.三级功能编号.N级功能编号 ●建议最多不要超过5级； ●例子：需求号1.2.1表示：第一个一级功能的第二个二级功能的一个三级功能。 软件需求描述：简单描述需求内容。这个描述看是冗余，但有简单描述可以使得跟踪矩阵更具可读性和独立性。 概要设计：描述需求在概要设计中的实现情况。建议使用编号对应，也可以使用文字对应，建议不要使用章节号。如果使用编号，请在编程规范中说明编号规则。 详细设计：描述概要设计在详细设计中的实现情况。建议使用编号对应，也可以使用文字对应，建议不要使用章节号。如果使用编号，请在编程规范中说明编号规则。 编码：描述详细设计在编码时的实现情况。可以使用函数名称，文件名称，对象名称等。 单元测试用例：描述详细设计对应的测试用例。 集成测试用例：描述概要设计对应的测试用例。 系统测试用例：描述需求对应的测试用例。 2需求跟踪矩阵的维护和使用 跟踪矩阵有助于在各个生命周期阶段跟踪所有需求，以此来确保实现所有已并入的需求，这也避免了由于遗漏需求而进行的重复劳动。通过为评审专家提供一套机制，矩阵有助于评审，使得很容易检验是否已处理所有的需求。当需求变更时，矩阵中包含的信息可用于分析变更带来的影响。它也有助于向顾客验证所开发的软件满足所有需求而且已经得到了充分的测试。 除非正确维护跟踪矩阵，否则它的作用是有限的。由于矩阵的设计方式，它不可能一成不变，而是在生命周期的很多点上需要更新。开始，矩阵只有需求数据。随着开发的进行，其他域的数据不断被加进来。更新矩阵最简单的方式是在相关阶段评审结束后更新它。为了对一个项目的跟踪矩阵进行维护，在工作产品的所有文档中必须使用编号机制。 在矩阵构建后以及矩阵维护期，需要执行一些完整性检查。这里列出一些需要遵循的检查和步骤。根据项目或客户的需要可以很容易地设计出其他检查。 ●浏览矩阵中的需求数目和需求文档中的需求，确保矩阵中列出了所有的需求，没有遗漏。

需求跟踪

需求跟踪

修订历史记录 日期版本说明作者2007年8月<1.0> 第1次发布Louis

1 目的 将系统设计、编程、测试等阶段的工作成果与需求文档进行比较，建立与维护“需求文档－设计文档－代码－测试用例”之间的一致性，确保产品依据需求文档进行开发。 2角色流程图 3 启动准则 ●需求文档已经通过正式评审并获得了承诺。 ●系统设计、编程、测试等阶段的工作成果如设计文档、代码、测试用例部分或全部已经产 生。 4 输入 ●需求文档 ●设计文档、代码、测试用例等 5 主要活动 [Activity1] 初始化跟踪需求矩阵 ●在需求确认之后，需求分析工程师应根据项目的需求规则说明书初始化需求跟踪矩阵中“需

求文档“的部分，同时通知项目组成员及相关人员。 注：具体需求跟踪矩阵格式请参见《需求跟踪报告》模板。 ●需求跟踪矩阵中“设计文档”部分的需求跟踪的初始化工作应在程序员完成详细设计后完 成初始化工作。 ●需求跟踪矩阵中“代码”部分的需求跟踪的初始化工作应在系统编码人员在完成相应的需 求功能的编码工作后完成初始化工作。 ●需求跟踪矩阵中“测试用例”部分的需求跟踪的初始化工作应在《需求规格说明书》已撰 写完成并通过确认后，系统测试之前完成。 [Activity2] 更新需求矩阵 ●项目成员在提交任务时，如果所完成的工作成果与需求跟踪矩阵的内容相关，应提交工作 产品前更新需求跟踪矩阵的相关内容。 ●在需求发生变化后，由需求文档的矩阵更新负责人先更新需求跟踪矩阵，同时通知相关的 矩阵更新负责人，在各负责人完成相应设计、代码、测试用例等的变更后，更新需求跟踪矩阵。 [Activity3] 跟踪需求矩阵 ●对于需求跟踪矩阵中“需求文档”部分的跟踪，将放在需求走查及审查评审时，对与评审 的需求文档相关的需求跟踪矩阵部分进行走查和审查评审，并将发现的缺陷及问题记录到评审报告中。 ●对于需求跟踪矩阵中“设计文档”部分的跟踪，将放在详细设计走查评审时对与评审的设 计文档相关的需求跟踪矩阵部分中进行走查评审，并将发现的缺陷及问题记录到评审报告中。 ●对于需求跟踪矩阵中“代码”部分的跟踪，将放在代码走查时对与走查相关的需求跟踪矩 阵部分进行走查评审，并将发现的缺陷及问题记录到评审报告中。 ●对于需求跟踪矩阵中“测试用例”部分的跟踪，将放在系统测试开始前对系统测试用例进 行审查评审，并将发现的缺陷及问题记录到评审报告中。 ●跟踪需求矩阵的方法有以下几种： ?正向跟踪。检查需求文档中的每个需求是否都能在后续工作成果中找到对应点。 ?逆向跟踪。检查设计文档、代码、测试用例等工作成果是否都能在需求文档中找到出处。 ?正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需