需求管理是项目管理的基石，根据我的经验，项目失败或者延期的原因十之八九都源于需求管理没做好。
需求划分方法因项目不同而不同，以软件类项目为例，需求分为9类：
- 流程性需求、
- 数据性需求、
- 接口性需求、
- 界面性需求、
- 权限性需求、
- 表单性需求、
- 报表性需求、
- 功能性需求、
- 非功能性需求。其中非功能性需求指的是性能、吞吐量及批处理等。
需求计划
为了把控需求收集的进度，需求撰写计划中要安排几个检查点。
举个例子，假如需求撰写的排期是1个月，那么就可以设置3个检查点。
- 第一个检查点为第一周结束，
- 第二个检查点为第三周结束，
- 第三个检查点为第四周结束前2天。
每到一个检查点，各个需求撰写人需将成果汇总到项目经理手里做review，根据review的意见或建议迅速调整或整改。
需求变更
需求变更控制简单的说就是控制需求尽量不要发生变化，但不绝对。比如项目进行期间业务模式发生变化，之前提出的业务模式已经不适用了，那么就一定要允许变化，否则失去了项目的意义。
需求变更控制最简单的方法，就是提高变更的代价，比如通过制定需求变更的模板及很长的审批链条来控制变更的频率。如果需求变更没有代价，那么用户提需求的时候就容易草率，对项目管理百害而无一利。当然，这个需求变更的模板由用户自己来填。图3-4就是一个比较复杂的需求变更模板。
项目内审查
一般来说，需求文档是很重要的交付物之一，为了确保需求文档的质量，就需要建立互查机制：项目组内互查、项目组间互查。该任务发生在最后一个检查点结束之后。
- 项目组内互查：确定交付物业务流程是否正确，格式是否出现不一致；
- 项目组间互查：大型项目可能涉及多个项目组，项目组间相互依赖，此时需要项目组间互查，以确保项目组间的输入输出是否对接的上。
