共创力研发咨询/杨学明
1. 原始需求提取活动在测试分析设计中的位置
原始需求提取活动，是产品测试需求分析活动的第一个子活动，在产品分析之后，依赖于产品分析确定的来源范围。原始需求提取活动的输出，作为产品测试规格分析活动的输入。
2. 角色职责
原始需求提取责任主体是本次产品的TSE，视具体规模和人员情况，TSE可以独自承担或者组织系统组成员分工完成。TSE要注意分工原则的合理性，并对最终提取出来的原始需求结果负责。
1 活动过程指导
1.1 活动步骤
首先，TSE需要视情况进行任务分工，然后进行具体的原始需求提取工作，并对每一个原始需求明确其测试规格分析要采取的工程方法。
因为不同来源范围或者不同分工责任主体提取出来的原始需求可能存在重复和冗余，所以整个过程中还存在着原始需求的整理工作。
1.1.1 TSE任务分工
TSE视本次产品具体规模和人员情况，决定是否需要进行任务分工。
分工的原则很多，不同的测试组可以不一样。可以按照特性这条线来分工，将该特性的开发文档，以及对应该特性相关的协议、标准、规范等划分到一个人；有些测试组也可以按照子系统来分工，比如：话单子系统，话统子系统等等。考虑分工原则时，不要忘记对整个产品的分析任务，也需要人负责，比如：产品的性能指标、可靠性指标等等.。TSE要考虑分工的合理性，并对最终结果负责。
1.1.2 原始需求提取
下面按照不同来源范围，分别说明其对应的原始需求提取方法。测试原始需求主要来源于五个方面：开发需求、协议和规范、用户需求、继承产品需求、测试经验库。
1.1.2.1 来源范围是开发需求（DR）
来源范围是开发需求的情况，涉及的开发文档包括产品包需求、设计需求、设计规格等。
目前FE-SE项目组对设计需求和涉及规格重新进行了定义，初步任务设计规格包括了设计因素，不适合作为测试分析设计的主要输入依据，设计需求才是测试分析设计的主要输入，设计规格作为参考输入，所以对于产品遵循IPD3.0流程，或者设计需求已经等同满足IPD3.0的质量要求的情况下，原始需求提取的直接输入是设计需求，原始需求提取活动和设计规格设计活动同步进行。
对于在FE-SE项目组还没有发布前，或者设计需求还有很多信息需要补充的情况，这时仍然需要将设计规格作为原始需求提取的主要输入。此时，原始需求提取启动时间点滞后于设计规格设计，需要等设计规格初稿完成后启动。
对于主要输入是设计需求的情况，可以考虑直接将一条设计需求作为一条原始需求来提取，然后参考产品包需求（或者还可以参考设计规格），检查提取出来的原始需求是否存在遗漏。当然，如果觉得设计需求的粒度不合适，可以考虑拆分成多条或者合并为一条原始需求，具体操作方法由TSE来把握。为明确测试和开发需求的对应关系，要明确提取的原始需求对应的需求标识，这里可以用对应的设计需求的标识，如果有合并的情况，则对应多个设计需求标识。
对于主要输入是设计规格的情况，因为设计规格中包含了较多设计成分，是依据设计需求分解出系统、子系统甚至模块的需求和具体实现，这时在提取原始需求时，要把握好提取的层面。因为测试分析设计是针对SDV/SIT，是产品层面的测试。不同于项目级IT和ST，所以在工作对象上应该限定在系统或者子系统层面。如果过多的关注系统内部的设计实现，会偏离了测试的方向，同时和项目级IT/ST工作重复。在理想情况下，从整个产品的测试流程来考虑，各个阶段的测试应该是分层的，各级有自己的目标、输入输出准则，各个阶段的测试串起来后实现对产品的全覆盖。而相互间又尽可能减少重复和冗余，以提高整体测试效率。但各个产品不一定都达到理想状况，部分产品可能实际在SDV/SIT中，还需要适当增加一些涉及内部实现的测试。一方面对项目级测试的抽检，一方面也对重复的实现细节进行验证。对于这种情况，可以考虑在后续产品或特性测试规格分析中，增加对应的测试规格，但我们建议在原始需求提取时，限定在系统或者子系统层面。这里提取出来的原始需求，对应的需求标识填写设计规格的标识。
同时，在从设计规格中提取原始需求时，还需要从测试角度来考虑。如前面所说，设计规格更多的是设计而不是需求，已经按照系统实现的方式将需求进行了分解，但这种分解方式并不一定适合测试。例如一个彩铃业务的需求，在设计规格中分解为如下五个功能块来实现：功能规格-支持彩铃业务触发、功能规格-支持彩铃业务启动、功能规格-支持彩铃业务建立、功能规格-支持彩铃业务拆除、功能规格-支持彩铃业务计费。但这种需求的划分方式不适合测试角度的划分，或者说不是最优的测试角度划分方式，因为实际测试中不可能去单独测试启动或者单独测试计费，而是在一个完整的流程中将一次将这两个点都覆盖了。对于这种情况，有两种操作方式：一是将设计规格合并还原为需求，再按照测试角度划分后提取原始需求，比如可以按照彩铃业务不同的触发方式，每种触发方式都能覆盖彩铃业务的全流程，所有触发方式融合起来能覆盖设计规格中的五个功能块实现；另一操作方式是按照设计规格来提取原始需求，分析得出产品测试规格后，通过后期的测试规格整合工程方法再来处理，以最终满足测试的要求。
提取出来的原始需求需要明确优先级。可以参考开发需求的优先级。
提取出来的原始需求都要有一个编号。具体的编号规格参见《测试分析设计编号方案》。
上面提到的情况，都是基于开发过程规范、开发文档质量满足要求的情况。但实际情况可能存在偏差，从开发文档中难以提取原始需求，或者就没有可供参考的有效的开发文档。这时是不是就不需要提取原始需求呢？其实我们提取原始需求的主要目的，就是要理清测试的输入，对于这种测试输入不明的情况，我们更应该强化这个活动。可以采用如下一些方法：通过和开发的讨论、交流，配合TSE的经验和对协议规范、用户需求的理解，把存在于开发人员脑子里的未文档化的需求明确；或者，参考传输某产品对于缺少开发文档的情况，是通过代码倒推系统实现的流程图，再明确系统层面的需求规格，也可供参考。当然，我们首先应该做的，还是推动开发区提高文档质量，这也是为什么测试分析设计强调前期测试要有自己输出的原因，因为通过测试的输出可以反向验证开发输出的质量，才能有效推动其改进。
1.1.2.2 来源范围是协议和规范（PR）
对于来源范围是协议和规格的情况，因为协议规范，同时也是作为开发需求的输入，两者实质上是保持一致的，所以如果两者分别提取原始需求会存在大量重复。实际操作中，通常是将开发需求和相关的协议规范分配给同一个人，以其中一个为主另一个为辅来进行原始需求的提取。比如以开发需求为主提取原始需求后，再针对协议、规范来分析补充，可补充的原始需求通常包括如下情况：开发文档未详细说明，而是参加某某协议规范；开发文档未充分考虑到相关协议规范的要求，存在遗漏或者错误；除开发文档要求外，还存在其他需要遵循的规范和标准等情况。
而对于某些特殊情况，也可以以协议规范为主来提取原始需求，如协议一致性测试，或者开发文档质量无法满足要求等情况。另外对于某些协议支撑类功能（如：智能业务），开发依据协议进行设计时，常常是从协议中定义的各种流程提取各种共性部分，然后针对这些共性的部分进行设计，相当于把流程拆成一个一个点进行设计。这种情况下我们也可以考虑以协议为主进行要求提取，辅助以开发的设计文档对流程的细节进行补充。
如前面所说，将协议规范作为一个来源范围来考虑，其中一个目的也是反向验证开发文档质量，所以在原始需求提取过程中发现的开发文档的问题，都要及时反馈给开发去修改，这也是为什么正常情况下测试分析设计的各个阶段和开发阶段应该有一定对应关系，这样便于测试反向验证的结果能尽可能早的反馈到开发去修改，减少返工带来的工作量，同时也让测试参与开发文档的评审活动更有针对性和目的性，是带着问题和建议去评审，提供开发文档质量的目的是为了满足测试工作输出的要求。
提取出来的原始需求需要明确优先级，可以参考对应开发需求的优先级。
1.1.2.3 来源范围是用户需求（UR）
同前面协议规范描述的原因一样，单独从用户需求和开发文档中提取原始需求，也会存在大量的重复，所以通常也是将开发文档和相关的用户需求文档分给同一个人，以其中一个为主另一为辅来进行原始需求的提取。因为开发需求往往是对用户需求的细化分解，所以一般情况下是以开发需求为主提取原始需求后，再通过对用户需求的分析验证看提取的原始需求是否全面正确。同时，为了让测试更直接面向用户，可以以用户需求为主线，将从开发需求提取出来的原始需求进行整理，因为实际上将这些开发需求还原后，真正的需求来源就是用户需求。
质量较高的用户需求通常是从用户实际使用的角度来描述和划分的（可以称之为用户使用场景），这比较符合我们测试的习惯或要求。这样我们可以把它们直接作为我们的原始需求核心内容，由于用户考虑问题并没有参考我们系统实现的知识，所以对应到具体的系统上信息不完整，所以需要结合设计需求、设计规格和产品知识进行补充，使得其更加完整和准确。
部分用户需求是没有体现在产品开发需求中的，但却可能提取作为原始需求。例如：局点的特殊组网要求、特殊数据配置要求。从系统开发角度来分析并不涉及开发，但可能需要进行测试验证；另一类是程序适配或者数据配置实现的需求，比如某些产品具有多国适配功能，对于新国家或地区的编号方案、信令方式等用户需求，通过程序适配或者数据配置就实现了，不涉及到开发，但却可能是需要进行测试验证的。因为之前即使测试了多国适配功能，也是从开发角度上对功能的验证，而且对于这种适配功能的测试，一般很难做到穷举测试，现在结合实际应用，还需要考虑从用户的角度进行验证，验证的是用户需求，而不是以前的开发规格。
还有一类是以解决方案实现的用户需求，分为两种，一种是不涉及开发，是通过多个产品组网或组合，或者结合数据配置来实现的客户化解决方案，这里可以产生直接的原始需求；另一种解决方案，涉及到跨产品的开发，可以分解出各个产品的开发需求，在对各个产品的开发需求进行验证后，还需要考虑验证各产品组合后整体解决方案的实现，是否能满足用户需求。这种解决方案形式的用户需求，可以参考 Marketing 的相关文档（如某某解决方案市场技术指导书）。
提取出来的原始需求需要明确优先级，可以通过对用户需求优先级的分析来明确（参见《测试风险评估方法》），同时对于已经从开发需求提取出来的原始需求，还可通过从用户需求直接分析获取的优先级，检验开发需求优先级的合理性。
1.1.2.4 来源范围是继承产品需求（SR）
来源范围是继承产品需求的情况，可以使用继承性分析工程方法，对产品继承特性（包括从其他产品继承的特性），对历史测试情况、网上使用情况反馈、网上应用环境变化、与新增特性的交互关系等方面进行继承性分析，根据分析的结果可能提取出原始需求。
同时通过继承性分析，还可以得到测试策略建议，和需要进行功能交互分析的继承特性，测试策略建议作为制订测试总体策略参考，需要进行功能交互分析的继承特性作为后续产品测试规格分析中功能交互分析工程方法的输入，经过分析后产生新的产品测试规格。
具体操作参见《继承性分析工程方法》
1.1.2.5 来源范围是测试经验库（ER）
如下两个问题是我们经常面对的，工作没有形成闭环，提出的问题和改进点没有得到有效监控和落实，经验基本是通过经历来获取，缺乏有效共享和继承。针对这两个问题，测试分析设计项目提出建立测试经验库，以达到测试工作的闭环和经验的有效共享和继承。经过CBSC测试组的初步实践，取得了较好的效果，已经成为测试组的一项例行工作发挥作用。
测试经验库的详细内容和操作方式参见《测试分析与设计维护活动指导书》，其中一项重要内容是通过测试执行、缺陷分析、网上应用反馈、相关产品同步等途径提取出来的原始需求库。这些原始需求可以作为测试分析设计的直接输入，在后续版本中落实。目前无线在部门级推广测试需求库，进行统一管理，其他产品可供参考。
1.1.3确定测试规格分析工程方法
原始需求提取出来后，需要明确后续产品测试规格分析活动中要采用的工程方法。目前己经确定的工程方法包括：测试类型分析、功能交互分析、关联图分析。
测试类型分析：从原始需求自身角度出发，借助测试类型的多个纬度来进行分析，得出不同测试类型下对应的产品测试规格，以提高测试分析完备性，详细说明参见《测试类型分析工程方法》。
功能交互分析：从原始需求和系统其他相关特性的交互出发，分析相互的交互影响，每一个交互点都可能派生出产品测试规格，详细说明参见《功能交互分析工程方法》。
关联图分析：从用户角度出发（注意这里的用户是泛指，而不仅仅指人）来关注每个用户是如何使用和影响被测功能特性，通过明确被测功能特性的所有用户和每个用户的影响接口，来确定每个被测功能特性的边界，从而得出产品测试规格，详细说明参见《关联图分析工程方法》。
实际操作中TSE还可以借助其他工程方法分析，来得出产品测试规格，在这些初始的产品测试规格的基础上，TSE通过测试特性建模得出测试特性，同时通过测试规格整合，得出最终的产品测试规格用于分解分配。
我们建议在资源（人力、时间等）允许的条件下，对于从开发需求、协议规范、用户需求中提取出来的原始需求，都经过测试类型分析、功能交互分桥，这两种工程方法可以互补，对于从继承产品需求提取出来的原始需求，至少要经过功能交互分析，最好也能进行测试类型分析；对于从测试经验库里提取出来的原始需求，通常情况下可不需要再采取特别的工程方法，直接参与后续测试规格整合即可；而关联图分析的工程方法，因为是针对功能特性而不是针对原始需求，所以可以由TSE视实际情况选取，作为对其他工程方法的补充。
除了这里确定的三种工程方法，各个产品各个测试组还可以根据自身实践，不断积累提炼新的工程方法加以应用。如果实际中出现资源不足无法完全按照如上原则来操作的情况，则由TSE根据具体情况综合权衡来从中选择一种或几种工程方法。
1.1.4原始需求整理
在原始需求提取过程中，需要考虑对重复的冗余的原始需求进行整理，同时从不同来源范围提取出来的原始需求，粒度可能存在差别，可以考虑进行细化或合并整理，保持粒度上的均匀。最终TSE要汇总所有的原始需求，并按一定方式来组织归类，如按照需求来源，或者按照特性。
整理后由TSE完成测试分析设计表的测试原始需求表。
作者简介：
杨学明 清华大学MBA，深圳市共创力企业管理咨询有限公司总经理，深圳市汇成研发管理咨询有限公司董事长，资深研发管理专家，国内首席研发管理专家，曾服务于华为，阿里巴巴等知名企业，杨老师先后在国内开设研发类公开课100多场，服务内训客户1000多家，为数百家企业提供了研发咨询服务，典型的客户如深圳迈瑞、华立仪表、步步高、英威腾、雷赛智能、埃斯顿、华工科技、中国科学院、电力科学研究院、中国工商银行、重邮信科、从兴电子、浙大网新、联迪商用等。近两年服务的客户如中电海康、网易、苏宁云商、烽火科技、29所、华为技术、中兴通讯、广联达、大唐电力、招商局、京信通信、航盛电子、国电南瑞、中航工业、维力医疗、寒武纪科技、海南邮政、京仪股份、海尔集团等。
