软件研发之需求分析（二）

       需求分析是分多阶段的，理想的流程是需求交流——〉分析整理——〉需求确认——〉变更控制，实际情况下该流程会多次循环往复，这个过程当中，变更控制显得异常重要，它既是原需求的终止，又是新需求的开始，做好变更控制，往往事半功倍。

       严格意义来讲，在需求说明书经过论证之后，用户追加或补充的需求内容才能称为需求变更，因此需求变更贯穿了需求说明书经过论证之后的所有软件管理过程。

（一）   需求分析阶段的需求变更

该部分的需求变更产生于需求分析阶段的后期，也就是需求说明书论证之后。此时产生变更多少会影响软件预期的进度，但由于尚未进行设计，因此对后续的过程影响不大。

（二）   系统设计阶段的需求变更

并非所有的需求变更都会对系统架构设计产生影响，但一旦产生影响，处理起来就很麻烦，这也是为什么大家都提倡在需求阶段把需求做充分，在设计阶段把架构设计灵活。前者可以预防问题发生，后者则可以尽量降低问题发生后对设计的影响。

（三）   测试阶段的需求变更

在这个阶段需求变更发生较少，但也会出现，有可能是用户突然又增加新的内容，而更多情况是测试人员发现的BUG是由需求的误差引发的。这也是为什么现在的软件测试从需求分析阶段就开始，而不是等到阶段性编码结束再开始。把问题尽量消灭在开始阶段总比在问题出现后再补救更合理。

（四）   实施阶段的需求变更

这个阶段出现的需求变更就更少，即使出现也不是功能方面的问题，可能是和实施相关的软硬件或网络问题。若要避免，则只能在设计时就考虑多种实施方案，以防万一。凡事预则立，不预则废。

（五）   系统维护阶段的需求变更

借用80/20原则，80%的需求变更产生于这个阶段，剩余的20%则产生于其他几个阶段。系统上线后，用户在使用起来肯定和原来的想法会有很大的出入，这就是理想与现实的差距。这个阶段的变更无法预料，只好认真的管理。

       上面分析了各个阶段的需求变更，那么对于变更控制也就有了清晰的解决思路。国内讲需求变更管理，大多提到加强沟通、区分对待、合同约束等问题，这种功利化的处理方式无可厚非，但是却没有讲到重点上。对于需求变更控制，我觉得仍要沿用需求分析的处理方式，先分主次，再具体分析。这个过程中就需要标明是哪个阶段的需求变更，还要估计变更对程序带来的影响，而不是泛泛的记录变更的内容。很多软件在系统维护阶段变得异常的被动，主要还是没有把需求变更带来的影响分析准确。

       把方法再明确一下，就是需求变更需要有专门的人员记录，这个人最好是项目组内部的人员，记录内容包括需求变更具体内容、发生于哪个阶段、以及由谁提出的等内容。项目经理需要每天关注需求变更记录，每周必须对需求变更产生的影响进行预估，并将预估结果记入到需求变更记录当中，以便于确定今后的工作计划。