项目需求分析是确定项目目标、范围的关键，是项目开端的重要步骤。要知道若是一开始的需求都为弄明白，不清楚自己要做什么，那么项目组后面的行动只会迷茫并举步维艰或在误差的方向越走越偏。
下面就从具体操作着手向大家讲讲从写需求计划，到与前线业务人员确定需求，到根据大家意见修改需求，具体都是如何做的。
需求计划撰写
需求类别和模板确定之后，就要分配给项目相关负责人去撰写需求。对中大型项目来说，撰写需求说明书的人应该有多个，所以需要切分工作任务。
切分的原则是：每个任务尽可能独立，任务的安排尽可能并行;每个任务必须要确定完成时间，如果时间不满足项目进度，需调配其它人力资源进行协助;有些项目比较特殊，可能现有项目成员的专业能力无法覆盖，此时需要引入外部专家或者将这部分任务外包出去。
为了把控需求收集的进度，需求撰写计划中要安排几个检查点。假如需求撰写的排期是1个月，那么就可以设置3个检查点。第一个检查点为第一周结束，第二个检查点为第三周结束，第三个检查点为第四周结束前2天。每到一个检查点，各个需求撰写人需将成果汇总到项目经理手里做审查，根据审查的意见或建议迅速调整或整改。
需求描述说明不能过于简单
有时，客户并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。
这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况。但在大多数情况下，这会给开发人员带来挫折，即：使他们在不正确的假设前提和极其有限的指导下工作，也会给客户带来烦恼，即：他们无法得到他们所设想的产品。
大致的计划说明比较容易，反而细节流程操作涉及真正执行者动手过程而多数情况大家都模棱两可。在项目执行过程中，风险是无处不在的，而在项目前期大家做需求分析时也蕴藏着不少风险因子。其中因为需求本身的描述、变更或是项目参与者的理解不当等，都可能让大家对项目需求分析产生误差。