对需求的确认分为外部确认与内部确认。外部确认就是与用户确认，内部确认是指与开发该需求所相关人员确认。

　　1. 内部确认：

　　当一个需求从用户那捕获来以后并不要急于承诺，应该首先与自己公司的研发、测试人员进行确认。如果研发或测试人员无法按照目标完成，那最好是放弃这个需求。我原来的公司就出现过这样的问题。需求人员答应了，但是研发却无法实现，这种现象我觉得可能现在也比较常见。当然，有时没办法只能答应，最后无法实现，可以用其他的一些“额外”功能来弥补，但是如果是关键需求，那你只能等死了。并且如果与研发、测试人员确认后，还应有个内部承诺书。

　　2. 外部确认：

　　当内部确认完成后要与用户进行确认，在国内用户往往不肯签字确认，因为怕担责任，尤其是一些国企和小型公司尤为突出。这样就要需求人员有些技巧性的工作。我带过一个烂尾项目，用户是个政府机关，用户代表相当的牛，用户需求从不给确认，想什么时候变更就什么时候变更，这个是造成烂尾的一个重要原因。我从离职的项目经理手中接下这个烂尾项目后改变了战略，专门找了个本子记录他的需求。每当他做需求变更时，我就翻开他原来的需求记录说：您原来的需求是这个，后来需求改为这个了，现在又要改成这个了，没问题我们马上改好。这样我们只改了三、四次，他就不好意思改了，其实这些变更对于功能都没有什么改进，属于无用功，但是对于这样的用户，你只能让他自己“觉悟”。

　　随便说一句：这些内外部确认，在需求变更时也都要相应进行。

　　SP 1.3 管理需求变更

　　在这个实践中将阐述如何管理需求变更。如果需求变更管理混乱的话，那么以后的开发会因为牛鞭现象呈现出更多的错误，直至研发失败。

　　1. 需求基线：

　　我不知道都有哪些公司有需求基线，有的公司不会叫这个名字，但是会起到基线的作用。需求基线首先必须通过同行评审，有的公司也会将需求基线作为研发阶段的一个重要里程碑，那这是还需要做一次管理评审。需求评审要非常严格，如果做管理评审时至少需要需求人员、产品经理、研发人员、测试人员、采购人员、财务人员、质量人员、配置人员等共同参与。如果在这时确认此产品不能开发，就要尽快舍弃，因为这时确定损失还是比较小的。

　　需求基线应对应一个或多个版本，需求的基线一般由配置管理，并且配置人员应定期发布需求基线，以使相关各方明确自己要开发什么，近期有什么变化。版本经理应时时关注基线，以达到时时更新版本计划。

　　例：有个公司刚成立，规模虽然不小但是管理还没上轨道。他们没有需求基线，当他们的几十万行代码开发2年后，他们就完全不知道现场跑的都有什么需求了。以后的补丁也不敢贸然向上打，没有办法只有和运行商协调，从现场下载运行版本回去分析。结果系统因此瘫痪，造成了几百万的损失。

　　从以上例子我们可以看出需求基线的重要性。并且只有进入基线后的需求才是正式要开发的需求。

　　2. 需求变更的执行：项目管理培训

　　只有在基线中的需求才需要进行变更，因为未在基线中的需求还在探讨阶段，不用做变更。

　　a) 对于自研产品的变更：

　　首先所有需求变更汇聚到需求人员处，需求人员申请变更。相关人员共同进行是否可开发;影响范围确定;程序规模、进度的影响，还要考虑已生产或在库、在途、现场等各阶段产品如何处理。

　　最终产品经理确定是否有可变更(变更评审人员范围和最终判定人员应由需求变更的影响范围确定)。为了固定人员，需成立CCB委员会，这个委员会可以根据需求变更范围确定几个层次人员。 CCB会在配置管理的PA中阐述。

　　b) 对于外协产品的变更：

　　对于有外协研发、生产的变更要比自研的变更复杂的多，因为它还涉及到另一个或几个公司的利益。我们需首先在自己公司内进行确认后还需发给外协厂家，只有双方都确认可以变更后，方可执行。并且，影响范围也要比自研产品更加复杂，本公司、外协厂、用户都应考虑清楚。

　　SP 1.4 维护对需求的双向溯源性

　　此实践是管理需求明确纵横两条线的关系，明确需求开发的对应关系和某需求所处的开发阶段以及需求与需求之间的关系。

　　1. 需求纵向跟踪：

　　需求的纵向跟踪是指从用户需要(包括谁提出的)、用户需求、研发需求、系统测试用例、构架、构架测试用例、概要设计、集成测试用例、详细设计、单元测试用例、代码等一系列开发阶段输出物的对应关系。一般我们的某一需求可以直接对应设计文档的章节和测试用例编号。此跟踪的用途在于：可以清晰地知道每个研发的需求来源以及完成情况和基线需求。跟踪可以使用正向和反向两种方式。

　　如果是包含不同层次、粒度的需求，比如：产品线需求和各产品需求也应在这明确关系并跟踪。

文章转自blog.mypm.net，作者高伟国。