什么是“需求基线”?在某个特定版本中实现的功能性和非功能性的一组需求集合。引入需求基线后，意味着要采用分阶段或迭代的开发方式。这和敏捷开发中“风险前移”、“分阶段交付”、“小步快走”、“中途回顾”等理念是相契合的。

　　需求基线，通俗点说就是把这些需求都划一根“线”，说明这些需求已经确定下来，添加新的需求和修改原有的需求都必须通过需求变更流程来操作。目的就是为了防止需求的滥变给程序架构造成重大影响。

　　需求项划分应以业务驱动划分标准，因为业务主题，业务流程和业务活动相对于具体的软件需求而言是稳定的。划定基线应采用“早基线，晚冻结”的方式，具体细节可以在迭代中逐步完善。

　　『写需求基线』这个说法不恰当，需求基线不是写出来的，而是在需求规格说明书评审通过以后所形成的，具体的步骤是开发人员先完成需求规格说明书的写作，然后组织相关人员对需求进行评审，在评审通过以后就纳入到配置库进行管理，形成需求基线。

　　动态文档：早基线，晚冻结

　　早基线：为了迟早启动开发，基线计划越早越好。

　　晚冻结：把文档看成是动态，并准备随时更改。

　　需求项优先级评定

　　优先级应先从业务角度划分优先级，要把它放到业务场景和业务流程中考虑。一般可分以下四级：关键需求项、重要需求项、有用需求项和一般需求项。

　　接下来要根据“技术可实现性”和“项目风险因素”角度考虑，对优先级进行调整。记住，在任何时候识别和处理风险都是最重要的!

　　优先级是相对的，需要在同一级中两两进行比较，最终结果是每个需求项有唯一确定的序号。这对在今后在资源受限时，是取舍任务范围的重要依据。

　　工作量估算

　　估算是一种手段，而不是目标，我们追求的是管理的可控性，而不是估算结果的准确性。

　　不同阶段的估算误差是不一样的，但随之开发的深入，估算值将越来越趋近实际值。

　　需求定义阶段应安排一次估算，其结果比较粗糙。

　　需求分析阶段应再安排一次估算，此阶段的估算结果是划定基线、安排迭代计划的基础。

　　每次迭代kai发完成后要填充实际进度数据，根据他调整估算值。

　　估算的核心思想可以归纳为“寻找计数单元，考虑复杂因子”两个步骤。

　　不同的开发阶段采用不同的计算单元，比如在定义阶段可以采用“业务事件”、“报表类型”和“接口”作为计算单元。

　　具体估算时，一是分类型进行估算，二是基于权重进行估算。

　　管理基线

　　在安排进度计划时，需要关注以下一些关键点：

　　划定基线时，优先级越高的需求项应放在较早的安排;

　　若一个需求项估算量过大，比如超过了3个“迭代人日”，就必须进一步拆分需求项;

　　当开发人员人数较多，比如超过5个时，为了便于开发管理要划分多个开发小组，这时划分任务时要考虑人员分组的因素;

　　落到实地的进度计划，为了提高准确度要考虑人员产能系数的因素，可以根据其工作年限、工资水平或者人员等级水平等作为产能系数的依据;

　　在践行进度计划时要关注需求变更(单独一个主题)和迭代未完成任务。这两个因素会对已制定基线产生影响，需要在开发过程中动态调整需求基线，这和“中途回顾”的良好习惯相契合。