需求跟踪矩阵(模板)
需求跟踪矩阵(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 的工作量还是比较大、比较烦琐。
需求开发与管理标准化流程说明及表单书写说明全套
需求开发与管理标准化流程说明及表单书写说明1 目的定义需求开发与管理过程，为需求开发及跟踪提供有效的流程和方法。
2 适用范围2.1 机构研发中心技术部门及PMO、技术拓展部。
2.2 业务提供需求工程的过程标准。
3 名词术语3.1 RDM（Request Development and Management）：需求开发与管理。
3.2 SRS(Software Requirement Specification)：软件需求规格说明书。
3.3 客户(Customer)：开发产品订单的付费方3.4 最终用户(End User)：最终真正操作软件的用户3.5 用户需求：指直接来自于客户或者用户的原始需求3.6 产品需求：指对用户需求进行需求分析和开发之后生成的对于软件产品开发的需求3.7 CCB(Change Control Board)：变更控制委员会。
CCB的组长一般为适用机构的领导，成员一般为PMO及适用机构领导制定的某些特定人员，对于子部门级别的项目，CCB可直接由子部门的经理担任组长，由PMO担任组员。
4 概述项目在工程活动的开始，首先要进行需求开发。
后续所有的工程活动，包括设计、实现、测试均是根据需求展开的，所以需求开发的重要程度是最高的，而由于需求的抽象性，需求开发人员（系统分析员）既需要有过硬的专业知识，还要具备较强的交流、沟通能力，所以需求开发也是最难的。
任何项目，需求在整个工程开发过程中必定会发生变化，因此对需求变更的控制，即需求管理必不可少。
5 过程定义5.1 需求开发与管理5.1.1 角色与职责5.1.2 入口准则◆项目已经启动；◆对于合同项目，合同已经签订。
5.1.3 输入◆项目计划5.1.4 过程活动1)、需求调查获取用户（客户和最终用户）的需求信息。
调查需求的方式包括：◆与用户交谈，向用户提问题◆参观用户的工作流程，观察用户的操作◆向用户群体发调查问卷◆与同行。
专家交谈，听取他们的意见◆分析已经存在的同类软件产品，提取需求◆从行业标准、规则中提取需求◆从internet上搜查相关资料在需求调查完成之后，需要生成需求搜集的文档，文档形式可以自定义，但搜集的需求形成的文档需要由项目经理组织进行非正式的评审，要尽最大努力使搜集到的需求正确无误的反映用户的真实意愿。
需求跟踪矩阵模板
软件需求 概要设计 系统/FAT测试用例
详细设计 编码文件 集成/SIT测试用例
XX项目需求跟踪矩阵
子系统 系统管理
需求 权限管理
业务需求 需求名称
用户添加
状态
类别
优先 级
执行 状态
功能子集(FS)
软件需求 执行单元名称(EU)
做
必须 高
权限管理
用户添加
关键 程度
模块
权限管理 高
概要设计
跟踪矩阵
概要设计 组件
用户添加 用户维护 角色添加 角色维护 测试 角色权限对照
机器参数添加
详细设计 开发单元
编码文件 代码文件
SRS_XTGL_YHGL_用户添加001 SRS_XTGL_YHGL_用户添加002 SRS_XTGL_YHGL_用户添加003 SRS_XTGL_YHGL_用户添加004
完
完
完
用户维护
做
必须 高
用户维护
高
角色添加 角色维护
做
必须 高
新增 必须 高
角色添加
中
角色维护
中
权限报表
待定 必须 中
权限报表
低
角色权限对照
删除 必须 中
角色权限对照
低
参数管理
机器参数添加
必须 高
参数管理
机器参数添加
参数管理 高
电话银行
机器参数维护
必须 高
完
完
完
完完完完 完ຫໍສະໝຸດ 完请在这行之前插入行。
完完
请在这行之前插入行。
j1.java j2.jsp F_AddEmployee.sql FormConfig.xml
需求说明跟踪模板
三、测试人员填写
需求编号：
可依据项目编号，如RIIL-BMC-审计署-机房-0001
需求名称：
需求简单的称呼，如：机房
优先级：
与JIRA的优先级一致
需求描述：
描述的是功能要达到的目标、所采用的方法和技术，还应清楚说明功能意图的由来和背景。
接收测试的时间：
预计接收测试的时间
环境搭建的时间：
执行测试用例前测试环境搭建需要的时间
该需求市场发布时间：
需求的补丁包或版本提供给市场的时间
备注：
需求理由：
该需求提出的原因
需求承诺完成的时间：
yy-m-d
需求来源：
需求提出人
验收标准：
要求1；
要求2；
要求3
需求依赖关系：
需求与现有功能及以前的需求是否相关
冲突需求：
其他项目是否提过相反是要求
支持材料：
对技术的实现可提供材料
需求变更历史：
简要记录需求变更的过程
备注：
二、开发人员填写
需求编号：
可依据项目编号，如RIIL-BMC-审计署-机房-0001
输入数据的有效性检查；
操作的顺序，包括事件的时间设定；
响应，例如，溢出、通信故障、错误处理等；
受操作影响的参数；
降级运行的要求；
用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）；
输出数据的有效性检查。源自输出详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息；
XX需求跟踪
一、需求人员填写
需求编号：
可依据项目编号，如RIIL-BMC-审计署-机房-0001
需求管理规范 (4)
目录1.前言 (2)2.需求管理背景 (3)3.需求管理流程 (3)4.指导规范 (4)5.需求管理体系 (6)5.1.制度 (6)（一）总则 (7)（二）机构职责 (7)（三）总体工作流程 (10)（四）需求提出 (10)（五）需求分析 (10)（六）需求评审 (11)（七）需求跟踪 (12)（八）需求实现 (12)（九）附则 (12)5.2.细则 (13)5.3.流程图 (13)5.4.评审细则 (14)5.5.模板 (15)5.6.编写指南 (16)6.合理性评价 (16)1.前言需求定义和管理是开发流程中最重要的一步，它能够确保软件项目符合客户的需求，遵守相关的合同并且在预算计划内按时完成。
此外，这也是诸如集成的能力成熟度模型（CMMI）这类标准、法规和质量改进计划的要求。
由于需求表达不佳造成的影响是毁灭性的，它会产生多米诺效应，导致开发团队需要耗费大量的时间对已完成的开发工作进行返工，无法按时交付产品，超出预算以及各种法规遵从问题。
优秀的需求管理方案从技术上和法律上都可能实现，能使需求变得完整、清楚。
保持一致性，不会与其它需求发生冲突。
证明系统满足需求，可以对需求进行跟踪，可以对需求进行唯一识别和跟踪。
此外，需求应该是模块化的，并且可以修改而不会造成过多的影响。
它们还应该独立于设计。
为了对需求进行组织和管理，可以采取以下的主要步骤。
首先，对需求进行组织，以避免重复和遗漏。
接下来，对客户需求、软件需求以及材料等信息进行管理并将其关联起来，通过集中的需求管理数据库来获取规格和要求。
然后，对那些决定性能、接口、安全等的非功能要求或者制约因素进行管理。
功能和非功能要求的文字版本应该通过直观的建模加以补充，这种建模包括从简单的白板图纸到精心制作的幻灯片演示在内的一切内容。
此外，还可通过将它们明确映射至测试案例的方式来保证需求可以测试，确保每个需求从一开始就可以明确识别，从而能够更加轻松地满足这些需求并实际证明。
需求跟踪矩阵的内容
需求跟踪矩阵的内容1. 介绍需求跟踪矩阵需求跟踪矩阵是一个用于追踪软件项目需求的工具。
它能够帮助团队有效地管理和掌控需求变更，确保项目在开发过程中的各个阶段能够满足用户的需求。
该矩阵记录了项目的需求以及与之相关的信息，如需求的来源、状态、优先级等，从而为开发团队提供了一个清晰的需求全貌。
2. 需求跟踪矩阵的结构需求跟踪矩阵通常由表格组成，其中包含了多个字段用于描述需求的各个方面。
常见的字段包括需求编号、需求描述、需求来源、需求状态、所属模块、开发优先级、验收标准等。
这些字段能够帮助团队跟踪和管理需求的生命周期，并确保参与项目的各方都对需求有一个共同的理解。
2.1 需求编号需求编号是每个需求的唯一标识符，用于在矩阵中区分不同的需求。
编号可以采用自定义的规则，比如简单的序号、项目缩写+序号等。
2.2 需求描述需求描述是对需求的详细说明，包括需求的背景、目标、功能要求等信息。
一个清晰、准确的需求描述能够帮助开发团队准确理解用户的期望。
2.3 需求来源需求来源是指提出该需求的人或团队。
需求可以来自于不同的渠道，比如用户反馈、市场调研、相关部门等。
记录需求来源能够帮助团队了解需求的背景和动机。
2.4 需求状态需求状态标识了需求所处的状态，比如已提出、待评审、开发中、已完成等。
需求状态的变更能够帮助团队了解需求的进展情况，并及时处理需求相关的事务。
2.5 所属模块所属模块指明了需求所属的功能模块或系统模块。
将需求按模块分类能够帮助团队更好地组织和安排开发工作，并便于后续的维护和升级。
2.6 开发优先级开发优先级用于确定需求的重要性和紧急程度。
通过给需求设置优先级，团队可以合理安排开发资源，确保高优先级需求得到及时处理。
2.7 验收标准验收标准是对需求实现的一组判断规则。
它描述了需求完成后应满足的条件和表现，便于项目验收和用户验收的进行。
3. 如何使用需求跟踪矩阵需求跟踪矩阵在项目的不同阶段都扮演着重要的角色。
需求分析模板
需求分析模板需求分析模板
1. 项目描述
- 项目名称：
- 项目目标：
- 项目背景：
- 项目范围：
- 项目期望交付时间：
2. 功能需求
- 功能1：
- 描述：
- 输入：
- 处理：
- 输出：
- 功能2：
- 描述：
- 处理：
- 输出：
- ...
3. 非功能需求
- 性能要求：
- 可用性要求：
- 安全性要求：
- 可扩展性要求： - 可维护性要求： - ...
4. 用户需求
- 用户1：
- 描述：
- 优先级：
- 需求详细描述：
- 描述：
- 优先级：
- 需求详细描述：
- ...
5. 系统需求
- 需求1：
- 描述：
- 优先级：
- 需求详细描述：
- 需求2：
- 描述：
- 优先级：
- 需求详细描述： - ...
6. 需求验证方法
- 验证方法1：
- 描述：
- 验证步骤：
- 预期结果：
- 验证方法2：
- 描述：
- 验证步骤：
- 预期结果：
- ...
7. 需求追踪矩阵
- 需求编号1：
- 涉及功能1：
- 涉及用户1：
- 涉及系统需求1： - 需求编号2：
- 涉及功能2：
- 涉及用户2：
- 涉及系统需求2：
- ...
以上是一个常用的需求分析模板，你可以根据实际情况进行相应的调整和修改。
软件项目WBS模板(V模型)
配置管理 需求管理
软件研制任务书入库 发布功能基线
建立需求跟踪矩阵 发布需求跟踪矩阵 维护需求跟踪矩阵
定义软件生存周期 定义项目过程 制定WBS
进行软件估计 评审软件估计 确定软件项目总体进度和 里程碑进度 进行软件项目风险评估 编写软件开发计划
编制配置管理计划
编制质量保证计划
编制X计划 编制Y计划
编制配置项测试计划初稿 编制系统测试计划初稿
编制软件配置项测试计划初稿 编制软件配置项测试说明初稿 评审软件配置项测试计划初稿 （SEG内部评审） 评审软件配置项测试说明初稿 （SEG内部评审）
参与软件系统测试计划初稿编制
编制用户文档
参与软件系统测试说明初稿编制 参与软件系统测试计划评审（系 统工程组内部评审） 评审软件系统测试说明初稿（系 统工程组内部评审）
评审项目软件各计划
各计划入库 软件项目策划阶段里程碑
顶层要求培训 工作技能培训
需求文档编制 配置管理 需求管理
编制软件需求规格说明 评审软件需求规格说明（同行评 审） 编制接口需求规格说明 评审接口需求规格说明（同行评 审）
软件需求规格说明入库 软件接口需求规格说明入库 建立分配基线 发布分配基线
维护需求跟踪矩阵
4.6.4 4.6.4.1
软件产品集成测试阶段 计算机配置项测试
4.6.4.2 4.6.5
4.6.5.1 4.6.5.2 4.6.5.3
4.6.6 5 软硬件集成测试阶段
5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.3 5.3.1 5.3.2 5.3.3