最近遇到一件事，要做一个特性，这个特性并不是第一次从头开始做，之前已经实现了大的框架，流程也已经打通，现在就是这之前的基础上修改一个接口，对齐客户的要求。
按说这样理解起来并没有多少复杂的地方，但是如果上述需求并没有描述清晰具体的流程是什么，系统间的交互应该是怎么样的，是否依赖于其他外部系统，并且需求也没有描述清楚依赖的需求，就是该需求️哪个需求为基础，那么当第一次接触这个需求的时候，难免会摸不清到底要做什么，做成什么样算是ok的，后续如何验收，验收的标准是什么。
于是，我根据这个需求，做了如下工作：
（1）阅读该需求，大概知道这个需求要做什么；
用户为什么要提交这个需求，背景是什么，现有功能是否能够满足用户的需求；
用户如何使用该需求；如果系统被多个外部系统使用时，实现该需求后，是否会影响其他使用该系统的用户；
具体的需求点是什么，比如是修改了接口，还是增加了变量；
（2）如果可以，找到在此需求之前的基础需求是如何实现的；
有没有需求描述，方案是怎么实现的，流程交互又是怎么实现的，系统间交互是什么样子的，此接口什么时候会调用，请求和响应又该是什么样子的，是否对header有要求；
（3）之前的需求是否有测试策略，测试策略重点是测试什么，有没有实现自动化验收；
是否已有测试用例可以参考；
如果实现了自动化验收，自动化用例是否能够满足当前需求的验收，是否对工具有要求，如果有要求，要求又是什么样子的；
之前的人工测试工作量是多少，遇到过哪些坑；自动化用例是如何模拟的，有没有现成的例子供参考下。
（4）对外部的依赖是什么；
是要求外部系统返回新增接口的数据，还是修改的接口的数据的变更/删除；
是否有依赖的外部系统可以用来验收；如果没有如何协调，协调不到如何处理，是否可以只根据自动化用例来验收交付；
该系统是否要对外提供该接口，外部调用该接口的时候是否新增了该参数，那么又涉及到通道问题；
（5）熟悉上述后，画出该需求的流程图；
流程图可以规避遗留功能点；
（6）写出测试策略；
大体是针对该需求的策略；当然最好能够在需求中明确该需求的流程是什么，实际上针对上述的1-5都应该中需求中明确出来。但是有时候并不能中每一个环节都能够做到最好，针对不同的需求，找到应对的策略。当自己无法根据需求文档得到什么的时候，尽可能让需求的作者给出，不懂就要问，这也是我自己需要努力克服的一点。
后面再补充一个需求跟踪的流程。此次也只是需求跟踪中的特例。需求跟踪涉及到很多环节，需要统筹考虑。
