什么是“需求基线”？在某个特定版本中实现的功能性和非功能性的一组需求集合。引入需求基线后，意味着要采用分阶段或迭代的开发方式。这和敏捷开发中“风险前移”、“分阶段交付”、“小步快走”、“中途回顾”等理念是相契合的。
需求基线，通俗点说就是把这些需求都划一根“线”，说明这些需求已经确定下来，添加新的需求和修改原有的需求都必须通过需求变更流程来操作。目的就是为了防止需求的滥变给程序架构造成重大影响。
需求项划分应以业务驱动划分标准，因为业务主题，业务流程和业务活动相对于具体的软件需求而言是稳定的。划定基线应采用“早基线，晚冻结”的方式，具体细节可以在迭代中逐步完善。
『写需求基线』这个说法不恰当，需求基线不是写出来的，而是在需求规格说明书评审通过以后所形成的，具体的步骤是开发人员先完成需求规格说明书的写作，然后组织相关人员对需求进行评审，在评审通过以后就纳入到配置库进行管理，形成需求基线。
动态文档：早基线，晚冻结
早基线：为了迟早启动开发，基线计划越早越好。
晚冻结：把文档看成是动态，并准备随时更改。
需求项优先级评定
优先级应先从业务角度划分优先级，要把它放到业务场景和业务流程中考虑。一般可分以下四级：关键需求项、重要需求项、有用需求项和一般需求项。
接下来要根据“技术可实现性”和“项目风险因素”角度考虑，对优先级进行调整。记住，在任何时候识别和处理风险都是最重要的！
优先级是相对的，需要在同一级中两两进行比较，最终结果是每个需求项有唯一确定的序号。这对在今后在资源受限时，是取舍任务范围的重要依据。
工作量估算
估算是一种手段，而不是目标，我们追求的是管理的可控性，而不是估算结果的准确性。
不同阶段的估算误差是不一样的，但随之开发的深入，估算值将越来越趋近实际值。
需求定义阶段应安排一次估算，其结果比较粗糙。
需求分析阶段应再安排一次估算，此阶段的估算结果是划定基线、安排迭代计划的基础。
每次迭代开发完成后要填充实际进度数据，根据他调整估算值。
估算的核心思想可以归纳为“寻找计数单元，考虑复杂因子”两个步骤。
不同的开发阶段采用不同的计算单元，比如在定义阶段可以采用“业务事件”、“报表类型”和“接口”作为计算单元。
具体估算时，一是分类型进行估算，二是基于权重进行估算。
管理基线
在安排进度计划时，需要关注以下一些关键点：
划定基线时，优先级越高的需求项应放在较早的安排；
若一个需求项估算量过大，比如超过了3个“迭代人日”，就必须进一步拆分需求项；
当开发人员人数较多，比如超过5个时，为了便于开发管理要划分多个开发小组，这时划分任务时要考虑人员分组的因素；
落到实地的进度计划，为了提高准确度要考虑人员产能系数的因素，可以根据其工作年限、工资水平或者人员等级水平等作为产能系数的依据；
在践行进度计划时要关注需求变更（单独一个主题）和迭代未完成任务。这两个因素会对已制定基线产生影响，需要在开发过程中动态调整需求基线，这和“中途回顾”的良好习惯相契合。
