需求跟踪矩阵(模板)
需求跟踪矩阵(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
需求管理 Microsoft Word 文档
需求管理因业务需要，“中科永联”正式更名为“中程在线”，欢迎大家浏览新网站“中程在线信息产业培训网”中科永联高级技术培训中心（）需求管理（Requirement management）是完整管理模式中的一环，同其他特性诸如完整性、一致性等不可分割，彼此相关而成一体。
一套需求管理应当是已知系统需求的完整体现，每部分解决方案都是对总体需求一定比例的满足（甚至是充分满足），仅仅解决部分需求是没有意义的。
对关键需求的疏忽很可能是灾难性的，试想一架飞机的安全设计不过关将会带来什么样的后果。
不同的需求组合起来，构成了一套完整的需求模型。
用户需求决定了系统设计所要解决的问题，所要带来的结果。
可以说，需求管理指明了系统开发所要做和必须做的每一件事，指明了所有设计应该提供的功能和必然受到的制约。
需求管理的过程，从需求获取开始贯于整个项目生命周期，力图实现最终产品同需求的最佳结合。
通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。
需求管理本就是一个动态的过程，离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。
需求管理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。
仅从字面出发，如果一个产品满足了客户需求，那它无疑就是成功的。
需求管理的过程，从需求分析开始贯穿整个项目始终，力图实现最终产品同需求性的最佳结合（参见Figure 1）。
通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。
需求管理能够确证：●我们确知客户的需求是什么（质量）；●满足客户需求的最佳解决办法（统一性）；著名学者Crosby对于质量的定义是"同需求保持统一"。
从这个意义上说，需求管理正是从质量出发以确定需求。
每个人都应当始终明白他们所做的具体任务其意义何在。
然而，在一个产品的生命周期里，其需求性是能动的，是处于变化之中的。
对于系统工程没有严格统一的定义，因此很难找到足够的数据以说明系统工程所起的作用。
需求跟踪表模板
需求跟踪表
项目名称：
说明：
1、此表以需求编号作为唯一，可维护一对多关系。
2、原编号填入该需求在《用户需求说明书》中的编号
2、需求编号方法：日期_4位流水号（yyyymmdd_0001）,例如20000517_0001;
3、需求类别：A、功能性需求B、非功能性需求；
4、优先等级：A、B、C、D、E五个等级；
5、需求状态：A、已提出；B、已批准；C、已拒绝；D、已变更；E、已删除；F、已关闭；
6、进度：Y表示已完成，P表示正在进行，---表示不需进入该步骤进行处理；
7、设计、编码、测试用例填写：编号+（命名），具体的编码方法是：design/code/test+4位流水号，例如，design0001
（class）；另外，设计、编码、测试用例需遵循一致的命名约定，如设计模型中名为 class 的类由实施模型中的 class 类来实现。
8、设计可以包括：模型中的对象、关系数据库中的模型、表单，或对象类；代码可以是：类中的方法、源代码的文件名、过程或
函数；测试用例是改需求所对应的测试用例；发布产品版本是该需求所对应的产品版本；
9、本表A,B,C,D,E,F,H,I,J,K栏由需求管理员进行维护；L栏由设计人员进行维护，需求管理员进行检查和跟踪；M栏由开发人员进行维护，需求管理员进行检查和跟踪；G栏由测试经理进行维护，需求管理员进行检查和跟踪。
N栏由项目经理进行维护。
10、需求基线编号填入本次需求基线的编号，对于每一次需求基线的变更都需要建立新的《需求跟踪矩阵》
11、“蓝色字”标注的内容需要及时填写，“黑体字”标注的内容可以延迟到项目验收后填写。
软件项目WBS模板(V模型)
软硬件集成测试计划编制
软硬件集成测试
配置管理 系统测试计划编制 系统测试 配置管理
6.4 7 软件验收测试与交付阶段
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
系统测试里程碑 组织验收 完成验收测试和检查
交付软件产品 配置管理 软件验收测试与交付阶段里 程碑 项目验证 质量保证
决策分析和决定
项目跟踪
配置管理
9 闭项阶段 9.1 9.2
9.3
9.4 9.5
9.5.1
9.5.2
收集、汇总开发过程数据 编制软件项目开发总结报告 编制《软件质量保证总结报 告》 向EPG提交项目数据 配置管理
编制配置项测试计划初稿 编制系统测试计划初稿
编制软件配置项测试计划初稿 编制软件配置项测试说明初稿 评审软件配置项测试计划初稿 （SEG内部评审） 评审软件配置项测试说明初稿 （SEG内部评审）
参与软件系统测试计划初稿编制
编制用户文档
参与软件系统测试说明初稿编制 参与软件系统测试计划评审（系 统工程组内部评审） 评审软件系统测试说明初稿（系 统工程组内部评审）
需求报告分析范例模板
需求报告分析范例模板需求报告分析范例模板一、引言在引言部分，需要说明需求报告的目的和背景，以及对该需求报告的分析方法和结构进行简要介绍。
二、需求分析需求分析是需求工程中的一个重要步骤，它旨在确定用户对产品或服务的需求、期望和约束。
以下是对需求报告中的需求进行详细分析的模板：1. 功能需求：- 详细描述用户对产品或服务功能的需求，包括必需功能和可选功能；- 确定功能之间的关联性和依赖关系；- 根据不同用户群体的需求，进行功能的优先级排序。
2. 性能需求：- 确定用户对产品或服务性能的要求，如响应时间、吞吐量等；- 分析产品或服务在预期使用环境下的性能瓶颈和优化方案。
3. 可靠性需求：- 确定用户对产品或服务可靠性的要求，如故障率、可用性等；- 分析产品或服务在异常情况下的行为和恢复能力。
4. 可用性需求：- 确定用户对产品或服务可用性的要求，如界面友好性、易学性等；- 分析产品或服务的操作流程和用户反馈机制，进行改进和优化。
5. 安全性需求：- 确定用户对产品或服务安全性的要求，如数据保护、身份认证等；- 分析产品或服务的安全漏洞和风险，制定相应的安全策略。
6. 兼容性需求：- 确定用户对产品或服务兼容性的要求，如操作系统、浏览器等；- 分析产品或服务与其他系统的集成，解决兼容性问题。
7. 可维护性需求：- 确定用户对产品或服务可维护性的要求，如易扩展性、代码可读性等；- 分析产品或服务的架构和代码，进行优化和重构。
三、需求确认在需求确认阶段，需要与用户和相关利益相关方进行沟通和讨论，以确保对需求的理解和共识。
1. 确认需求的完整性和准确性，是否覆盖了用户的所有需求；2. 确认需求的可行性和可实现性，是否符合产品或服务的技术限制；3. 确认需求的优先级和紧急性，根据资源和时间约束进行调整；4. 确认需求的变更和追加，根据用户的反馈和实际情况进行调整。
四、需求跟踪需求跟踪是在整个开发过程中对需求的变更和实现状态进行跟踪和管理，以确保项目的可控性和可管理性。
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维护阶段需求变更.................................................... 错误！未定义书签。
需求跟踪的若干实现方式
联系
• 徐明庆 • mqxu@ • QQ：463916
需求跟踪的若干实现方式
目的
• 作为CMMI咨询师，开发模型的主任评估师，本人在工作中经 常遇到关于如何实现需求的双向跟踪问题 • 本文提供若干种需求跟踪方式，希望能起到借鉴作用
若干种需求跟踪方式
• 需求跟踪矩阵 • 需求对应关系表 • 基于编号规则 • 基于存放地址 • 支持需求跟踪的系统工具
需求跟踪矩阵
• 使用简单的二维表格 • 以需求-设计的跟踪为例
设计a 需求1 需求2 需求3 X X Xห้องสมุดไป่ตู้X X 设计b 设计c
需求对应关系表
• 类似于数据库的关系表
需求 需求1
需求1 需求2
设计 设计a
设计b 。。。
实现 实现A
实现B 。。。
测试 用例1
用例2 。。。
基于编号规则
• 为需求及其他工作产品定义编号规则 • 需求编号具有惟一性 • 其他工作产品编号中应用需求编号规则 • 如，对应需求R001对应的 – 设计：R001-D001和R001-D002
– 实现：R001-C008
– 测试： R001-T101
基于存放地址
• 在某些情况下，以需求为中心确定物理存放位置 • 其他的工作产品也存放在同样的位置或者子目录下
支持需求跟踪的系统工具
• 有些开发管理工具能够在不同工作产品间任意建立关联 – 如：TFS
总结
• 本文简单列举了若干实现需求跟踪的方式 • 没有追求语言的严谨，而是希望用最少的文字说明 • 建议根据本身的特征选择或者“创造”适合的需求跟踪方式
需求跟踪矩阵 模板
表格编号：XY202-项目编号-两位顺序号
项目名称： 需求分析 用户需求 编号 章节编号 需求名称 首页 1 状 章节 态 编号 原 始 软件需求 子模块名 系统监视 状态 原始 修改 删除 增加 风电监控 2 修 改 需求优 先级 高 中 低 责任人 概要设计 章节编号
3
删 除
4
567源自8原始需求总数 修改需求总数 删除需求总数 增加需求总数 总需求数
3 0 0 0 3
需求跟踪矩阵
项目经理PM： 系统设计 概要设计 名称 是否完成 责任人 详细设计 章节编号 名称 是否完成 责任人 代码单元 编码实现 是否完成 责任人 √ √
项目QA： 功能测试 测试单元 是否完成 责任人 备注