在项目进行的过程中，如果只是靠大家在口头上去同步，那么对ASPICE的需求变更进行管理，还有为它留下相应的痕迹，这件事在后期评审的时候，是站不住脚的，需求一旦发生了变动，跟在它后面的系统设计、软件设计、测试用例、验证的结果，还有那些要交付的文件，全部都会被牵动起来；如果我们只是在开会的时候，随口说了一句“这个地方改一下”，那么到了后面做评审的时候，就很难去解释清楚，当时到底是为什么要改、这个改动经过了谁的批准、它影响到了哪些地方、以及改完之后有没有被重新验证过，ASPICE这套东西，它所关注的，就是过程是可以被追溯的，还有变更一定是处于受控状态的，所以，对需求变更的管理，就是要把它的来源、影响、决策、实施，还有验证，这五个环节给串到一条线上。

　　一、ASPICE需求变更怎么管理

　　在对ASPICE的需求变更进行管理的时候，首先就要把每一次的变更，都当成一个正式的事项去处理，而不是以为把需求的文档改完了，这件事就算结束了，一个项目越往后走，需求的改动所带来的影响面也就越大，特别是那些跟接口、诊断、通信、状态机，还有功能安全有关的需求，更不能只是看到文字上面的变化。

　　1、先把变更的来源给确认下来

　　需求的变更，有可能是来自于客户的评审、系统上冒出来的问题、测试中发现的缺陷、供应商那边的反馈、法规的约束、接口的调整，或者是内部设计上的一些改动，当我们收到了一个变更之后，要先把提出的人、提出的时间、变更的原因，还有它对应的是哪一条需求的编号，都记录下来，不要一上来就直接去需求文档里面动手修改正文，如果来源都搞不清楚，到了后面，就很难去判断，这次变更究竟是客户硬性要求的、是我们内部自己想做的优化，还是纯粹为了修一个缺陷。

　　2、接下来再去做影响的分析

　　做影响分析的时候，不光要盯着这条需求本身看，还要去看它可能会牵动到的那些上游和下游的对象，通常，我们需要去检查一下系统的需求、软件的需求、架构的设计、详细的设计、接口的文档、测试的用例、测试的结果、发布的计划，还有识别出来的风险项，就举一个例子来说，假如一个通信的周期，要从一百毫秒改成五十毫秒，那么被影响到的，绝对不会只是需求文档里的一句话，它后面还可能涉及到总线上的负载、任务的调度、超时的判断，还有回归测试这一大串东西。

　　3、接着去组织评审和做出决策

　　对需求变更的评审，是不能只由那个负责改文档的人自己说了算的，项目的负责人、需求的负责人、开发、测试、质量，还有面对客户的接口人，都要坐到一起，根据影响的范围来判断，这个变更到底要不要接、如果要接，打算在什么时候去实施、要不要把它放进当前的版本里面，评审得出的结论，是需要非常明确的，是要么接受、要么拒绝、要么延期到后面版本处理，要么就把它拆分开来，分步去实现，不要仅仅是写上一句“已经讨论过了”，像这样的记录，在审核的时候，是没有多大价值的。

　　4、按照基线的规划去更新相关的文档

　　等到变更被批准了之后，我们再去修改需求的文档，以及跟它相关联的那些工作产品，在修改的时候，要尽量保持原来需求编号的稳定性，除非这条需求本身，已经被明确地废弃掉了，新增了哪些、删掉了哪些、修改了哪些，这几类操作要分得清清楚楚，并且，要同步去更新它们之间的追踪关系，如果需求已经被改掉了，可是测试用例还原封不动地留在那里，那么到了后面，就会出现“文档上看着是通过了，可实际上验证压根就没有覆盖到”这种问题。

　　二、ASPICE需求变更记录怎么留痕

　　给ASPICE的需求变更记录留下痕迹，目的并不是为了把表格给机械地填满，而是要让后面来做评审的人，能够顺着这些记录，一步一步地还原出当时做出判断的那个过程，我们留下的这些痕迹，要能够回答好几个关键的问题，这次变更是从哪来的，它到底改了什么东西，影响到了哪些对象，是谁最终同意的，还有，最后是怎么去验证的。

　　1、保留好变更申请的记录

　　每一次的变更，都应该有一条属于它自己的独立记录，里面的内容要包括变更的编号、关联的需求编号、变更的类型、变更的原因、是谁提出来的、是什么时候提的、期望在哪个版本里实现，还有它的优先级，不要把很多次的变更，都混在一起写在同一个备注栏里面，不然的话，到了后面要往回查的时候，根本就分不清楚，哪一次的修改，对应的是哪一次的评审。

　　2、保留好影响分析的记录

　　关于影响分析的记录，不能只是简单地写上“没有影响”或者是“已分析”就完了，如果分析下来，确实觉得没有影响，那也要把做出这个判断的依据给写清楚，比如说，是因为接口没有变化、现有的测试用例仍然可以覆盖得住、还是设计的参数根本就没有受到波及，而如果确实是有影响的，那就要把受影响的文档、模块、接口、测试项，还有风险项，都一一给列出来，并且标明每一项的负责人是谁。

　　3、保留好评审结论的记录

　　关于评审的记录，里面要写清楚都有谁参与了、是什么时候评审的、得出来的结论是什么、还有哪些遗留的问题没有解决，以及关闭这些问题的要求是什么，对于那些被拒绝掉，或者被延期处理的变更，也要把当时的理由给留下来，很多项目，只习惯去记录那些被通过的变更，却不记录那些没通过的，这样一来，等到后面客户再次问起来的时候，就会缺少用来解释的依据。

　　4、保留好实施和验证的证据

　　当需求的修改都完成了之后，我们要能够看到，对应的代码提交记录、文档的新版本、基线的更新、测试用例的修改，还有最终验证的结果，一种比较稳当的做法是，让那个变更的编号，能够贯穿需求管理的工具、缺陷管理的工具、代码提交的记录、评审的记录，还有测试的报告，这么做的好处是，从一条需求的变更开始，你可以一路追到它最终被验证的结果。

　　三、ASPICE需求变更评审怎样闭环

　　ASPICE对需求变更的评审，是要形成一个完整的闭环的，这个动作，不能仅仅是停在“已经把文档给改好了”这一步，闭环的意思是说，这个变更从被提出来的那一刻起，一直到它被验证通过，中间的每一步，都有证据可以拿出来看，所有相关的对象，也都同步地更新完了，而那些遗留的问题，也都有了一个明确的状态。

　　1、建立一套变更状态的流转机制

　　我们可以给变更设置这样一些状态，像是已提出、正在分析当中、等着评审、已经被批准了、正在实施当中、等着被验证、已经关闭了，还有被拒绝了，每一个状态，都应该有一个明确的进入条件，还有对应的责任人，这样做是为了避免，一个变更长期地停在“处理中”这个状态里，结果根本没人说得清楚，它到底是卡在了评审环节、开发环节，还是测试环节。

　　2、利用追踪关系去做反查

　　在最终关闭一个变更之前，我们需要去反查一下，需求到设计、需求到测试、缺陷到需求，还有变更到版本，这几条追踪关系是不是都还通着，只要这中间有一条链路是断开的，那就说明，这个闭环还没有真正地完成，尤其是当我们要去删除某些需求，或者是合并某些需求的时候，更要去确认一下，原来那些跟它关联的测试和设计对象，是不是也需要被同步地处理掉。

　　3、在变更之后去安排回归的验证

　　当需求的变更做完了以后，我们要根据前面做出来的影响分析，去决定这一次回归的范围有多大，一个很小的改动，并不代表它就不需要做验证了，只不过是验证的范围，可以被适当地裁剪一下而已，但凡是涉及到了接口、控制的逻辑、诊断的功能、边界的条件，还有跟安全有关的内容，相关的那些测试，就需要被重新再跑上一遍，并且在记录里面，要把验证的结论给说清楚。

　　总结

　　总地来说，ASPICE的需求变更到底要怎么去管理，还有它的记录又要如何去留痕，这里面最关键的一点，就是要把每一次的变更，都放进一个受控的流程里面去处理，我们先去把它的来源给记录下来，接着再做影响的分析，然后去走评审和决策的流程、去把相关的文档给更新掉、把遗漏的追踪关系给补齐，最后再完成验证，留痕这件事，并不是在让你去多填几张表格，而是要让你能够做到，对于每一次需求的变动，我们都能查到它背后的原因、它经历的过程、谁应该为此负责，还有它最终的验证结果是什么样的，这样，等到项目评审的时候，我们才不用仅仅依靠会议上的回忆，去做出各种解释。