04需求跟踪矩阵(模版)V1.4_SINO-I-IT-QM-模板-2008-188-A
填写目的
注意事项
1
2
3
表单说明
一
（一）
1
2
3
4
5
6
7
8
（二）
1
2
3
4
（三）
1
二
（一）
1
2
（二）
2
三（一）
1
2
3
4
（二）
1
2
四（一）
1
2
3
4
5
6（二）
1
2
3（三）
1
2
五（一）
1
2
3
4（二）
2
3
4（三）
1
六（一）
1
2
3
4
（二）
1（三）
1
2
3
填写说明与使用指南
用于项目需求的跟踪以及需求变更的统计。
使用时可删除掉“模版信息”工作表。
表单中此种颜色表格为自动计算，无需填写。
表单中此种颜色表格为下拉列表，请从列表中选择选项作为单元格的值。
××模块功能点列表
字段定义
子系统:对于所实现系统在功能上做的整体划分，可以是某个子系统；
功能模块:子系统下的功能点的集合；
功能点：通过用户交互触发、外部系统触发或后台程序触发来完成的一个完整的动作；
功能点编号：为“需求用例编号”+“-”+“功能点流水号”。每个功能模块下的功能点，流水号从01起编。需求用例编号为：系统名称的拼音缩写＋功能模块序号＋需求用例流水号。
如果需求划分到需求用例级，则需求用例流水号从01起编。例：需求用例编号为MPJ0301，对应的功能点编号则为：MPJ0301-01、MPJ0301-02等。
如果需求只划分到功能模块级，则需求用例流水号用“00”表示。例：需求用例编号为MPJ0300，对应的功能点编号则为：MPJ0300-01、MPJ0300-02等。注意此列不能为空；
从属编号：如果某个功能点在不同模块中重复出现，则再次描述时，须填写“从属编号”,即为此功能点第一次出现时分配的功能点编号；
重要程度：一般与客户业务需求相关。指产品部门对于需求要求的精细程度.项目组依据此程度制定开发策略，由高到低依次为1级、2级和3级。通常系统的核心模块，级别最高。注意此列不能为空；需求是否明确：指相关需求第一次形成基线时，功能点描述是否准确、可行。如准确则填“是”，反之填“否”。根据《评审报告》填写；
删除说明：需求分析阶段结束之后，后续如有删除功能时，需要在该列填写删除原因，如：产品部门要求本版不实现或研发部门暂时无法实现等。仅当删除功能点时填写该列。
填写要点
功能点包括：本版本新增功能点，以及以往版本中已经存在的、需要在本版本中删除或修改的功能点。如：功能点MPJ01-01属于版本1.0中的功能，在版本1.1中需要删除或修改此功能，则版本1.1中的功能点列表中也要包含MPJ01-01；
需求分析阶段填写该表。之后，如有新增功能点，则增加在相应模块底部，字体设置为红色；如有删除功能点，用蓝色标记同时在“删除说明”中标明原因；
此表由项目经理主导编写并维护；
即使需求存在部分不明确的内容，但是，重要程度仍然需要填写。
使用指南
为“功能点汇总表”提供基础数据。
通用功能点列表
字段定义
通用功能点：可以为本产品或者其他产品多次使用的功能点称为通用功能点；
功能点编号：为“需求用例编号”+“-”+“功能点流水号”。每个项目的通用功能点，流水号从01起编。需求用例编号为：TY＋功能模块序号＋通用需求（用例）流水号。如果没有对应到具体的功能模块，则功能模块序号用00表示。每个模块的需求用例流水号从“01”起编。例：需求用例编号为TY0001，对应的功能点编号则为：TY0001-01、TY0001-02等。
填写要点
需求分析阶段填写该表。之后，如有新增功能点，则增加在通用功能点列表底部，字体设置为红色；如有删除功能点，用蓝色标记，同时在“删除说明”中标明原因。对于在其他模块中也引用了该通用功能点的功能点，也应用蓝色标识，以示被删除；
其它填写说明，请参照“××模块功能点列表”中的填写要点。
非功能需求列表
字段定义
非功能需求点概述：指软件产品为满足用户业务需求而必须具有的、除功能需求以外的特性。软件产品的非功能性需求，包括系统的性能、可靠性、可维护性、可扩充性和对技术、对业务的适应性等；非功能需求点编号：不强制要求编号规则，只需保证需求矩阵中的编号与非功能需求说明书中的编号一一对应，且唯一即可；
重要程度：一般与客户业务需求相关。指产品部门对于需求要求的精细程度.项目组依据此程度制定开发策略，由高到低依次为1级、2级和3级。通常系统的核心模块，级别最高。注意此列不能为空；需求是否明确：指相关需求第一次形成基线时，功能点描述是否准确、可行。如准确则填“是”，反之填“否”。根据《评审报告》填写。
填写要点
本表与《需求规格说明书》同步形成需求基线。之后，如有新增功能，则增加在相应模块底部，字体设置为红色；如有删除功能，用蓝色标记；
即使需求存在部分不明确的内容，但是，重要程度仍然需要填写。
功能点汇总表
字段定义
从属功能点数：= 子系统或功能模块中包含的从属编号的个数；
实际功能点数：= 子系统或功能模块中包含的“功能点编号”的个数 - 所包含的“从属编号”个数；
功能点数：根据“模块功能点列表”，分别统计重要程度为1级、2级和3级的功能点个数。功能点数为三者之和。
需求未确定功能点数：依据“模块功能点列表”中的“需求是否明确”中的“否”进行统计；
需求未确定率：＝ 需求未确定功能点数/功能点数；
重要程度分布比例：＝ 各级别的功能点总数/整个系统的功能点总数。
填写要点
需求基线第一次形成后填写该表。如有需求变更，本表不更新。如果需求分别形成基线，则分次填写；
本表填写后，需更新下方的两个图；
项目组可根据项目规模大小，决定：是按照子系统进行汇总统计？还是按照模块进行汇总？
使用指南
通常，重要程度为1级的功能点数，不超过50%；或者1级和2级的功能点数，不超过80%。如果超过上述比例，则项目经理应与客户沟通后调整，以便项目组采取最优的开发策略；
通过查看“需求未确定率”，可以判断各模块/子系统需求是否讨论清楚。如果需求未确定率过高（例如，超过20%），则反映该部分的需求还不清晰，需要项目组协同客户重新进行讨论；
需求变更记录表
字段定义
变更类型：分为新增、修改、删除三种。新增功能，字体设置为红色；如有删除功能，用蓝色标记；提出阶段: 指项目计划中划分的阶段,在第一次填写该表时确定。可参考本页右侧的《阶段对应表》。例如：“单次交付型项目”的设计、编码、测试等阶段或者“多次展示，单次交付型项目”的阶段一、阶段二等；
变更工作量：（1）项目组根据需求变更预估的工作量（含开发和测试）填写；（2）如果一次变更包含多个功能点，变更申请的预估工作量是针对多个功能的，变更记录还是按照一个功能点一条记录填写，变更工作量可以合并单元格把多个功能点的工作量合起来填写；
是否应变更需求基线：两种情况下，填写“是”。（1）某阶段内，需求变更累计导致里程碑延期大于10个工作日；（2）整个阶段内，需求变更对里程碑的影响不超过10个工作日，则里程碑结束前，统一进行一次变更。
填写要点
该表记录需求基线形成后发生的所有需求变更，包括需办理变更手续和不需办理变更手续的变更项；根据需求变更提出的情况，本表随时记录；
每一个功能点的变更，均做为单独一条记录记载；
QA工程师将定期（建议每里程碑结束）冻结历史变更记录；
使用指南
为“需求变更统计表”提供基础数据。
需求变更统计表
字段定义
变更功能点数：根据“需求变更记录表”，分别统计某阶段内，新增、修改和删除的功能点个数。变更功能点数为三者之和；
功能点总数：＝ 上一阶段形成需求基线时统计的功能点总数＋本阶段新增的功能点数－本阶段删除的功能点数；
对于“分次交付型项目”，功能点总数：＝本次交付中第一次形成需求基线时的功能点总数（即初始功能点数）＋新增的功能点数－删除的功能点数。其中，增加和删除，只针对本次交付中第一次形成的需求基线而言，不包括以往交付中的需求在本阶段的变更；
需求变更率：＝本阶段变更的功能点数/本阶段的功能点总数。如采用“单次交付型项目”，则统计设计、编码、测试等阶段的需求变更率。如采用“多次展示，单次交付型项目”/“分次交付型项目”，则根据展示阶段或交付阶段分别统计需求变更率；
变更工作量：指变更申请提出后，项目组预估的工作量，应与“需求变更记录表”中记录的工作量保持一致。
填写要点
每个阶段结束后，项目经理填写本表，并同步更新下方的三个图；
使用指南
本表是《项目周报》中“里程碑报告”的组成部分；
通过需求变更率，观察需求的稳定趋势。如果某阶段需求变更率较大（例如：超过15%），则建议项目组尽快协同产品经理对需求进行重新讨论和确定。通常，“单次交付型项目”和“分次交付型项目”，变更率较小；“多次展示，单次交付型项目”，变更率可能会大一些；
通过变更工作量，辅助分析 里程碑进度偏离的原因。