我觉的从根本上说，最终客户对软件系统的需求是始终如一的，真正变化的是开发团队对客户需求的理解和认证程度。成熟而有经验的软件团队能够在项目开始阶段准确掌握客户的需求，并且将需求层层细化，形成有效的文档，作为系统设计和测试的依据。

项目初期一定要制定清晰的目标和项目范围，并且让项目主要干系人(最重要的当然是最终客户了)确认。
　　不管通过什么途径得到的项目，作为项目主管，在项目前期，可以分三步走。
　　第一个想到的问题应该是“为什么”，也就是客户做项目有什么目的，知道这些以后，才能在以后的工作中更加想客户之所想，不至于项目方向错误，最终争取达到双赢得局面。
　　知道了“为什么”以后，接下来就要非常清晰的知道“做什么”，有一个比较好的办法就是用一两句非常简洁的话概括出来整个项目，并且能够用这种方法概括出项目中的各个子任务，并且能够让前台业务人员和后台研发人员都能够心领神会，那么说明项目主管对项目的内容在大方向上已经有很好的把握了。
　　最后就要弄明白“怎么做”了，对于比较陌生的项目来讲，这一阶段工作量比较大也很重要，在这个阶段多花点精力绝对值得，当然，根据具体的情况，也可以在这个需求调研阶

段简化一些不必要的工作，这需要项目主管具备平衡那些彼此冲突的项目目标的能力。在实际的工作中，这需要一个过程，值得注意的是，在需求整理完毕形成文档以后，最好先让项目组人员把自己总结的需求跟客户比较详细的讲一遍，在实际的操作中，这种做法不仅能够把项目人员与客户在业务层面的歧义问题数量大大降低，还可以很好的发先潜在的问题，并且掌握一些沟通技巧，也会让客户更能深刻的感觉到承包商对他们的重视。另外，如果项目前期得需求人员对技术非常不了解，根据实际情况最好在需求每次提交给客户前与研发人员沟通，以避免不必要的给客户的承诺，更加准确的界定工作量。总之，有效的计算出项目范围将会占用一定的时间，但是同样会节省资源、资金以及解决项目今后令人头疼的问题，例如：需求(范围)变更。
项目的需求经过几次确认以后，要让有权力的客户明确确认，最好有书面签字，这个有说服力的文件会在以后客户发生需求变更的时候起到很好的作用，很显然，因为客户已经签字确认，总是反悔肯定理亏呀，即便因为业务变化不得不对项目进行大的调整以至于项目延期，这种情况下也会是项目组处于有利地位，不至于让自己的公司非常不满，甚至可以以此为依据来要求客户重新考虑项目经费。当然，对于客户来讲，通过这些很好理解的需求的阐述，也会以此作为以后交付产品的依据，做到心里有数，消除不必要的疑虑，这个对双方有同等的约束力，很有好处。