项目需求跟踪矩阵表
简练网软考知识点整理-项目需求跟踪及需求跟踪矩阵
简练⽹软考知识点整理-项⽬需求跟踪及需求跟踪矩阵1.需求跟踪需求跟踪包括编制每个需求同系统元素之间的联系⽂档。
这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助⽂件、⽂档等。
跟踪能⼒信息使变更影响分析⼗分便利，有利于确认和评估实现某个建议的需求变更所必须的⼯作。
2.需求跟踪⽬的需求跟踪提供了⼀个表明与合同或说明⼀致的⽅法，需求跟踪可以改善产品质量，降低维护成本，⽽且很容易实现重⽤。
需求跟踪是个要求⼿⼯操作且劳动强度很⼤的任务，要求组织提供⽀持。
随着系统开发的进⾏和维护的执⾏，要保持关联链信息与实际⼀致。
跟踪能⼒信息⼀旦过时，可能再也不会重建它了。
由于这些原因，应该正确使⽤需求跟踪能⼒。
下⾯是在项⽬中使⽤需求跟踪能⼒的⼀些好处：（1）审核跟踪能⼒信息可以帮助审核确保所有需求被应⽤。
（2）变更影响分析跟踪能⼒信息在增、删、改需求时可以确保不忽略每个受到影响的系统元素。
（3）维护可靠的跟踪能⼒信息使得维护时能正确、完整地实施变更，从⽽提⾼⽣产率。
要是⼀下⼦不能为整个系统建⽴跟踪能⼒信息，⼀次可以只建⽴⼀部分，再逐渐增加。
从系统的⼀部分着⼿建⽴，先列表需求，然后记录跟踪能⼒链，再逐渐拓展。
（4）项⽬跟踪在开发中，认真记录跟踪能⼒数据，就可以获得计划功能当前实现状态的记录。
还未出现的联系链意味着没有相应的产品部件。
（5）再设计（重新建造）你可以列出传统系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。
通过定义跟踪能⼒信息链提供⼀种⽅法收集从⼀个现成系统的反向⼯程中所学到的⽅法。
（6）重复利⽤跟踪信息可以帮助你在新系统中对相同的功能利⽤旧系统相关资源。
例如：功能设计、相关需求、代码、测试等。
（7）减⼩风险使部件互连关系⽂档化可减少由于⼀名关键成员离开项⽬带来的风险。
（8）测试测试模块、需求、代码段之间的联系链可以在测试出错时指出最可能有问题的代码段。
以上所述许多是长期利益，减少了整个产品⽣存期费⽤，但同时要注意到由于积累和管理跟踪能⼒信息增加了开发成本。
需求跟踪矩阵模板
软件需求 概要设计 系统/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
SugarCRM项目ST需求跟踪矩阵表
关联商业活动 创建新文件
SRS-Documents-FUNC-Manege SRS-My Portal -FUNC-New SRS-My Portal -FUNC-Delete SRS-My Portal -Mass Update
SRS-Campaigns-FUNC-Create
文件管理 添加我的门户网站 删除我的门户网站 批量更新
SRS-SugarCRM-FUNC-001
SRS-SugarCRM-FUNC-002
删除当前机会 批量删除机会
查找重复记录 查看更改日志
合并重复 导出 导入商业机会 批量更新 基本查找 删除当前新闻 批量删除新闻 导出
新增活动
查找活动
SRS-SugarCRM-FUNC-003
SRS-SugarCRM-FUNC-004 SRS-SugarCRM-FUNC-001
快速创建文件
SugarCRM-ST-Documents-New-002
完整创建文件
SugarCRM-ST-Documents-Basic Find
基本查找
SugarCRM-ST-Documents-Advanced Find
高级查找
SugarCRM-ST-Documents-Mass Update
批量更新
新增营销活动
SRS-Campaigns-FUNC-Manage
营销活动管理
SRS-Campaigns-FUNC-Manage
SRS-Campaigns-FUNC-TargetLst-Create SRS-Campaigns-FUNC-Associate-TargetLst SRS-Campaigns-FUNC-AssoTarget-001 SRS-Campaigns-FUNC-AssoTarget-002 SRS-Campaigns-FUNC-AssoTarget-003
需求跟踪矩阵的内容
需求跟踪矩阵的内容1. 介绍需求跟踪矩阵需求跟踪矩阵是一个用于追踪软件项目需求的工具。
它能够帮助团队有效地管理和掌控需求变更，确保项目在开发过程中的各个阶段能够满足用户的需求。
该矩阵记录了项目的需求以及与之相关的信息，如需求的来源、状态、优先级等，从而为开发团队提供了一个清晰的需求全貌。
2. 需求跟踪矩阵的结构需求跟踪矩阵通常由表格组成，其中包含了多个字段用于描述需求的各个方面。
常见的字段包括需求编号、需求描述、需求来源、需求状态、所属模块、开发优先级、验收标准等。
这些字段能够帮助团队跟踪和管理需求的生命周期，并确保参与项目的各方都对需求有一个共同的理解。
2.1 需求编号需求编号是每个需求的唯一标识符，用于在矩阵中区分不同的需求。
编号可以采用自定义的规则，比如简单的序号、项目缩写+序号等。
2.2 需求描述需求描述是对需求的详细说明，包括需求的背景、目标、功能要求等信息。
一个清晰、准确的需求描述能够帮助开发团队准确理解用户的期望。
2.3 需求来源需求来源是指提出该需求的人或团队。
需求可以来自于不同的渠道，比如用户反馈、市场调研、相关部门等。
记录需求来源能够帮助团队了解需求的背景和动机。
2.4 需求状态需求状态标识了需求所处的状态，比如已提出、待评审、开发中、已完成等。
需求状态的变更能够帮助团队了解需求的进展情况，并及时处理需求相关的事务。
2.5 所属模块所属模块指明了需求所属的功能模块或系统模块。
将需求按模块分类能够帮助团队更好地组织和安排开发工作，并便于后续的维护和升级。
2.6 开发优先级开发优先级用于确定需求的重要性和紧急程度。
通过给需求设置优先级，团队可以合理安排开发资源，确保高优先级需求得到及时处理。
2.7 验收标准验收标准是对需求实现的一组判断规则。
它描述了需求完成后应满足的条件和表现，便于项目验收和用户验收的进行。
3. 如何使用需求跟踪矩阵需求跟踪矩阵在项目的不同阶段都扮演着重要的角色。
需求跟踪矩阵模板
地图显示项目点位。 ①地图放大、缩小；②回到
当前定位。 切换地图底图。 ①地名地址搜索；②持项目
名称搜素。 地图显示项目点位。 ①地图放大、缩小；②回到
当前定位。 切换地图底图。 ①地名地址搜索；②持项目
名称搜素。 地图显示项目点位。 ①地图放大、缩小；②回到
当前定位。 切换地图底图。 ①地名地址搜索；②持项目
件测试/验收交付
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
原始
已测试
软件测试
对应概要设 详细设计状 对应详细设
计章节
态
计章节
单元测试 集成测试用 系统测试
用例
例
用例
对应代码
示例：6.1.1 示例：修订 示例：6.1.1 示例：E1 示例：E5 示例：T3.1 示例：
一、项目信息（主要指项目基本信息）
项目名称 项目编号 客户名称 项目经理 项目发起人 编制人
日期
二、需求跟踪矩阵（把产品需求连接到可交付成果，把每个需求与业务目标或项目目标联系起来，有助于确保每
需求跟踪表模板
需求跟踪表
项目名称：
说明：
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、“蓝色字”标注的内容需要及时填写，“黑体字”标注的内容可以延迟到项目验收后填写。
软件开发项目需求跟踪矩阵
一级菜单
模块名称
1 界面需求
全局
全局
2 功能需求 3 功能需求 4 功能需求 5 功能需求 6 功能需求 7 功能需求 8 功能需求 9 功能需求 10 功能需求 11 功能需求 12 功能需求 13 功能需求 14 功能需求
全局 用户管理 用户管理 用户功能 用户功能 用户功能 用户功能 用户功能 用自定义。
单位设置 账户权限过滤 账户登录 对用户进行分组管理 按管理层级查询（及操作）用户权限台帐明细 修改用户组信息 删除用户组 添加新用户 不同角色查看不同的页面 按部门管理不同的用户 访问时间、ip范围等 不同角色配置不同的节点查看操作权限 不同角色配置不同的数据查看操作权限
全局 全局/用户管理 用户权限管理 用户权限台帐 用户权限台帐 用户权限台帐 用户权限台帐 用户权限台帐 用户权限管理 用户组管理 访问配置 用户权限管理 用户权限管理
需求编号
IR001
BR001 BR002 BR003 BR004 BR005 BR006 BR007 BR008 BR009 BR010 BR011 BR012 BR013
优先 所属阶段 级 低 第2阶段
中 第2阶段 中 第2阶段 中 第1阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第2阶段 高 第3阶段 高 第2阶段 高 第2阶段
对应功能
上传Logo图片和输入 项目名称 修改各参数的单位标 签 权限过滤 登录 新建用户组 用户（组）节点树 编辑用户组 删除用户组 添加新用户 权限过滤
数据表
接口
../auth/v1/login
自测用例
系统测试用例 完成情况
R
R R R R S S S S S S S S S
项目管理：怎样做需求分析
如果将需求分析阶段的工作归结为编写需求规格说明书，这种简化的做法往往是导致项目后期层出不穷问题的罪魁祸首。
建议采用以下步骤形成软件需求：获取用户需求→分析用户需求→编写需求文档→评审需求文档→管理需求。
下面我们先来讨论前两个步骤（获取用户需求、分析用户需求）的做法。
获取用户需求这是该阶段的一个最重要的任务.以下为获取用户需求需要执行的活动（如图1所示）。
● 了解客户方的所有用户类型以及潜在的类型。
然后，根据他们的要求来确定系统的整体目标和系统的工作范围。
● 对用户进行访谈和调研。
交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。
需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。
例如，可以将需求细分为功能需求、非功能需求(如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。
● 需求分析人员对收集到的用户需求做进一步的分析和整理。
下面是几条常见的准则：⑴对于用户提出的每个需求都要知道“为什么"，并判断用户提出的需求是否有充足的理由;图1 获取用户需求的活动⑵将那种以“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”；⑶分析由用户需求衍生出的隐含需求，并识别用户没有明确提出来的隐含需求（有可能是实现用户需求的前提条件），这一点往往容易忽略掉，经常因为对隐含需求考虑得不够充分而引起需求变更。
● 需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员.大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。
需求分析人员在这个任务中需要执行下述活动：⑴明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）；⑵使需求符合系统的整体目标；⑶保证需求项之间的一致性，解决需求项之间可能存在的冲突。
分析用户需求在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。