需求跟踪矩阵
【PMP考试通】需求文件和需求跟踪矩阵
【PMP考试通】需求文件和需求跟踪矩阵
收集需求过程是PMBOK中相对比较重要的一个过程,该过程的ITTO(“输入、工具、输出”的英文单词缩写)都非常重要,所以这是在授课时着重去讲的过程。今天我们主要来讨论一下该过程的输出—需求文件和需求跟踪矩阵。
经常会有学员会有疑问,不太理解需求文件和需求跟踪矩阵的区别,我们先来看一下PMBOK对于这两项文件的描述:
需求文件描述各种单一需求将如何满足与项目相关的业务需求。一开始,可能只有高层级的需求,然后随着有关需求信息的增加而逐步细化。只有明确的(可测量和可测试的)、可跟踪的、完整的、相互协调的,且主要干系人愿意认可的需求,才能作为基准。需求文件的格式多种多样,既可以是一份按干系人和优先级分类列出全部需求的简单文件,也可以是一份包括内容提要、细节描述和附件等的详细文件。
需求跟踪矩阵是把产品需求从其来源连接到能满足需求的可交付成果的一种表格。使用需求跟踪矩阵,把每个需求与业务目标或项目目标联系起来,有助于确保每个需求都具有商业价值。需求跟踪矩阵提供了在整个项目生命周期中跟踪需求的一种方法,有助于确保需求文件中被批准的每项需求在项目结束的时候都能交付。最后,需求跟踪矩阵还为管理产品范围变更提供了框架。
我们把以上内容简化一下:需求文件,可以理解为是对已经收集到的各种需求的记录文件,为了使需求文件看起来更加正式正轨,我们可以对已经记录的需求进行分类,例如业务需求、干系人需求、解决方案需求、项目需求等;而需求跟踪矩阵,就是将与需求关联的一系列属性通过表格的形式记录,这样根据需求的编号可以向前或向后追踪,向前可以追踪到原始需求,向后可以追踪到可交付成果等,目的是为了保证成果是符合干系人需求并且满足商业利益和价值。
需求跟踪矩阵
结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项 结项
评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过
评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过
评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过 评审通过
原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 原始 删除 删除 删除 删除 删除 删除 删除 删除 删除 删除 删除 删除 删除 删除
需求跟踪矩阵(需求管理过程)
LOGO
需求跟踪矩阵
1需求跟踪矩阵—单元测试前阶段
1
义,编号必须唯一,而且统一,可以使用数字、中文、英文;2)当工作产品发生变更时,要及时更新(填写)需求跟踪矩阵。
【填表说明】
1)单元测试用例对应软件设计;2)当工作产品发生变更时,要及时更新(填写)需求跟踪矩阵。
3 需求跟踪矩阵--系统测试阶段
1)系统测试用例对应软件需求;2)当工作产品发生变更时,要及时更新(填写)需求跟踪矩阵。
4 需求跟踪矩阵--验收测试阶段
12
写)需求跟踪矩阵。
需求跟踪矩阵_产品版本标识
填写说明: 1)产品经理完成本文件的第一版,后续由软件需求、设计、测试负责人进行完善 2)本文件与产品需求、软件需求、设计文档、测试案例一同评审并基线 3)项目组如裁剪软件需求,则需完成产品需求到设计的跟踪,可删除软件需求到设计跟踪 4)项目组如不裁剪软件需求,则需完成软件需求到设计的跟踪,产品需求到设计的跟踪可删除 5)测试案例如使用TD维护,应将可说明跟踪关系的截图粘贴在产品需求到测试案例跟踪一页 6)其他跟踪关系项目组可自行添加,如跟踪到架构设计、集成测试案例、单元测试案例、代码等
产品需求跟踪矩阵
所属产品 编写人 编写日期 修订记录: 版本号 修订人 修订日期 修订描述
说明: 1 )该表用于产品开发过程中维护需求跟踪性。如果产品线或项目组使用 RequisitePro 或其他需求管理工 具,则不必wk.baidu.com用此表。 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_一级模块英文/中文第一个大写字母_二级模块英文/中文第一个大写字母_功能点英文/中文第一个大写字母)
RD01-04需求跟踪矩阵
代号
1 1 1 1 1 1 1 1
400 401 402
系统模块 接收呼叫信息并转入呼叫队列 排队呼叫信息根据设置分派给在线客服人员 3 3
403 404 405 406
向指定终端发送控制命令 根据指令拨打电话 发送短信 自动检测布防报警终端状态
3 3 3 3
需求跟踪矩阵
需求状态 需求变更次数 设计产品名称 代号 详设产品名称 代பைடு நூலகம் 编码 测试文档名称
需求跟踪矩阵
需求编号 需求简述 优先级
100 101 102 103 104 105 106 200 201 202 203 204
运行在家庭网关上主要负责信息采集配置管理 输入、修改客户资料。基础数据部分从crm接口获取 设置指定客户的房屋结构图、设置各防区信息设置、各防区 报警信息 设置支持的探头类型 设置短信网关地址流媒体服务器地址自动巡查时间间隔等系 统参数 主要是设置PHS、PSTN等类型拨号报警器 针对不同的客户提供不同的服务类型 运营中心服务器 设置报警方式、设置报警目标 设置不同布防方案 控制现场布防方案 查询报警日志以及布防日志信息 4 4 4 4 2 2 2 2 2 2
300 301 302 303 304 305 306 307 308
客服平台 查询客户资料\根据客户要求修改可以修改的客户资料 应答客户请求 显示报警分部图\报警列表、提供指定视频查看、更改布防、 撤防状态、拨打预设联系电话、发送报警短信、 增加、修改、删除、停用客服人员设置客服人员等级设置客 服优先接警规则 增加、修改、删除、停用客服人员设置客服人员等级设置客 服优先接警规则 查询客户报警以及布防日志信息。查询客服人员服务日志信 息。 对客服人员的工作位置进行设置 设置客服人员回答客户问题所使用的常用语
需求跟踪矩阵的内容
需求跟踪矩阵的内容
1. 介绍需求跟踪矩阵
需求跟踪矩阵是一个用于追踪软件项目需求的工具。它能够帮助团队有效地管理和掌控需求变更,确保项目在开发过程中的各个阶段能够满足用户的需求。该矩阵记录了项目的需求以及与之相关的信息,如需求的来源、状态、优先级等,从而为开发团队提供了一个清晰的需求全貌。
2. 需求跟踪矩阵的结构
需求跟踪矩阵通常由表格组成,其中包含了多个字段用于描述需求的各个方面。常见的字段包括需求编号、需求描述、需求来源、需求状态、所属模块、开发优先级、验收标准等。这些字段能够帮助团队跟踪和管理需求的生命周期,并确保参与项目的各方都对需求有一个共同的理解。
2.1 需求编号
需求编号是每个需求的唯一标识符,用于在矩阵中区分不同的需求。编号可以采用自定义的规则,比如简单的序号、项目缩写+序号等。
2.2 需求描述
需求描述是对需求的详细说明,包括需求的背景、目标、功能要求等信息。一个清晰、准确的需求描述能够帮助开发团队准确理解用户的期望。
2.3 需求来源
需求来源是指提出该需求的人或团队。需求可以来自于不同的渠道,比如用户反馈、市场调研、相关部门等。记录需求来源能够帮助团队了解需求的背景和动机。
2.4 需求状态
需求状态标识了需求所处的状态,比如已提出、待评审、开发中、已完成等。需求状态的变更能够帮助团队了解需求的进展情况,并及时处理需求相关的事务。
2.5 所属模块
所属模块指明了需求所属的功能模块或系统模块。将需求按模块分类能够帮助团队更好地组织和安排开发工作,并便于后续的维护和升级。
2.6 开发优先级
需求追踪矩阵
关于需求跟踪矩阵的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,是否所有的需求都被覆盖了。
需求跟踪矩阵
需求跟踪矩阵
1. 简介
需求跟踪矩阵是一种用于追踪软件开发项目中的需求和实
现之间的关系的工具。通过创建一个需求跟踪矩阵,开发团队可以清楚地了解每个需求是否已经得到满足,并且可以在项目的不同阶段进行跟踪和评估。本文将介绍需求跟踪矩阵的定义、作用以及如何使用Markdown文本格式输出。
2. 定义
需求跟踪矩阵是一个表格,其中列表示项目的需求,行表
示项目的实现。通过填充矩阵中对应的单元格,可以追踪每个需求的实现状态。需求跟踪矩阵通常包括以下列:
•需求ID:对需求进行唯一标识的编号。
•需求描述:对需求进行详细描述,包括其背景、目
的和功能要求等。
•需求状态:表示需求的实现状态,如“已实现”、“未
实现”、“正在实现”等。
•需求优先级:表示需求的优先级,如“高”、“中”、“低”等。
•实现说明:对需求的实现进行详细说明,包括具体
的实现方式、开发进度等。
3. 作用
需求跟踪矩阵可以帮助开发团队在整个项目开发周期中跟
踪和评估每个需求的实现情况。它具有以下主要作用:
•需求管理:通过列出和描述每个需求,需求跟踪矩
阵帮助团队清晰地了解项目的需求,并确保所有需求都得
到满足。
•进度追踪:通过填充矩阵中的需求状态和实现说明,团队可以追踪每个需求的实现进度,并及时发现和解决可
能存在的问题。
•问题发现:通过对比需求跟踪矩阵中实现状态与实
际开发情况,可以及时发现需求是否被遗漏或实现是否存
在问题,并及时进行调整和改进。
•优先级管理:通过列出需求的优先级,可以帮助团队合理安排项目开发的顺序,并确保重要的需求得到优先满足。
4. 如何使用Markdown文本格式输出
需求跟踪矩阵
知识创造未来
需求跟踪矩阵
需求跟踪矩阵是一种项目管理中常用的工具,用于跟踪需求与项目的关联关系。它有助于确保项目中的所有需求得到满足,并提供了一种追踪需求变更和确认的方法。需求跟踪矩阵通常由一个二维表格组成,其中列代表项目中的需求,行代表项目中的各个阶段或工作包。每个单元格中的标记表示该需求在对应阶段或工作包中的状态。以下是一个示例需求跟踪矩阵:
阶段/工作包 | 需求1 | 需求2 | 需求3
项目规划| √ | |
需求分析| | √ | √
系统设计| √ | √ |
编码| | √ |
测试| √ | | √
验收| √ | √ |
在这个例子中,我们可以看到每个需求在项目的每个阶段或工作包中的状态。例如,需求1在项目规划、系统设计、测试和验收阶段都得到了满足,而需求2只在需求分析、系统设计和编码阶段得到了满足。需求跟踪矩阵可以帮助项目团队了解需求的状态,及时发现并解决与需求相关的问题,并确保项目按照预期进行。
1
需求跟踪矩阵
1.目的和范围
本文件用于项目的需求跟踪,以确保该项目需求在需求分析、设计实现、测试等环节得到完整的管理一般情况下需求跟踪包括以下环节内容(详见需求跟踪矩阵):
追溯输入需求:即建立项目需求与其来源需求的追溯;
跟踪此需求的分解和实现的过程;
跟踪需求的设计实现和相关验证过程情况。
2、填表说明
1)“需求来源”:需说明需求的出处,如:业务/产品自身完善/运维/客户等
1)需求部分,在项目立项后,需求确认阶段填写,由项目经理或指派人员填写;
2)设计部分,在项目实现阶段填写,由项目经理或指派人员填写;
3)测试部分,在项目测试阶段填写,由项目测试负责人填写;
4)完成状态,在测试结束后,由项目经理填写。
的管理和控制,保证一致性。
需求分解与需求跟踪矩阵
需求分解与需求跟踪矩阵
需求分解是将需求分解成一个个的功能点。先写出大的模块,然后子模块,然后细分成各个功能点,模块的个数名称,子模块的层数,名称,功能点均可维护。同时每个功能点后面还有开发人员和维护人员的记录。开发人员和维护人员可以根据不同时期叠加。
需求跟踪矩阵保存需求与最终成果间的对应关系。具体就是要写出需求中功能点相对应的需求分析文档,详细设计文档,代码及相应的版本。
入口:从需求分解中取出详细的功能点。
功能点:功能点编号,功能点说明,所属模块,功能点变更;功能点的变更可以有数次。
需求文档:各功能点对应的需求文档,文档名称,作者,基线时间,版本,修改时间,备注
。每个文档可以有数次的修改。
设计文档:各功能点对应的设计文档,文档名称,作者,基线时间,版本,修改时间,备注。每个文档可以有数次的修改。
代码:对应功能点编号,组件/包/类名称,代码存放位置,文件名称,作者,版本
测试报告:测试报告名称
需求跟踪矩阵
功能点
功能点编号功能点说明所属模块功能点变更时间功能点变更次数功能点变更内容
需求文档
文档名称作者基线时间版本修改时间备注
代码
功能点编号代码存放位置文件名称作者版本
需求跟踪矩阵 模板
3 0 0 0 3
需求跟踪矩阵
项目经理PM: 系统设计 概要设计 名称 是否完成 责任人 详细设计 章节编号 名称 是否完成 责任人 代码单元 编码实现 是否完成 责任人 √ √
项目QA: 功能测试 测试单元 是否完成 责任人 备注
ห้องสมุดไป่ตู้需求跟
表格编号:XY202-项目编号-两位顺序号
项目名称: 需求分析 用户需求 编号 章节编号 需求名称 首页 1 状 章节 态 编号 原 始 软件需求 子模块名 系统监视 状态 原始 修改 删除 增加 风电监控 2 修 改 需求优 先级 高 中 低 责任人 概要设计 章节编号
3
删 除
4
5
6
7
8
原始需求总数 修改需求总数 删除需求总数 增加需求总数 总需求数
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
2008/8/20 修改
1
阶段 需求分析 概要设计 概要设计 详细设计 详细设计 编码单元测试 编码单元测试 集成测试 系统测试 验收测试
涉众类型 客户 研发人员 客户 研发人员 客户 研发人员 客户 系统限制 客户 客户
注:每次更新需求跟踪矩阵的需求信息时,首先填写变更明细表
变更记录人
张三 李四 张三 李四 张三 李四 张三 李四 王二
2、需求变更在各阶段的分布
阶段
需求分析 概要设计
需求变更数 0
5
需求分布 0.00% 35.71%
详细设计 3 21.43%
编码单元测试 集成测试
2
1
14.29%
7.14%
系统测试 2 14.29%
需求变更数
5 4.5
4 3.5
3 2.5
2 1.5
1 0.5
0
需求变更数
需求分 析
0
概要设 计
5
详细设 计
3、需求稳定度/变化率统计
初始
增加
删除
修改
未更改变更数 现有需求总数 需求稳定度
16
9
2
3
11
23
68.75%
注:
1、需求稳定度 = 未更改变更数/原始需求总数
2、需求变化率 = 需求变更总数/原始需求总数
其中:需求变更总数 = 增加的需求数+删除的需求数+修改的需求数
需求变化率 87.50%
参考文档 需求规格说明书 需求变更统计表 需求变更统计表 需求变更统计表 需求变更统计表 需求变更统计表 需求变更统计表 需求变更统计表 需求变更统计表 需求变更统计表
累计需求 16 20 20 22 21 22 22 21 23 23 23 23
变化率
25.00% 5.00% 10.00% 4.55% 4.76% 4.55% 4.55% 9.52% 4.76% 0.00% 0.00%
3
编码单 元测试
2
集成测 试
1
系统测 试
2
验收维 护
1
注:由该图可以看出项目各阶段的需求变更数
验收维护 1
7.14%
需求变更数
总计 14 100%
wk.baidu.com
各阶段需求变更分布图
0%
7%
14%
36%
7%
14% 22%
需求分析 概要设计 详细设计 编码单元测试 集成测试 系统测试 验收维护
注:由该图可以看出项目各阶段的需求变更的分布(用百分比表示)
<项目名称>需求度量分析
1、需求变更明细表
变更日期 需求数
2008/6/10 原始需求 16
2008/6/20 增加
4
2008/6/21 修改
1
2008/7/10 增加
2
2008/7/10 删除
1
2008/7/20 增加
1
2008/7/20 修改
1
2008/7/30 删除
1
2008/8/10 增加
2