04需求跟踪矩阵(模版)V1.4_SINO-I-IT-QM-模板-2008-188-A
- 格式:xls
- 大小:115.00 KB
- 文档页数:2
编写需求跟踪矩阵指南山东中创软件工程股份有限公司二ОО七年三月文件变更记录*A–增加M–修改D–删节目录1目的 (1)2角色和职责 (1)3格式 (1)4表格说明 (1)4.1项目基本信息 (1)4.1.1 角色等基本信息 (1)4.2需求跟踪矩阵(纵向) (1)4.2.1 基线标识 (1)4.2.2 列值说明 (1)4.2.3 注意事项 (3)4.3 需求跟踪矩阵(横向) (4)4.3.1 列值说明 (4)5需求跟踪矩阵的不断完善 (4)1目的需求跟踪是需求管理的一项重要内容。
需求跟踪的主要意义在于获得需求目前的实现状态,确保用户所有的需求都得到满足。
它的主要目标是: 维护软件工作产品间的一致性。
2角色和职责3格式需求跟踪矩阵采用EXCEL电子表格形式制作。
具体格式请参考《需求跟踪矩阵模板》。
4表格说明4.1项目基本信息4.1.1 角色等基本信息填写项目名称、项目经理、项目小组责任人、更新次数、最后更新日期、更新需求跟踪矩阵的工作量(多次更新累加)以及版本号(此为需求跟踪矩阵的版本号)等信息。
4.2需求跟踪矩阵(纵向)4.2.1 基线标识列出该需求跟踪矩阵中用到的各个工作产品的基线标识号。
4.2.2 列值说明关于优先级的说明:优先级表示的是某项内容相对于同类的其他内容的优先级顺序,其取值范围为:高、中、低。
如果某几项内容的优先级相同则将其优先级设为相同的值。
《用户需求说明书》需求编号:《用户需求说明书》中描述软件需求的唯一代号(或标识)。
责任人:相关需求的责任人。
《软件需求规格说明书》需求编号:《软件需求规格说明书》中每项需求的编号(如:章节号)。
责任人:相关需求的责任人。
优先级:相对于其他需求,实现该需求的优先级顺序。
《系统测试方案》系统测试用例编号:《系统测试方案》中用例的编号(如:章节号)。
责任人:相关测试的责任人。
优先级:相对于其他测试用例,实施该用例测试活动的优先级顺序。
《概要设计说明书》概要设计编号:《概要设计说明书》中每条设计的编号(如:章节号)。
关于需求跟踪矩阵的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,是否所有的需求都被覆盖了。
5 RTM是否纳入基线管理?RTM要纳入基线管理。
纳入基线后,每次变更都要申请,RTM的变更一般是和其他配置项的变更一起申请,很少单独申请变更RTM,除非RTM有错误。
6 如何简化RTM的工作?由于在RTM中,需求可能有很多项,设计、测试用例、代码等都有多项,所以建立和维护RT M的工作量还是比较大、比较烦琐。
需求跟踪修订历史记录日期版本说明作者2007年8月<1.0> 第1次发布Louis1 目的将系统设计、编程、测试等阶段的工作成果与需求文档进行比较,建立与维护“需求文档-设计文档-代码-测试用例”之间的一致性,确保产品依据需求文档进行开发。
2角色流程图3 启动准则●需求文档已经通过正式评审并获得了承诺。
●系统设计、编程、测试等阶段的工作成果如设计文档、代码、测试用例部分或全部已经产生。
4 输入●需求文档●设计文档、代码、测试用例等5 主要活动[Activity1] 初始化跟踪需求矩阵●在需求确认之后,需求分析工程师应根据项目的需求规则说明书初始化需求跟踪矩阵中“需求文档“的部分,同时通知项目组成员及相关人员。
注:具体需求跟踪矩阵格式请参见《需求跟踪报告》模板。
●需求跟踪矩阵中“设计文档”部分的需求跟踪的初始化工作应在程序员完成详细设计后完成初始化工作。
●需求跟踪矩阵中“代码”部分的需求跟踪的初始化工作应在系统编码人员在完成相应的需求功能的编码工作后完成初始化工作。
●需求跟踪矩阵中“测试用例”部分的需求跟踪的初始化工作应在《需求规格说明书》已撰写完成并通过确认后,系统测试之前完成。
[Activity2] 更新需求矩阵●项目成员在提交任务时,如果所完成的工作成果与需求跟踪矩阵的内容相关,应提交工作产品前更新需求跟踪矩阵的相关内容。
●在需求发生变化后,由需求文档的矩阵更新负责人先更新需求跟踪矩阵,同时通知相关的矩阵更新负责人,在各负责人完成相应设计、代码、测试用例等的变更后,更新需求跟踪矩阵。
[Activity3] 跟踪需求矩阵●对于需求跟踪矩阵中“需求文档”部分的跟踪,将放在需求走查及审查评审时,对与评审的需求文档相关的需求跟踪矩阵部分进行走查和审查评审,并将发现的缺陷及问题记录到评审报告中。
●对于需求跟踪矩阵中“设计文档”部分的跟踪,将放在详细设计走查评审时对与评审的设计文档相关的需求跟踪矩阵部分中进行走查评审,并将发现的缺陷及问题记录到评审报告中。
姓名 文本框 必填项,支持20个字符,支持汉字、字母、数字、下划线,特殊字符等
姓名 文本框 必填项,支持20个字符,支持汉字、字母、数字、特殊字符等
教师用户名 文本框 必填项,支持20个字符,支持汉字、字母、数字、特
殊字符等
教师用户名 文本框 必填项,支持20个字符,支持汉字、字母、数字、特殊字符等
发.测试
要求必须输入yyyy-mm-dd格式
1.搜索功能能用,且按钮存在
2.可以根据教师姓名,教授方向,隶属角色,入职日期等内容进行单项查询或组合查询,并都支持模糊查询
3.确定搜索文本框可用,并支持信息输入
4.搜索文本框支持20个字符(一个汉字占两个字符),支持汉字、字母、数字、特殊字符等
5.搜索文本框要支持yyyy-mm-dd
格式,且不能晚于系统时间
教师管理模块-编辑模块:
1.隶属角色-下拉列表-根据班级管理中的角色进行选择;
2.姓名-文本框-必填项,支持20个字符,支持汉字、字母、数字、特殊字符等;(一个汉字占两个字符)
3.教师用户名-文本框-必填项,支持20个字符,支持汉字、字母、数字、特殊字符等;(一个汉字占两个字符)
4.密码-文本框-支持10位字符,支
字符,支持汉字、字母、数字、特殊字符等;(一个汉字占两个字符)
3.教师用户名-文本框-必填项,支持20个字符,支持汉字、字母、数
字、特殊字符等;(一个汉字占两个字符)
4.密码-文本框-支持10位字符,支持数字,字母,特殊符号(字母区分大小写);
5.教授方向-单选-备选开发和测试;
6.入职时间-文本框-要求必须输入yyyy-mm-dd格式。
入职时间。
操作说明:一、需求分析1.模块功能分析分为需求编号、功能、渠道、类别、关键点、结果验证、验证要求、需求标识、需求分析者、对应的用例编估(分钟)、变更文件引申位置、需求变更历史跟踪表、备注、版本2.需求变更历史跟踪表的A-L列与模块功能分析表的A-L列完全相同,新增了需求变更日期、变更指向位置、需求变更前内容注3.需求编号统一用t_req_XXX4.需求编写人员在编写需求分析时,填写A-I列。
在首次编写测试需求时,需求标识为“4-原需求”。
5.用例编写人员填J-K列,将对应的用例编号填入J列、用例量填入K列、用例编写的实际时间填入L列。
注:用例编号的总和6.需求分析人员填M列(变更文件引申位置),在未发生需求变更时该列填原需求名变超链接该需求文档。
二、需求变更1.将变更的需求copy至需求变更历史跟踪表作为历史记录保存并填写需求变更日期、需求指向位置、需求变更前内容/位置、2.变更指向位置要求超链接到变更文档,并指向相应的变更话述。
3.1 当需求发生修改时:手动修改关键点、结果验证、验证要求当关键点、结果验证和验证要求发生变更时,同时将修改需 3.2 当需求新增时,直接在表格最下方新增一条需求,需求标识标记为:新增。
3.3 当该需求被删除时,直接将需求标识修改为:删除4.重新修改用例编号、用例量、用例编写工作量评估。
用例编号为该需求最新的用例编号,用例量为发生变更的用例量,用的用例编写时长。
5.需求变更历史跟踪表要求超链接到需求变更历史跟踪表原有的用例位置。
6.如果需求发生重复变更,则重复步骤1-5需求跟踪表求标识、需求分析者、对应的用例编号、用例量、用例编写工作评期、变更指向位置、需求变更前内容/位置、需求变更提出人、备4-原需求”。
时间填入L列。
注:用例编号的总和应为用例量相等。
链接该需求文档。
求指向位置、需求变更前内容/位置、需求变更提出人。
验证要求发生变更时,同时将修改需求标识为:修改。
号,用例量为发生变更的用例量,用例编写工作量评估为发生变更。
统一充值平台简介统一充值平台主要由充值业务处理、卡信息管理等业务功能构成,实现充值操作的核心控制功能,主要包括:接收来自IVR或自服务平台的充值请求,对充值卡进行鉴权、对被充值帐本进行归属认证,向被充值用户余额归属系统(OCS/HotBilling/SRD/其他系统)发送充值通知和将结果返回IVR或自服务平台1.怎么调研需求?客户提供一些资料,需求人员根据资料编写问题清单,在会议中与客户确认问题,了解客户的流程。
客户提供资料-》整理问题——》开会调研-》确认问题-》形成文档(用户需求说明书)2.使用什么方法分析及定义需求?a. 操作概念?产品的总体描述b. 操作场景?操作逻辑等,使用产品时可能发生的事件顺序,以明确说明干系人的需要c. 定义一个需求时,包含哪些内容?输入、输出、界面、逻辑d. 优先级有什么用?在需求规格说明书中,决定开发顺序和投入资源及测试等的投入资源等3.形成什么结果?用户需求调研单、用户需求和产品需求、需求跟踪矩阵a.产品需求中的内容;b.产品需求完成之后项目组完成产品设计需求;c.需要了解产品设计需求里面包含哪些接口d.用户需求书中内容软件需求说明书的编制是为了使用户和软件开发者双方对该软件的运行环境、功能和性能需求的初始规定有一个共同的理解,使之成为整个开发工作的基础,为概要设计提供需求说明。
e.产品需求说明书内容软件需求说明书的编制是为了使用户和软件开发者双方对该软件的运行环境、功能和性能需求的初始4. 怎么进行需求跟踪?a. 是用什么文档?需求跟踪矩阵---记录对应关系b. 需求跟踪矩阵的使用方法需求阶段,我们开发和分析出用户需求说明书之后对把客户需求提取出来记录在需求跟踪表中,然后在对应用户需求的章节做填写,然后在开发和得出产品需求规格说明书的时候,也要对需求做章节的追溯和不要遗落需求!而且在需求变更之后,也要对变更的需求做记录和跟踪,并分析其影响和记录!在设计阶段,针对已经填好的需求跟踪列表做更新,在概要设计和详细设计出来之后都要对需求做比较,查看是否有遗漏的需求,或者新加了哪些需求,变更哪些需求,都要记录和实时跟踪其影响和效果!在编码阶段,在做单元测试的时候,就是要对其集成的模块做最基础的需求的测试和分析,查看是否满足了需求跟踪表中的需求,是否有变动需求和更改需求,如果发现了更改和变动以及遗漏就要马上告之且修改!当然在测试阶段也要重新对整体集成之后的测试版做全部需求的覆盖测试和全部的需求功能的实现完整性测试!查看是否满足和变动了需求,是否有遗漏的需求,是否有对需求理解不到位的需求,是否有新增不需要的需求!c. 需求跟踪矩阵里面包含什么内容?见需求跟踪矩阵的内容(需求、设计、编码、测试)d. 哪些人使用?整个项目团队在各个阶段完成时填写e. 什么时候填写及更新?完成每个阶段的工作后填写,需求变更后更新该表f.需求跟踪矩阵有什么用?检查完整性、分析变更影响性5. 怎么进行需求评审?a. 评审哪些人参加?评审报告中,团队所有领域代表b. 评审流程是怎么样的?预评审和正式会议评审,评审的时候使用检查检查单c. 评审的时候需要检查什么?-见评审检查单必要性和正确性,一致性和完整性d. 怎么跟客户确认需求?在评审会议中,以往的产品和原型展示给客户。
需求追踪矩阵编写规程Preparation of Requirement Traceability Matrix1 目的/Purpose本规程规定需求追踪矩阵编写和维护This document defines the procedure on the preparation and maintenance of requirement traceability matrix.2 范围/Scope2.1 所有与质量有关的设备和系统All quality related equipment and system.2.1.1设备:工艺设备及化验室设备、仪器Equipment: process equipment and laboratory equipment/ instrument.2.1.2系统:设施与公用系统System: Facilities and utilities.2.1.3计算机系统:工艺控制与分析系统、化验室信息管理系统、制造资源计划、警惕及文档管理系统Computerized system: process control and process analytical system, laboratory information management systems, manufacturing resource planning, vigilance and document management system.3 职责/Responsibilities3.1 用户部门/User Department编写和更新需求追踪矩阵Prepare and update the requirement traceability matrix.3.2 生产运营部/Operation审核专业化计算机系统如仓库管理系统等需求追踪矩阵Review all enterprise system eg warehouse management system requirementtraceability matrix.3.3 公共支持部/Utilities Support审核DCS、SCADA、数据采集系统、生产设备/系统计算机系统、公用工程和环境监控系统需求追踪矩阵Review DCS, SCADA, data acquisition system, computerized manufacturing equipment/ system, utilities and environmental monitoring system requirement traceability matrix.3.4 质量管理部/Quality Management Departmenta)审核需求追踪矩阵Review the requirement traceability matrix.b)批准需求追踪矩阵Approve the requirement traceability matrix.4 定义/DefinitionDCS:分布式控制系统Distributed Control System.SCADA:监督控制和数据采集Supervisory Control and Data Acquisition. RTM:需求追踪矩阵Requirement Traceability Matrix.一个以矩阵形式将所有规定的需求和规格映射到最终系统和所执行测试的文件A document that maps all defined requirements and specifications to the final systems and tests performed using a matrix.5 程序/Procedure5.1 需求追踪矩阵编写Preparation of RTM5.1.1需求追踪矩阵可以从计划、开发和确认阶段循序渐进编写或修订不过只需要在验证结束时批准。