(1)测试需求的名称

　　为了便于对测试需求进行规范管理，方便查询和统计分析，用来唯一标识一个测试需求。

　　(2)测试需求的编号

　　“需求编号”采用“REQ-A-B-C”四段编号，其中“REQ”代表需求，“A”代表系统名称，“B”代表模块名称，“C”代表三位的功能点顺序编号，从“001”编起。

　　如“REQ-CCI-外呼-001”，表示CCI系统“外呼”功能模块的第一个功能点。

　　(3)上级需求的编号

　　为了对某测试需求进行详细划分，请将该测试需求作层状显示。如下所示：

　　需求1

　　需求11

　　需求111

　　……

　　需求12

　　需求121

　　……

　　需求2

　　需求21

　　需求211

　　……

　　需求22

　　需求221

　　……

　　“上级需求名称”，即为该需求的父需求名称。若为空，表示该需求为第一级需求。

　　(4)所属子系统名称

　　例如：

　　· BIS：银行保险系统

　　· CCBSS：证券系统

　　· CCI：呼叫中心整合系统

　　· CMIS：信贷管理信息系统

　　· DCC：数据集中系统

　　· EAIH：总行企业级应用整合平台

　　· ECIF：企业级客户信息平台

　　· ECTIP：企业级渠道交易整合平台

　　· IPSS：综合产品服务系统

　　· OCRM：操作型客户关系管理

　　· UDI：数据交换池

　　· SRF：Server Farm(基础实施项目组)

　　· ICS：国际卡系统

　　(5)评审状态

　　为了便于需求跟踪，需要设置该需求的评审状态。

　　“评审状态”有“创建”、“变更”、“评审”三个状态。

　　(6)重要性

　　测试需求的“重要性”用来度量该测试需求对应的“业务需求”在整个系统业务功能中的重要程度，其来源一般依据“软件需求”的重要性指标。

　　“重要性”指标的取值有“核心”、“重要”、“一般”和“可选”四个值。

　　(7)优先级

　　测试需求的“优先级”指标用来表明测试需求实施的优先次序。

　　优先级的取值有“高”、“中”和“低”三个值。

　　优先级取值的设定由测试经理综合考虑测试需求的“重要性”、“稳定度”和“工作量”三个值来设定。

　　(8)稳定度

　　测试需求的“稳定度”指标用来表明该测试需求在测试实施过程中可能发生变更的可能性程度。

　　测试需求的“稳定度”指标有“高”“中”“低”三个取值。

　　影响测试需求稳定度的因素有业务需求的变更、业务需求的不正确理解等原因。

　　需求的稳定度由测试经理根据相应的业务需求的稳定度和其它因素进行设置。

　　(9)工作量

　　测试需求的“工作量”指标用来标明在后续的测试实施过程中，为完全覆盖该测试需求而需要的工作量。

　　该数值由测试经理根据该测试需求对应的业务需求的复杂程度及其业务流程的繁简程度进行设置。

　　该值是一个权重值，采用百分制。

　　工作量最大的为100，最小的为10，以10为增量进制。

　　需求的工作量由测试经理进行设置。

　　据此对测试人员的工作量进行量化考核。

　　(10)版本

　　需求版本用来记录该测试需求对应的测试版本号。

　　(11)创建人

　　记录该测试需求的创建人。

　　(12)创建日期

　　记录该测试需求的创建日期。

　　(13)功能点描述

　　“功能点描述”是对该测试需求对应的业务功能进行详细的描述。

　　每个测试需求只对应一个功能点，这一点一定注意。

　　(14)业务规则描述

　　“业务规则描述”指对与该测试需求相对应业务功能的逻辑约束的描述。

　　业务规则一定要采用R1：到R9：进行编号。