写在前面

ASPICE理解起来容易，毕竟是有条有理的。但实操起来，尤其是把ASPICE各过程域做全的时候，会遇到各种各样的问题（不是技术问题有多难，而是该如何做选择，如何既能符合ASPICE要求，保证过程质量，又能不过多降低交付速度，组织整体效能不被过多削弱）。

这才有此系列文章，将实操中遇到的争论较多的问题和我们的落地方案抛出来，一起交流进步。

议题：如何解决上、下游一致性难以保证的问题

由于文档编写需要时间，开发人员又有经验积累，实际项目开展中，为了快速推进开发，各工程域往往是并行开展的，硬件和软件在没有收到完整的系统需求后可能就开干了。之后就是边开发边补文档，这个过程中就会造成上、下游难以对齐，问题来源多种多样，如：

1. 按计划冻结了需求，打了基线，但开发人员在实施过程中，发现需求存在不合理处（这是难以避免的，只能说多少的问题），在开发过程中按照合理的方案（讨论过的）实施，但这时候需求冻结了，不允许改。

2. 如果在1的场景中，需求冻结后仍保留修改权限，则会导致文档处于动态调整中，下游尤其是测试，需要花费大量时间来辨识哪些用例需要调整。加之项目交付时间紧张，就会导致用例未修改（与需求不一致）而测试结果又标识为正确（测试结果与当前需求一致）的情况。

解决方案：

正式基线后文档冻结，并存档，不允许更改。同时建立下个阶段的文档，开辟新空间，在此空间的文档上进行修改。

如果开发端发现了需求问题，需求的变更在此空间的文档上进行修改，但实际开发可以按照评审后制定的合理方案实施。

如果测试端发现了问题，则测试结果记为Fail项，并标记是软件问题还是需求问题。