今年开始做需求跟踪的活。需求跟踪的目的是针对需求和团队情况给出对应的策略，帮助特性开发团队更高效高质量的交付特性需求。

你说这个活没有技术含量吧，可是我又没跟踪好；要说这个活有技术含量吧，说实话还真不需要啥技术，这里的技术类似于C++技术的概念。这里主要是对最近半年以来跟踪需求的总结。可能需要多篇文章来覆盖。

在公司内部，需求的生命周期包括如下几个阶段，下面列出我在每个阶段的角色和目标，以及经验教训。

（1）需求提出；

这个阶段我不需要参与，只需要在阶段（2）的时候知道有这个需求即可。

这个阶段，一般都是用户提交的功能需求或者内部提交的优化需求；

（2）需求评审；

这个是我需求跟踪的开始阶段。

需求评审会把需求系统工程师以及相关人员集中评审一下，由需求系统工程师牵头评审。

这个阶段主要是看该需求是否合理、如何实现等等。需求中会列出需求背景、需求场景、实现需求的意义、需求验收的准则等等。

这个阶段，我关注的是如下abc。

a.搞清楚需求是什么；

前提：用户为什么会提出该需求，用户使用该续期的场景是什么，用户怎么使用该需求，有没有当前已经实现的功能可以满足该需求，实现该需求是否与当前已有功能冲突，或者是否与自动化用例有冲突；

作用：搞清楚上述后，就可以大概知道要做什么功能了。如果该需求是在以前需求的基础上开发的，需要找出来依赖的需求看一遍详细的流程是怎么样的，这个时候就可以把测试策略中的测试点列出来了。

b.该需求的依赖是什么；

前提：是否需要联调，联调环境谁来提供，环境是否能够满足当前功能验收，联调时间什么时候，是否依赖外部实现，如果依赖外部实现，外部实现什么时候提供，是否已经和外部协商好联调时间；是否可以自动化，如果需要自动化，当前工具是否支持；是否依赖其他需求，如果依赖，就要学习下依赖的需求，以及之前需求是否有对应的测试策略、测试用例、自动化用例、QA测试报告可以参考下。

作用：提前协调好环境为后面测试验收做好准备。如果该需求依赖其他需求，就要提前学习下依赖的需求，并告知给QA一起学习；

c.该需求合入到哪个版本，人力安排是怎么样的；

前提：该需求要求什么时候提供，开发和测试人员是否已经安排，人力是否能够满足，开发和测试是有经验，或者开发和测试以前经常犯错的地方是否熟悉；安排的人力，中间是否有其他任务安排，比如其他功能验收，外场故障的支持等等。

作用：测试策略出来后，就可以知道大概的人力需求了，再和安排的人力评估下就知道该需求是否能够如期交付了。

需求评审阶段的经验教训就是，一定要搞清楚需求是什么，用户怎么用这个需求，不要被实现细节困住，可能现有的方案实现（也就是阶段3）都无法满足用户的要求。

需求评审阶段的目标是大概列出测试策略，就是主要的测试点。

（3）方案评审；

这个阶段我也会参与。该阶段还是由需求系统工程师牵头。

该阶段主要是把实现需求的详细细节描述下，比如用到的关键技术、需求场景详细的流程、接口变更、数据库变更、客户端和服务端实现细节。如果有客户端变更，是否需要UX出高保真图，这个需要需求系统工程师和开发BA确认，如果需要出高保真图，还需要中UX画出高保真图后评审。如果需求不大，可能都不需要方案描述，直接在需求中描述下实现细节，就不用走方案评审了。

这一阶段，我关注的就是如下abc.

a.客户端是否有变更；

前提：如果有变更，是否需要UX出高保真图；客户端显示的数据最初来源于什么地方，是取自文件，还是数据库，长度有没有要求，如果有要求，是否存在超过该长度的场景；如果新增了客户端界面，是否考虑过对新增界面的权限控制；客户端组件是否需要测试，如何测试，验收标准是什么。

作用：知道客户端显示的数据是否正确。

b.接口是否有变更或者新增；

前提：如果客户端到服务端到接口有变更，是否波及之前到功能，需要测试下，比如新增了字段，新增的字段是必选还是可选还是条件必选，什么情况会用到这个字段，该字段是否允许传递多个参数，还是只能传递单个参数，传递的参数来源于什么地方，字段的长度是否有要求；响应接口是否有变更，异常情况是否有考虑。如果接口中有涉及ftp等，是否满足GDPR要求。

作用：能够根据接口的变更找出代码流程的分支，从而确定此次需求改动波及的地方，从而确定出详细点测试点。

c.数据库是否有变更；

前提：数据是否入库，是否新增表或者表中新增字段，为什么要新增表字段，作用是干什么的；如果新增字段或者表是否考虑过版本升级或者全新安装后表数据的迁移与兼容；数据什么时候入库，入库的数据是否正确，新增的字段是否必选/可选/条件必选，这些数据的最初来源是什么地方。

作用：搞清楚服务端在做什么。

d.方案是否需要分阶段做完

前提:当方案大到需要分阶段或者联调计划分阶段时，这个时候可以把方案拆分出更小的粒度，方便分析与交付。

作用:当拆分方案后，暂时只需要关注这一小块即可，跟踪起来也容易，交付质量也能够得到保证。具体多大才算大，我自己认为当需要多个流程覆盖的时候就是比较大的方案，可以拆开来做。并且让系统工程师在方案中标注每个阶段交付的功能，方便后面测试跟踪。

方案评审阶段的经验教训就是，一定要画出流程图，一定要画出流程图，一定要画出流程图，重要的事情说三遍。只有通过流程图才能尽可能的不遗漏测试点。另外，大需求可以拆开来做，然后跟踪。

方案评审阶段的目标就是完善测试策略，测试策略基本上完成了。

（4）故事卡评审；

这个阶段我也会参与。该阶段由开发BA牵头。

故事卡就是把开发需要做的事情详细的描述出来，接口间的调用顺序是怎么样的，如何写缓存，数据如何传递的。

这一阶段，我关注的和目标就是，补充完善测试策略。

这一阶段过后，就开始开发了。

（5）测试策略评审；

这个阶段由我牵头，评审测试策略，就是如何测试这个需求，测试什么，如何测试。

主要是把需求中的测试点和方案中分析出来的波及测试下。测试策略需要列出客户端的测试策略，业务流程的测试策略，配置/安全/告警/性能/资源/安装升级/接口/文档修改的测试策略，自动化的测试策略等等。

测试策略评审过后，就是QA写文本用例了。文本用例是UT/FT/人工/自动化测试的依据。

（6）测试用例评审；

这一阶段就是评审下QA根据测试策略写出的测试用例。

这一阶段，我关注的是测试用例检查点是否齐备，测试点是否完整，测试方法是否有。

测试用例评审阶段的经验教训就是，一定要在测试用例评审的时候检查好用例的检查点是否齐全，测试点是否满足。

（7）开发；

这一阶段，我基本上不参与。

（8）QA测试；

这一阶段会稍微参与下。关注下开发实现是否满足该需求，以及提醒QA测试是否遗漏。

QA测试阶段的经验教训就是，一定要根据QA的测试水平来判断是否要关注QA测试，比如开发实现的界面是否满足高保真图/国际化，自动化用例写的是否满足要求，如果QA水平不高，一定要在自动化用例刚开始写的时候检查下，以防止后面自动化用例返工。
QA测试完成后，提醒QA提交QA测试报告。

（9）功能演示；

这一阶段我也会参与。功能演示的目的就是大家一起看下开发实现是否满足该需求，主要是QA演示下需求的正常功能。

该阶段结束后，需求的特性开发阶段就基本上结束了。

（10）验收；

在自动化用例和QA测试完成后，功能就交付给后端测试了。就走到我这边验收了。

验收是否通过的标准，就是之前评审过的测试用例。如果在测试过程中，发现之前自己定的测试策略遗漏测试点，也只能自己补充下。

总结：需求跟踪主要是以上几个阶段。总体来看，风险发现的越早，造成的代价越小；比如在方案评审阶段就发现该功能实现后也无法满足用户要求，那就能够在未开发前修改方案，如果到验收阶段才发现不满足，那开发的工作量就要白费了。主要的关注点就是，需求是什么，客户端数据/页面，接口变更，数据库变更。

当然在需求跟踪阶段，还有一个比较重要的就是沟通。和系统工程师的沟通，和BA的沟通，和开发人员的沟通，和团队SM的沟通，和QA的沟通，和后端测试人员的沟通，和用户的沟通。这个还真是一门艺术，在需求跟踪过程中，有时候就会和团队SM因为需求的并行开发，或者和QA的验收等沟通存在过摩擦，等后面专门学习下相关的书籍提升下自己的沟通。

这一篇也仅仅是对需求的生命周期做了下回顾，后面还需要补充与优化。